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!
Axon 2.4.6 has been released, which contains a few minor improvements over the previous version.
- The QuarztEventScheduler now allows for custom serialization of the Trigger Job. This helps when migration application versions while jobs are scheduled in an old format.
- The exception message for JSR303 validation errors has been improved.
- A timing issue when auto-detecting AggregateFactory instances for the snapshotter has been fixed
- Saga’s don’t survive their creation when an exception is thrown during the @StartSaga event handler. This prevent ‘ghost’ instances from lingering around after a failure.
- EventMessages in SagaTestFixture now use simulated fixture time
- In AMQP configuration, the ‘exclusive mode’ is set (to false) before configuring concurrent consumers (>1)
We’re proud to announce that the 3.0 release has reached an important milestone: the first release candidate is now available for download from Maven Central. All the major features that we want to include in the 3.0 release have been implemented.
Axon 3 brings a large number of API improvements over version 2. Aggregates and Sagas, for example, do not need to extend any Axon classes anymore. Configuration can be declaratively set up using the Configuration API and even automatically using the Spring Boot Starter modules.
We’ve also included some simplifications of the infrastructure required. For example, if you use Event Sourcing, your Event Store may also serve as the Event Bus. Event handlers can be configured as ‘subscribing’, receiving events from when they occur, but also ‘tracking’, where the events are read from the event store. The processor keeps track of the events it processed using a Tracking Token. After reboot, it will automatically continue where it left off. Tracking Processors also allow for replays, simply by dropping its data and tracking token.
The maven coordinates for this release are:
artifactId: axon-core / axon-test, etc
We are confident that Axon 3 is another step forward to developing CQRS based applications on the JVM as simple as possible. We look forward to any feedback you may have.
The Axon Framework team
Axon 2.4.3 has been released. It contains fixes for a few issues found in 2.4.2.
Under certain circumstances, it was possible that a JDBC connection wasn’t properly closed in the JDBC Event Store. This could cause issues in applications using Connection Pools (supposedly most of them).
A few fixes have been made in the batched reading of events from the JPA and JDBC event store. In some circumstances, a query would not return any results, due to a number overflow in the Event Store. This could happen when reading events with a start index of less than 2.
Finally, a number of inefficiencies have been fixed. Such as the rollback of a Unit of Work while using optimistic locking. The optimistic lock would retain the sequence number of the aggregate that was rolled back, effectively (temporarily) rejecting all changes to the same aggregate. The DisruptorCommandBus is now also optimized to handle exceptions from the command handler better.
Read more about the details in the release notes..
Axon 2.4.2 has been released. It contains fixes for a few issues found in 2.4.1, as well as a usability improvement.
This versions fixes two issues in the JGroupsConnector. The first is an issue where the connector fails to connect under certain circumstances. This would cause commands to be rejected on that node indefinitely, requiring a restart. The other is that the callback would not be invoked when the result of a command failed to be serialized.
The AsyncAnnotatedSagaManager is also improved. This release resolves some issues around the AsyncAnnotatedSagaManager’s behavior when the connection with the database is lost. Under very specific circumstances, it was possible that it would get caught in a retry-loop while waiting for new messages. In other circumstances, it was possible that messages were discarded.
The last fix is the JacksonSerializer, which was unable to deserialize MetaData instances.
This release also comes with a usability improvement. You can now register a listener with the JGroupsConnector, which will be notified when a change in memberships is detected. This listeners can be used, for example, to invalidate caches for items that have moved to another instance.
Read more about the details in the release notes..