Weld
  1. Weld
  2. WELD-1175

EAR with two CDI web archives will not deploy

    Details

    • Steps to Reproduce:
      Hide

      Deploy the attached ears on a clean Glassfish 3.1.2.

      Show
      Deploy the attached ears on a clean Glassfish 3.1.2.
    • Similar Issues:
      Show 10 results 

      Description

      I already filed this issue in the Jersey JIRA, however, after some research by Michal Gajdos, the issue is closed as "invalid", since the problem would by caused by Weld/Glassfish Weld.

      So here the details:
      We are experiencing the following issue with Jersey 1.12 in combination with Weld 1.1.4 and Glassfish 3.1.2:
      When using an EAR with two WAR's in it, the last WAR doesn't get deployed. Both WAR's are CDI enabled and contains a REST service. When deploying both WAR's without the EAR, they deploy just fine.
      I will attach a test case.

      Depending on the VM property
      com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager we will get another Exception:

      com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=false:

       
      java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'com/sun/jersey/config/CDIExtension' in SerialContext[myEnv=java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
      [Root exception is javax.naming.NameNotFoundException: CDIExtension not found]	
      	at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:177)
      	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:92)
      	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
      	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
      	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
      	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
      	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
      	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
      	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
      	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
      	...
      

      com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true

      java.lang.NullPointerException
      	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:94)
      	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
      	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
      	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
      	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
      	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
      	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
      	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
      	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
      	...
      

        Gliffy Diagrams

          Activity

          Hide
          Ramon Rockx added a comment -

          ear file with which this issue can be reproduced.

          Show
          Ramon Rockx added a comment - ear file with which this issue can be reproduced.
          Hide
          Ales Justin added a comment -

          You should first file this against GlassFish,
          as they are in-charge of the actual integration.
          If it really turns out to be CDI/Weld issue,
          reopen with more info.

          Show
          Ales Justin added a comment - You should first file this against GlassFish, as they are in-charge of the actual integration. If it really turns out to be CDI/Weld issue, reopen with more info.
          Show
          Ramon Rockx added a comment - filed http://java.net/jira/browse/JERSEY-1232 filed http://java.net/jira/browse/GLASSFISH-18946
          Hide
          Joseph Snyder added a comment -

          There is definitely a bug in GlassFish, not specific to Jersey, which I am in the process of fixing. There also appears to be a bug in Weld. Here are the steps to reproduce the bug (I will attach a test ear and sources):

          • Define a portable extension and package it in a jar.
          • Create multiple web apps.
          • Define an injection point to the portable extension in some class in each of the web apps.
          • Package the jar into each web app's WEB-INF/lib directory.
          • Package the web apps into an Ear and deploy the ear.
            After successfully deploying the app you must force the injection of the portable extension into another class for both of the wars. For the attached test app execute the folowing urls:
            http://localhost:8080/war1/MultiwarWar1Servlet
            http://localhost:8080/war2/MultiwarWar2Servlet
            One of these will cause the following:

          [#|2012-10-05T12:36:57.908-0400|WARNING|44.0|javax.enterprise.web|_ThreadID=13;_ThreadName=http-listener-1(2);_TimeMillis=1349455017908;_LevelValue=900;|StandardWrapperValve[MultiwarWar2Servlet]: PWC1382: Allocate exception for servlet MultiwarWar2Servlet
          java.lang.IllegalArgumentException: Can not set multiwar_lib.MultiwarExtension field multiwar_war2.MultiwarWar2Servlet.multiwarExtension to multiwar_lib.MultiwarExtension
          at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
          at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
          at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
          at java.lang.reflect.Field.set(Field.java:657)
          at org.jboss.weld.introspector.jlr.WeldFieldImpl.set(WeldFieldImpl.java:88)
          at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:120)

          ...

          I looked into the Weld code and it appears that AbstractContainerEvent.fire(...) is filling a Set of ObserverMethod objects. The key for the set is the id of the ObserverMethod object. The id being returned for the portable extension is the same for both wars in which the PE is contained so that the set only contains one ObserverMethod instead of 2.

          Show
          Joseph Snyder added a comment - There is definitely a bug in GlassFish, not specific to Jersey, which I am in the process of fixing. There also appears to be a bug in Weld. Here are the steps to reproduce the bug (I will attach a test ear and sources): Define a portable extension and package it in a jar. Create multiple web apps. Define an injection point to the portable extension in some class in each of the web apps. Package the jar into each web app's WEB-INF/lib directory. Package the web apps into an Ear and deploy the ear. After successfully deploying the app you must force the injection of the portable extension into another class for both of the wars. For the attached test app execute the folowing urls: http://localhost:8080/war1/MultiwarWar1Servlet http://localhost:8080/war2/MultiwarWar2Servlet One of these will cause the following: [#|2012-10-05T12:36:57.908-0400|WARNING|44.0|javax.enterprise.web|_ThreadID=13;_ThreadName=http-listener-1(2);_TimeMillis=1349455017908;_LevelValue=900;|StandardWrapperValve [MultiwarWar2Servlet] : PWC1382: Allocate exception for servlet MultiwarWar2Servlet java.lang.IllegalArgumentException: Can not set multiwar_lib.MultiwarExtension field multiwar_war2.MultiwarWar2Servlet.multiwarExtension to multiwar_lib.MultiwarExtension at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146) at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150) at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63) at java.lang.reflect.Field.set(Field.java:657) at org.jboss.weld.introspector.jlr.WeldFieldImpl.set(WeldFieldImpl.java:88) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:120) ... I looked into the Weld code and it appears that AbstractContainerEvent.fire(...) is filling a Set of ObserverMethod objects. The key for the set is the id of the ObserverMethod object. The id being returned for the portable extension is the same for both wars in which the PE is contained so that the set only contains one ObserverMethod instead of 2.
          Hide
          Joseph Snyder added a comment - - edited

          multiwar.jar contains the source and the deployable archives.

          Show
          Joseph Snyder added a comment - - edited multiwar.jar contains the source and the deployable archives.
          Hide
          Ales Justin added a comment - - edited

          I couldn't re-produce this.

          But I did find another issue – the app wouldn't deploy for me in AS7.
          It required a small fix in Weld and a small fix in AS7+Weld integration.

          This is the Weld fix:

          And the AS7 fix:

          Can you try if this (Weld' fix) fixes your problem as well?

          Show
          Ales Justin added a comment - - edited I couldn't re-produce this. But I did find another issue – the app wouldn't deploy for me in AS7. It required a small fix in Weld and a small fix in AS7+Weld integration. This is the Weld fix: https://github.com/alesj/core/tree/weld-1175 And the AS7 fix: https://github.com/alesj/jboss-as/tree/weld-1175 Can you try if this (Weld' fix) fixes your problem as well?
          Hide
          Joseph Snyder added a comment -

          Yup that fixed it! Both web apps run successfully now. Thanks Ales.

          Show
          Joseph Snyder added a comment - Yup that fixed it! Both web apps run successfully now. Thanks Ales.

            People

            • Assignee:
              Ales Justin
              Reporter:
              Ramon Rockx
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development