Events and Event handlers with generics

[coderinabstract]

Have a scenario with an event with generic data;

AggregateEvent<T>  aggregateEvent;

EventHandler listener for lister1 listens for

AggregateEvent<ConcreteDataType1> event

and another event handler listener2 listens for

AggregateEvent<ConcreteDataType2> event

Event fired is only with a Aggregate which has <T> in abstract class and the inherited class gets its own repository and data type e.g.

Have AbstractAggregate<T>

ConcreteAggregateForType1 extends AbstractAggregate< ConcreteDataType1> and ConCreteAggregateForType2 extends AbstractAggregate<ConcreteDateType2) and they apply the above events.

Axon is firing both Event handlers for AggregateEvent<ConcreteDataType1> and throwing class cast exceptions... when is should be firing for the event with its corresponding data Type ConcreteDataType1 and neglecting the other handler. This is major issue for reuse in design, otherwise lot of cut and paste code for type specific transformations in the listeners with payload/pass through type data differing for aggregates inherited leveraging generics and common aggregate logic for types/flavors of similar aggregates.

Any thoughts... Cheers and Thanks

[Sebastian Ganslandt]

Due to the java language design and type erasure the only type information available at runtime is the generic type AggregateEvent, not the specific type ConcreteDataTypeX. Axon (as well as any other java based technology) has no way of choosing the correct event handler in your case. (Same reason why you can't build an EventHandler<T> interface and have an Implementation implementing EventHandler<E1>, EventHandler<E2> ... but but solve this via annotated methods and reflection) 

Could you not solve it the same way as you did with the ARs, with a non generified type ConcreteDataType1AggregateEvent extents AggregateEvent<ContcreteDataType1>, and keep AggregateEvent<T> abstract? ConcreteDataType1AggregateEvent would not contain any additional information but the concretisation of AggregateEvent<ContcreteDataType1> ie not much duplication and minimal amounts of boiler plating...

Would that help? 

'Sebastian

[coderinabstract]

I thought so too about generics and type erasure... but with some high level glancing http://www.artima.com/weblogs/viewpost.jsp?thread=208860

that using parameterized type java.lang.reflect.Type reflecting generics would be possible as of Java 5, however have never deep dived to learning it...

the challenge is that the abstract base class applies the generic event... and concrete class does not know of that event... so maybe

in abstractbase class after common logic call abstract applyEvent method which is then actually supplied by the concrete class with the apply(...) call in the concrete template method... and uses a concrete event extending the generic Event.. though one problem  is that abstact base class does handle the generic event and that works fine and it needs to do that for all specializations of abstract. Maybe need to do both. Apply generic event for base class handler and apply specializedEvent by concrete... 

Another way by which I have made it work in current design, even though is ugly is by doing instance of check in the datatype specifc listener for the appropriate datatype and that is working.

need to think through this...

Thanks for the insight and Cheers....

[Sebastian Ganslandt]

Aha, interesting! 

Although this solution would still require you to subclass the generified event, that could be accomplished at runtime with apply(new AggregateEvent()<ConcreteType>(){}); and by adding those {} you should be able to get a hold ConcreteType at run time as well. Very interesting indeed.

On Thursday, June 28, 2012 7:56:30 AM UTC+2, coderinabstract wrote:

[bui...@gmail.com]

It's an interesting one. I am aware of the Reflection API being able to provide information about generic parameters, but it is very brittle, in my opinion. Personally, I tend to prevent generic type to be a differentiator in my code. I just use them to make API's clearer. 

I am not discarding this improvement, though. Might be interesting to have a look at in the future.

Cheers,

Allard