Bug Report: CDI deployment failure for 6.2025.2 #7201
Comments
RInverid
added
Status: Open
|
|
|
No I am not able to build a small reproducer, I tried recreating the structure of my project but I have no idea what the issue could be, so not really able to produce any results |
|
I can try running your app if that's at all possible. Is it using containers at all? |
|
Is your app a WAR or EAR? Can you post a "file tree" from the WAR file? |
|
Hi, sorry for forgetting to respond. Yeah, sharing the ear isn't an option sadly, but I can share the file tree for the ear. I'll be anonymising some stuff, is there anything specifically you're looking for? |
|
Can you try the fix in #7211 please? You can try either building the branch / PR or get the pre-built here: |
|
sadly looks like the same issue is still present:
I tried attaching a debugger, and saw that the DeploymentImpl constructor has a return on line 168, if libJarRootBDAs is not empty. This is the case for our project, which causes the deploymentImpl constructor to not run any code that sets the contextId. Does this info help? do you need to me to look at anything else? |
|
Hi. I have the exact same problem with one of our deployments. My analysis of the problem matches with that of @RInverid |
|
We also have massive problems deploying our EAR (containing lots of WARs) on 6.2025.2, while 6.2025.1 was pretty fine. Edit: We also have the problem that if we succeed to deploy on 6.2025.2 (after many attempts and very long waiting, it works "eventually"), then at some point we fail to
|
|
Hi. For my deployment this fix sadly does not work. I am getting the same deployment error as for #7214: |
|
@lprimak I built it myself by checking out flowlogix:fix-cdi-context-npe and merging in flowlogix:fix-deployment-bugs. Sadly, it did not work - with a different error:
Again, sorry for not being able to share a reproducer, but if I can help in any way by debugging & gathering more info, or sharing the file structure of our ear, I would be more than glad to help. |
|
Please share file structure. Thank you |
|
I just checked. You can also see the exact same problem when you try to deploy the reproducer from #7214 Hope this helps. |
|
I have to build the Payara build myself, I just took #7211 and #7212 and merged them just like last time. Sadly I got the same stack trace:
For the ear file structure, a shortened summary:
|
|
@RInverid Thank you for the update. Will keep working on it. Can I get a more detailed summary? Perhaps output of Thank you |
|
am sorry for the bit of a short-term pain, but in the long-term, this is leading to #7165 performance, |
|
Good news is that with @TheOnlyAl 's reproducer, I can see your initial error, and that the changes do fix it. I will close the initial PR and incorporate all the fixes into a single PR. Still work in progress, but progress is finally being made I think... he he |
|
I just built #7212, I assume thats the branch you mean. Failed again in new unique ways, 4 different stacktraces that seem relevant, so I collected them in a gist: https://gist.github.com/RInverid/1a923ed6764cf827090ae97305a2530d Sorry about the more detailed overview, can't do that. I can show an example unpacked war: |
|
I have another fix pending. Getting close I think |
|
It works! :o fantastic, thanks for your hard work |
|
#Awesome! Now I can finally get back to performance PR :). Thank you for your help. |
The exact same EAR worked fine on 6.2025.1, but it still fails on 6.2025.2-6 (!). So it seems, this still is related to the 6.2025.2-CDI-changes, but unrelated form @lprimak's already fixed bugs. Shall we enable some particular logger or run a particular test drive? 🤔 |
|
I think reproducer is key here. Also I think there is a special meaning in Payara with "DeploymentPlan". Can you rename the bean to see if that helps? |
|
@mkarg you should open a separate bug for this, since there is no reproducer (yet, I hope) |
|
@mkarg So here is my idea... Old code did not do this, and "mashed" all the CDI beans together in the same EAR, even if they are present in separate WARs. Due to this, "old code" could see beans from one WAR to another. My guess is that your code is using this "bug" / old behavior to rely on seeing all the beans in the EAR, even the ones you are not supposed to. |
|
Renaming of both, injected POJO and injection point, did not change the behavior. Yes, the EAR actually contains many WARs, but thanks to the renaming the problem also happens when injected POJO, its CDI producer, and the CDI injection target live in the very same WAR -- and only in that one. Still the problem occurs though. It might be related to that idea anyways: Inside the WAR, no classes exists, but all classes live in separate JARs inside the lib folder of that very WAR. Maybe you changed something in that area, too, which now separates the producer libs from the injection target libs? Anyways, will set up a reproducer tomorrow and open a separate ticket for this. |
|
Thank you! Appreciate it. |
|
Still working on the reproducer, and the situation is rather weird: As soon as I simply remove all other WARs from the EAR but keep solely the failing one, it starts working perfectly and the error is gone completely! This proofs that the bug indeed is related to the "mixing CDI among WARs" paradigm, but apparently in the reverse direction: The EAR wants separated namespaces, but 6.2025.2-6 mixes them?! 😲 |
Brief Summary
deployment failure because some internal string is unexpectedly null:
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:Cannot invoke "String.contains(java.lang.CharSequence)" because "beanArchiveId" is null -- Cannot invoke "String.contains(java.lang.CharSequence)" because "beanArchiveId" is null at org.jboss.weld.bootstrap.BeanDeployments.getFinalId(BeanDeployments.java:39) at org.jboss.weld.bootstrap.WeldStartup.startContainer(WeldStartup.java:189) at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:73) at org.glassfish.weld.WeldDeployer.startWeldBootstrap(WeldDeployer.java:578) at org.glassfish.weld.WeldDeployer.processApplicationLoaded(WeldDeployer.java:533) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:422) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:135) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:344) at com.sun.enterprise.v3.server.ApplicationLifecycle.prepare(ApplicationLifecycle.java:580) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:570) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:556) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:552) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at java.base/javax.security.auth.Subject.doAs(Subject.java:376) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:551) at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:582) at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:574) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at java.base/javax.security.auth.Subject.doAs(Subject.java:376) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:573) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1497) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1879) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1755) at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.executeCommand(CommandExecutorImpl.java:183) at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.run(CommandExecutorImpl.java:96) at fish.payara.boot.runtime.BootCommand.execute(BootCommand.java:69) at fish.payara.boot.runtime.BootCommands.executeCommands(BootCommands.java:166) at fish.payara.boot.runtime.BootCommands.executeCommands(BootCommands.java:160) at com.sun.enterprise.v3.bootstrap.BootCommandService.doBootCommands(BootCommandService.java:81) at com.sun.enterprise.v3.bootstrap.BootCommandService.postConstruct(BootCommandService.java:91) at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:303) at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:351) at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:466) at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:281) at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:65) at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2103) at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93) at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:67) at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1213) at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1144) at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneLevel.run(CurrentTaskFuture.java:762) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:840)Looks like this might've been introduced by #7032 @lprimak
Expected Outcome
My app deploying normally, as it would on 6.2025.1
Current Outcome
Deployment failure
Reproducer
TBD, will work on creating one
Operating System
Debian Linux 12
JDK Version
OpenJDK 17
Payara Distribution
Payara Server Full Profile
The text was updated successfully, but these errors were encountered: