glassfish
  1. glassfish
  2. GLASSFISH-18946

EAR with two CDI Jersey web archives will not deploy

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.0
    • Component/s: jax-rs
    • Labels:
      None
    • Environment:

      Windows 7

      Description

      I already filed this issue in the Jersey JIRA (http://java.net/jira/browse/JERSEY-1232), however, after some research by Michal Gajdos, the issue is closed as "invalid", since the problem would by caused by Weld/GlassFish Weld. I also filed an issue at the Weld JIRA (http://issues.jboss.org/browse/WELD-1175), but they think it should be investigated first by the GlassFish team... (from pillar to post).
      Hopefully, the GlassFish team can help solving this problem.

      So here are 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
        jjsnyder83 added a comment -

        There is a work-around...I removed the WEB-INF/lib/jersey-gf-servlet-1.12.jar from the wars and I was able to deploy the ear successfully and execute http://localhost:8080/rest1_war/service/rest/RestService1 with "Hello world" as the result. I was able to reproduce the NPE above so I'm still looking into it.

        Show
        jjsnyder83 added a comment - There is a work-around...I removed the WEB-INF/lib/jersey-gf-servlet-1.12.jar from the wars and I was able to deploy the ear successfully and execute http://localhost:8080/rest1_war/service/rest/RestService1 with "Hello world" as the result. I was able to reproduce the NPE above so I'm still looking into it.
        Hide
        jjsnyder83 added a comment -

        I have checked in a fix. The application now deploys. However this has uncovered what I believe to be a bug in Weld. See https://issues.jboss.org/browse/WELD-1175.

        I have checked in the fix into 3.1.2 and trunk.

        Show
        jjsnyder83 added a comment - I have checked in a fix. The application now deploys. However this has uncovered what I believe to be a bug in Weld. See https://issues.jboss.org/browse/WELD-1175 . I have checked in the fix into 3.1.2 and trunk.
        Hide
        jjsnyder83 added a comment -

        Reopening due to the bug in Weld

        Show
        jjsnyder83 added a comment - Reopening due to the bug in Weld
        Hide
        Ramon Rockx added a comment -

        Great that this one is fixed!
        I'm looking for a way to patch our GlassFish installation (version 3.1.2.2).
        jjsnyder83, you mentioned that it is fixed on trunk and 3.1.2. I can only find commits on the trunk (GF 4.0 I assume). Can you help me out patching 3.1.2/3.1.2.2?

        Show
        Ramon Rockx added a comment - Great that this one is fixed! I'm looking for a way to patch our GlassFish installation (version 3.1.2.2). jjsnyder83, you mentioned that it is fixed on trunk and 3.1.2. I can only find commits on the trunk (GF 4.0 I assume). Can you help me out patching 3.1.2/3.1.2.2?
        Hide
        jjsnyder83 added a comment -

        I made the change to the 3.1.2-SUSTAINING line as well as trunk (4.0).

        I will get back to you on the patching.

        Please note that even though the app will deploy a fix to Weld (https://issues.jboss.org/browse/WELD-1175) is still required for the app to work correctly. See the Weld issue for details.

        Show
        jjsnyder83 added a comment - I made the change to the 3.1.2-SUSTAINING line as well as trunk (4.0). I will get back to you on the patching. Please note that even though the app will deploy a fix to Weld ( https://issues.jboss.org/browse/WELD-1175 ) is still required for the app to work correctly. See the Weld issue for details.
        Hide
        jjsnyder83 added a comment -

        The next patch due out is 3.1.2.4 (not sure of the date yet.) But until Weld fixes the issue there's no reason to include this in the patch.

        Show
        jjsnyder83 added a comment - The next patch due out is 3.1.2.4 (not sure of the date yet.) But until Weld fixes the issue there's no reason to include this in the patch.
        Hide
        Ramon Rockx added a comment -

        Can we expect this fix will be included in 3.1.2.4 since WELD-1175 is fixed too?
        (3.1.2.3 is skipped for release?)

        Show
        Ramon Rockx added a comment - Can we expect this fix will be included in 3.1.2.4 since WELD-1175 is fixed too? (3.1.2.3 is skipped for release?)
        Hide
        jjsnyder83 added a comment -

        Yes...I made the fix in the patch line and so it should be included in the next patch release. I have also requested that weld 1.1.10.Final be included as this relies on weld to work properly.

        Show
        jjsnyder83 added a comment - Yes...I made the fix in the patch line and so it should be included in the next patch release. I have also requested that weld 1.1.10.Final be included as this relies on weld to work properly.
        Hide
        jjsnyder83 added a comment -

        GlassFish integration with Weld was updated to Weld 1.1.10.Final with revision 56665.

        Show
        jjsnyder83 added a comment - GlassFish integration with Weld was updated to Weld 1.1.10.Final with revision 56665.
        Hide
        jjsnyder83 added a comment -

        I just tested this on trunk with weld 1.1.10.Final and it doesn't work.

        Show
        jjsnyder83 added a comment - I just tested this on trunk with weld 1.1.10.Final and it doesn't work.
        Hide
        jwells added a comment -

        I get this error now when I deploy the above ear in GF 4.0:

        Exception while loading the app : CDI deployment failure:Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
        org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
        at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:179)
        at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:190)
        at org.jboss.weld.resources.ClassTransformer.getEnhancedAnnotatedType(ClassTransformer.java:224)
        at org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:71)
        at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:464)
        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:192)
        at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
        at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)

        I looked at this a little bit, the class com.sun.jersey.server.impl.cdi.CDIExtension is in the jersey-gf-servlet-1.12.jar included in the WAR files included in the EAR. My guess would be that the old CDIExtension (which no longer exists in the Jersey included in GF 4.0) cannot be loaded properly anymore...

        So to me this seems like it is currently a Jersey issue, and may have to do with backwards compatibility...

        Show
        jwells added a comment - I get this error now when I deploy the above ear in GF 4.0: Exception while loading the app : CDI deployment failure:Error loading class com.sun.jersey.server.impl.cdi.CDIExtension org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.jersey.server.impl.cdi.CDIExtension at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:179) at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:190) at org.jboss.weld.resources.ClassTransformer.getEnhancedAnnotatedType(ClassTransformer.java:224) at org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:71) at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:464) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:192) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219) I looked at this a little bit, the class com.sun.jersey.server.impl.cdi.CDIExtension is in the jersey-gf-servlet-1.12.jar included in the WAR files included in the EAR. My guess would be that the old CDIExtension (which no longer exists in the Jersey included in GF 4.0) cannot be loaded properly anymore... So to me this seems like it is currently a Jersey issue, and may have to do with backwards compatibility...
        Hide
        Ramon Rockx added a comment -

        I'm wondering if this bug will be fixed with the upcoming 4.0 release?
        It really makes it impossible for us to use REST in a large modular EAR application properly.

        Show
        Ramon Rockx added a comment - I'm wondering if this bug will be fixed with the upcoming 4.0 release? It really makes it impossible for us to use REST in a large modular EAR application properly.
        Hide
        dbenegiamo added a comment -

        As the "double WARs in a EAR" is a common solution for applications that expose a FORM authentication for the web presentation and a BASIC authentication for restful web-services, priority of this bug should - in my opinion - raised.

        Show
        dbenegiamo added a comment - As the "double WARs in a EAR" is a common solution for applications that expose a FORM authentication for the web presentation and a BASIC authentication for restful web-services, priority of this bug should - in my opinion - raised.
        Hide
        Ramon Rockx added a comment -

        Like jwells mentioned, the current test case results in ClassNotFoundExceptions.
        I downloaded GlassFish 4.0 b88. Tweaked the test case:

        • no Jersey servlet configuration anymore (web.xml is empty)
        • no explicit dependency to Jersey 1.12 anymore (it now depends on Jersey 2.x)
        • used the javax.ws.rs.ApplicationPath annotation to configure the REST path prefix.

        Now each REST service does work in both web modules.

        However, GlassFish does log warnings like
        "[WARNING|glassfish 4.0|javax.enterprise.web.util|_ThreadID=60;_ThreadName=AutoDeployer;_TimeMillis=1369210288543;_LevelValue=900; _MessageID=AS-WEB-UTIL-00035;| Unable to load class nl.asknow.sandbox.RestService1, reason: java.lang.ClassNotFoundException: nl.asknow.sandbox.RestService1|#]".
        I'm not sure if this warning can be ignored.

        I will attach my new test case.

        Show
        Ramon Rockx added a comment - Like jwells mentioned, the current test case results in ClassNotFoundExceptions. I downloaded GlassFish 4.0 b88. Tweaked the test case: no Jersey servlet configuration anymore (web.xml is empty) no explicit dependency to Jersey 1.12 anymore (it now depends on Jersey 2.x) used the javax.ws.rs.ApplicationPath annotation to configure the REST path prefix. Now each REST service does work in both web modules. However, GlassFish does log warnings like " [WARNING|glassfish 4.0|javax.enterprise.web.util|_ThreadID=60;_ThreadName=AutoDeployer;_TimeMillis=1369210288543;_LevelValue=900; _MessageID=AS-WEB-UTIL-00035;| Unable to load class nl.asknow.sandbox.RestService1, reason: java.lang.ClassNotFoundException: nl.asknow.sandbox.RestService1|#] ". I'm not sure if this warning can be ignored. I will attach my new test case.
        Hide
        Ramon Rockx added a comment -

        It seems I cannot add an attachment anymore...

        Show
        Ramon Rockx added a comment - It seems I cannot add an attachment anymore...
        Hide
        Jakub Podlesak added a comment -

        Ramon, could you please send the test case to my e-mail address (jakub.podlesak at oracle.com)? I will attach it here as well once i get it. Thanks!

        Show
        Jakub Podlesak added a comment - Ramon, could you please send the test case to my e-mail address (jakub.podlesak at oracle.com)? I will attach it here as well once i get it. Thanks!
        Hide
        Jakub Podlesak added a comment -

        Updated test case from Ramon.

        Show
        Jakub Podlesak added a comment - Updated test case from Ramon.
        Hide
        sebastian2 added a comment -

        Is there a plan to fix that issue? I am also struggeling with this bug....

        Show
        sebastian2 added a comment - Is there a plan to fix that issue? I am also struggeling with this bug....

          People

          • Assignee:
            Jakub Podlesak
            Reporter:
            Ramon Rockx
          • Votes:
            15 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

            • Created:
              Updated: