Axon 3.0.4 has been released. It is a quick follow up on the 3.0.3 release and fixes some issues related to the distributed command bus in combination with Spring.
Due a timing issue in the configuration of several components, it was possible that certain Command Handlers were registered with the wrong Command Bus instance (the local segment instead of the distributed command bus). 3.0.4 addresses those issues.
Furthermore, 3.0.4 provides methods on the Configuration interface that provide access to the different submodules and Event Processors.
For full details of this release, check the release notes.
Axon 3.0.3 has been released! This release contains quite a few fixes and improvements to earlier versions.
We have solved some issues related to the Spring Cloud components for the Distributed Command Bus. Nodes not accepting any commands themselves caused Class Cast exceptions on the other side, preventing them from participating at all. We have also included Spring Boot Auto Configuration for the Spring Cloud components.
The Tracking processor is now more resilient to failure and exposes its current state. It can now also be paused/resumed at Runtime.
The issue that prevents Axon to work nicely with Spring Boot Devtools has also been identified and fixed. That means it’s now possible to use the Axon starter modules in combination with Spring Boot Devtools.
For more details about this release, check the release notes.
Today, we have released Axon 3.0.2! This release contains a few fixes to issues found in earlier versions.
The generic types in the Given-When-Then test fixtures have been fixed, so that the expectEventMatching() methods now accept the Matchers provided by Axon. Certain matchers could not be used due to incorrect Generic type expectations.
We have also resolved an issue that could cause certain events to be published out-of-order when command handlers would send out new commands as well as events.
In 3.0.1, the TrackingToken would be updated in the JpaTokenStore, even if the data itself didn’t change. In certain databases (e.g. Postgres), this would cause large numbers of LOB Pointers to be ‘consumed’, for no obvious reason. This has been improved in 3.0.2.
We have also implemented a minor improvement: Components registered using the Configuration API are now injectable as parameters of annotated handler methods (e.g. @CommandHandler, @EventHandler).
For more details about this release, check the release notes.
Today, we have released Axon 3.0.1. This release contains fixes for a few bugs and usability issues that were found since the release of 3.0.
A notable new feature is the possibility to use Spring’s @Autowired for resources in the SagaTestFixture.
We have also simplified the configuration of MessageHandlerInterceptors on Processors using the Configuration API. It is no longer necessary to configure a complete custom Processor Builder function. You can now simply register the interceptors that need to be assigned to the Processors as they’re created.
For a list of fixes, check the GitHub issue tracker.
The initial ideas for Axon 3 started about 2 years ago. The first commit was on about 15 months ago. The first milestone release was published about 6 months ago. And finally, the 3.0 GA release is here now! It’s been quite a journey, and we’re proud of the results.
Axon 3.0 contains a complete overhaul of the most important inner workings of Axon. Mainly because of a lot of new features that Java 7 and 8 have brought us (Axon 2 was Java 6 based). A lot of components were simplified as a result of this redesign.
The most important changes are:
- Java 8 support: Axon makes good use of Java 8 features, such as Lambdas and the Stream API. Many Axon APIs are now based on these features
- Event Store is now also an Event Bus: While this may sounds strange, it actually makes sense. The Event Store is a specialized version of the Event Bus, which happens to store events and make them available for Event Sourcing.
- Configuration API: Easily set up an Axon environment using the new Configuration API. It takes just 1 line of code to set up a Command Bus, Event Bus (or Event Store with 1 extra line), etc.
- Spring Boot Auto-Configuration support: Simply add a few starter depenencies and the Axon Spring Boot components will setup up a basic infrastructure for you depending on the other dependencies you have. If you have JPA, Axon will automatically configure all the JPA based components for you. Did you put @Aggregate or @Saga on a class? Axon will automatically configure the components necessary to operate these Aggregates and Sagas. Obviously, you can still customize behavior by defining your own beans.
- Tracking Processors: Processors, formerly known as (Event Handler) Clusters, come in 2 shapes: Subscribing and Tracking. Subscribing Processors are the default and invokes handlers as Events are published. The Tracker has it’s own thread, and tails the Event Store at its own speed, using a Token to keep track of its progress. This makes replays as easy as clearing the token; the processor will automatically start at t=0.
- Redesigned Spring AMQP Support: Dispatching messages over AMQP has been simplified a lot. You can easily decide per processor if they need to read from an Event Bus, Event Store or a specific AMQP Queue. Sending messages to AMQP is as easy as defining a single line of configuration in application.properties.
- More modelling freedom: In Axon 3, there is no more Abstract..AggregateRoot. You can simply annotate your Command Handlers and Event Handlers, and Axon will take care of the rest. Apply events by invoking the static AggregateLifecycle.apply() method. It is now also a lot easier to create multi-entity Aggregates. There is now only a single annotation for fields containing (event sourced) members.
- Improved monitoring: Axon comes with improved metrics support. Each component is now able to produce detailed information about its health and performance.
- Improved upcaster API: The upcaster API has been brought back to the bare essential. This makes it possible and more powerful, especially when it comes to more complex upcast mappings.
- Conflict detection: Detecting concurrency conflicts is now made a lot simpler. Simply add a ConflictResolver parameter to your @CommandHandler method, and you simply provide a few predicates of what you believe are Events indicating a conflict for the incoming command.
- And so much more…
The documentation has also gone through a full-blown transformation. It is now published using GitBook and available for on-line reading, as well as offline using pdf, modi and epub. GitBook also allows readers to post comments next to paragraphs. So if something isn’t clear, just raise an issue. The documentation is written in MarkDown and published in its own GitHub repository, so creating pull requests is a breeze.
There are a few chapters that need some attention, but the vast majority is already available. We’ll also start working on an Axon 2 to Axon 3 migration guide soon.
We have also brought the issue tracker back to GitHub. The old issue tracker is now read-only.
But instead of reading all about the release, why not try for yourself? You can get a download package, or update your maven dependencies* to use Axon 3.
Special thanks go out to all committers and contributors, as well as the brave developers that have battle tested the milestones and release candidates in their production environments. We’re proud to have you on board!
Now go, and develop!