Support SpEL on an `@ProcessingGroup` annotation equivalent

[jangalinski]

I have a shared lib that provides a bean that implements a method annotated with "EventHandler" and builds a projection (which is stored via jpa).
Multiple clients use this lib to build their own projection of frequently changing data so they do not have to perform a REST or QueryHandler remote call to access the data. For developer convinience and information hiding, the "how events are handled and stored in a projection database" is hidden in the shared lib.

Now I have two apps running using the lib and get a "duplicated sequment claim" warning in axon server.
I guess this is because no matter if I leave the eventProcessor name to the default (=package of the EventHandlerBean in the shared lib) or if I set a custom name via @processinggroup, the name of all eventprocessors will be the same, although they are running in different applications.

From my knowlegde (correct me if I am wrong) this will result in the two applications sharing the same processor name and thus each event might go to either of the apps, but not both. This is a problem for us, since we do rely on correct handling of changes in both (or multple) apps.

We had a similar problem with a shared KafkaListener in the past and solved it by using SPEL in the listener name defined in the annotation. This allows us to use applicationNames, counters, ... to identify listeners.

This does not seem to be possible with axon/axon-spring-autoconfiguration at the moment.

Possible workaround:

• make the shared EventHandler abstrat and force extending it in the app that wants to use it ... so I have control how it will register.

Solution idea:

• Open the EventProcessingModule to allow an optional converter in the TypeProcessingGroupSelector so before using the typeFallback, the value of processingGroup can be converted by a spel processor

[jangalinski]

From what I get from Marcs answer on google groups: https://groups.google.com/forum/#!topic/axonframework/sAtjjJezal8
I think I had a false alarm caused by my dev setup with axonServer CE and h2-inmem dbs ... I could not reproduce it today, so having spel in the annotations does not seem to be necessary (I was confused because we just had a similar problem with KafkaListeners) ... I leave it up to you to close this if you like ... though having the choice of using spel would still be great, and easily achievable (at least that what I got from inspecting the code) if we just would open the EventProcessingModule for modifications by making private finalfields protected or introducing setters to change the TypeResolvers ...

[smcvb]

Interesting idea @jangalinski, worth discussing I'd say. From a prioritization stand point to be honest I don't think this will end on the backlog very high for the time being. We have some other (we feel) more pressing features with further stretching use cases.

Of course I am happy to hear it was a false alarm for your scenario!

[smcvb]

It's been quite some time, but here's an update on this issue.
I've adjusted the title slightly, as I believe the @ProcessingGroup wouldn't be the right annotation to add SpEL logic to.
Mainly because the @ProcessingGroup annotation, right now, isn't a Spring-specific annotation within Axon Framework.

However, having another Axon/Spring-specific annotation that uses SpEL for defining the name definitely has its place.
Note that the priority is still at a "would," as, although this is great, there are other tasks that are a bit more pressing.

On top of that, I feel the "under discussion" label can be removed, to clarify there's a desire to check this out a little further.
At least eventually.

[smcvb]

Added this issue to release 5.0.0 as we intend to validate the feasibility of this in the new APIs.
Given the fact there is a desire to move all Spring (Boot) related support to a dedicated extension repository, there is a chance this issue will be moved when that repository exists.