Axon doesn't throw any error when adding an AR to an event sourced repository when the repo is not configured

Imported from Google Groups
1

Hi,

First of all, congrats to the Axon team for finally bringing CQRS to
the Java world !

I was playing a little bit with Axon, everything when good up to the
point where I started dealing with more than one Aggregate Root while
doing event sourcing.

The symptoms were the following :

1. I instantiate a Foo object (Foo is an AR type). I add it to a
repository, and then load it back later --> ok, it works
2. I instantiate a Bar object (Bar is another AR type). I add it to a
repository, and then load it back later --> fails, I get a "Cannot
cast class Foo to Bar" !

When looking to Hibernate logs, I saw that the DomainEventEntry
corresponding to the creation of Bar actually had the aggregateType
"Foo" when being inserted in the db.

Ok, so one big headache later, I came to realize that I hadn't
declared the event sourcing repository for Bar in my Spring app
context.
So, instead of telling right to my face that I'm stupid, it looks like
Axon just tried to use another repository to store the event... which
worked. But, deserializing is another story :slight_smile:

So, is that a normal behaviour ? (which I doubt ; or I might again be
missing something)
Is that a bug ?

Thanks,

Eric

2

Hi Eric,

first of all, thank you for trying Axon! :wink:

interesting situation. I fully agree with you that Axon should throw an exception when attempting to store an aggregate of another type into a repository. The only problem is, I have no way to know. That’s because generics information is “erased” at runtime. Only the GenericEventSourcingRepository implementation is currently aware of the aggregate type. I could add this feature in that implementation for now.

One of the (minor) api changes I have planned is to ask for a Class in the constructor of the AbstractRepository. Then, I can assert that any incoming aggregate is assignable to that class. Other features are also dependent on this information (e.g. using the UnitOfWork as 1-level-cache).

I’ll create an issue for it in the issue tracker. Thanks for pointing it out!

3

Hi Allard,

Sorry for the late reply, just got back from holidays.
Thanks for your answer ! Ok I see how the generic type info erasure
thing doesn't make things any easier for Axon to prevent this from
happening...

Anyway, I'm diving back into my Axon experiments :slight_smile: