Bug Report: EAR inter-WAR CDI Isolation Failure with 6.2025.2-6

[mkarg]

Brief Summary

The existence of one WAR within an EAR prevents CDI provider lookup within a second WAR in the same EAR.

Both WARs are not interconnected and do not share common libraries (at least they should not, as CDI separation is what 6.2025.2 pretends to fix).

As soon as the other WAR is removed from the EAR, CDI provider lookup succeeds!

Worked well in 6.2025.1, fails since 6.2025.2 (up to and including 6.2025.2-6).

This bug report is a spin-off from the discussion in #7201.

Expected Outcome

Dependency Injection works well in 6.2025.2-6, i. e. CDI lookup within WAR 1 does not interfer with CDI lookup in WAR 2, even when both WARs are found within the same EAR.

Current Outcome

If both WARs are registered as web-applications in application.xml of EAR, CDI lookup in WAR 1 does not work (will not find provider which is also contained in WAR 1).

If WAR 2 is not registered as a web-application in application.xml of EAR, CDI lookup in WAR 1 works well (finds provider).

Reproducer

reproducer.zip

Unpacking the ZIP provides the reproducer EAR.

asadmin deploy --upload quipsy-ng-ear.ear
asadmin stop-domain
asadmin start-domain
curl -v https://quipsy:8080/api/inspections/test/

This will produce HTTP status 500, and the error message is found in server.log:

WELD-001408: Unsatisfied dependencies for type DeploymentPlanX with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private de.quipsy.inspections.server.api.references.InspectionPointReference$Adapter.deploymentPlanX
  at de.quipsy.inspections.server.api.references.InspectionPointReference$Adapter.deploymentPlanX(Adapter.java:0)

        at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:367)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:285)
        at org.jboss.weld.bootstrap.Validator.validateProducer(Validator.java:414)
        at org.jboss.weld.injection.producer.InjectionTargetService.validateProducer(InjectionTargetService.java:36)
        at org.jboss.weld.manager.InjectionTargetFactoryImpl.validate(InjectionTargetFactoryImpl.java:153)
        at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:81)
        ... 71 more

Then remove this <webmodule> section...

<module>
  <web>
    <web-uri>de.quipsy.qdas.server-quipsy-qdas-server-ee-2025-SNAPSHOT.war</web-uri>
    <context-root>/qdas/api</context-root>
  </web>
</module>

...from META-INF\application.xml, undeploy and deploy again, and run curl again. Now curl returns status 200 OK, which proofs that somehow the isolation between both WARs is broken, because there is actually no interconnection between both WARs in this EAR (at least nothing that is intended). 😲

Operating System

Windows 10 Pro

JDK Version

Zulu JDK 17

Payara Distribution

Payara Server Full Profile

[lprimak]

Awesome, thank you

[lprimak]

Any chance I can get the source code for the reproducer? It's much more difficult to deal with the pre-built binary, leaves a lot of guesses. Thank you

[lprimak]

Hi,

I was able to reproduce the problem, however it's very very difficult to make progress without the source code for the reproducer.

There are no META-INF/beans.xml present in the JARs.
Please put beans.xml into META-INF/ directory in CDI JARs, like this https://github.com/flowlogix/flowlogix/blob/main/jakarta-ee/flowlogix-datamodel/src/main/resources/META-INF/beans.xml

Maybe it has something to do, it'll help me debug this.
But source code is better :)

Thank you