[GLASSFISH-19429] CDI integration does not handle properly beans.xml files from library JAR Created: 11/Dec/12  Updated: 19/Sep/14  Resolved: 05/Mar/13

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

Type: Bug Priority: Major
Reporter: win_wave Assignee: jjsnyder83
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, Java Oracle jdk1.7.0_03


Tags: beans, cdi, jar

 Description   

If you enable Decorator (may be also Interceptors, Alternatives) in beans.xml in JAR, which included to WAR application package, it Glassfish does not enable them properly (at least Decorators for sure).
If uses only "first" beans.xml file from the resources, even if you have several JARs. By CDI specs, we should enable decorator at least in one bundle, to make it enabled.
Structure of WAR:

  • WEB-INF/beans.xml
  • lib1.jar
    • MEAT-INF/beans.xml <-- here we enable decorator A
    • classes...
  • lib2.jar
    • MEAT-INF/beans.xml <-- here we enable decorator B
    • classes...
      Result: Only decorator A will be loaded!!

Problem in code:
org.glassfish.weld.BeanDeploymentArchiveImpl (org.glassfish.main.web:weld-integration:jar:3.1.2)
line 503:
URL beansXmlUrl = Thread.currentThread().getContextClassLoader().getResource(entry); <-- here is entry variable, which is always "META-INF/beans.xml", that makes wUris.add(beansXmlUrl.toURI()); context loader return always the same resource file

there are exists already "proper" way of loading beans.xml, it used to load WEB-INF/beans.xml from WAR:
line 352:
URI uri = archive.getURI();
File file = new File(uri.getPath() + entry);
URI beansXmlUri = file.toURI();
wUris.add(beansXmlUri);

I think, the same way should be implemented to load META-INF/beans.xml from JARs

WORKAROUND:

I've found solution, which is not complient, but at least works for now.
I need to have such structure:

  • WEB-INF/beans.xml
  • lib1.jar
    • MEAT-INF/beans.xml <-- leave that empty
    • WEB-INF/beans.xml <-- here we enable decorator A
    • classes...
  • lib2.jar
    • MEAT-INF/beans.xml <-- leave that empty
    • WEB-INF/beans.xml <-- here we enable decorator B
    • classes...


 Comments   
Comment by win_wave [ 11/Dec/12 ]

Actually workaround does not work. It was working in Eclipse, it was deploying open projects as folders, and properly found all resources. In case of jar package it fails to properly construct path to beans.xml

Comment by win_wave [ 11/Dec/12 ]

The working workaround is: Identify library which is "first", and add to it's beans.xml all required info about registration.
How to identify "first" library: I think, it is identified by alphabetical order. In order to be sure you can add comment into beans.xml like <!-- my lib 1--> into all libraries and after see into folder <domain_folder>\generated\<WAR_APP_NAME>\loader_<SOME_NUMBER>\META-INF\beans.xml, and check what comment it contains.

Actually that bug, "enables" possibility to configure CDI interceptors independently of the libraries. So it is possible to create library like "_configure.jar" which will contain all configurations.

Also figured out, that this issue is duplicate for http://java.net/jira/browse/GLASSFISH-18802

Comment by jjsnyder83 [ 05/Mar/13 ]

Duplicate of http://java.net/jira/browse/GLASSFISH-18802

Generated at Fri May 22 12:43:57 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.