Hi there,
I’m running a Spring Boot application (v3.1.2) with Java 20 (graalvm-ce, v20.0.1), and axon spring boot starter with reactor extensions (both v4.8.0)
I’m encountering the following error…any help will be appreciated.
Hi Kahiga,
Can you maybe share a minimal example with the same problem, please? That combination does work for some projects.
Oh, I’m using webflux too, if it helps
This is exactly what I’m running in my demo application, and it works like a charm.
Are you sure you imported the right starter modules in you pom? I once accidentally included just a regular dependency, and then there are many things missing.
In your case, make sure you imported the spring-boot-starter-webflux module.
1 Like
@allardbz You’re right. The problem lay in my implementation of Spring Security and 0auth2 Resource Server configuration. It was still reliant on mvc dependencies while the app itself run on webflux, thus, the discrepancy. It’s got nothing to do with Axon.
A major issue that has come up is that the event store isn’t compatible with r2dbc repositories…
The application defaults to an In-Memory Token Store. I can go ahead and plug-in Mongo as a Token Store since the application needs to be reactive, however, it’ll be problematic as we scale.
Will there be future support for a R2DBC compatible token stores…and how soon?
I’m not sure why you want to use Mongo? Since this won’t help making it reactive. The main problem with an R2DBC token store, is that the TokenStore is no reactive interface. What are you trying to solve?
@Gerard
My goal is to have end-to-end reactive microservices, with spring boot and Axon + axon-reactor.
In this effort, I have been migrating my codebases to a minimal reactive stack (webflux/netty, reactor, r2dbc, reactive redis - for caching and axon’s reactor extension)
Previously, my stack ran on (spring-mvc, JPA/Hibernate and standard axon). This worked perfectly as the current token store is compatible with JPA.
With this in mind, I overlooked the fact that TokenStore is a non-reactive interface. This will be a major problem going forward not only for myself but also for users of your framework that will consider a fully reactive stack.
Consider this challenge as your team marches toward Axon 5.0
Unless there’s an immediate solution to this problem, I’ll be forced to scale back.
With Axon Framework 4 is not possible to be fully reactive. One of the reasons we started working on Axon Framework 5, is to make this easier. Please note that you don’t just need a reactive token store, you need a reactive event processor, using a reactive token store.
What currently is possible, is to use Mono.block() in correct places, and have part reactive code, and part sequential blocking code. But this is not ideal.
What’s the timeline on Axon 5. It may deteremine if we scale backward or make these Blocking compromises as we await v5.
When it’s done. Which likely will take at least more than 6 months from now.
Noted, We can’t wait 