Timer Start Event Expression cannot be resolved in Spring Process Application

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):

1. During the deployment of the process application, the BPMN process is parsed
2. 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
3. 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
4. The Expression Language Resolver SpringProcessApplicationElResolver from the WAR file cannot be retrieved to resolve the expression
5. 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