we’re working hard on getting Axon 2 out as soon as possible. In the issue tracker, you can see that the number of open features is diminishing rapidly. Special thanks go out to the sponsors that provided me with the time and resources to make this possible. And not to forget you guys, for diving into the remote edges of the framework and digging up the bugs that were left behind.
There is a number of features scheduled for Axon 2.0 that I believe might not be as “critical” as I initially thought. Especially the following features are candidates to postpone to later versions, or remove alltogether.
AXON-6: Remoting CommandBus. This feature is superseded by the DistributedCommandBus and the JGroups connector.
AXON-7: EventBus Connector (point-to-point). There is an AMQP Connector already.
AXON-10: Infrastructure for replaying events. Just a candidate to postpone to 2.1. It’s already possible to replay Events using the EventStoreManagement interface, but it requires some custom coding.
AXON-5: Support for aggregates without extending Axon classes. A nice feature to have, but it’s a lot of work. It won’t remove the dependency on Axon from you classes anyway, since you’ll still have to register your events somewhere. The amount of “intrusiveness” of the superclass has already been diminished to a minimum.
AXON-9: High performance snapshotter. Probably a good example of premature optimization. Snapshotting can easily run on a remote machine and fully asynchronous from the command handling process.
If you’re eagerly waiting on any of these features, or better, if you have implemented your own version of any of these, please let me know. You can either reply on this message, or vote for the features in the issue tracker.
Your opinion is very much appreciated!
Although some incidents happened at the voting booths and some people might have cast a double vote ;-), the results show a 'slight' preference (9003,5 points ahead) for AXON-10 - Infrastructure for replaying events. As promised that one will make it to the 2.0 release. I'll start on it soon.
we have implemented our homegrown solution for ΑΧΟΝ-10 but it would be nice if the framework supported this feature.
In our solution we have implemented a BeanPostProcessor that is responsible for finding the beans we want to reconstruct from events as well as for replaying these events as soon as Spring’s application context is initialized. In order to determine which beans to reconstruct we annotate them with a “marker” annotation (say, @ReplayEvents). Also we support @BeforeReplay and @AfterReplay annotations for operations that need to take place before and after the replay of the events. Lastly, the post processor gets the appropriate DomainEventStream from an injectable EventQueryService.
We are using this solution in order to replay all the events of our store to the different components of our system at deployment time. If you are interested I could share some of the code.
that definitely sounds interesting. The annotations (@BeforeReplay and @AfterReplay) was definitely something I wanted to go for as well. If you could share some code, that would be awesome. A marker annotation is a nice way to prevent listeners not compatible with replaying (such as sagas and listeners sending out messages to 3rd party systems) being replayed.
How do you currently distinguish between a “regular” restart and one that requires some events to be replayed?
Sorry, not sure I can share code, but here are few thoughts.
AXON-6: Remoting CommandBus. This feature is superseded by the DistributedCommandBus and the JGroups connector.
We’ve created JsonCommandMessage to make messages be serialized with Jackson. It has payload implementing our JsonTypified interface and metaData is just java.util.Map. JsonCommandMessage is used as argument in CommandBusWs powered with Jersey.
AXON-7: EventBus Connector (point-to-point). There is an AMQP Connector already.
Didn’t investigate AMQP Connectory, but AXON-7 should be very important feature for me in few month.
AXON-10: Infrastructure for replaying events. Just a candidate to postpone to 2.1. It’s already possible to replay Events using the EventStoreManagement interface, but it requires some custom coding.
We defined interface Replayable with beforeReplay() and afterReplay() methods. We injected all implementations of this interface to Replayer with Spring. Replayer has single replayAll() method for now and use o.a.e.m.EventStoreManagement.visitEvents(Criteria, EventVisitor) to dispatch events found in methods of Replayable event handlers. Replayable event handlers are subscribed to dedicated instance of SimpleEventBus directly before replay, so it knows noting about Sagas and non-Replayable event handlers.
We implemented @BeforeReplay and @AfterReplay, with the Reflections library, but human-factor problem happened. Our event handlers are expected to be Spring Beans and our implementation didn’t guarantee annotated classes are spring beans so to have fast solution we switched to Replayable interface.
I can create a pull request today with all the supporting classes, annotations and tests if you are interested in this approach. As you will see we reuse classes provided by Axonframework itself (AnnotationEventHandlerInvoker, ReflectionUtils, …) wherever is possible…
Distinguishing between a “regular” restart and one that requires replay of events is not supported as we never needed it. It would be a valuable addition though. At the moment, the only way to “disable” the replaying of events is to remove the definition of the post processor bean from the application context.
