Add support for Quarkus

[tunovic]

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

[smcvb]

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. :-)

[tunovic]

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.

[pepperbob]

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?

[tunovic]

@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.

[JohT]

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’t stable enough for me and can’t 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’ve 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.

[nicolas-vivot]

Hi,

Erf, i was interested in moving on AxonIQ, especially now that there is a cloud offer. But i'm now using 100% Quarkus in place of Spring boot so if there is no extension or support it's going to be hard :/

Adding support for Quarkus would be great, definitely as an official (supported) extension.

Of course Quarkus support Spring, but not 100% and the reflection things (and probably a few other points as reported) would still need to be addressed for the native support. So i agree having an official extension is the way to go.

I see that the mentioned extension attempt has not been changed since 2 years now and the showcase is running on an old version of Quarkus and GraalVM.

What is the status about this request ? Would Axon think about it or not at all ?

[JohT]

@nicolas-vivot, I recently updated my showcase-quarkus-eventsourcing. It now runs with the latest axon and quarkus version.

I also activated Renovate and automated native image build and integration tests so it should be possible to keep it up to date with minimized effort.

All previously working versions are tagged as releases and remain for reference.

Currently, I'm working on automating native image agent reports as mentioned in #1427 with this pull request: https://github.com/JohT/showcase-quarkus-eventsourcing/pull/28

[smcvb]

Would Axon think about it or not at all ?

I can assure you, we're definitely still thinking about this, @nicolas-vivot. It's more a matter of resources on this end. Supporting it as intended means removing or providing an alternative means to Axon's reflection use. Doing this in a backward-compatible manner is something we've looked at, but isn't overly feasible.

I'd thus rather expect better support for this to come along once work starts on the following major release.

So, all I can ask is some patience for the time being. Meanwhile, I believe @JohT's sample is your best bet to get something workable.

[cartel1]

@smcvb Hello, has the Axon team made any progress on plans to support Quarkus and/or GraalVM deployments?

[gklijs]

Hi, we're still in the process op updating the former Spring Native, now Spring Ahead of Time extension, to easily compile to native. Which would mean for a Spring (Boot) project it would be very easily to compile to native.

For Axon Framework 5 we plan to make it less tied to Spring Boot, with a possibility to also have Quarkus extensions. I hope that's good enough an update. But don't hesitate to ask additional questions.

[cartel1]

@gklijs Thanks for this update. Really looking forward to the release of Axon Framework 5 soon.

Would you say an Axon 5 release is possible within the next 4 to 6 months?

[gklijs]

I would say it's very unlikely to have Axon Framework 5 released that soon.

[cartel1]

@gklijs Understood. Thanks.

[smcvb]

Just a small addition to @gklijs his reply.

Once development on this starts, we will update the ticket accordingly, @cartel1. So, if you want to be kept in the loop, you can watch this issue to be notified automatically.

[cartel1]

@smcvb Thanks for the tip.

[smcvb]

Added this issue to release 5.0.0 as we intend to validate the feasibility of this in the new APIs. Granted, when work starts on this issue, it will likely move to a dedicated extension repository. This would be inline with our intent to move Spring (Boot) support to a separate extension repository, as described in issue #3075.