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

[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.

[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 ;-)