axon-spring-boot-starter | Spring Boot Starter for Axon Framework | Microservice library

This is resolved. I had to exclude the axon-server-connector dependency from the below axon-spring starter

I wrote a blog about set-based consistency validation and added some code samples on Github for it. One of the examples is using a ParameterResolverFactory. See https://github.com/AxonIQ/code-samples/tree/master/set-based-validation at point 3

Yes, I believe you have to configure the EventScheduler Bean yourself if you are not using AxonServer. Try adding this to your @Configuration, for example:

Interesting scenario you're having here @thowimmer. My first hunch would be to say "use the SubscribingEventProcessor instead". However, you pointed out that that's not an option in your setup. I'd argue it's very valuable for others who're in the same scenario to know why that's not an option. So, maybe you can elaborate on that (to be honest, I am curious about that too).

Now for your problem case to ensure events are only handled within the same JVM. Adding the origin to the events is definitely a step you can take, as this allows for a logical way to filter. "Does this event originate from my.origin()?" If not, you'd just ignore the event and be done with it, simple as that. There is another way to achieve this though, to which I'll come to in a bit.

The place to filter is however what you're looking for mostly I think. But first, I'd like to specify why you need to filter in the first place. As you've noticed, the TrackingEventProcessor (TEP) streams events from a so called StreamableMessageSource. The EventStore is an implementation of such a StreamableMessageSource. As you are storing all events in the same store, well, it'll just stream everything to your TEPs. As your events are part of a single Event Stream, you are required to filter them at some stage. Using a MessageHandlerInterceptor would work, you could even go and write a HandlerEnhacnerDefinition allowing you to add additional behaviour to your Event Handling functions. However you put it though, with the current setup, filtering needs to be done somewhere. The MessageHandlerInterceptor is arguably the simplest place to do this at.

However, there is a different way of dealing with this. Why not segregate your Event Store, into two distinct instances for both applications? Apparently they do not have the need to read from one another, so why share the same Event Store at all? Without knowing further background of your domain, I'd guess you are essentially dealing with applications residing in distinct bounded contexts. Very shortly put, there is zero interest to share everything with both applications/contexts, you just share specifics portions of your domain language very consciously with one another.

Note that support for multiple contexts, using a single communication hub in the middle, is exactly what Axon Server can achieve for you. I am not here to say you cant configure this yourself though, I have done this in the past. But leaving that work to somebody or something else, freeing you from the need to configure infrastructure, that would be a massive timesaver.

Hope this helps you set the context a little of my thoughts on the matter @thowimmer.

Changes between RC2 and RC2 of the Kafka Extension provided by Axon are not compatible. This choice was made to have the freedom to adjust the API according to further findings. Hence why it's a release candidate and not a final release. This is stated on the GitHub page of the project and on the reference guide page on the Kafka Extension.

Configuration properties used in RC2 are thus not compatible with RC3. Check the reference guide (which has been expanded together with RC3) for more specifics on how to adjust your config.