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

        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: