[GLASSFISH-18802] Wrong beans.xml associated with bean deployment archive Created: 13/Jun/12  Updated: 29/Mar/13  Resolved: 29/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: titmus Assignee: jwells
Resolution: Fixed Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bit
JDK 1.6.0_29


Attachments: Zip Archive beansxml.zip    

 Description   

I had an issue whith interceptor activation for CDI beans. I investigated the issue and found that GlassFish associates wrong beans.xml resource with bean deployment archives. This causes Weld to think that interceptors for BDA are not enabled because provided beans.xml has no interceptors enabled (although beans.xml in BDA has them enabled).

The cause of this is the way GlassFish constructs URL for beans.xml which is then passed to org.jboss.weld.bootstrap.WeldBootstrap.
Method handleEntry in class org.glassfish.weld.BeanDeploymentArchiveImpl constructs the URL as follows:

URL beansXmlUrl = Thread.currentThread().getContextClassLoader().getResource(entry);
wUris.add(beansXmlUrl.toURI());

In case of web application with multiple bean archives located in WEB-INF/lib it loads the same beans.xml for all bean archives (the first one found). That's beacuse there is one class loader for whole web application. There are no separate classloaders for specific archives in WEB-INF/lib. The entry in all cases is "META-INF/beans.xml", so the classloader always loads the same resource.

I attached a test case which demonstrates this bahaviour.
Commenting out the fragment

.addAsLibrary(
    ShrinkWrap.create(JavaArchive.class, "lib1.jar")
           .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
)

makes it pass.



 Comments   
Comment by pgliznie [ 11/Jul/12 ]

We have the same issue. Our EAR has the following structure:

app.ear
+lib
 +beans1.jar [bean archive]
 +beans2.jar [bean archive]
 +... other-libs.jar [no bean archives]
+ejb.jar [bean archive]
+web-app1.war [bean archive]
+web-app2.war [bean archive]
+web-app3.war [bean archive]
+web-app4.war [bean archive]

Our Interceptor and InterceptorBinding are in ejb.jar. The interceptor is enabled in beans.xml in web-app1.war and there is the class annotated which method calls we try to intercept. The application starts, there are no errors but the interceptor doesn't work. Changing the enabled interceptor in beans.xml to some non-existant class doesn't produce error messages. Only adding any interceptor to the beans.xml in beans1.jar works - it seems only this beans.xml is loaded.

Comment by thilian [ 08/Aug/12 ]

We experience a similar thing in 3.1.1.

app.ear
+lib
 +beans.jar
+ejb1.jar
+ejb2.jar
+ejb3.jar

All are bean archives.

We have an interceptor with binding defined in beans.jar. It is also enabled in beans.xml of beans.jar. We have interceptor binding annotations on beans in all archives, and they all work, even though they are not enabled in any other beans.xml.

We now created a new interceptor with binding defined in ejb1.jar. We enabled it in ejb1.jar's beans.xml, but it it totally ignored. Only the interceptor enabled in beans.jar in actually working, regadless of what we write in ejb1.jar's beans.xml.

Comment by Piotr Kulasek [ 07/Feb/13 ]

I have found something similar but in my case I had to enable interceptor in all bean archives under META-INF/lib.
More details on Stackoverflow

Comment by jwells [ 29/Mar/13 ]

This must have been fixed as part of other fixes.

I have a test case under:

appserver/tests/cdi/cases/multiBeansXml

that demonstrates that this is currently working. It has two EJBs in an EAR and each EJB has a different interceptor defined in beans.xml. Both interceptors work properly. If the described behavior above were still in the product then only one of the interceptors would have been seen.

Generated at Thu Jul 02 16:35:22 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.