The engine-cdi module defines the custom annotations @ProcessVariableTyped and @ProcessVariable. It can be used in two ways:
- Accompanied with the @Inject CDI annotation on a field, the value of the variable by name defined by #value or member name is injected
- When a StartProcessInterceptor assigns a value to a field annotated with the aforementioned annotations, and without @Inject, a new variable is created
The first case is not problematic for the Quarkus extension. However, the second case conflicts with the default Quarkus behavior: it tries to inject beans since the aforementioned annotations get in turn the annotation @Qualifier dynamically (implicitly) assigned. This breaks the engine-cdi behavior.
- Disable auto-inject-fields in the extension
- Pros: engine-cdi behavior works out of the box
- Cons: The configuration changes the default behavior for the entire application (including all extensions)
- Users might find it annoying that their business logic does not work anymore after adding the Camunda extension, or even worse: users don't use the Camunda extension because it changes the default behavior of Quarkus
- Document that there is only full support for the StartProcessInterceptor if auto-inject-fields is disabled; by default, this property is enabled
- Pros: When adding the Camunda extension, the previously created business logic continues to work; the user can decide on their own if enabling the configuration makes sense or not
- Cons: The aforementioned problem occurs under the circumstances described
- Remove @Qualifier annotation from @ProcessVariableTyped and @ProcessVariable
- Pros: Both weld and quarkus test suites are successful independently of the auto-inject-fields configuration
- Cons: Removing the @Qualifier annotation from the annotations is against the CDI specification; while Weld 1.0 is graceful in this regard, we might face problems when we ever update to a newer Weld version or use another CDI implementation
- Configure quarkus to exclude only these annotations with the help of an AnnotationsTransformer
- Pros: Default behavior must not be changed
- Confusing because annotation behavior is not consistent.
- Leads to additional implementation and test effort.
- Might break unrecoverable in future Quarkus releases if they change the behavior of the AnnotationsTransformer.
- Forcing the user to change the already created business logic to use the Camunda extension is frustrating (solution #1).
- Removing the @Qualifier annotation might have side effects that we cannot foresee currently (solution #3).
- Configuring quarkus to exclude only the problematic annotations is inconsistent and extra effort while we are not aware of if the users actually want to use it (solution #4).
Before we build something inconsistent like solution #4, let's wait for user feedback. We can still build solution #4 if we see a demand for it. Until then, we will document the limitation. When we don't manage to complete the subtask CAM-13770 within the 7.16 release cycle, we convert it at the end of the project from a sub-task to a bug report.