Axonframework: Provide Jakarta EE friendly version of axon-core module

[danhaywood]

We use axon framework for its event bus (this is within Apache Isis, http://isis.apache.org). For our next release we are aiming to leverage more of JEE (previously we depended only on standard servlet stuff etc).

However, the class org.axonframework.common.jpa.ContainerManagedEntityManagerProvider (which we don't use) is annotated with @PersistenceContext and this basically prevents us from deploying to TomEE (JEE7):

• persistence context resolution is not processed by CDI, so there is no way to skip the scanning process
• the annotation scan is done by JPA which goes before CDI gets bootstrapped

So, would it be feasible to break core? ideally want we want is just org.axonframework.eventhandling.SimpleEventBus (+ related classes) in its own module

[andi-huber]

I'd like to add some background to Dan's question:

We have the intent to provide Eventbus functionality for Apache Isis via 'plugins' such that developers may pick from available technologies. So we provide plugins (jar files) that integrate with our framework and enable these technologies.

We have in mind to also include the AxonFramework as a eventbus solution, but stumbled over difficulties regarding deployment.

Apache Isis was initially designed to run on Servlet Containers like Tomcat, but we are now in the progress of extending Container support into the field of JEE 7/8. What's particularly interesting with our scenario is, that we do not depend on JPA instead we utilize JDO.

As of yet we could not figure out how to deploy AxonFramework's core (axon-core.jar) on JEE7/8 without the requirement of having to provide a persistence context configuration.

The only workaround we found is to configure a web-app's deployment descriptor (web.xml) in such a way, that it either includes a persistence-context-ref entry that declares a dummy persistence unit or by adding a 'metadata-complete=true' which breaks the idea of having servlets plugged in from other modules.

For both workarounds we would need our framework users to customize their web-descriptors, just because the AxonFramwork ships with this single class that declares a PersistenceContext annotation.

By splitting out org.axonframework.common.jpa.ContainerManagedEntityManagerProvider into a separate and only optional module, we would see our problem solved.

Thanks in advance for any advice!

[pepperbob]

Looking at it org.axonframework.common.jpa.ContainerManagedEntityManagerProvider is really kind of a pain and caused some confusions in the past. Deploying this in a JavaEE environment forces you to take care about it as there's hardly any way to prevent the container from discovering the @PersistenceContext even though it's not used it at all. Furthermore it enforces to mark a persistence unit as "default" when naming it explicitly or when using more then one.

The documentation implies you have a choice about this but you really don't. So I really don't see why this is "core".

[danhaywood]

If @andi-huber and I spent the time working on a pull request, is this something that the committers would consider merging? My preference would be to move the event bus into its own submodule (assuming it can be easily decoupled), but I'm happy to work on a different design that would address the issue if the committers have a preference.

[abuijze]

Hi all,
sorry for the late response. I'm was (and still am) on a busy travel schedule in the last weeks.
We are aware of the unfortunate annotation in the axon-core module. We have discussed this internally, and are reluctant to make any structural changes to the modules in our minor releases.
We do think it is a good idea to start separating things out for the next major release.

One thing that we could do to make the JEE developer's life a bit easier, is to create an axon-core jar with a special classifier that doesn't come with this specific class, so that there is no conflict. This should be fairly trivial to do with a maven plugin in the current build. I would be fine to include such an option in Axon 3.3. This will resolve the issue, without forcing any changes on existing users.

What do you think?

[andi-huber]

Hi @abuijze, thanks for you response, your proposal sounds promising to me.

[danhaywood]

Hi @abuijze - sounds good to me also. Thx

[smcvb]

As we're about to resolve version 3.3, I'll add this issue to 3.4.

[andi-huber]

It seems the proposed usage in a maven pom.xml is

<dependency>
    <groupId>org.axonframework</groupId>
    <artifactId>axon-core</artifactId>
    <version>3.3.5</version>
    <classifier>ee-compat</classifier>
</dependency>

But this artifact seems not available yet. Do we need to add a special repository entry to our pom file?

Cheers Andi!

[abuijze]

Hmm... it seems that the additional files haven't been synced with maven central. Will look into it.

[abuijze]

My bad. this feature is part of Axon 3.4, which hasn't been released yet

[andi-huber]

Ah I see, we'll wait then. Thanks!