Axonframework: Add support for Quarkus

Created on 15 Jan 2020  路  5Comments  路  Source: AxonFramework/AxonFramework

Please add support for Quarkus or contribute to https://github.com/quarkusio/quarkus/issues/1753

Under Discussion

Most helpful comment

I did a showcase for axon on Quarkus:
showcase-quarkus-eventsourcing

It shows how to integrate axon with microprofile standards:

  • JTA for transactions
  • JSON-B for serialization
  • CDI for dependency injection and bean discovery
  • JAX-RS Server-Sent-Events for reactive subscription query

It works - even in native mode - without further extensions or integration. But it was really hard to do it even with this simple example. An Quarkus extension could make this much easier.

There is an attempt to try this from another guy (not running yet)
quarkus-axonframework-extension

My thoughts/experiences:

  • Axon does a lot of stuff using reflections and ServiceLoader.
    This needs to be addressed writing extension code.
  • Axon is really well made for extension, since nearly everything can be wired using the configuration api.
  • Even if Axon is written with Spring in mind, it integrates well with Java EE
  • Axon Java EE wasn鈥檛 stable enough for me and can鈥檛 be used for Quarkus, since CDI extensions are not supported.
  • Getting the native image to run is really painful. Compile runs very long and most problems occur during runtime. There are some ways to address it (I鈥檝e documented these).

Since my showcase is also made to show how to get axon behind a boundary to not depend on it directly and how to not get dependent on Quarkus, it is maybe a bit more complicate than it could be.

All 5 comments

Do you mind elaborating what providing support for Quarkus would entail for Axon, @tunovic?
I can likely fill in some blanks myself, but I'd prefer to hear somebodies take on the issue instead of making assumptions. :-)

Similar to axon-spring-boot-starter where it sets a lot of configuration automatically. So that the CommandGateway and QueryGateway can be injected easily. In addition creating native image with GraalVM could be supported.

We're currently elaborating what changes would be implied by using Quarkus in our stack.

What we detected today is that we had issues getting the TrackingEventProcessor to work properly: it relies on a long running Threads and to access managed Beans (EntityManager, Transactions, CDI Beans in general) you'd provide a ManagedThreadFactory to the Axon-configuration for context propagation. Quarkus - which is backed by vert.x for some parts and thus more reactive in nature - does not seem to provide this and encourages to use an ExecutorService instead of Thread-Factories.

@tunovic Did you manage to get the Tracking Event Processor to work esp. with regards to Transactions and persistent storage, etc. where Quarkus-Managed-Beans need to be accessed?

@pepperbob I haven't used Quarkus in combination with Axon yet. But I do have plans if it gets supported to create more lightweight application. This could be a good opportunity for Axon to extends its reach.

I did a showcase for axon on Quarkus:
showcase-quarkus-eventsourcing

It shows how to integrate axon with microprofile standards:

  • JTA for transactions
  • JSON-B for serialization
  • CDI for dependency injection and bean discovery
  • JAX-RS Server-Sent-Events for reactive subscription query

It works - even in native mode - without further extensions or integration. But it was really hard to do it even with this simple example. An Quarkus extension could make this much easier.

There is an attempt to try this from another guy (not running yet)
quarkus-axonframework-extension

My thoughts/experiences:

  • Axon does a lot of stuff using reflections and ServiceLoader.
    This needs to be addressed writing extension code.
  • Axon is really well made for extension, since nearly everything can be wired using the configuration api.
  • Even if Axon is written with Spring in mind, it integrates well with Java EE
  • Axon Java EE wasn鈥檛 stable enough for me and can鈥檛 be used for Quarkus, since CDI extensions are not supported.
  • Getting the native image to run is really painful. Compile runs very long and most problems occur during runtime. There are some ways to address it (I鈥檝e documented these).

Since my showcase is also made to show how to get axon behind a boundary to not depend on it directly and how to not get dependent on Quarkus, it is maybe a bit more complicate than it could be.

Was this page helpful?
0 / 5 - 0 ratings