AxonFramework | Evolutionary Message-Driven Microservices | Application Framework library

Recently some CVEs were found in XStream, requiring it to change its approach to serializing. Previously, it simply de-/serialized everything by reflection, assuming it had the freedom to read everything, now you need to tell XStream which classes it can check through reflection.

This post from AxonIQ's forum explains this predicament in more detail.

Now, what can you do to solve it? Well, using the JacksonSerializer would be a simple step. Weirdly enough, I would expect that your configuration would've picked up that you have set the JacksonSerializer for all serializers.

My hunch is that the combination of the Mongo and Kafka Extension from Axon Framework doesn't correctly set the JacksonSerializer on your MongoTokenStore. Note that this is a hunch as we're missing the entire stack trace. However, it's the TokenStore dealing with TrackingTokens. And, it are the KafkaTrackingTokens that fail to serialize properly.

Note that the Mongo Extension from Axon Framework does not have a Spring Boot Auto Configuration. Thus, the settings you're using in your application.properties file aren't automatically picked up by any of the Mongo-extension-specific classes you built. Unless you're wiring them yourself, that is.

Relevant extract:

The bean archive is synthesized from:

• the application classes,

• dependencies that contain a beans.xml descriptor (content is ignored),

• dependencies that contain a Jandex index - META-INF/jandex.idx,

• dependencies referenced by quarkus.index-dependency in application.properties,

• and Quarkus integration code.

1. You just "build" the configuration, but don't start it. After buildConfiguration(), make sure to call 'start()' on the returned Configuration instance. Alternatively, directly call start() on the Configurer. It returns a started configuration instance.

   That should resolve the registrations not coming through. But it will probably trigger an exception related to the next issue....

2. Your MongoTokenStore configuration is incomplete. The TokenStore needs at least a serializer and a MongoTemplate instance. The latter tells the Axon which collections you want to certain types of information in. In your case, only the TrackingTokenCollection would be relant.

To add to that, let me give you a pseudo-sample of what a Saga should look like.

This is the only missing point for the exception handlers at this stage. Honestly, the reference guide should be a bit more specific about this. I am sure this will change in the future, though.

There's a different approach for having a command handler that constructs the aggregate and that can use the @ExceptionHandler: with the @CreationPolicy annotation. The reference guide has this to say about it, by the way.

Thus, instead of having a constructor command handler, you would set up a regular command handler using the AggregateCreationPolicy.ALWAYS. That would adjust your sample like so:

Let me list what they are for:

• SAGA_ENTRY - Stores the serialized sagas. Read more on Sagas here.
• ASSOCIATION_VALUE_ENTRY - Stores the associations from event identifiers to saga identifiers. Hence, it is the lookup table for Axon to associate your events with your sagas.
• TOKEN_ENTRY - Stores the serialized TrackingToken instances your StreamingEventProcessors use for handling events. In short, these tokens keep track of the progress through the event stream. Read more on Streaming Processors and Tracking Tokens here.

Is it normal for a table like this to be created in the h2-DB?

When using Axon's Spring Auto Configuration, then yes, it is. Axon expects you need all of them, so it is created upfront.

I'm a beginner at Axon, and I don't know where to start.

enter link description hereYou should know that there is an Axon training you can follow (as found here). Either attend one of the live sessions you can find here or go for the AxonIQ Academy.