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!
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