properties = processApplication.getProperties();
properties.put(ProcessApplicationInfo.PROP_SERVLET_CONTEXT_PATH, contextPath);
}
public void contextDestroyed(ServletContextEvent arg0) {
}
}
```
Finally, the custom `ProcessArchiveServletContextListener` has to be added to your `WEB-INF/web.xml` file:
```xml theme={null}
org.my.project.ProcessArchiveServletContextListener
...
```
### Invocation Semantics of the EJB process application
The fact that the EJB process application exposes itself as a Session Bean Component inside the EJB container determines
* the invocation semantics when invoking code from the process application and
* the nature of the `ProcessApplicationReference` held by the process engine.
When the process engine invokes the EJB process application, it gets EJB invocation semantics. For example, if your process application provides a `JavaDelegate` implementation, the process engine will call the `EjbProcessApplication`'s `execute(Callable)` method and from that method invoke the `JavaDelegate`. This makes sure that
* the call is intercepted by the EJB container and "enters" the process application legally.
* the `JavaDelegate` may take advantage of the EJB process application's invocation context and resolve resources from the component's environment (such as a `java:comp/BeanManager`).
Big pile of EJB interceptors
|
\| +--------------------+
\| |Process Application |
invoke v | |
ProcessEngine ----------------OOOOO--> Java Delegate |
\| |
\| |
+--------------------+
The EJB process application allows to hook into the invocation by overriding the `execute(Callable callable, InvocationContext invocationContext)` method. It provides the context of the current invocation (e.g., the execution) and can be used to execute custom code, for example initialize the security context before a service task is invoked.
```java theme={null}
public class MyEjbProcessApplication extends EjbProcessApplication {
@Override
public T execute(Callable callable, InvocationContext invocationContext) {
if(invocationContext != null) {
// execute custom code (e.g. initialize the security context)
}
return execute(callable);
}
}
```
When the EJB process application registers with a process engine (see `ManagementService#registerProcessApplication(String, ProcessApplicationReference)`, the process application passes a reference to itself to the process engine. This reference allows the process engine to reference the process application. The EJB process application takes advantage of the EJB Containers naming context and passes a reference containing the EJB process application's Component Name to the process engine. Whenever the process engine needs access to process application, the actual component instance is looked up and invoked.
## The EmbeddedProcessApplication
**Supported on:** JVM, Apache Tomcat, Wildfly
**Packaging:** JAR, WAR, EAR
The `org.camunda.bpm.application.impl.EmbeddedProcessApplication` can only be used in combination with an embedded process engine. Usage in combination with a Shared Process Engine is not supported as the class performs no process application context switching at runtime.
The embedded process application also does not provide auto-startup. You need to manually call the `#deploy` method of your process application:
```java theme={null}
// instantiate the process application
MyProcessApplication processApplication = new MyProcessApplication();
// deploy the process application
processApplication.deploy();
// interact with the process engine
ProcessEngine processEngine = BpmPlatform.getDefaultProcessEngine();
processEngine.getRuntimeService().startProcessInstanceByKey(...);
// undeploy the process application
processApplication.undeploy();
```
Where the class `MyProcessApplication` could look like this:
```java theme={null}
@ProcessApplication(
name="my-app",
deploymentDescriptors={"path/to/my/processes.xml"}
)
public class MyProcessApplication extends EmbeddedProcessApplication {
}
```
Remember that to make a manually managed EmbeddedProcessApplication work, you will have to register your ProcessEngine on the RuntimeContainer:
```java theme={null}
RuntimeContainerDelegate runtimeContainerDelegate = RuntimeContainerDelegate.INSTANCE.get();
runtimeContainerDelegate.registerProcessEngine(processEngine);
```
## The SpringProcessApplication
**Supported on:** JVM, Apache Tomcat.
**Packaging:** JAR, WAR, EAR
The `org.camunda.bpm.engine.spring.application.SpringProcessApplication` class allows bootstrapping a process application through a Spring Application Context. You can either reference the SpringProcessApplication class from an XML-based application context configuration file or use an annotation-based setup.
If your application is a web application you should use `org.camunda.bpm.engine.spring.application.SpringServletProcessApplication` as it provides support for exposing the servlet context path through the `ProcessApplicationInfo#PROP_SERVLET_CONTEXT_PATH` property.
We recommend to always use `SpringServletProcessApplication` unless the deployment is not a web application. Using this class requires the `org.springframework:spring-web` module to be on the classpath.
### Configuring a Spring Process Application
The following shows an example of how to bootstrap a SpringProcessApplication inside a Spring application context XML file:
```xml theme={null}
```
Remember to additionally add a `META-INF/processes.xml` file.
> If you are manually managing your processEngine, you will have to register it on the RuntimeContainerDelegate as described in the EmbeddedProcessEngine section.
### Process Application Name
The `SpringProcessApplication` will use the bean name (`id="invoicePa"` in the example above) as auto-detected name for the process application. Make sure to provide a unique process application name here (unique across all process applications deployed on a single application server instance). As an alternative, you can provide a custom subclass of `SpringProcessApplication` (or `SpringServletProcessApplication`) and override the `getName()` method.
### Configure a Managed Process Engine Using Spring
If you use a Spring process application, you may want to configure your process engine inside the Spring application context Xml file (as opposed to the processes.xml file). In this case, you must use the `org.camunda.bpm.engine.spring.container.ManagedProcessEngineFactoryBean` class for creating the process engine object instance. In addition to creating the process engine object, this implementation registers the process engine with the ASEE Flow infrastructure so that the process engine is returned by the `ProcessEngineService`. The following is an example of how to configure a managed process engine using Spring.
```xml theme={null}
```