I have an app that uses its own context and jackson serialization (Aggregate, Command, EventStore, Projection). This app connects to axon server via auto configuration specifying servers, context and serializers. So far so good.
Now this app has to inform another app about data changes (command messaging only), using a different context. This communication has to be serialized with xstream.
I understand that for context-routing I could configure a TargetContextResolver, but it seems that I can only configure one type of message serialization (the very moment I provide an AxonServerCommandBus bean for context/serializer B, there will be no primary default for context/serializer A anymore). Correct assumption? What are my options? Thanks!
Seems like would would need to be able to make a difference between which serializer to use for reads, and which for writes? Almost always that should be the same, but not this time. Would introducing such a distinction in the framework help your use case?
A shot in the dark here, but maybe you can have a custom serializer that uses one of the two other serializers based on the message type or context or meta data or …
OK, sounds interesting. But it would still mean that I configure an addition (optional) serializer for my “main” context, while what I really would like to do is configuring multiple commandBusses, each with its own, fixed serializer.
I am considering creating a “non-spring” commandBus using the autoConfiguration method as a factory and use that in my command-sender (for the remote context). This way I would not mess with the beans registered in the context, but I would also have some unmanaged core component, basically I would mix spring context and plain java context. Could this work?
I think you could have multiple CommandBusses in your context, as long as you name them, then you can use @Qualifier to select the correct Command Bus for where you use it. It does mean you might need to dig in what’s already auto wired, to get to the pieces where you need the command bus.
How would I decide what “getConverter()” should return in that case? I do not get any context so I could not decide whether to call “myJacksonSerializer.getConverter()” or “myXstreamSerializer.getConverter()”, couldn’t I?
Well, I wrote it’s a “shot in the dark” for a reason
However, you inspired me to have a look at the code, and from what I see the default is ChainedConverter which seems to find converters configured as services. So theoretically if you use this one and you have all the converters available it should be able to find the correct one to convert one type to another. But that is another shot in the dark.
