Using axon to route events within standalone event handling application

[Sebastian Ganslandt]

I am setting up a stand alone application which is supposed to
subscribe to events from an axon application. The application is not
an "axon based application" since only subscribe to events and doesn't
do commands, but it would still be very convenient to use the axon
annotation @EventHandler and let a ClusteringEventBus handle the
routing of events within the application.

The problem seems to be that when I throw in the <axon:annotation-
config/> in my spring config, it complains that there is no command
bus configured which is perfectly true since I won't be doing any
commands. Couldn't axon just wire up my event handlers to the event
bus without require a command bus? Is the something conceptually wrong
with the idea or is it something that you have thought on supporting?

As I see it this would be a very neat way of physically separating the
command side from the query side as well...

Best Regards
Sebastian

[Allard Buijze]

Hi Sebastian,

you're right. It should work. It should only complain if there are actually command handlers found in the spring context.

The solution in your case, you could just configure a bean of type (if I recall correctly, don't have the source code at hand) AnnotationEventHandlerBeanPostProcessor.

Meanwhile, I'll work on getting the namespace support working for this case. In the end, there is nothing wrong with working this way. Axon isn't the solution for every application...

Cheers,

Allard

[Sebastian Ganslandt]

Allard,

Thanks for your input, and for the hints towards manually setting up
an AnnotationEventListenerBeanPostProcessor, probably directly towards
a SpringIntegrationEventBus since we are already using spring
integration towards rabbit.

However, manually setting an AnnotationEventListenerBeanPostProcessor
for every event handling class seems almost as cumbersome as manually
creating the necessary spring integration config to route the events
to the necessary listeners although you do get the filter for free...

For now I think we will go for just using spring integration between a
rabbit queue containing all events, unwrapped from
GenericEventMessage, and the @ServiceActivator annotation which seems
to give just about the same functionality with the amount of config I
desired (a rabbit q, a spring integration channel and annotated event
handling methods) without forcing us to depend an axon in the
applications that don't really make use of the whole cqrs
infrastructure.

Moving a query side updating listener out of the axon command handling
app will not be as seamless but doing a one time job of replacing
@EventListener to @ServiceActivator is probably something you can live
with.

Thanks again for the feedback and a great framework!

Cheers

On Apr 30, 6:48 pm, Allard Buijze <bui...@gmail.com> wrote:
> Hi Sebastian,
>
> you're right. It should work. It should only complain if there are actually command handlers found in the spring context.
>
> The solution in your case, you could just configure a bean of type (if I recall correctly, don't have the source code at hand) AnnotationEventHandlerBeanPostProcessor.
>
> Meanwhile, I'll work on getting the namespace support working for this case. In the end, there is nothing wrong with working this way. Axon isn't the solution for every application...
>
> Cheers,
>
> Allard
>

[Allard Buijze]

Sebastian,

the AnnotationEventListenerBeanPostProcessor is just a bean that you need to put in your context once. It will automatically detect annotated beans and wrap them for you. The <annotation-config/> does exactly the same, except that is also adds the same bean for command handlers.

So it has nothing to do with any kind of event bus you choose.

Cheers,

Allard

On 1 mei 2012, at 00:20, Sebastian Ganslandt <seba...@ganslandt.nu> wrote:

> AnnotationEventListenerBeanPostProcessor

[Sebastian Ganslandt]

The axon way turned out somewhat easier so we went with that. So far
it works like a charm, thanks again for guiding along the way!

'Sebastian

On May 1, 7:26 am, Allard Buijze <bui...@gmail.com> wrote:
> Sebastian,
>
> the AnnotationEventListenerBeanPostProcessor is just a bean that you need to put in your context once. It will automatically detect annotated beans and wrap them for you. The <annotation-config/> does exactly the same, except that is also adds the same bean for command handlers.

Ah, nice!

>
> So it has nothing to do with any kind of event bus you choose.

Of course...

>
> Cheers,
>
> Allard
>
> On 1 mei 2012, at 00:20, Sebastian Ganslandt <sebast...@ganslandt.nu> wrote:
>
>
>
>
>
>
>
> > AnnotationEventListenerBeanPostProcessor