Major Releases

All the enhancements and features which have been introduced to our major releases of the Axon Framework are noted here.

Release 4.5

This release has seen numerous addition towards Axon Framework. The most interesting adjustments can be seen down below. Note that the BOM (as marked in #1200) is not part of the release notes, as this will use its own separate release cycle. For those interested, the BOM repository can be found here.

For an exhaustive list of all adjustments made for release 4.5 you can check out this page.

Enhancements

• A new type of EventProcessor has been introduced in pull request #1712, called the PooledStreamingEventProcessor. This EventProcessor allows the same set of operations as the TrackingEventProcessor, but uses a different threading approach for handling events and processing operations. In all, this solution provides a more straightforward processor implementation and configuration, allowing for enhanced event processing in general. For specifics on how to configure it, check out this section.

• Sagas support the use of Deadline Handlers, but an @DeadlineHandler annotated method couldn't automatically close a Saga with the @EndSaga annotation. This enhancement has been described in #1469 and resolved in pull request #1656. As such, as of Axon 4.5, an @DeadlineHandler annotated can also be annotated with @EndSaga, to automatically close the Saga whenever the given deadline is handled.

• Whenever an application uses snapshots, the point arises that old snapshot versions need to be invalidated when loading an Aggregate. To that end the SnapshotFilter can be configured. As a simplified solution, the @Revision annotation can now be placed on the Aggregate class to automatically configure a revision based SnapshotFilter. Due to this, old snapshots will be filtered out automatically when an Aggregate is reconstructed from the EventStore. For those interested, the implementation of this feature can be found here.

• At the basis of Axon's message handling functionality, is the MessageHandlingMember. For the time being, the sole implementation of this is the AnnotatedMessageHandlingMember, which expect the use of annotations like the @CommandHandler and @EventHandler, for example. As a step towards constructing an annotation-less approach, #1621 was introduced into the framework. The first steps taken in this pull request are the deprecation of annotation-specific methods from the MessageHandlingMember interface. Added to this is a new approach towards defining attributes of a message handling member through HandlerAttributes.

Bug Fixes

• The InMemoryEventStorageEngine is a good fit for testing purposes. However, it included a discrepancy towards the event storing solution compared to other event storage solutions. This issue was addressed in #1056 and resolved in pull request #1660.

• In issue #1733 a confusion around the EventUtils#asDomainEventMessage was described. This reiterated the fact that this method is purely intended for internal use inside Axon Framework, which was not clear to the users. As such, it has now been deprecated, containing a clear statement why this method is not to be used.

Release 4.4

Enhancements

• Axon Framework can now be used in conjunction with Spring Boot Developer Tools. You can simply achieve this by adding the required dev-tools dependency to your project.

• As a partial solution to #1106, Axon Server can now be used to schedule events. Building an AxonServerEventScheduler as the EventScheduler implementation as defined through the builder is sufficient to start with scheduling events through Axon Server.

• An EventTrackerStatusChangeListener can now be configured for a TrackingEventProcessor, as was requested in #1338. It can be configured through the TrackingEventProcessorConfiguration, allowing users to react upon status changes of each thread processing event messages.

• Component specific message handler interceptors can now be defined through a dedicated annotation: the @MessageHandlerInterceptor annotation. This annotation allows you to introduce a specific bit of logic to be invoked prior to entering the message handling function or after invocation. It for example allows the additional introduction of a @ExceptionHandler annotation, allowing you to specifically deal with the exceptions thrown from your message handlers. The original pull request can be found under #1394. For more specifics on using this annotation, check ou the @MessageHandlerInterceptor section.

• Configuring a Snapshotter and SnapshotFilter have been simplified in this release. Pull request #1447 shares the load of allowing for distinct Snapshotter configuration. Issue #1391 describes the intent to the configuration of snapshot filtering to be performed on Aggregate level. The former can be configured through the Configurer, whereas the latter is by usage of the AggregateConfigurer.

Bug Fixes

• The AggregateTestFixture was incorrectly noting an old method in one of its exceptions. This has been marked and resolved in #1428.

• The CommandValidator and EventValidator had a minor discrepancy; namely, the CommandValidator cleared out contained commands upon starting whereas the EventValidator didn't. Pull request #1438 resolved the problem at hand.

For a full list of all the feature request and enhancements done for release 4.4, you can check out this page.

Release 4.3

Enhancements

• Aggregate Polymorphism has been introduced, allowing for an aggregate hierarchy to come naturally from a domain model. To set this up, the AggregateConfigurer#withSubtypes(Class... aggregates) method can be used. In a Spring environment, an aggregate class hierarchy will be detected automatically. For more details on this feature, read up on it here.

• An Axon application will now shutdown more gracefully than it did in the previous releases. This is achieved by marking specific methods in Axon's infrastructure components as a @StartHandler or @ShutdownHandler. A 'phase' is required in those, specifying when the method should be executed. If you want to add your own lifecycle handlers, you can either register a component with the aforementioned annotations or register the methods directly through Configurer#onInitialize, Configuration#onStart and Configuration#onShutdown.

• We have introduced the @CreationPolicy annotation which you can add to @CommandHandler annotated methods in your aggregate. Through this, it is possible to define if such a command handler should 'never', 'always' or 'create' an aggregate 'if-missing'. For further explanation read the Aggregate Command Handler Creation Policy section.

• Both the XStreamSerializer and JacksonSerializer provide a means to toggle on "lenient serialization" through their builders.

• Various test fixture improvements have been made, such as options to register a HandlerEnhancerDefinition, a ParameterResolverFactory and a ListenerInvocationErrorHandler. Additional validations have been added too, revolving around asserting scheduled events and deadline message. The Test Fixture page has been updated to define these new operations accordingly.

• The TrackingEventProcessor#processingStatus method as of 4.3 exposes more status information. The current token position, token-at-reset, is-merging and merge-completed position have been added to the set. Read the Event Tracker Status section for more specifics on this.

Bug Fixes

• A ConcurrencyException was thrown when an aggregate was created at two distinct JVM's at the same time. As ConcurrencyExceptions are typically retryable, the creation command would be issued again if a RetryScheduler was in place. Retrying this operation is however useless and hence has been replaced for an AggregateStreamCreationException in pull request #1333.

• The test fixtures for state-stored aggregates did unintentionally not allow resource injection. This problem has been resolved in pull request #1315.

• The MultiStreamableMessageSource did not deal well with one or several exceptional streams. Hence exception handling has been improved on this matter in #1325.

For a complete list of all the changes made in 4.3 you can check out this page.

Release 4.2

Enhancements

• Axon Framework applications can now use tags to support a level of 'location awareness' between Axon clients and Axon Server instances. This feature is further described here.

• Axon Server already supported several contexts, but Axon Framework application could not specify to which context message should be dispatched. The Axon Server Connector has been expanded with a TargetContextResolver to allow just this.

• A new implementation of the StreamablbeMessageSource has been implemented: the MultiStreamableMessageSource. This implementation allows pairing several "streamable" message sources into a single source. This can in turn be used to for example read events from several distinct contexts for a single Tracking Event Processor.

• Handler Execution Exception now allow application specific information to be sent back over the wire in case of a distributed set up.

• The TrackingToken interface now provides an estimate of it's relative position in the event stream through the position() method.

• Optional return types can now be used for Query Handling methods.

Bug Fixes

• An Aggregate's Snapshotter was not auto configured when Spring Boot is being used, as was filed under #932.

• The CommandResultMessage was returned as null when using the DisruptorCommandBus. This was solved in pull request #1169.

• The ScopeDescriptor used by the DeadlineManager had serialization issue when a user would migrate from an Axon 3.x application to Axon 4.x. The axon-legacy package has been expanded to contain legacy ScopeDescriptors to resolve this problem.

For a full list of all features, enhancements and bugs, check out the issue tracker.

Release 4.1

Enhancements

• The TrackingEventProcessor now has an API to split and merge TrackingTokens during runtime of an application. Axon Server has additions to the UI to split and merge a given Tracking Event Processor's tokens.

• Next to Dropwizard metrics the framework now also supports Micrometer metrics. The MessageMonitor interface is used to allow integration with Micrometer. Lastly, we are incredibly thankful that this has been introduced as a community contribution.

• Primitive types are now supported as @QueryHandler return types.

• We have introduced the EventGateway in a similar fashion as the CommandGateway and QueryGateway. As with the command and query version, the EventGateway provides a simpler API when it comes to dispatching Events on the EventBus.

Bug Fixes

• Command and Query message priority was not set correctly for the Axon Server Connector. This issue has been addressed under bug #1004.

• The CapacityMonitor was not registered correctly for Event Processor, which user "Sabartius" resolved under issue #961.

• Some exception were not reported correctly and/or clearly when utilizing the Axon Server Connector (issue marked under number #945).

We refer to this page for a full list of all the changes.

Release 4.0

Enhancements

• The package structure of Axon Framework has changed drastically with the aim to provide users the option to pick and choose. For example, if only the messaging components of framework are required, one can directly depend on the axon-messaging package.

• In part with the package restructure, all components which leverage another framework to provide something extra have been given their own repository. These repositories are called the Axon Framework Extensions.

• The configuration of Event Processor has been replaced and greatly fine tuned with the addition of the EventProcessingConfigurer.

• Some new defaults have been introduced in release 4.0, like a bias towards expecting a connection with Axon Server. Another important chance is the switch from defaulting to Tracking Processors instead of Subscribing Processors.

• The notion of a CommandResultMessage has been introduced as a dedicated message towards the result of command handling.

• To simplify configuration and more easily overcome deprecation, the Builder pattern has been implemented for all infrastructure components.

Bug Fixes

The bugs marked for release 4.0 were issues introduced to new features or enhancements. As such they should not have impacted users in any way. Regardless, the full list can be found here.

For more details, check the list of issues here.