EAR – project structure with WARs and EJB

[Bernd Varga]

Hallo,

 

we actually plan following project structure:

 

• EAR
• taskservice-binding.war
• taskservice-process.war
• taskservice-jar (ejb)

 

We want to separate the taskservice implementation from the process implementation but composite the moduls to one ear. The taskservice should only start a process in a specific transaction. All other dependencies to camunda should be implemented in taskservice-process.war.

 

The actually generated EAR has following content:

• EAR-Content
• Lib
• camunda-ejb-client-7.3.0.jar
• camunda-engine-cdi-7.3.0.jar
• taskservice-binding.war
• taskservice-process.war
• WEB-INF/lib
• camunda-ejb-client-7.3.0.jar
• camunda-engine-cdi-7.3.0.jar
• WEB-INF/classes
• *bpmn
• META-INF/processes.xml
• taskservice-jar (ejb)
• META-INF/application.xml

 

During the deployment on jboss the following error is output:

 

10:33:07,166 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."customer-ear-1.0.0-SNAPSHOT.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."customer-ear-1.0.0-SNAPSHOT.ear".PARSE: JBAS018733: Failed to process phase PARSE of deployment "customer-ear-1.0.0-SNAPSHOT.ear"

        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.2.0.Final.jar:7.2.0.Final]

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]

        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_20]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_20]

        at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_20]

Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Class org.camunda.bpm.application.impl.ejb.DefaultEjbProcessApplication is annotated with @ProcessApplication but is neither a ServletProcessApplication nor an EJB Session Bean Component.

        at org.camunda.bpm.container.impl.jboss.deployment.processor.ProcessApplicationProcessor.detectExistingComponent(ProcessApplicationProcessor.java:189)

        at org.camunda.bpm.container.impl.jboss.deployment.processor.ProcessApplicationProcessor.deploy(ProcessApplicationProcessor.java:72)

        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Final.jar:7.2.0.Final]

        ... 5 more

 

Is it possible to access the camunda engine from a ejb modul?

 
Cheers,

Bernd

 

[Daniel Meyer]

Hi Bernd,

the exception should go away if you remove the camunda-ejb-client-7.3.0.jar from the lib folder of the ear.

Did you have any specific reason for adding it there?

That jar contains the default ejb process application implementation. Inside an EAR file you can either add it as an ejb module to the ear or as a web library to a WAR file (like you also did).

Cheers,

Daniel

[Bernd Varga]

Hi Daniel,

thanks for your advise.

The reason for the generated dependencies was in the pom. The EJB had following dependency to camunda (as documented in the camunda maven dependencies):
         <!-- camunda engine dependency -->
        <dependency>
            <groupId>org.camunda.bpm</groupId>
            <artifactId>camunda-engine</artifactId>
            <scope>provided</scope>
        </dependency>
 
        <!-- camunda cdi beans -->
        <dependency>
            <groupId>org.camunda.bpm</groupId>
            <artifactId>camunda-engine-cdi</artifactId>
        </dependency>
 
        <!-- provides a default EjbProcessApplication -->
        <dependency>
            <groupId>org.camunda.bpm.javaee</groupId>
            <artifactId>camunda-ejb-client</artifactId>
        </dependency>

So the EJB add each dependency to the EAR/lib folder. Now I defined the camunda-ejb-client in the taskservice as provided.

The actually generated EAR has now following content:

• EAR-Content
• Lib
• camunda-engine-cdi-7.3.0.jar
• taskservice-binding.war
• taskservice-process.war
• WEB-INF/lib
• camunda-ejb-client-7.3.0.jar
• WEB-INF/classes
• *bpmn
• META-INF/processes.xml
• taskservice-jar (ejb)
• META-INF/application.xml

Cheers,
Bernd

[Falko Menge]

I just tried Daniel's second option, i.e. adding the camunda-ejb-client as an EJB module to an EAR, and though I could share my configuration and some feedback.

I added the following dependency to the Maven pom.xml:

      <dependency>

      <!-- client for Java EE application server integration, included in WAR as an alternative to write your own ProcessApplication class -->

      <groupId>org.camunda.bpm.javaee</groupId>

      <artifactId>camunda-ejb-client</artifactId>

      <version>7.4.0</version>

        <type>ejb</type>

    </dependency>

Note: The version number of the camunda-ejb-client as <type>ejb</type> is not in the Camunda BOM.

In addition the EJB module needs to be registered in pom.xml:

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-ear-plugin</artifactId>

<configuration>

<finalName>my-ear</finalName>

<version>1</version>

<generateApplicationXml>false</generateApplicationXml>

<defaultLibBundleDir>lib</defaultLibBundleDir>

<modules>

<ejbModule>

      <groupId>org.camunda.bpm.javaee</groupId>

      <artifactId>camunda-ejb-client</artifactId>

</ejbModule>

</modules>

</configuration>

</plugin>

and application.xml:

  <module>

    <ejb>camunda-ejb-client-7.4.0.jar</ejb>

  </module>

In jboss-deployment-structure.xml nothing needs to be added, since the camunda dependencies are injected implicitly. However, the following option was set in this file:

<ear-subdeployments-isolated>false</ear-subdeployments-isolated>

[Bernd Varga]

Hi Falko,

I verified your proposal and switch the implementation to the default
ProcessApplication.

Thanks.

Cheers,
Bernd