@Dependent scoped beans in EL expressions are prematurely destroyed with Weld versions > 1.1.4

Problem

• When using a @Dependent scoped bean in an EL expression, the bean is destroyed while it is still in use; i.e. given an expression ${foo.bar()}, #bar is invoked after foo is destroyed
• Problem occurs with Weld versions > 1.1.4
• E.g. JBoss 7.2 uses Weld 1.1.10; Wildfly probably uses newer versions

Reason

• Weld 1.1.5 fixes a bug that enables the ELResolver obtained via BeanManager#getELResolver to resolve @Dependent scoped beans (see WELD-1280 in links below)
• Before that fix, Weld would throw an IllegalStateException that we catch in our Cdi EL resolver, confer https://github.com/camunda/camunda-bpm-platform/blob/master/engine-cdi/src/main/java/org/camunda/bpm/engine/cdi/impl/el/CdiResolver.java#L61-L70
• In case of the exception, we manage the bean creation ourselves (and ultimately destroy the bean at the end of the engine command); see catch block
• The WELD-1280 fix lets any @Dependent scoped bean be destroyed before the ELResolver invocation finishes (because then the reference is out of Weld's hands)

My interpretation:

• I think we are using the CDI API incorrectly here. It appears that BeanManager#wrapExpressionFactory is exactly made for this case, i.e. it wraps a given expression factory such that any expressions produced make sure that a creational context is created for the entirety of the EL invocation => we should wrap our expression factory this way
• This proposed fix is not trivial because
  • We do not use javax.el.ExpressionFactory in our code base but include use our own org.camunda.bpm.engine.impl.javax.el.ExpressionFactory
  • I think this requires to have one expression factory per process application (assuming different applications have different bean managers???), whereas we are currently using one expression factory per process engine
• Thus, a pragmatic way could be to always look up beans "our" way (catch clause in https://github.com/camunda/camunda-bpm-platform/blob/master/engine-cdi/src/main/java/org/camunda/bpm/engine/cdi/impl/el/CdiResolver.java#L61-L70); not sure if that breaks anything else, though

Related links:

• https://forum.camunda.org/t/problem-in-handling-of-dependent-cdi-beans/4224
• https://github.com/weld/core/commit/f68a4d83c75345eade7adedcf522a821703ae6bd
• https://issues.jboss.org/browse/WELD-1280