I created a simple application, that makes use of tracking eventhandling, this works fine. But when I add an aspect on the eventhandler, the event handler becomes subribing instead of tracking.
The application uses spring boot 1.4.2 and axon 3.0-RC1. In the application.properties the property “axon.eventhandling.processors.test.mode=TRACKING” is added and on the eventhandler the annotation @ProcessingGroup(“test”) is added.
The sources can be found here: https://github.com/erwinvb/AxonTrackingEventHandler
this might actually be a limitation by the current implementation. Axon checks for an annotation on the class of the instance of an Event Handler. The proxy is most likely not annotated (but its parent class is). I guess that Axon should also inspect parent classes for any annotations…
Checking parent classes for annotations would be helpful in another context, too, which we have in our app: when an abstract superclass or an interface defines event handler methods that should be implemented by concrete subclasses. Right now we put a comment in the Javadoc of the superclass/interface to remind ourselves to annotate the implementation methods with @SagaEventHandler or @EventHandler but it’s possible to forget to do so. It would be preferable to be able to put those annotations on the parent.
for event handlers, this is actually already the case. Axon inspects the entire hierarchy of classes for event handler methods. From those methods, it will invoke the most specific handlers on the subclasses, moving up the hierarchy until it finds a candidate.
From your comment, it sounds like you see different behavior. Can you provide an example?
I was misremembering the problem I ran into, which is real but is more complicated than I described. Say you have
public abstract class MySagaSuperclass extends AbstractAnnotatedSaga { @StartSaga @SagaEventHandler(associationProperty = “someProperty”)
public abstract void on(T event);
}
public class MySaga1 extends MySagaSuperclass { @Override
public void on(MyEvent1 event) {
System.out.println(event.toString());
}
}
public class MySaga2 extends MySagaSuperclass { @Override
public void on(MyEvent2 event) {
System.out.println(event.toString());
}
}
Then when you publish a MyEvent2, Axon tries to deliver it to both sagas, resulting in a ClassCastException in the MySaga1 case since the parameter type doesn’t match.
Simply moving the annotations down to the subclasses isn’t sufficient; you have to remove the abstract method from the superclass. This is not a huge deal but makes it marginally easier to forget to include an event handler when writing a new saga subclass.
that classcast exception was a bug in Axon 2.x, which, if I recall correctly, has already been fixed. In Axon 3, a single SagaManager instance only manages a single Saga type, so this won’t be an issue either.
Thanks for your quick response. After watching your third live coding session, I found a workaround. It is also possible to register a tracking processor by package name. In this case the @ProcessingGroup is not necessary.
Thank you,
Just tried removing the workaround from my code under Axon 3.0.1 and this problem still exists. Removing the abstract method from the superclass continues to solve it, so it’s not an urgent issue.
the issue you were referring to is a ‘slightly’ different one than the one by the OP. In his case, it had to do with instances being assigned to the wrong processor.
However, I checked why your case wasn’t solved yet, and everything seemed fine in code.
An then I noticed your abstract method had a generic parameter (and a parameter of that generic type). Axon doesn’t support generic parameters in Command Handlers (nor event handlers). So it seems to be a slightly different issue, which indeed hasn’t been resolved.