glassfish
  1. glassfish
  2. GLASSFISH-19429

CDI integration does not handle properly beans.xml files from library JAR

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 3.1.2
    • Fix Version/s: 4.1
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      Windows 7 x64, Java Oracle jdk1.7.0_03

      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...

        Activity

        Hide
        jjsnyder83 added a comment -
        Show
        jjsnyder83 added a comment - Duplicate of http://java.net/jira/browse/GLASSFISH-18802
        Hide
        win_wave added a comment -

        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

        Show
        win_wave added a comment - 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
        Hide
        win_wave added a comment -

        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

        Show
        win_wave added a comment - 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

          People

          • Assignee:
            jjsnyder83
            Reporter:
            win_wave
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: