Allow configuration of a processing group's type through the annotation.

[vab2048]

Enhancement Description

Allow the @ProcessingGroup annotation to also specify the type of the processing group as well as the name.
Type being either tracking/subscribing.

Current Behaviour

Processing groups default to tracking event processors unless a config parameter is placed in properties file.

Wanted Behaviour

I would like to make it explicit in the code that I want a subscribing event processor rather than having to look in the config.

Possible Workarounds

This is an enhancement - you could get the desired behaviour by using the config as is done now.

---

I'm not sure if this would be a desirable feature from your stand point. @smcvb - what do you think?

[smcvb]

Although I get where this is coming from, I don't think we should expand the @ProcessingGroup annotation for this.

The Processing Group should not dictate the configuration of the Event Processor since the control is the other way around.
So, the Event Processor manages Processing Groups by passing it the events it retrieves and invoking the reset tasks when triggered.

The referred to "type" is the type of the Event Processor. Not the type of the Processing Group.
Hence, I wouldn't find the placing of a type attribute on the @ProcessingGroup annotation correct.

Secondly, I think the most straightforward way to support your suggestion would be for the @ProcessingGroup annotation to be a Spring stereotype.
Basically, like Axon's @Aggregate and @Saga annotation.
As the @ProcessingGroup annotation isn't part of Axon's Spring modules, that would insert Spring logic throughout the core of Axon Framework.
This is similarly undesirable.

Granted, I believe there'd be a way to have the plain Java configuration (that reads the @ProcessingGroup annotation at this point in time, too) define the Event Processor's type based on the annotation.
But then we would fall back on my earlier argument that the Event Processor is in charge of Processing Groups and not vice versa.
Scenarios like "there are two Event Handling Components with a @ProcessingGroup annotation with the same name, but different types" aren't the kind of things that are beneficial for the complexity of the configuration, I think.

So, that's my two cents, @vab2048.
However, perhaps I am missing something obvious.
So I am looking forward to your reply on the above :-)

[vab2048]

ah... that makes things complicated!

my use case was for a pet project where I receive price data for a market. I want a number of views in the command model to be in-memory and making it explicit on the class for the event handlers itself would have been better (in my opinion) than in a properties file or specific java config file.

I'll leave it to you if you think this idea (some mechanism to explicitly label the class/set of classes which make up the event processor as subscribing) is worth keeping the ticket open for.

[smcvb]

I think the idea makes sense, @vab2048, but perhaps we need to look for another annotation or a different configuration approach.
I'll leave it open for now. I am confident the team will pass this again somewhere in the future, once AF5 development is further underway ;-)

[vab2048]

Sounds good @smcvb.

I played around a bit and found a "hacky" workaround which worked for my example app. I put this directly on the component and it worked:

.

Then when I query the app for the running event processors I get it as subscribing:

This is probably a hack but I thought I would add it as a result of experimenting.