glassfish
  1. glassfish
  2. GLASSFISH-15721

"injection points in one bean deployment archive cannot be satisfied by a bean in a separate bean archive, even when they are from libraries in the same module (web archive)"

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1_b39
    • Fix Version/s: 3.1.1_b05
    • Component/s: cdi
    • Labels:
      None

      Description

      The Bean Deployment Archive visibility graph does not correctly implement the spec.

      Beans in WEB-INF/lib are made availible to beans in WEB-INF/classes, however the converse is not true (i.e. beans is WEB-INF/classes cannot be injected into WEB-INF/lib injection points), and beans in one jar in WEB-INF/lib cannot be injected into beans in a different jar in WEB-INF/lib.

      According to the CDI and EE6 Platform spec both of these should work.

      https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/web/weld-integration/src/main/java/org/glassfish/weld/DeploymentImpl.java

        Issue Links

          Activity

          Hide
          mojavelinux added a comment -

          Two tests have been prepared to demonstrate cases when beans within the same bean archive are not visible to each other.

          https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/TypeVisibilityForExtensionInNonBeanArchiveTest.java
          https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/TypeVisibilityWithinBeanArchiveTest.java

          These tests can be run from the root of the Solder project as follows:

          mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest
          mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest

          These tested use the new Arquillian GlassFish adapter created by Jason Porter and based on the GlassFish REST API.

          Show
          mojavelinux added a comment - Two tests have been prepared to demonstrate cases when beans within the same bean archive are not visible to each other. https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/TypeVisibilityForExtensionInNonBeanArchiveTest.java https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/TypeVisibilityWithinBeanArchiveTest.java These tests can be run from the root of the Solder project as follows: mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest These tested use the new Arquillian GlassFish adapter created by Jason Porter and based on the GlassFish REST API.
          Hide
          Sivakumar Thyagarajan added a comment -

          Investigation in progress. It appears to be an issue with the way Weld handles accessibility of cyclic references among BeanDeploymentArchives. I have requested the help of Weld engineering team to understand this better, and will update this issue.

          Show
          Sivakumar Thyagarajan added a comment - Investigation in progress. It appears to be an issue with the way Weld handles accessibility of cyclic references among BeanDeploymentArchives. I have requested the help of Weld engineering team to understand this better, and will update this issue.
          Hide
          Sivakumar Thyagarajan added a comment -

          This issue occurs because of the way Weld handles cyclic references among BDAs. I have raised https://issues.jboss.org/browse/WELD-846 to track the Weld side change needed to fix this issue. We will integrate the next available release of Weld that provides a fix for this issue in the next update release of GlassFish 3.1.

          Release note/Workaround:
          Until then the application could be repackaged such that either:

          • Beans in WEB-INF/classes are not used/injected in classes bundled in WEB-INF/lib/*.jar
          • All Beans are available as part of WEB-INF/classes [ie collapse the bundled library in WEB-INF/lib/*.jar into WEB-INF/classes].
          Show
          Sivakumar Thyagarajan added a comment - This issue occurs because of the way Weld handles cyclic references among BDAs. I have raised https://issues.jboss.org/browse/WELD-846 to track the Weld side change needed to fix this issue. We will integrate the next available release of Weld that provides a fix for this issue in the next update release of GlassFish 3.1. Release note/Workaround: Until then the application could be repackaged such that either: Beans in WEB-INF/classes are not used/injected in classes bundled in WEB-INF/lib/*.jar All Beans are available as part of WEB-INF/classes [ie collapse the bundled library in WEB-INF/lib/*.jar into WEB-INF/classes] .
          Hide
          Sivakumar Thyagarajan added a comment - - edited

          FWIW, Weld has fixed the root issue https://github.com/stuartwdouglas/core/tree/WELD-846 in their trunk and this scenario would work again once we integrate the Weld 1.2.0.Beta distribution when it becomes available.

          I also tried this scenario against a local build of Weld trunk(attached the weld-osgi-bundle.jar that I used at http://java.net/jira/secure/attachment/44919/weld-osgi-bundle.jar , place this under $INSTALL_ROOT/modules and restart the domain to reproduce this).

          Show
          Sivakumar Thyagarajan added a comment - - edited FWIW, Weld has fixed the root issue https://github.com/stuartwdouglas/core/tree/WELD-846 in their trunk and this scenario would work again once we integrate the Weld 1.2.0.Beta distribution when it becomes available. I also tried this scenario against a local build of Weld trunk(attached the weld-osgi-bundle.jar that I used at http://java.net/jira/secure/attachment/44919/weld-osgi-bundle.jar , place this under $INSTALL_ROOT/modules and restart the domain to reproduce this).
          Hide
          mimik789 added a comment -

          I tested provided weld-osgi-bundle.jar in GF3 b_41 (web), and also in latest nightly build - as described in guidliness https://issues.jboss.org/browse/WELD-846 (in exception to that I have to remove content from arquillian.xml config file for jboss - without that test can't be executed, and that I need to replace test with integration-test).
          ie:
          1/
          mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest

          2/
          mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest

          first test (TypeVisibilityWithinBeanArchiveTest) passes OK

          but second test (TypeVisibilityForExtensionInNonBeanArchiveTest) FAIL with:

          org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [BeanClassToRegister] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.solder.test.compat.AnotherBeanClassToRegister.collaborator]. Possible dependencies [[Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default]]]
          at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
          at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:139)
          at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:162)
          at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:385)
          at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:371)
          at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:394)
          at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190)
          ...

          having same issue?

          Show
          mimik789 added a comment - I tested provided weld-osgi-bundle.jar in GF3 b_41 (web), and also in latest nightly build - as described in guidliness https://issues.jboss.org/browse/WELD-846 (in exception to that I have to remove content from arquillian.xml config file for jboss - without that test can't be executed, and that I need to replace test with integration-test). ie: 1/ mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest 2/ mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest first test (TypeVisibilityWithinBeanArchiveTest) passes OK but second test (TypeVisibilityForExtensionInNonBeanArchiveTest) FAIL with: org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [BeanClassToRegister] with qualifiers [@Default] at injection point [ [field] @Inject private org.jboss.seam.solder.test.compat.AnotherBeanClassToRegister.collaborator]. Possible dependencies [[Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default] , Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default] ]] at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:139) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:162) at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:385) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:371) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:394) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190) ... having same issue?
          Hide
          vostok added a comment -

          I'm experiencing a lot of problems in 3.1 versions with my modular project using CDI. It works great (despite CDI memory leaks issues, manually fixed) with 3.0.1 but I cannot deploy it with 3.1 RCs!

          Tags: 3_1-exclude 3_1-release-notes

          ^

          ----- Solving this bug is being excluded from 3.1 final???

          Show
          vostok added a comment - I'm experiencing a lot of problems in 3.1 versions with my modular project using CDI. It works great (despite CDI memory leaks issues, manually fixed) with 3.0.1 but I cannot deploy it with 3.1 RCs! Tags: 3_1-exclude 3_1-release-notes ^ ----- Solving this bug is being excluded from 3.1 final???
          Hide
          eratzlaff added a comment -

          It would be nice to have this bug fix for glassfish 3.1 release.

          Show
          eratzlaff added a comment - It would be nice to have this bug fix for glassfish 3.1 release.
          Hide
          mimik789 added a comment -

          You may be interested with this good news:
          http://seamframework.org/Community/SeamFacesPersistenceServletCatchProduceNullPointerException#comment149620

          for lazy guys and girls: I'm attaching fixed weld-core.jar (weld-osgi-bundle.jar) built from:
          https://github.com/stuartwdouglas/core/tree/WELD-859

          Show
          mimik789 added a comment - You may be interested with this good news: http://seamframework.org/Community/SeamFacesPersistenceServletCatchProduceNullPointerException#comment149620 for lazy guys and girls: I'm attaching fixed weld-core.jar (weld-osgi-bundle.jar) built from: https://github.com/stuartwdouglas/core/tree/WELD-859
          Hide
          DiegoCoronel added a comment -

          The jar attached does not resolved my problem. I deleted osgi-cache after change the jar and it does not worked.
          My war classes cant inject my jar classes.

          It works fine in glassfish 3.0.1 final.

          In my specific case i have this scenary

          myWebModule.war
          – MyJarProject1.jar (depends:MyFramework, myWebModule.war)
          – MyJarProject2.jar (depends:MyFramework, MyJarProject1, myWebModule.war)
          – MyFramework.jar (depends:myWebModule.war)

          where all jar modules depends on war because they inject EntityManager that is produced by war because it does not worked if jar produce EntityManager.

          Show
          DiegoCoronel added a comment - The jar attached does not resolved my problem. I deleted osgi-cache after change the jar and it does not worked. My war classes cant inject my jar classes. It works fine in glassfish 3.0.1 final. In my specific case i have this scenary myWebModule.war – MyJarProject1.jar (depends:MyFramework, myWebModule.war) – MyJarProject2.jar (depends:MyFramework, MyJarProject1, myWebModule.war) – MyFramework.jar (depends:myWebModule.war) where all jar modules depends on war because they inject EntityManager that is produced by war because it does not worked if jar produce EntityManager.
          Show
          mojavelinux added a comment - Here's an updated test case: https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/visibility/VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest.java
          Hide
          Scott Fordin added a comment -

          Need more info to add issue to 3.1 Release Notes.

          Show
          Scott Fordin added a comment - Need more info to add issue to 3.1 Release Notes.
          Hide
          Nazrul added a comment -

          It would be useful to look into this issue for 3.1.1

          Show
          Nazrul added a comment - It would be useful to look into this issue for 3.1.1
          Hide
          vrcollins added a comment -

          I am in the same boat as vostok. I am able to get everything working fine in glassfish 3.0.1. I am using glassfish 3.1 with build 43. I have replaced the weld-osgi-bundle.jar file with the one in this ticket. I am getting the same errors.

          Show
          vrcollins added a comment - I am in the same boat as vostok. I am able to get everything working fine in glassfish 3.0.1. I am using glassfish 3.1 with build 43. I have replaced the weld-osgi-bundle.jar file with the one in this ticket. I am getting the same errors.
          Hide
          toomanyryans added a comment -

          I think I've been running into this bug. Assume I have two .jars:

          WEB-INF/lib/jarA
          WEB-INF/lib/jarB

          If jarB is dependent on jarA, is it possible they could get scanned in a different order depending on the system I'm deploying to? Specifically, embedded Glassfish on Windows vs normal Glassfish on Linux?

          I noticed that Glassfish 3.1.1-b04 is using Weld 1.1.1.Final and it fixes my problem. The Weld issue mentioned here (WELD-846) was fixed for 1.1.1.Final, so I think this maybe resolved in Glassfish 3.1.1-b04+. It may be worth testing again if you're watching this issue.

          Show
          toomanyryans added a comment - I think I've been running into this bug. Assume I have two .jars: WEB-INF/lib/jarA WEB-INF/lib/jarB If jarB is dependent on jarA, is it possible they could get scanned in a different order depending on the system I'm deploying to? Specifically, embedded Glassfish on Windows vs normal Glassfish on Linux? I noticed that Glassfish 3.1.1-b04 is using Weld 1.1.1.Final and it fixes my problem. The Weld issue mentioned here (WELD-846) was fixed for 1.1.1.Final, so I think this maybe resolved in Glassfish 3.1.1-b04+. It may be worth testing again if you're watching this issue.
          Hide
          Scott Fordin added a comment -

          Added issue to 3.1 Known Issues section in 3.1-3.1.1 Release Notes.

          Show
          Scott Fordin added a comment - Added issue to 3.1 Known Issues section in 3.1-3.1.1 Release Notes.
          Hide
          scatari added a comment -

          Fix expected by first week of June.

          Show
          scatari added a comment - Fix expected by first week of June.
          Hide
          Sivakumar Thyagarajan added a comment -

          This issue has been fixed since the integration of Weld 1.1.1.Final (that fixes root cause WELD-846) into GlassFish 3.1.1(b4+) and GlassFish trunk.

          Through svn revision 47397, I have also added the following developer tests to cover this scenario
          javaee-integration/cdi-servlet-3.0-annotation-with-web-inf-lib/

          Show
          Sivakumar Thyagarajan added a comment - This issue has been fixed since the integration of Weld 1.1.1.Final (that fixes root cause WELD-846) into GlassFish 3.1.1(b4+) and GlassFish trunk. Through svn revision 47397, I have also added the following developer tests to cover this scenario javaee-integration/cdi-servlet-3.0-annotation-with-web-inf-lib/
          Hide
          cbarragan added a comment -

          As for Glassfish 3.1.1b11 I think the issue might not be solved, although my problem differs from the original issue.

          I have an EAR with an ejb module and some jars in the lib directory.
          A dependency in a class that resides in the lib directory cannot be satisfied. This dependency should be solved by a class in my ejb module, but it seems that the class in the ejb module is not visible to the class in the lib directory. Is this another issue? If so, is there an issue related to this problem?

          Show
          cbarragan added a comment - As for Glassfish 3.1.1b11 I think the issue might not be solved, although my problem differs from the original issue. I have an EAR with an ejb module and some jars in the lib directory. A dependency in a class that resides in the lib directory cannot be satisfied. This dependency should be solved by a class in my ejb module, but it seems that the class in the ejb module is not visible to the class in the lib directory. Is this another issue? If so, is there an issue related to this problem?
          Hide
          Sivakumar Thyagarajan added a comment -

          @cbarragan:

          As per section 5.1 of the CDI 1.0 specification:
          "In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."

          In the scenario you had mentioned above: as the EJB module class is not required to be accessible to a jar in the lib directory, the bean class is not available for injection.

          Show
          Sivakumar Thyagarajan added a comment - @cbarragan: As per section 5.1 of the CDI 1.0 specification: "In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification." In the scenario you had mentioned above: as the EJB module class is not required to be accessible to a jar in the lib directory, the bean class is not available for injection.

            People

            • Assignee:
              Sivakumar Thyagarajan
              Reporter:
              stuartdouglas
            • Votes:
              20 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: