I’m currently in the process of porting an existing project from Camunda 7.18 to Operaton 2.0.0-M3 to make it fully Jakarta EE compliant. However, I’ve hit a brick wall regarding CDI injections on WildFly and could really use some help.
My Setup:
Operaton 2.0.0-M3
Vaadin 24.9.11
Java 21
Standard WAR deployment
The Issue: When deploying the application, the WeldStartService fails to start with multiple exceptions. CDI cannot resolve any of the standard engine services. For example: WELD-001408: Unsatisfied dependencies for type TaskService with qualifiers @Default at injection point...(This happens for IdentityService, RepositoryService, RuntimeService, etc. as well).
What I’ve configured/verified so far:
Dependencies: I am using standard Jakarta EE @Inject in my beans.
Modules: I have a jboss-deployment-structure.xml in WEB-INF that explicitly exports org.operaton.bpm.operaton-engine and org.operaton.bpm.wildfly.operaton-wildfly-subsystem. WildFly resolves these modules successfully (no ModuleNotFoundException).
Process Application: My custom application class extends JakartaServletProcessApplication and is annotated with @ProcessApplication("GUIDEMO"). The deployment scanner detects it successfully.
The Clue in the Server Log: At the very end of the failed deployment, WildFly reports that a specific subsystem service is missing, which seems to prevent the CDI bridge from establishing:
Plaintext
WFLYCTL0184: New missing/unsatisfied dependencies:
service org.operaton.bpm.platform.process-application-module."deployment.opv-demo.war".NO_VIEW (missing)
dependents: [service org.operaton.bpm.platform.process-application-module."deployment.opv-demo.war".START,
service org.operaton.bpm.platform.process-application-module."deployment.opv-demo.war".STOP]
It feels like the CDI bridge from the Operaton subsystem is not registering the beans properly in the WildFly 38 environment.
Is this a known limitation/bug in the 2.0.0-M3 release? Or has the configuration to expose the engine services to CDI changed in the new Jakarta EE environment compared to Camunda 7.x?
Any hints or workarounds would be greatly appreciated. I’m out of ideas!
A naked WAR project with only operaton-engine (provided) and operaton-engine-cdi (compile) dependencies.
A beans.xml (version 4.1).
A jboss-deployment-structure.xml explicitly exporting org.operaton.bpm.operaton-engine and org.operaton.bpm.wildfly.operaton-wildfly-subsystem.
An empty processes.xml.
A simple Servlet trying to inject the engine: @Inject private IdentityService identityService;
The Error: The deployment completely fails. The WeldStartService crashes because it cannot find the CDI beans provided by the engine:
Plaintext
WELD-001408: Unsatisfied dependencies for type IdentityService with qualifiers @Default at injection point...
However, the root cause seems to be located deep within the Operaton WildFly subsystem integration. At the end of the log, WildFly complains about a missing internal service:
Plaintext
WFLYCTL0412: Required services that are not installed:
["org.operaton.bpm.platform.process-application-module.\"deployment.opv-cdi-test.war\".NO_VIEW"]
WFLYCTL0180: Services with missing/unavailable dependencies:
service org.operaton.bpm.platform.process-application-module."deployment.opv-cdi-test.war".START is missing [org.operaton.bpm.platform.process-application-module."deployment.opv-cdi-test.war".NO_VIEW]
Exhaustive Debugging we already tried (none of which worked):
Changing the @ProcessApplication class from @ApplicationScoped to an EJB (@Singleton, @Startup) to force WildFly to spawn the NO_VIEW component.
Removing the @ProcessApplication class entirely.
Writing a custom CDI @Produces method to bypass the subsystem CDI producers.
In all cases, the Operaton subsystem aggressively looks for the WildFly-internal NO_VIEW service, fails to find it, and blocks the entire deployment and CDI initialization.
It looks like the subsystem component-lookup is incompatible with how WildFly 38 handles Jakarta EE 11 deployments. Is this a known bug in the 2.0.0-M3 release? Is there any workaround available, or will this be addressed in M4?
I can provide the zipped 10KB MRE project if needed.
If I completely delete the processes.xml and the @ProcessApplication class, and write my own CDI @Produces method to fetch the IdentityService manually, the WAR deploys perfectly fine. No NO_VIEW errors, no WELD errors.
This leads me to believe that CDI and Java 21 are working fine, but as soon as the Operaton WildFly Subsystem deployment processor detects a process application (via processes.xml), it tries to attach to the NO_VIEW service. It seems this service either behaves differently or is no longer exposed in the same way in WildFly 38 / Jakarta EE 11.
Is this a known incompatibility with the M3 release? Are there any configuration workarounds to get the subsystem to start properly, or will this be addressed in M4?
I am happy to provide my zipped MRE project if it helps with debugging.
To verify if this is an Operaton-specific issue, I ran the exact same minimal test setup against the original Camunda 7.24 Engine on WildFly 37.0.0.Final (using Jakarta EE 10). It produces the exact same NO_VIEW crash and WELD-001408 error. This means the bug was inherited from upstream Camunda 7 and the camunda-wildfly-subsystem. The subsystem’s deployment processor relies on a NO_VIEW service that modern WildFly versions do not seem to expose for standard Jakarta CDI deployments.
fixed the problem. Stupid typo in my HelperClass…… I miss my colleague Stephan for pair-programming
and here my fix
@ApplicationScoped
public class OperatonProducer { @Produces
public IdentityService produceIdentityService() {
ProcessEngine engine = ProcessEngines.getDefaultProcessEngine();
return engine != null ? engine.getIdentityService() : null;
}
}
Proposed Fix for M4: Please ensure that the operaton-engine-cdi artifact is fully compatible with CDI 4.1 discovery rules (e.g., adding bean-discovery-mode="all" to its beans.xml or ensuring all producer classes have the correct bean defining annotations like @Dependent or @ApplicationScoped).
Thanks, this will help debugging this problem. It’s great to see more WildFly users in the Operaton community. Most installations i know of run on one of the other integrations — especially Spring Boot — which means issues there tend to surface earlier simply due to the larger user base.
Feedback from WildFly setups is therefore especially valuable for us, as it helps ensure all supported runtimes stay reliable and well-maintained. Please keep sharing your findings.
Many thanks for the support so far. However, in a real-world scenario, we are still facing a persistent issue. I applied your latest fix and built a custom WildFly distribution, but the injection only works if I manually include a jboss-deployment-structure.xml in the deployment.
I have experimented with the module code and various adjustments to the Deployment Unit Processors, but unfortunately without success in achieving a native ‘Zero-Config’ integration. It seems that without the explicit export directives in the deployment metadata, the CDI beans remain invisible to the application.
Hi @dieter12, thanks for mentioning the issue and digging into the wildfly distro!
I thought about this, and I wondered why the engine-cdi dependency was not put into the Wildfly distro by Camunda, in the end we just kept the mechanisms they built.
I think the reason could be that CDI scans for beans in the deployment itself. As classes provided by a Wildfly module are not part of a deployment, the necessary producers wouldn’t be discovered by your application. Also, scopes like @RequestScoped or @ConversationScoped which we both use are managed by the deployment and would not work on a module level. Currently I don’t see how we could make it work to put operaton-engine-cdi into the Wildfly model.
Many thanks for the feedback! I understand the concerns regarding deployment-bound scopes like @RequestScoped. However, from a Jakarta EE perspective, this is exactly what a WildFly subsystem is designed to handle.
The goal is to have the subsystem inject the operaton-engine-cdi module as an implicit bean archive into the application’s CDI context. This would allow the producers to be discovered while the actual bean instances remain managed within the deployment’s own scope.
I have documented the behavior where the injection currently only succeeds with a manual jboss-deployment-structure.xml. This confirms that the classes are technically compatible with the container; it is simply the automatic discovery and visibility that is currently missing in the subsystem’s DeploymentUnitProcessor.
I’ve shared a minimal reproducer on GitHub that highlights this gap. It would be great if we could find a way to make the subsystem ‘CDI-aware’ so that users can enjoy a true ‘Zero-Config’ experience on WildFly 38."
Hi, thanks for the clarification, now I understand.
I’m not that deep into Wildfly, but searched around a little. It seems like this code takes care of registering the other dependencies in the process applications while they deploy. I think you are way more knowledgeable in Wildfly than I am, could we add operaton-engine-cdi here, too?
Thanks for the feedback! I understand the concerns regarding deployment-bound scopes like @RequestScoped. However, my tests with a manual jboss-deployment-structure.xml prove that WildFly handles this architecture perfectly: the producers stay in the module, while the bean instances and their scopes are managed within the application’s context.
I am currently working on a local branch to automate this visibility within the ModuleDependencyProcessor. Since its priority is 0x2300, it runs well before the Weld scan, which should allow us to achieve a true ‘Zero-Config’ experience for WildFly 38.
I will test the implementation locally—including the necessary beans.xml requirements for Jakarta EE —and will get back to you with the results once I’ve verified the fix."