WAR packaging, CDI lookup of JPA unit fails when in separate jars

[glassfishrobot]

I have 3 modules: 1. JPA module 2. EJB module with META-INF/beans.xml, with 2 EJBs: one uses @Inject to inject EntityManager to an EJB, another using @PersistentContext; there is a class with a producer field annotated @Produces @PersistentContext to adapt 'old-style' resource injection to CDI 3. webapp that bundles the modules in WEB-INF/lib as siblings, and contains a servlet that uses EJBs from module #2, injected by @EJB

Invoking the bean that uses @Inject to inject EntityManager results in this at runtime:

org.jboss.weld.NullInstanceException: WELD-000044 Unable to obtain instance from org.jboss.weld.bean-/home/rafal/Apps/glassfishv3/glassfish/domains/domain1/applications/TestWEB/-ProducerField-com.test.ejb.EntityManagerProducer.entityManager

Sibling EJB in module #2 that uses @PersistenceContext for injection works fine, so the JPA unit is deployed correctly and can be found.

When all classes / resources are packaged inside WEB-INF/classes, all works fine. However, this puts big restrictions on application packaging and doesn't support what the specs mandates (CDI and JPA modules within WEB-INF/lib of a WAR).

Setting this to P1 as this prevents us from packaging and deploying the application using the new WAR deployment.

A post about the issue can be found here: http://forums.java.net/jive/thread.jspa?threadID=75932&tstart=75

Environment

Operating System: All Platform: All

Affected Versions

[V3]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/11653
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @sivakumart
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented jpleed3 said: Is this a duplicate of or related to https://glassfish.dev.java.net/issues/show_bug.cgi?id=11640?

[glassfishrobot]

@glassfishrobot Commented jhasenbe said: Add me on CC

[glassfishrobot]

@glassfishrobot Commented szczyp said: I am not sure, the author there writes that if the producer and the injection point are in the same module, it works. My producer and injection points are in the same ejb.jar, and it still doesn't work for. The class that produces the JPA context is not an EJB though, but the specs don't require that. I would say it is not the same, but related. The error number and runtime behavior looks exactly the same, though.

Later I will upload my application as I don't have it handy right now, so that it can be tested.

[glassfishrobot]

@glassfishrobot Commented szczyp said: I re-read the topic by the author of https://glassfish.dev.java.net/issues/show_bug.cgi?id=11640 and I saw this: "If I move the producer and qualifier into the war's classes, then @Dependent works fine." This would imply that the EJBs / managed beans are in WEB-INF/classes. Mine are in a separate ejb.jar. I wrote in the initial bug report that when I package everything in WEB-INF/classes, it works. Packaging every module as a separate jar inside WEB-INF/libs is the problem for us, as this is how our application is structured - the webapp will only contain basic servlet(s) that use(s) beans from other modules.

[glassfishrobot]

@glassfishrobot Commented szczyp said: Created an attachment (id=4257) test case

[glassfishrobot]

@glassfishrobot Commented szczyp said: Added the test case. Notes:

• these are 3 Eclipse project (developed in 3.6 M5)
• JPA unit uses the default 'jdbc/__default' DataSource, and specifies that the database schema be created on start, so making sure the bundled JavaDB is running should be enough to be able to start the app
• when deployed and run from Eclipse, the context root is 'web' and there is a welcome file 'test'; also the only servlet is mapped to '/test', so going to 'http://localhost:8080/web' should work
• the servlet presents 2 links: 'plain' and 'cdi', and after clicking the link it uses the chosen @EJB; 'plain' uses @PersistentContext and 'cdi' uses @Inject
• the producer and injection point have no qualifier by default, but I also created one that I commented out - using it doesn't change anything, I just wanted to test it
• the 'plain' bean works fine, 'cdi' results in an error mentioned in the initial bug report

Hope it is helpful.

[glassfishrobot]

@glassfishrobot Commented rogerk said: Can you please provide built archive(s) (war/jar/ear)? Thanks for providing source.

[glassfishrobot]

@glassfishrobot Commented szczyp said: Created an attachment (id=4260) war file

[glassfishrobot]

@glassfishrobot Commented szczyp said: I attach the war file. As additional input, it has been tested on a Linux machine (Ubuntu 9.04 x86-64) and multiple windows machines (one Windows Vista, 3 distinct XPs, all x86).

[glassfishrobot]

@glassfishrobot Commented rogerk said: 3.1

[glassfishrobot]

@glassfishrobot Commented domdorn said: Created an attachment (id=4350) Another example webapp;

[glassfishrobot]

@glassfishrobot Commented rogerk said: Hello Siva -

Can you take a look at this issue?

[glassfishrobot]

@glassfishrobot Commented szczyp said: Hi. I just noticed that this issue is rescheduled to 3.1; I also took a peek at the roadmap, and I am very surprised - 3.1 has scheduled 'Go / No go' on 14.12.2010 - a long time from now. Don't you think that providing a working version of CDI should be done sooner? CDI seems and feels a crucial part of the new Java EE 6 ecosystem, has been announced 'the next big thing' and is considered to be just that by many. But it doesn't work. I am a little afraid to use such big words, and I don't want to offend anyone, but such CDI / Weld integration related bugs make 3 Final / 3.0.1 completely unusable. This also means that CDI would start working a year and 4 days after GF 3 has been first announced final. This issue is of utmost importance for us, that's why I would humbly like to rise the priority to what it was in the very beginning. Regards.

[glassfishrobot]

@glassfishrobot Commented rogerk said: OK fair enough. We will evaluate this and see if we can get it into 3.0.1.

[glassfishrobot]

@glassfishrobot Commented jhasenbe said: Hi, I can only add my strong support to the opinion expressed by szczyp. Being able to deploy a JEE 6 application with regular CDI stuff to Glassfish seems like a natural thing and one of the big promises of JEE 6. We have already planned for such an application to become productive by September this year with GF 3.0 (assuming that GF acting as reference implementation for JEE 6 is way ahead of competitors). Waiting for GF to become available is not an option and we would be sadly forced to look for other container providers and drop GF for the time being. I personally would love to see GF 3.0 fulfill our requirements which are just plain simple Java EE 6 support. For the time being, we can work around the described CDI integration bug. But if you move the bug fix to GF 3.1, I am really sorry to say that we would need to drop GF as deployment option.

So please do consider moving a fix to 3.0. If we can be of any help, please let us know.

Thanks a lot and best regards, jhasenbe

[glassfishrobot]

@glassfishrobot Commented choicegh said: I too would like to see this issue be fixed much sooner rather than later. This is basic JEE6 functionality. I am now having to develop in an alternate manner to work around this when I should not have to.

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: szczyp: you mentioned when packaging everything in WEB-INF/classes, it worked. Can you share the application packaged that way? I was trying to repackage the application by putting everything under WEB-INF/classes (I wanted to compare the code paths to see why one worked and the other did not work), and the repackaged application did not work for me either. Wondering what I did differently in the repackaging.

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: add myself to Cc

[glassfishrobot]

@glassfishrobot Commented szczyp said: Created an attachment (id=4365) working war packaging

[glassfishrobot]

@glassfishrobot Commented szczyp said: I added the working war packaging requested. The zip contains the exported (in Eclipse) WAR and the source code. I didn't do much really - it is enough to simply move the source packages from TestJPA and TestEJB to TestWEB and it works for me.

[glassfishrobot]

@glassfishrobot Commented szczyp said: Created an attachment (id=4372) corrected test case

[glassfishrobot]

@glassfishrobot Commented szczyp said: Hi again. I am sorry, but the previous test case didn't work. I hasted it a little bit. This one should do it. The problem were the descriptor files: persistence.xml must be in WEB-INF/classes/META-INF (strange path, but dictated by the specs) beans.xml must be in WEB-INF

Now this should work. Sorry for the previous attachment.

[glassfishrobot]

@glassfishrobot Commented @sivakumart said: Thanks szczyp for reporting the issue and providing a good test-case to reproduce the issue. While debugging this issue I found out that we successfully process the EntityManagerReference related InjectionTarget but still miss it later. This has been found to be due to an error while we merge EntityManagerReferenceDescriptors in WebFragmentDescriptors and have a patch that fixes this issue. With this change, the application in the bug report works fine(Injection of EntityManager and the producer field for CDI are working).

This issue would now be fixed in 3.0.1 and in the trunk. Thanks again for all your support in this issue

[glassfishrobot]

@glassfishrobot Commented @sivakumart said: Created an attachment (id=4373) Patch to fix this issue

[glassfishrobot]

@glassfishrobot Commented szczyp said: Hi. Thank you for looking into this. I downloaded, however, glassgish 3.0.1.snapshot from here: http://dlc.sun.com.edgesuite.net/glassfish/v3.0.1/nightly/glassfish-3.0.1-b19-05_21_2010.zip dating to May 21., but this build was created after the comment about fixing the issue (right after I read the comment I wanted to test it and the last build was May 2., so it wasn't there yet. Is it supposed to work in the snapshot already?

[glassfishrobot]

@glassfishrobot Commented szczyp said: I meant to say that right after the comment the latest build was May 20., so May 21. was created after the comment. Sorry for the typo.

[glassfishrobot]

@glassfishrobot Commented @sivakumart said: szczyp: Please use Sunday's nightly for verifying the fix. I had checked in the fix into the trunk and the 3.0.1 branch only today [commit revisions 37186 and 37185]. If you want a fix earlier than that, you can apply the patch or check out latest workspace and build. Hope this helps.

Closing this issue as fixed as we checked in the patch as part of commit revisions 37186 and 37185.

[glassfishrobot]

@glassfishrobot Commented szczyp said: I tested it today and it works fine with the build from 25.05. Thanks for the effort to fix it.

[glassfishrobot]

@glassfishrobot Commented @sivakumart said:

• • • Issue 11640 has been marked as a duplicate of this issue. ***

[glassfishrobot]

@glassfishrobot Commented File: test.zip Attached By: szczyp