Using MongoDB as EventSourcingRepository in Axon 3

Does anyone has sample code to use MongoDB as EventSourcingRepository with Axon 3? I am trying to modify the AxonBank example to use MongoDB instead of in-memory storage. I have successfully configured the eventStore and SagaStore - I found that events can be persisted into MongoDB. However, it doesn’t seem that I can use the eventStore as EventSourcingRepository. Below is the modified code for AxonConfig:

Hi,

I got it running with a similar setup. the only thing I think you should change is to instantiate the

    @Bean
    public MongoEventStorageEngine eventStorageEngine() {
        return new MongoEventStorageEngine(eventStoreMongoTemplate);
    }

with the DefaultMongoTemplate instead of the current one:

Hi Ricky,

pls check my sample: https://github.com/EdisonXu/sbs-axon/tree/master/lesson-4
I’ve implemented 7 samples step by step introducing how to use Axon3

在 2017年4月2日星期日 UTC+8下午2:14:57,Wong Ricky写道:

Hi guys,

I am running into a similar issue. Couldn’t spot significant difference in my configuration file.
But I bump into this annoying Mongo Exception:

Exception in thread “main” org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘eventStorageEngine’: Invocation of init method failed; nested exception is com.mongodb.MongoCommandException: Command failed with error 86: ‘Trying to create an index with same name uniqueAggregateIndex with different key spec { aggregateIdentifier: 1, sequenceNumber: 1 } vs existing spec { aggregateIdentifier: 1, type: 1, sequenceNumber: 1 }’ on server 127.0.0.1:27017. The full response is { “ok” : 0.0, “errmsg” : “Trying to create an index with same name uniqueAggregateIndex with different key spec { aggregateIdentifier: 1, sequenceNumber: 1 } vs existing spec { aggregateIdentifier: 1, type: 1, sequenceNumber: 1 }”, “code” : 86 }

… anyone bumped into a similar issue?

Thank you very much.

Alberto

Hi Alberto,

I only see this error after migrating an Axon 2 database with Axon3. Dropping the indices once should resolve it.
The exception is thrown in a mongo ensureindex method. For some reason it doesn’t see it as identical, while the messages shows identical column names…

If you get the exception on every startup, we’ll need to look further into it.

Frank

OH YEAH!

I was running on default to be quick, but it was already dirty… :wink:

Thank you very much.

Alberto