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

[mkarg]

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

Please find attached R.zip containing the source code so no more guessing needed. Please don't mind that it might not actually build using Maven, as I had to quickly strip it from lots of unrelated POM modules, Company POM, and POM dependencies, which are unrelated with the reproducer but de facto closed-source (so I may not share those stripped parts). I might have broken POM syntax by doing so. But the hierarchy itself is correct, and the Java files are the original ones.

R.zip

[mkarg]

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

Actually there are META-INF/beans.xml in the JARs, I just double checked that. The sole JAR missing it (intentionally) is the one with api in its name. That one just contains a single interface, so no beans.xml makes sense there, as that JAR does not hold any beans.

[lprimak]

I'll try it. Actually, I tried to create my own reproducer, following your layout, but it didn't reproduce, so I will try again

[lprimak]

I found the issue. It's in Jax-RS integration modules.
After lots of experimentation, I have something already running on my machine...
Thinking I'll be your hero once again :)

[mkarg]

Thinking I'll be your hero once again :)

You are, definitively! 🦸‍♂ I even have big hopes that you might be the one solving my next issue... #7234 😃

[lprimak]

Don't want to get your hopes up for #7234 Markus. My plan for the year is to finish #7165 and take a long Payara vacation, probably for the rest of 2025. #7165 was supposed to be done in December, and it's now almost mid-March and it's nowhere near done.

After that long break, I plan to work on Apache Shiro, FlowLogix / Jakarta EE Starter, or something completely different to maybe make me some $$
I've got a million things in the pipeline that I have to publisize, so probably will do some marketing mostly for 2025.

I am sure I will be involved in some Payara work, but not much / primary / priority, unless they make me an offer I can't refuse :)

[lprimak]

Try https://nexus.hope.nyc.ny.us/repository/maven-releases/fish/payara/distributions/payara/6.2025.2-7/payara-6.2025.2-7.zip please

[mkarg]

Don't want to get your hopes up for #7234 Markus.

Didn't want to put you under pressure, Lenny, just wanted to express my gratitude for your great work, which I really do appreciate. Take all the time you need, and be assured, you will be very welcome if / once you're back at Payara!

[mkarg]

Try https://nexus.hope.nyc.ny.us/repository/maven-releases/fish/payara/distributions/payara/6.2025.2-7/payara-6.2025.2-7.zip please

Wow, great! 🤩 Will test it ASAP. Unfortunately I am out of office today, so it might need until Monday to give feedback.

[mkarg]

Try https://nexus.hope.nyc.ny.us/repository/maven-releases/fish/payara/distributions/payara/6.2025.2-7/payara-6.2025.2-7.zip please

Did just a very quick test, but as far as I can tell, the original application is not failing anymore. The bug seems to be gone. Will do an intensive test on Monday, but I do not expect it to fail. Good job! 👍

[mkarg]

Correcting myself. No need for deeper tests on Monday. Just found a simple trick to let our business application test itself completely (like a macro). So I can already give the final answer: Your fix definitively works like a charm! 🚀

[lprimak]

System test? End to end test? That's great. Glad I could help.

[lprimak]

What really helped is the reproducer. I could have been looking for a bug in WAR/EAR/ CDI integration until I was blue in the face when the bug was really an old Jax-RS/CDI integration bug.

[mkarg]

System test? End to end test? That's great. Glad I could help.

I performed an end-to-end test of the real business application with real data. Due to its use case, a single REST request invokes virtually 99% of all endpoints in turn, rendering a compount response. Therefore I can safely say: All is fine now! :-)

[mkarg]

What really helped is the reproducer. I could have been looking for a bug in WAR/EAR/ CDI integration until I was blue in the face when the bug was really an old Jax-RS/CDI integration bug.

It took me 16 hours to set it up, but it was worth it. I had to strip from an EAR approx. 50 WARs containing hundres of endpoints to finally find those two WARs that I have to keep... 😅

[lprimak]

Wow. So glad it worked out

[mkarg]

Wow. So glad it worked out

Happy that you found a solution! 😄