registerTrackingEventProcessor
Hi Bjorn,
The migration guide is a pending implementation, which is currently biting you…we’re sorry for that Bjorn!
It’s on the to-do list for the Reference Guide. We’re however first updating the overall look and feel of the guide to be up to par with how we view the framework could (and should) be used.
A part from that, you’re encountering a couple of things:
- Mongo Tokens:
I would not assume you’d have any trouble with de-/serializing MongoTrackingTokens.
It is a correct assumption that you initially did not have any tracking tokens, right?
If that’s the case, I do not fully comprehend why the serializer wouldn’t be able to cope with them.
Nonetheless, I can tell you that you shouldn’t have to bother with custom ContentTypeConverters to get it to work.
What you could try is to use the XStreamSerializer for your tokens however.
Configuring the serializer can be done on several levels, namely default, message and event.
Typically, just setting the eventSerializer to something like the JacksonSerializer is desired, whilst the rest could just as well stay in the default XML format.
- Tracking Event Processor token initialization:
You can configure where your TrackingEventProcessor initialize their token.
This is done by instantiating a TrackingEventProcessorConfiguration, either with the forSingleThreadedProcessing() or forParallelProcessing(int) static functions on that class, and calling the andInitialTrackingToken() function.
The andInitialTrackingToken() expects a Function<StreamableMessageSource, TrackingToken> as input. The StreamableMessageSource in turn has function to create a tail, head or token-at TrackingToken.
If you use the StreamableMessageSource#createHeadToken() function here, you’ll ensure the tracking event processor will start with an initial token at the head of the event stream.
This thus ensure your query models will not be created a new, or that any undesired emails are sent for a second time.
The TrackingEventProcessorConfiguration instance should be provided when registering your Tracking Event Processors with the EventProcessingConfigurer#registerTrackingEventProcessor() function.
The last parameter of that function allows you to provide the TrackingEventProcessorConfiguration instance.
This thus requires some work to configure correctly, but it should be doable.
And, your concern is heard, we will add this to the migration guide.
-
Old event side note:
Could you specify which version you mean with ‘older version of axon 3’?
I’ve been in the loop with one Axon project for over 2 years now, following every Axon Framework upgrade since 3.0 release candidates.
Can’t recall we’ve hit such an issue yet though, so I am curious what this is exactly.
Hope this helps you out Bjorn.
And please do not hesitate to pose further questions in regards to your migration!
Cheers,
Steven