Axon CDI Extension: What spec version to target

Imported from Google Groups
1

This is a question/poll targeted at the current and future users of the Axon CDI extension.

The current implementation of the CDI extension has Alpha status, and works reasonably well with Axon 3.3.x and 4.0.x.
In my own time I have begun a rework of the extension’s internals that hopefully will pull it out of Alpha status, and targets Axon 4.x,
probably starting at 4.2-SNAPSHOT since that is the current Axon “master”. My goal is to more closely parallel the
services provided by the Spring module. For unit testing I am using Weld-SE, so no need for Arquillian or Cargo.

The current Axon CDI extension targets CDI spec 1.1 by including a “provided” dependency on Java EE 7. The current

version, included in Java/Jakarta EE 8 as well as Eclipse MicroProfile is CDI 2.0. This is also supported by Weld-SE,
although that should not be surprising as it’s the reference implementation for the spec.

I would like to get a general feeling for the need to stick to CDI 1.1, as it requires quite a bit of boilerplate code to
wrap Beans, or the inclusion of an additional dependency on something like Apache DeltaSpike.

Cheers,
Bert Laverman

2

If it doesn’t make a difference besides the internals, supporting java ee 6 would be nice.
If some features aren’t possible or it is much more complicated to use, then support from Java ee 7 up is fine.
Use/Reuse isn’t always that easy to balance.

I tried axon-cdi with websphere liberty and couldn’t get it to start.
It tries to resolve types with InitialContext null, which seems to work for some providers.
I guess, that there are currently a lot of individual solutions to get axon to work with Java ee.

Even if the spring approach is very convenient and easy to use,
i prefer the more encapsulated one place configuration approach
and call the configuration Api directly, even if this is sometimes not easy.

3

Johnnie,
could you tell me what your reason would be for using JEE 6? Are you on e.g. WebSphere 8.0? (later versions support JEE 7) The current CDI extension has JEE 7 as a provided dependency, so going back in time needs some convincing.

Which version of WebSphere Liberty profile did you try? The first alpha release of the CDI module has been tested on it, so I would like to see what went wrong there.

On JEE using CDI is not just convenient, the application servers supporting JEE 7 and 8 actually expect you to use it, so integrating with it should not provide surprises.

Cheers,
Bert Laverman

4

Hi Bert,

these were only my thoughts about supporting as much as possible. Java EE 7 is perfectly fine.
I’m only playing around with axon in my spare time and also use Java EE 8.
So i’m not a reference for using it in production.

In my professional life, Java EE 6 is standard, J2EE is still not dead and CQRS or event sourcing aren’t an issue :slight_smile:

I tried axon-cdi with
“Liberty (WebSphere Application Server 18.0.0.2/wlp-1.0.21.cl180220180619-0403) auf Java HotSpot™ 64-Bit Server VM, Version 1.8.0_45-b14 (de_AT)”
I got an error in “AxonCdiExtension” in method “produce” because of the “null” parameter:

`

// TODO: 8/29/2018 should we store produced components in some kind of cache and extract them if present?

private T produce(BeanManager beanManager, Producer producer) {

// Antoine: Is createCreationalContext(null) is correct here?

// If not, what should I do instead? Again, many of these things

// may be indirectly referencing container resources.

// Yes it’s correct, but I don’t think you need to produce your instances by hand

return producer.produce(beanManager.createCreationalContext(null));

}

`

I tried a quick fix by introducing the type to be produced (and extended all places where it is called).This works in most of the cases:

private <T> T produce(BeanManager beanManager, Producer<T> producer, Class<T> type) { Bean<T> bean = (Bean<T>) beanManager.getBeans(type).iterator().next(); return producer.produce(beanManager.createCreationalContext(bean)); }

There are also quite some issues with CDI proxied classes.
Eventhandler need to be @Dependent scope and/or (i’m not sure) they need to be annotated with @ProcessingGroup(…),

otherwise you get a NullPointerException during this ProcessingGroup fallback in the class “EventHandlingConfiguration”:

`

private Function<Object, String> fallback = (o) -> o.getClass().getPackage().getName();

`

But maybe i’m a bit out dated, since you wrote that you are reworking the internals.
And maybe i gave up to early.

Cheers.

Johnny.