Cannot use Activiti-CDI in an EAR

[felipe1]

I had a WAR application with activiti-cdi working perfectly. Then I've changed the deployment artifact to an EAR containing the exact same WAR and I get an error on startup:

"Could not find an implementation of the org.activiti.cdi.spi.ProcessEngineLookup service returning a non-null processEngine. Giving up."

The WAR is the "book-cdi-app" example from "Activiti in Action", which uses "activiti.cfg.xml" to configure the engine.

I have found an old post (http://forums.activiti.org/content/packing-and-booting-activiti-cdi-ear) which seems to relate to the issue I'm having.


Any help will be much appreciated.

[felipe1]

Some additional info about my environment…

- jBoss 7.1.1
- activiti version: 5.9
- spring version: 3.0.5-RELEASE

[matthias_]

I have the same issue. To help debugging the problem i created a minimalistic ear file based on the war file published on https://bitbucket.org/meyerd/activiti-cdi-jbossas7.1.1-setup/overview. The war is a minimalistic activiti on jboss artifact which actually works.
Well, the minimalistic war file works but the minimalistic ear does not. The error message is "org.activiti.engine.ActivitiException: Could not find an implementation of the org.activiti.cdi.spi.ProcessEngineLookup service returning a non-null processEngine. Giving up." Full Stacktrace is attached.

I uploaded both artifacts in case somebody wants to reproduce the problem and debug it here: https://www.dropbox.com/s/1chp1nenx1ojiml/activiti%20ear%20on%20jboss.zip

Any input is appreciated.

[saatsch]

Matthias,

I looked at your example and also meyerd's.
Like the name implies activiti-cdi is prepared for Java CDI. I would not hope to have two different dependency injection containers (CDI/Spring)  in parallel and still know exactly what I am doing.

Please decide using Spring OR CDI.
I would recommend CDI because it's standard Java and must come along with standard Java EE Containers.

Also when you want to build an EAR use skinny wars: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html
And let your EAR depend on the libraries that your war needs.
Then configure your maven-ear-plugin:
<code>
    <artifactId>maven-ear-plugin</artifactId>
    <configuration>
     <defaultLibBundleDir>lib</defaultLibBundleDir>
</code>
This way everything outside war is loaded by ear classloader and you have fewer problems if you want to put a 2nd war into your ear later.

In case you decide for CDI:

remove spring dependencies. Remove activiti.cfg.xml
Make an ejb that contains your ProgrammaticProcessEngineLookup.
Put a file like this
https://bitbucket.org/meyerd/activiti-cdi-jbossas7.1.1-setup/src/4216c17d3adc6b21f99360dc220fdf71372...

into your ejb. Let it reference your ProgrammaticProcessEngineLookup and do not forget beans.xml. Also put beans.xml into your war.

Now you should be able to @Inject ProcessEngine into your war.

If you are missing the good ability of spring to handle unit tests, take a look at http://deltaspike.apache.org/documentation.html

Regards

[matthias_]

saatsch, thank you very much for your input.

I understand your argument about spring vs. jee cdi and retried the test with a programmatic config, as you suggested. I would like NOT to use skinny wars because this requires redundancies in the pom.xml files (see your link http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html).

Unfortunately, the problem still occurs (same stack trace). I uploaded the test ear and test war file here: https://www.dropbox.com/s/oeeftat7hkpawek/activiti%20ear%20on%20jboss%20programmatic%20config.zip . Any input is appreciated.