Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
AnnotationEventHandlerAdapter returns prematurely #1058
Looking at the code in AnnotationEventHandlerAdapter:81 the loop is stopped immidiately after the call to the first event handler.
While it is certainly reasonable to
The issue can easily be fixed by removing the return statement from line 81.
Apparently, there are more variations of filtering of EventHandlers:
This still looks like some bug or at least an unnecessary restriction imposed by implemenation details, but maybe there is a specific reason for this?
Use case: we'd like to enrich semantics on our events by adding interfaces to them. That means two events can share the same abstraction/s.
this is actually by design. The semantics of the handler invocation is that the most specific handler matching the incoming message is invoked on an instance. Since the handlers are sorted by how specific they are, it can stop after the first invocation.
@abuijze, thanks for your explanation.
Still I really can't get my head around how this behavior is helpful in the case of event-handlers:
I think the current behavior even makes some situations more or less unpredictable, e.g. in this example it's not obvious which method will be called and why:
When working with interfaces to describe shared aspects of events, it gives us a hard time dealing with these efficiently because we have to be really careful that the framework won't silently ignore registered
Unfortunately the described behavior is currently hard-coded for the most part (Sagas and Aggregates) and can only be overwritten for ordinary EventHandlers (by using a custom MessageHandler), rendering event handling inconsistent.
Do you think this has a chance to be generalized and made configurable for all event handlers?