Camunda configuration on Wildfly 8.0 as part of EJB-module

[iryna....@gmail.com]

Hello dear Camunda-Devs,

I have evaluated camunda and it's usage in a jee environment for a week or so. Now I would like to integrate it in our existing jee application running on Wildfly 8.0.0 and I am facing the following problem.

In my test project I have used camunda as maven compiled dependency, the project had a war-packaging-type, the processes.xml was configured accordingly and placed under <project>/src/main/resources/META-INF. This worked just fine. Each time I have deployed my application-war, camunda engine would be get deployed directly afterwards and my process definition get deployed on the engine as well.

Now I have a rather big jee project, which packages all its submodules into an ear (which is then deployed on a wildfly). For my workflow functionality I created a separate submodule as well. I set camunda as compiled dependency into my submodule pom. The packaging type is ejb, which is then bounded into the project's ear. The processes.xml has the same configurations and is placed in <submodule>/src/main/resources/META-INF. Unfortunately the engine isn't getting deployed on the project deployment. Does the packaging type play any role here? Do I have to place the processes.xml somewhere else? Any other ideas?

Regards,
Iryna.

[Daniel Meyer]

Hi Iryna,

How do you bootstrap the process engine? Do you have a @ProcessApplication annotated EJB?

Regards,

Daniel

[iryna....@gmail.com]

Hello Daniel,

I don't have any @ProcessApplication EJB. Do I need one? Accordinly to the Camunda documentation a default implementation of EjbProcessApplication class is provided by camunda-ejb-client.jar. I have added the dependency to the camunda-ejb-client to my pom.xml. But the dependencies seem not to get resolved.

My pom.xml looks like:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>parent-groupId</groupId>
<artifactId>my-workflow-engine</artifactId>
<version>02.11.00-SNAPSHOT</version>
</parent>
<artifactId>my-workflow-engine-service</artifactId>
<packaging>ejb</packaging>

<properties>
<failOnMissingWebXml>false</failOnMissingWebXml>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<dependencies>

<dependency>
<groupId>org.camunda.bpm.javaee</groupId>
<artifactId>camunda-ejb-client</artifactId>
<version>7.1.0-Final</version>
</dependency>

<dependency>
<groupId>org.camunda.bpm</groupId>
<artifactId>camunda-engine</artifactId>
<version>7.1.0-Final</version>
</dependency>

<dependency>
<groupId>org.camunda.bpm</groupId>
<artifactId>camunda-engine-cdi</artifactId>
<version>7.1.0-Final</version>
</dependency>

<dependency>
<groupId>com.fasterxml.uuid</groupId>
<artifactId>java-uuid-generator</artifactId>
<version>3.1.0</version>
</dependency>

... other dependencies ...


</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.3</version>
<configuration>
<ejbVersion>3.2</ejbVersion>
</configuration>
</plugin>
</plugins>
</build>

</project>

Do you see any problems with my pom.xml?

Greetings,
Iryna.

[Daniel Meyer]

Hi Iryna,

 camunda-ejb-client.jar

Is fine, it contains the default implementation of EjbProcessApplication, as you write.

I suspect that you have the following deployment structure:

my-app.ear
 | --- lib /
        | --- camunda-ejb-client.jar
        | --- camunda-engine-cdi.jar

 | --- my-workflow-engine-service.jar
        | --- META-INF/processes.xml
        | --- bpmn/process1.bpmn

This won't work since the the camunda-ejb-client is deployed as a library. In that case the Default EjbProcessApplication will not be recognized and deployed as EJB by the container.

Inside an EAR file, the deployment needs to be done is a way that 

1. the default or custom EjbProcessAplication is deployed as an EJB module (or as library inside a WAR)
   
2. the processes.xml file and the *.bpmn resources are visible from the classpath of the default or custom EjbProcessAplication
3. all CDI beans and Java Classes invoked from the processes are visible from the classpath of the default or custom EjbProcessAplication

In the following I have compiled 3 Options for you which should all work. Please note that EAR deployment is an advanced topic and it is important to understand EAR classloading in general.

Option 1

Downsides: 

1. my-workflow-engine-service.jar cannot contain EJBs
2. classes & resources from my-workflow-service.jar are visible to all modules inside the ear.

my-app.ear

 | --- lib /
        | --- camunda-engine-cdi.jar
        | --- my-workflow-engine-service.jar
              | --- META-INF/processes.xml
              | --- bpmn/process1.bpmn

 | --- camunda-ejb-client.jar

Option 2

Both my-workflow-engine-service.jar and camunda-ejb-client.jar are deployed as ejb modules.

In that case camunda-ejb-client.jar needs to be able to "see" the classes from my-workflow-engine-service.jar. The way to achieve this is

1. disable ear subdeployment isolation (default on jboss AS 7 / Wildfly AFAIK)
   
2. portable was: Classpath: entry in MEATA-INF/MANIFEST.mf
3. application server-proprietary: JBoss module dependency / jboss-deployment-structure.xml ...

my-app.ear
 | --- lib /
        | --- camunda-engine-cdi.jar

 | --- my-workflow-engine-service.jar
        | --- META-INF/processes.xml
        | --- bpmn/process1.bpmn

 | --- camunda-ejb-client.jar

Option 3

(Simplest)

my-app.ear
 | --- lib /

 | --- my-workflow-engine-service.war
        | --- WEB-INF/
              | --- lib/
                    | --- camunda-ejb-client.jar
                    | --- camunda-engine-cdi.jar
              | --- classes/
                    | --- META-INF/processes.xml
                    | --- bpmn/process1.bpmn

Does this help you?

Regards,

Daniel

[iryna....@gmail.com]

Hello Daniel,

thank you very much for your answer. It helped me to understand the project packaging preferred by camunda a little bit more now. Although I still couldn't find the right solution for my deployment environment.

I've reconstructed my project to the following deployment structure:

my-app.ear
| --- lib /
| --- my-workflow-engine-war.war

| --- WEB-INF/
| --- lib/
| --- camunda-ejb-client.jar
| --- camunda-engine-cdi.jar

| --- camunda-engine.jar
| --- classes/
| --- META-INF/processes.xml
| --- my-workflow-engine-service.jar
| --- META-INF/
| --- beans.xml
| --- MANIFEST.MF
| --- myprocess.bpmn
| myDelegatesAndOtherCodeUsingCamundaAPI

On deployment the process engine is getting started now. Also myprocess.bpmn is getting deployed on the process engine. The problem that I'm facing now is, that I have dependencies on camunda-*-.jars in my-workflow-engine-service.jar which aren't getting resolved.
If I add the respective maven dependencies to my-workflow-engine-service pom, then they would clash with the dependencies in my war file. If I add them as "provided", they won't be resolved, because wildfly looks for them in ear's own lib-folder and not in the war/WEB-INF/lib.
I cannot stack the classes/packages from my-workflow-engine-service module to my-workflow-engine-war as I am using also services from other modules in our project there, and so have to keep the "ejb" packaging type.

How could I make the camunda*.jars being available to my-workflow-engine-service.jar, but at the same time keeping it for deployment in my war?

I hope I could explain clearly what I need...

[da...@krizic.net]

Hi Iryna,

I would suggest to quickly try to deploy the whole thing as a single WAR file:

my-app.war
- WEB-INF/lib/*.jar (all jar, including the EJBs)
- WEB-INF/classes/processes.xml (META-INF?)

and the rest. This has the advantage, that there will be a single class loader used and all components can see all other components. This requires EJB 3.1 which is given on WildFly 8.0.

Regards,

Darko

[iryna....@gmail.com]

Hello Darko,

we have considered to convert our project to a war-packaged one. But because of go-live planned next week, and because we are not sure what impact it could have on other components we decided not to do it yet.

Instead we tried out the second option suggested by Daniel (deploying camunda jars as ejb modules) and it works for us.

By the way the ear subdeployment isolation is disabled by default in Wildfly 8.0.0 (as opposed to former jboss versions), so we don't have to configure it.

Thanks a lot to Daniel and Darko for your help!

Regards,
Iryna.