glassfish
  1. glassfish
  2. GLASSFISH-15225

[OSGi] CDI beans not accessible in web applications

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1_b33
    • Fix Version/s: 4.0.1
    • Component/s: cdi, OSGi-JavaEE
    • Labels:
      None

      Description

      This seems to be related to GLASSFISH-14842.

      However as that bug seems to be fixed this could be introduced by the OSGi/CDI integration.

      Attached a test project ( dummy-cdi-web-test.tar.gz ) which is a maven project building a WAB. To see the issue immediately try to access it like this:

      http://localhost:8080/dummy-web/?name=John

      The error I then get is:

      /index.xhtml @12,69 value="#

      {dummyBean.name}

      ": Target Unreachable, identifier 'dummyBean' resolved to null

      The application worked fine at least with 3.1 promoted b06.

        Issue Links

          Activity

          Hide
          TangYong added a comment -

          About scene1, I have some interesting finding as following:

          Noting the following exception info,

          Caused by: java.lang.ClassNotFoundException: org.jboss.weld.jsf.WeldPhaseListener
          at java.lang.ClassLoader.findClass(ClassLoader.java:522)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
          at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:257)
          at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:222)
          at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:170)
          at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:153)
          at java.lang.Class.forName0(Native Method)
          at java.lang.Class.forName(Class.java:264)
          at com.sun.faces.util.Util.loadClass(Util.java:301)
          at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376)
          ... 35 more
          ]]

          Noting an important change[1] from Weld 1.x --> Weld 2.x
          [1]: https://community.jboss.org/wiki/WeldIntegratorGuide-ChangesForWeld20

          "WeldPhaseListener has been removed. The listener served as a hook for activating / deactivating conversations. In CDI 1.1 (CDI-80) conversations are now available for pure Servlet requests and therefore conversation activation is handled in the WeldListener (which is a Servlet listener)."

          The same issue can be found in [2],
          [2]: https://community.jboss.org/thread/218292

          I will confirm whether truly being caused by the change.

          Show
          TangYong added a comment - About scene1, I have some interesting finding as following: Noting the following exception info, Caused by: java.lang.ClassNotFoundException: org.jboss.weld.jsf.WeldPhaseListener at java.lang.ClassLoader.findClass(ClassLoader.java:522) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:257) at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:222) at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:170) at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:153) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at com.sun.faces.util.Util.loadClass(Util.java:301) at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376) ... 35 more ]] Noting an important change [1] from Weld 1.x --> Weld 2.x [1] : https://community.jboss.org/wiki/WeldIntegratorGuide-ChangesForWeld20 "WeldPhaseListener has been removed. The listener served as a hook for activating / deactivating conversations. In CDI 1.1 (CDI-80) conversations are now available for pure Servlet requests and therefore conversation activation is handled in the WeldListener (which is a Servlet listener)." The same issue can be found in [2] , [2] : https://community.jboss.org/thread/218292 I will confirm whether truly being caused by the change.
          Hide
          TangYong added a comment -

          Adding priority into Major because the issue maybe related to Weld 2.x change.

          Show
          TangYong added a comment - Adding priority into Major because the issue maybe related to Weld 2.x change.
          Hide
          TangYong added a comment -

          From JBOSS guy(Jozef Hartinger)'s fixing[1], org.jboss.weld.jsf.WeldPhaseListener should be removed from faces-config.xml since weld 2.x.

          [1]: https://source.jboss.org/browse/WeldCore/environments/servlet/core/src/main/resources/META-INF/faces-config.xml?r2=99d2f3568c5671a297319b8ef6d967b07b6279c7&r1=fb35e1d1b8106854b606c999ab634ab59b92045d

          So, weld.faces-config.xml should be updated and remove the following

          <lifecycle>
          <phase-listener>org.jboss.weld.jsf.WeldPhaseListener</phase-listener>
          </lifecycle>

          Now, scene1 has OK! I will update the workaround.

          Show
          TangYong added a comment - From JBOSS guy(Jozef Hartinger)'s fixing [1] , org.jboss.weld.jsf.WeldPhaseListener should be removed from faces-config.xml since weld 2.x. [1] : https://source.jboss.org/browse/WeldCore/environments/servlet/core/src/main/resources/META-INF/faces-config.xml?r2=99d2f3568c5671a297319b8ef6d967b07b6279c7&r1=fb35e1d1b8106854b606c999ab634ab59b92045d So, weld.faces-config.xml should be updated and remove the following <lifecycle> <phase-listener>org.jboss.weld.jsf.WeldPhaseListener</phase-listener> </lifecycle> Now, scene1 has OK! I will update the workaround.
          Hide
          Sanjeeb Sahoo added a comment -

          Sorry, this didn't get due attention for 4.0.

          Show
          Sanjeeb Sahoo added a comment - Sorry, this didn't get due attention for 4.0.
          Hide
          TangYong added a comment -

          Scene2 has been resolved and investigation result is as following,

          While using primefaces 2.1 with CDI(Weld) in the sample(dummy-web.war), Scene2's exceptions will be caused by the following and caused the whole WAB's deployment failed.

          Caused by: org.jboss.weld.exceptions.DefinitionException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
          at org.jboss.weld.util.Beans.getBeanConstructor(Beans.java:327)
          ....

          [Analyze]
          1 in primefaces 2.1, org.primefaces.context.PrimeExternalContextFactory does not offer a default or no-args constructor, so, in org.jboss.weld.util.Beans.getBeanConstructor method, "constructor" will be null, then, throwing a DefinitionException called "UNABLE_TO_FIND_CONSTRUCTOR" , thus, causing the above exception.

          The exception also caused two bad results:
          1) WebContainer.loadWebModule failed
          2) WAB expanded failed

          2 I investigated primefaces 2.x and 3.x and found an interesting thing as following:
          In primefaces 3.x(eg. 3.5), org.primefaces.context.PrimeExternalContextFactory has not existed. So I made an experiment to replace primefaces-2.1.jar with primefaces-3.5.jar in the WAB's WEB-INF/lib. Then, after deploying the new WAB, the exceptions all did not happen. And can access "http://localhost:8080/dummy-web/" normally.

          Only a issue is that while accessing "http://localhost:8080/dummy-web/", there are the following warning info:
          "
          Warning: This page calls for XML namespace http://primefaces.prime.com.tr/ui declared with prefix p but no taglibrary exists for that namespace.
          Warning: This page calls for XML namespace http://primefaces.prime.com.tr/ui declared with prefix p but no taglibrary exists for that namespace. "

          The warning info is caused by [1]:
          [1]: http://stackoverflow.com/questions/7565431/warning-this-page-calls-for-xml-namespace-http-primefaces-prime-com-tr-ui-dec

          While modifying the sample's index.xhtml from xmlns="http://primefaces.prime.com.tr/ui" to xmlns="http://primefaces.org/ui" , although the warning has not disappeared, primefaces's tree tag was not still displayed normally. However, I think that this should be primefaces's using problems rather than gf's problems.

          So, in a word, the Scene2 should belong to user's sample problem rather than gf's problem.

          Thanks
          --Tang

          Show
          TangYong added a comment - Scene2 has been resolved and investigation result is as following, While using primefaces 2.1 with CDI(Weld) in the sample(dummy-web.war), Scene2's exceptions will be caused by the following and caused the whole WAB's deployment failed. Caused by: org.jboss.weld.exceptions.DefinitionException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1 at org.jboss.weld.util.Beans.getBeanConstructor(Beans.java:327) .... [Analyze] 1 in primefaces 2.1, org.primefaces.context.PrimeExternalContextFactory does not offer a default or no-args constructor, so, in org.jboss.weld.util.Beans.getBeanConstructor method, "constructor" will be null, then, throwing a DefinitionException called "UNABLE_TO_FIND_CONSTRUCTOR" , thus, causing the above exception. The exception also caused two bad results: 1) WebContainer.loadWebModule failed 2) WAB expanded failed 2 I investigated primefaces 2.x and 3.x and found an interesting thing as following: In primefaces 3.x(eg. 3.5), org.primefaces.context.PrimeExternalContextFactory has not existed. So I made an experiment to replace primefaces-2.1.jar with primefaces-3.5.jar in the WAB's WEB-INF/lib. Then, after deploying the new WAB, the exceptions all did not happen. And can access "http://localhost:8080/dummy-web/" normally. Only a issue is that while accessing "http://localhost:8080/dummy-web/", there are the following warning info: " Warning: This page calls for XML namespace http://primefaces.prime.com.tr/ui declared with prefix p but no taglibrary exists for that namespace. Warning: This page calls for XML namespace http://primefaces.prime.com.tr/ui declared with prefix p but no taglibrary exists for that namespace. " The warning info is caused by [1] : [1] : http://stackoverflow.com/questions/7565431/warning-this-page-calls-for-xml-namespace-http-primefaces-prime-com-tr-ui-dec While modifying the sample's index.xhtml from xmlns ="http://primefaces.prime.com.tr/ui" to xmlns ="http://primefaces.org/ui" , although the warning has not disappeared, primefaces's tree tag was not still displayed normally. However, I think that this should be primefaces's using problems rather than gf's problems. So, in a word, the Scene2 should belong to user's sample problem rather than gf's problem. Thanks --Tang

            People

            • Assignee:
              Sanjeeb Sahoo
              Reporter:
              chaoslayer
            • Votes:
              2 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated: