-
Bug Report
-
Resolution: Fixed
-
L3 - Default
-
7.14.3
Environment (Required on creation):
Tomcat 8 with Camunda Platform Runtime 7.14.3 in a shared Engine scenario
Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):
When deploying a Spring-based WAR to Tomcat with a process containing a Timer Start Event with an expression-based definition that contains a bean defined in the WAR, the deployment of the WAR fails with the attached exception.
Steps to reproduce (Required on creation):
- Start a Tomcat distro
- Build the minimal project [1]
- Deploy the WAR file
Observed Behavior (Required on creation):
An exception is thrown:
09-Jun-2021 14:36:50.233 SEVERE [Catalina-utility-1] org.camunda.commons.logging.BaseLogger.logError ENGINE-16004 Exception while closing command context: Unknown property used in expression: #{somebean.somemethod()}. Cause: Cannot resolve identifier 'somebean' org.camunda.bpm.engine.ProcessEngineException: Unknown property used in expression: #{somebean.somemethod()}. Cause: Cannot resolve identifier 'somebean'
Expected behavior (Required on creation):
Deployment succeeds.
Root Cause (Required on prioritization):
- During the deployment of the process application, the BPMN process is parsed
- For Timer Start Events, the job is already created when executing the DeployCmd
- This is why the expression of the Timer Start Event definition #{somebean.somemethod()} is tried to be resolved
- The Expression Language Resolver is tried to be retrieved from the process application in ProcessApplicationElResolverDelegate#getElResolverDelegate
- However, Context#getCurrentProcessApplication() is null since it was not set yet
- Reason: missing context switch into the process application before starting the deployment process
- However, Context#getCurrentProcessApplication() is null since it was not set yet
- The Expression Language Resolver SpringProcessApplicationElResolver from the WAR file cannot be retrieved to resolve the expression
- This leads to the exception shown above
Solution Idea
In AbstractProcessApplication#deploy, switch into the context of the process application with Context.setCurrentProcessApplication(getReference()) before triggering the actual deployment of the process application. Make sure to remove the current process application again after the deployment or when it failed. See solution on GitHub [2]
Hints
- This bug might also be present in other deployment scenarios.
- Think about if changing the context classloader for deployment can have unwanted side effects
[1] https://github.com/tasso94/SUPPORT-10952
[2] https://github.com/camunda/camunda-bpm-platform/pull/1489