Is it true that the CDI extension's JEE example is not in working order?

Axon Framework
#1

Hi,

I’m trying out Axon for the first time and have had the Giftcard application up and running.
However, my team use JEE 8 with CDI and are reluctant to have Spring on top of that. Therefore, I’m exploring the CDI-extension.

I have cloned https://github.com/AxonFramework/extension-cdi and is using the master branch. I know this is alpha software, but had hoped that the examples were in working order. I’m looking at example/javaee/pom.xml and it has

   <axon.version>3.3.5</axon.version>
   <axon-cdi.version>3.3-alpha2-SNAPSHOT</axon-cdi.version>

which seems pretty old. I tried copying over some of the example code while targeting the framework version 4.4.5, but that gives me compile errors as the example code includes things like

        return new JpaTokenStore(entityManagerProvider, serializer);

which I assume is outdated.

It seems as though I’m off in the wrong direction, so it’ll be great if someone could set me on the right path.

Cheers,
Jacob Grydholt

#2

Jacob,
version 4.1-alpha1 is actually the last version published, specifically for the single customer who needed only the updated component. I admit the JEE example was left unfixed, so I just now adjusted versions and updated the code to use the new Builders pattern. This is what caused those compiler errors. Please look at my updates in the “axon-cdi-4.1.x” branch.

We are actually looking at the extension again, because of the changes due to the “jakarta” package naming, but we’re a bit busy with the 4.5 release at the moment. Please let us know if the above helps you further, and do also tell us about your intentions; It would help if we knew there is actual interest in the extension.

Cheers,
Bert Laverman

#3

Hello and welcome Jacob!

For now I’m afraid your only option is to try what @Bert_Laverman said.

That said I would like to ask you to provide as many details as you can about your environment and intended usage. It would be very beneficial to understand your use case so we can better address it in the newer versions. That is particularly important if you are using some “modern” JEE microservices approach.

For example, currently it is developed as CDI Portable Extension which does not work well with Quarkus. I am experimenting with converting it to “simple” collection of CDI Beans/Providers and I got most of it working. The challenge, as Bert already mentioned, is that at the moment different versions of different CDI containers expect different CDI packages (javax vs jakarta). In addition to that the framework itself has (optional) dependencies on javax.persistense which among other things makes it impossible to wire jakarta.persistence.EntityManager from a CDI container.

I can’t make any promises about new version release of the CDI extension, but I’d like to encourage you to contribute to it in any way you can (feedback, issues, code, …). If you are interested in experimenting with my new, only partially working and not properly tested code I can share that with you too.

#4

Thanks Bert and Milen,

The branch axon-cdi-4.1.x Java EE example compiles and builds a war-file just fine. However, when I deploy it I get the errors:

WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "javaee-axon-example-3.3-alpha2-SNAPSHOT.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"javaee-axon-example-3.3-alpha2-SNAPSHOT.war\".WeldStartService" => "Failed to start service
    Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type CommandGateway with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private org.axonframework.cdi.example.javaee.AccountApplication.commandGateway
  at org.axonframework.cdi.example.javaee.AccountApplication.commandGateway(AccountApplication.java:0)

When I include part of the example code, I get the same error even when I include a producer of the Configuration which seems to be the issue with the above error. I’ll research a bit more as this is not much to go on, but I’m including it here in case you recognise the problem and know of a solution.

To the question of our environment and intended usage: We are running a ‘traditional’ Java EE application server: JBoss EAP 7.3.x which supports Java EE 8. We have no plans to switch to EAP’s XP extension which tracks the Eclipse MicroProfile.

My team is currently migrating an old application. We translate the old application’s data into a stream of events in a new domain model. When we have generated the events, we ‘process’ them thereby persisting them into a new database (PostgreSQL).

At the moment, we are using a home-grown implementation for the events and their processing. Each event class is serialised as JSON and stored as such in the database.

Our plan is to reuse this event structure as we create a replacement for the old application. As we educate ourselves on things like event sourcing, it becomes clear that we’re going to need much more support code, e.g. a hierarchy of commands which can either accept or veto changes. Strict definitions of aggregates will also inform our modelling.

So instead of building everything ourselves, our hope is to leverage an existing solution such as Axon, which is why I’m evaluating the framework.

Hope that sheds a bit of light on our intended usage, but I’m happy to elaborate if things are unclear.

Cheers,
Jacob Grydholt

#5

Just a quick update, I can create a deployable .war file. I didn’t solve the issue with your Java EE example, but the issues I had with my own code was due to missing dependencies.

Now I get exceptions when I try to send commands on the bus:

        commandGateway.send(new CreateAccountCommand(
                UUID.randomUUID().toString(), 100.00));

results in

java.util.concurrent.CompletableFuture@6ec365c9[Completed exceptionally: org.axonframework.eventsourcing.eventstore.EventStoreException: An event for aggregate [8512ab42-7ac9-4039-909b-36f9a91a205c] at sequence [0] could not be persisted]

I hope that this is an issue unrelated to the CDI extension and can be resolved by the right configuration.

Cheers,
Jacob Grydholt