Is there any specific way for Axon migration from 2.4.3 version to 3.1.1

问题

I am new to axon and doing migration from Axon 2.4.3 to 3.1.1 but I am not able to find any migration guide which is available for other version? Can you please share your experience on how to do the same. I am facing a lot problem, some classes have been removed, some packages have been changed. For some classes I am even not able to find replacements, so please help me with some suggestion. If there is a guide for same please provide me with link of that.

Thanks in Advance

Acctually I am not able to find replacement for these which were there in axon 2.4.3 ClusteringEventBus- DefaultClusterSelector- EventBusTerminal- SimpleCluster- SpringAMQPTerminal- SpringAMQPConsumerConfiguration- ListenerContainerLifecycleManager-

回答1:

There currently is not an official Axon 2.x to 3.x migration guide, although it is on the backlog to be introduced. I can, however, give you a couple of pointers you should look for whilst migrating:

1. AbstractAnnotatedAggregateRoot is no longer necessary for your Aggregates, so remove it.
2. Publishing events in your aggregates is now done with the static AggregateLifecycle.apply() function, so import it.
3. AbstractAnnotatedSaga is no longer necessary for your Sagas, so remove it.
4. If in an Spring application, it is suggested to use the @Aggregate annotation on your aggregates to notify Spring to create all the required beans (repository, factory,,,) for an Aggregate.
5. If in an Spring application, it is suggested to use the @Saga annotation on your sagas to notify Spring to create all the required beans (repository, manager,,,) for a Saga.
6. The domain_event_entry table has an added globalIndex column, which if you already have quite some events needs correct migration. This post gives some insights how an Axon Framework user is solving this.
7. In Axon 2.x you had the notion of Clusters, were you could group your Event Handling Components in. This has been replacing by Event Processing Groups, where you've got the possibility to choose between a SubscribingEventProcessor (push events to the Event Handling Components) and a TrackingEventProcessor (pull events being stored and handle them in your Event Handling Components).
8. In a Spring / Axon 2.x mix, you've possibly used configuration through Spring XML. In 3.x you can use (1) the Configurer API, (2) use the @EnableAxon annotation on a Spring Configuration class or (3 - recommended) use the axon-spring-boot-starter dependency to automatically get all your Axon beans.

This is what I can think of on the top of my mind, but I'm probably forgetting some pointers. You can also find some info on migration in this Axon User Group post, or more generally the Axon User Group might have some things you're looking for.

By the way, feel free to update your question, then I can update my answer to fill in the blanks you're still missing!

Update

This bit is regarding the specific classes you're missing when updating from 2.4.3 to 3.1.1:

Like I've shared in my earlier response, bullet point 7 to be exact, the complete Cluster approach in Axon 2.x has been replaced for the Event Processor approach in Axon 3.x. Conceptually not much has changed here, internally it however behaves differently and intendedly more concise. So the short answer is, all those classes have been replace by Event Processor, for which the documentation is here.

As that's not very helpful at all, I'll give you a specific answer to the classes you're missing to help you out. It's quite long, so be prepared:

• ClusteringEventBus: This was in place to publish events to a Cluster of Event Handling Components. In Axon 3.x, that's a now behind a Processing Group, handled by either a Subscribing or Tracking implementation. Hence, do not search for the ClusteringEventBus to publish events to groups. All the 3.x EventBus implementations will know how to publish events to a SubscribingEventProcessor, whilst the TrackingEventProcessor will pull the events from the store itself (so no bus involved).
• DefaultClusterSelector: The Cluster selector was in charge of grouping Event Handling Components / Event Listeners into a cluster. As shared, we no longer regard a set of Event Listeners as a cluster, but as a Processing Group. The behavior in 3.x is such that the package name of your Event Listeners implementation is the name of the Processing Group used. You can however overwrite this, but adding the @ProcessingGroup({processing-group-name}) as a class level annotation to your Event Listener implementation. The Axon 3.x configuration will automatically group the Event Listeners with the same Processing Group Name under the same Event Processor (which in 2.4.x would translate to the same Cluster). By default, the Event Processor implementation used will be Subscribing. This can be adjusted to Tracking in the configuration.
• SimpleCluster: As follows from my earlier explanation, there no longer is a SimpleCluster. This has been replaced by the EventProcessor interface, which is implemented by the Subscribing and Tracking Event Processors.
• EventBusTerminal: The EventBusTerminal was in charge of publishing the events to the right Clusters, albeit local or remote. As shared, we no longer have Cluster, but Event Processor groups. How events get to a Event Processor depends on the implementation used. If Subscribing (read: the default Event Processor) is used, the EventBus is in charge of publishing the events to them. The TrackingEventProcessor will however, asynchronously, start it's own thread(s) to pull events from the EventStore and in place send those events to its Event Listeners. Thus, you no longer have to search for the EventBusTerminal, as it's obsolete.
• SpringAMQPTerminal: As I've shared above, the EventBusTerminal has been removed in favor of the Subscribing or Tracking approach. As of Axon 3.1.1, for Spring AMQP we've got a Subscribing Event Processor implementation to listen to events and publish them on a Queue, which is the SpringAMQPPublisher.
• SpringAMQPConsumerConfiguration: This configuration class was in place, because when axon-amqp was introduced, Spring did not create the ListenerContainers as it does at introduction point of Axon 3.x. Hence there was decided against keeping our own configuration set up for this consumers and leave that to the competent hands of Spring. Hence you will not find SpringAMQPConsumerConfiguration and should search how Spring creates the consumers for AMQP.
• ListenerContainerLifecycleManager: This class was the implementation to correctly receive all event incoming from queues and send them over to all your Event Listeners. This class has been replaced by the SpringAMQPMessageSource.

Hope this gives you the answers you're looking for @AS!

来源：https://stackoverflow.com/questions/48124335/is-there-any-specific-way-for-axon-migration-from-2-4-3-version-to-3-1-1