Engine CDI module is integrated into Quarkus Extension

User Story

I can use the feature set provided by the process engine CDI integration [1].

Functional Requirements

• Associate a conversation with a process instance [2] (might not be supported via @ConversationScoped, only via @RequestScoped)
• Controll the process declaratively [3]
• Work with @BusinessProcessScoped beans [4] (might not be supported due to Quarkus CDI limitations)
• Work with built-in beans (e.g., @Inject ProcessEngine, RuntimeService, ProcessInstance, Task) [5]
• Event Bridge [6]

Technical Constraints

• Quarkus.io supports only a subset of the CDI 2.0 standard with the help of the quarkus-arc module
  • Please see the supported features [7] and limitations [8]
• Our CDI integration makes use of CDI concepts that are not supported by quarkus-arc

How we deal with limited CDI 2.0 support

• We thoroughly document to which extent and what features of the engine-cdi module work and whatnot
• We ensure that the working features are actually working by automated tests
• We provide an alternative configuration approach since the content of the beans.xml is ignored by Quarkus.io
  • beans.xml is already not the preferred way of applying configurations; the state-of-the-art way is using annotations

Potentially Problematic Limitations

Disclaimer: The following things were identified based on the quarkus-arc limitations [8] documentation and evaluating the source code of our engine-cdi module. To get full confidence in what works and whatnot, we might need to execute the test suite of the engine-cdi module against Quarkus.io.

1. The @ConversationScoped is not supported: Task forms and ConversationScopedAssociation uses it
2. Only some methods of the BeanManager are supported
3. beans.xml descriptor content is ignored
4. Passivation and passivating scopes are not supported: @BusinessProcessScoped needs to be PassivationCapable
5. Portable Extensions are not supported: ProcessEngineExtension uses the portable Extension interface
6. Implicit bean discovery: DefaultContextAssociationManager, ProcessVariableLocalMap, ProcessVariableMap, BusinessProcess, ProcessVariables
   • Explicit bean definition (annotation) on class level is missing

Solutions to mitigate limitations

• RE 1
  • Document it and describe that association works within a request context (REST API call)
• RE 3
  • Introduce configuration properties in the application.properties file to compensate what can be configured in the beans.xml file
• RE 6
  • a) Add AdditionalBeanBuildItem in Quarkus.io extension which registers the classes with missing bean definition and assigns a scope
  • b) Add bean definition directly to engine-cdi module (might break behavior)

Limitations discovered by running engine-cdi testsuite

• Most of the tests make heavy use of the @ConversationScoped bean behavior which is not supported by Quarkus.io
  • However, Quarkus.io as well as engine-cdi support @RequestScoped beans
    • This scope gets enabled e.g. when performing a REST request but also in other situations [9]
    • When activating the request context in the test suite via Arc.container().requestContext().activate(), the tests pass
• BeanManager
  • #getELResolver is called which is not supported
• The prototype is currently designed in a way that the default process engine starts automatically and cannot be replaced with a custom process engine
  • This is probably a solvable problem
• The @Alternative annotation only seems to work in conjunction with @Priority(1)
  • Might also be related to the fact that the engine-cdi module is tested against Weld 1.1 which supports CDI 1.0
• The @Specializes is not supported
  • Not used by the engine-cdi module but there is a test for it
• Quarkus.io does not assign a scope implicitly which means that all beans are ignored without a scope
  • Added @ApplicationScoped to beans without scope so that the test suite succeeds
• engine-cdi has @Qualifier annotation on @ProcessVariable and @ProcessVariableTyped which leads to auto injections when fields are annotated with these annotations
  • Auto injection for fields can be disabled with quarkus.arc.auto-inject-fields=false
• engine-cdi exposed beans have @Dependent scope by default which leads to warning logs
  • Obtained instance of @Dependent scoped bean org.camunda.bpm.engine.cdi.CurrentProcessInstance_ProducerMethod_getExecutionId_62b5049703b5a9e9ea537d15ef7a7605df494847_Bean@665d124a outside of process engine command context. Bean instance will not be destroyed. This is likely to create a memory leak. Please use a normal scope like @ApplicationScoped for this bean.

Failing tests by problem

Heads-up: failing tests might hide further problems we cannot oversee right now.

• BeanManager#getELResolver unsupported
  • ThreadContextAssociationTest.testBusinessProcessScopedWithJobExecutor
  • DmnJuelTest
  • BusinessProcessContextTest#testConversationalBeanStoreFlush
  • MultiInstanceTest
  • ElTest

Technical Requirements

• Testsuite exists which ensures our Quarkus.io extension supports the features up to a certain extent
  • Limitation of Scope
    • 1) Copy test cases to Quarkus.io extension and make them work
    • 2) Preferred way: In engine-cdi module, tests are additionally executed against Quarkus.io environment (we can exclude tests for unsupported behavior)
• Documentation exists which outlines the limitations

Further investigation necessary

• Have a look at the excluded test cases and refactor them to run under quarkus when possible
• Decide if quarkus.arc.auto-inject-fields=false should be part of the engine extension or not; what is the user impact?
• Evaluate if we can fix the unsupported BeanManager#getELResolver to allow accessing methods on beans from expressions
• Evaluate if the changed behavior of the @Alternative annotation is related to changes in the CDI 2.0 specification
• Evaluate the impact of the following Quarkus.io limitations
  • Passivation and passivating scopes are not supported: @BusinessProcessScoped needs to be PassivationCapable
  • Portable Extensions are not supported: ProcessEngineExtension uses the portable Extension interface
• Evluate the impact of missing beans.xml configuration capabilities and decide if we need an alternative solution

[1] https://docs.camunda.org/manual/7.15/user-guide/cdi-java-ee-integration/
[2] https://docs.camunda.org/manual/7.15/user-guide/cdi-java-ee-integration/contextual-programming-model/#associate-a-conversation-with-a-process-instance
[3] https://docs.camunda.org/manual/7.15/user-guide/cdi-java-ee-integration/contextual-programming-model/#declaratively-controlling-the-process
[4] https://docs.camunda.org/manual/7.15/user-guide/cdi-java-ee-integration/contextual-programming-model/#work-with-businessprocessscoped-beans
[5] https://docs.camunda.org/manual/7.15/user-guide/cdi-java-ee-integration/built-in-beans/
[6] https://docs.camunda.org/manual/7.15/user-guide/cdi-java-ee-integration/the-cdi-event-bridge/
[7] https://quarkus.io/guides/cdi-reference#supported_features
[8] https://quarkus.io/guides/cdi-reference#limitations
[9] https://docs.jboss.org/cdi/api/2.0/javax/enterprise/context/RequestScoped.html