12 Replies Latest reply on Jun 4, 2014 6:02 AM by jerome110011

    RESTEasy/Jersey conflict on JBoss AS 6

    ringerc

      Hi all

       

      (This post has been significantly edited now that I've produced a proper test case and had a stupid mistake pointed out to me. Old text is struck so that responses seen below still make sense.)

       

       

      I'm increasingly stumped with the problems I'm having getting my app running on JBoss AS 6. It deploys & works perfectly on Glassfish 3.1's OSGi runtime, but for the life of me I can't seem to make it do so on JBoss AS 6.

       

      The main problem is that I need Jersey 1.5. JBoss bundles an older version RESTEasy instead. In Glassfish I just include Jersey 1.5 in my war's lib/ and Glassfish uses it by preference. On JBoss, this seems to cause a variety of exciting failures because of the jaxb-impl and stax jars that Jersey pulls in by default.

       

      A more minimalist test case ( https://github.com/ringerc/scrapcode/tree/master/testcases/javaee/jbossas6-jersey15-testcase ) that only tries to deploy jersey-server to jboss, with nothing but a web.xml and my pom.xml, fails with:

       

      18:35:07,569 ERROR [AbstractKernelController] Error installing to PreReal: name=vfs:///C:/jboss-6.0.0.Final/server/default/deploy/jbossjerseydemo.war state=PostClassLoader mode=Manual requiredState=PreReal: org.jboss.deployers.spi.DeploymentException: Only one JAX-RS Application Class allowed. com.sun.jersey.api.core.WebAppResourceConfig com.sun.jersey.api.core.ResourceConfig com.sun.jersey.api.core.ClasspathResourceConfig com.sun.jersey.api.core.DefaultResourceConfig com.sun.jersey.api.core.ApplicationAdapter com.sun.jersey.api.core.ScanningResourceConfig com.sun.jersey.api.core.PackagesResourceConfig com.sun.jersey.api.core.ClassNamesResourceConfig com.sun.jersey.server.impl.application.DeferredResourceConfig
       at org.jboss.resteasy.integration.deployers.ResteasyScannerDeployer.scan(ResteasyScannerDeployer.java:175) [:6.0.0.Final]
      

       

      ... so it looks like there's a conflict between RESTEasy and Jersey. Is there anything I can put in my deployment descriptor (jboss-web.xml) to turn off RESTEasy for my app and tell JBoss that I have my own Jersey I want to use instead?

       

      I found this post:

       

        http://atmosphere-users-mailling-list.2493822.n2.nabble.com/Deploying-jquery-pubsun-on-JBoss-6-final-failed-td5908136.html

       

      .. which suggests that it's possible to remove RESTEasy from JBoss, but I can't really expect anybody using JBoss to do that. They're more likely to deploy Glassfish in parallel or deploy my app standalone under the embedded glassfish runtime.

       

      Additionally, JBoss AS 6 doesn't seem to like Jersey 1.5, complaining that com.sun.jersey.server.impl.cdi.CDIExtension is not serializable (http://pastebin.com/D4GxiBRX).

       

      I really don't know where to go from here. It "just works" on Glassfish and I've been fighting to get it going for half a day on JBoss. I realise now that that's because JBoss ships a different JAX-RS provider, but I'm still not sure quite where to go from here.

       

      My full apps' current POM is here, though I'd recommend the simpler test case linked to above instead: https://github.com/ringerc/postupload/blob/master/pom.xml

       

      ... and the full code for the project is here: https://github.com/ringerc/postupload/

       

       

      I think right now I'm going to get it running on the embedded glassfish container and/or tomcat or jetty. Standalone deployment is more important anyway, but I wanted to support JBoss as a "nice to have". Ideas on how that might be possible while retaining the use of Jersey 1.5?

        • 1. Classloader issues with Jersey 1.5 on JBoss AS 6
          alesj
          The main problem is that I need Jersey 1.5. JBoss bundles an older version.

          Don't we use RESTEasy?

           

          
          Caused by: java.io.NotSerializableException: com.sun.jersey.server.impl.cdi.CDIExtension
                    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
                    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
                    at java.rmi.MarshalledObject.<init>(MarshalledObject.java:101)
                    at org.jnp.interfaces.MarshalledValuePair.<init>(MarshalledValuePair.java:65)
                    at org.jnp.interfaces.NamingContext.createMarshalledValuePair(NamingContext.java:1429)
                    at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:569)
                    ... 74 more
          

          What about if you make this CDIExtension transient or somehow don't serialize it?

          Which object / instance is actually put into JNDI, which holds a ref to this CDIExtension?

          1 of 1 people found this helpful
          • 2. Re: Classloader issues with Jersey 1.5 on JBoss AS 6
            ringerc

            Er ... yes, apparently it _is_ RESTEasy. I made a stupid assumption there - and my only (weak) defense is that I've been flipping between app servers all week. If anything that makes it even stranger that I can't seem to deploy Jersey 1.5, though.

             

            I've put together a simple test case app that just tries to deploy Jersey 1.5 to JBoss. It's nothing but a pom.xml and web.xml (to start the servlet). It fails with:

             

            DEPLOYMENTS IN ERROR:
            Deployment "vfs:///C:/jboss-6.0.0.Final/server/default/deploy/jbossjerseydemo.war" is in error due to the following reason(s): org.jboss.deployers.spi.DeploymentException: Only one JAX-RS Application Class allowed. com.sun.jersey.api.core.ClasspathResourceConfig com.sun.jersey.api.core.ApplicationAdapter com.sun.jersey.api.core.ResourceConfig com.sun.jersey.api.core.ClassNamesResourceConfig com.sun.jersey.api.core.ScanningResourceConfig com.sun.jersey.api.core.DefaultResourceConfig com.sun.jersey.server.impl.application.DeferredResourceConfig com.sun.jersey.api.core.WebAppResourceConfig com.sun.jersey.api.core.PackagesResourceConfig
            
                      at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1370) [:2.2.0.GA]
                      at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1316) [:2.2.0.GA]
                      at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:968) [:2.2.0.GA]
                      at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.checkComplete(MainDeployerPlugin.java:82) [:6.0.0.Final]
                      at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.checkComplete(ProfileControllerContext.java:138) [:0.2.2]
                      at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:246) [:0.2.2]
                      at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
                      at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
                      at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
                      at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
                      at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
                      at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
                      at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
                      at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
                      at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
                      at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
                      at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
                      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_24]
                      at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_24]
                      at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_24]
                      at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_24]
                      at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_24]
                      at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_24]
                      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
                      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
                      at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
            
            

             

            (full server startup log here: https://github.com/ringerc/scrapcode/blob/master/testcases/javaee/jbossas6-jersey15-testcase/README)

             

            As for the CDI extension - it's part of Jersey its self, not my code. While I guess I can repackage Jersey to omit it, I'm just not going to go there for the sake of supporting another application server I don't personally need.

             

            Any ideas why Jersey might not be deploying? Is there any way to disable RESTEasy so I can use Jersey? Unfortunately I'm handling file uploads and need to use Jersey-specific extensions to the JAX-RS spec to do it properly.

             

            The demo app can be found at:

             

                https://github.com/ringerc/scrapcode/tree/master/testcases/javaee/jbossas6-jersey15-testcase

            • 3. Classloader issues with Jersey 1.5 on JBoss AS 6
              alesj

              Is there any way to disable RESTEasy so I can use Jersey?

              You can always simply remove resteasy.deployer/ from deployers/. :-)

              1 of 1 people found this helpful
              • 4. Classloader issues with Jersey 1.5 on JBoss AS 6
                ringerc

                The trouble is that that affects everything else deployed on the app server, including things that have the reasonable expectation to have a JAX-RS implementation present, or even rely on JBoss's RESTEasy being present.

                 

                There's no way to disable its activation just within the scope of my app? If not, anyone who wanted to deploy it would probably land up running another JBoss instance with RESTEasy disabled just for this one app, which would make very little sense when they could just run it standalone.

                 

                The idea of supporting JBoss was that it'd be easier for people who already had and knew JBoss to deploy the app. It doesn't seem like that's likely to be the case. Thanks for taking the time to consider this and try to help, though.

                 

                Maybe the OSGi support in JBoss AS 7 will - when it comes out - make it easier to selectively hide/disable components for particular webapps.

                • 5. Classloader issues with Jersey 1.5 on JBoss AS 6
                  maurenginaldo

                  I'm having the same problem. I wanted to disable resteasy.deployer for an application or if not possible, for all jboss.

                  Is to disable rather than delete?

                  • 6. Re: RESTEasy/Jersey conflict on JBoss AS 6
                    ceefour

                    I also get this problem.

                     

                    Try this :

                     

                    Disable RESTEasy in JBoss AS 7

                    RESTEasy needs to be disabled since it collides with the REST libraries included in the OpenAM.

                    To disable it, remove the jaxrs references from your configuration. For example if you are using either the standalone or domain configuration, you should edit one of these:

                    <JBoss_AS_7_Home>/standalone/configuration/standalone.xml
                    <JBoss_AS_7_Home>/domain/configuration/domain.xml

                    And remove the lines:

                     

                    ... <extension module="org.jboss.as.jaxrs"/> ... <subsystem xmlns="urn:jboss:domain:jaxrs:1.0"/> ... 

                     

                     

                    Source: https://wikis.forgerock.org/confluence/display/openam/Deploy+OpenAM+in+JBoss+AS+7

                    • 7. Re: RESTEasy/Jersey conflict on JBoss AS 6
                      ceefour

                      I have tried putting the following in WEB-INF/jboss-deployment-structure.xml :

                       

                      <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">

                          <deployment>

                              <exclusions>

                                  <module name="org.jboss.as.jaxrs"/>

                                  <module name="org.jboss.resteasy"/>

                                  <module name="org.jboss.resteasy.resteasy-jaxrs"/>

                              </exclusions>

                          </deployment>

                      </jboss-deployment-structure>

                       

                      But it doesn't work.

                       

                      What I can make work is disabling the module and subsystem in JBoss AS's standalone.xml as the reply above.

                      • 8. Re: RESTEasy/Jersey conflict on JBoss AS 6
                        ceefour

                        BTW a little background on my case.

                         

                        Why I needed to disable RESTEasy (actually just on this specific application) is twofold:

                        1. The app is using Jersey *client*, not the JAX-RS server.
                        2. The Jersey client is not directly used by the application, but by Spring Data Neo4j Rest Client, which we use.
                        • 9. Re: RESTEasy/Jersey conflict on JBoss AS 6
                          hgupta

                          Hi Hendy,

                          Are you able to find a solution via jboss-deployment-structure.xml file and not disabling the module completely by removing it from standalone.xml file?

                          Thanks.

                          • 10. Re: RESTEasy/Jersey conflict on JBoss AS 6
                            ceefour

                            In my case : http://spring-java-ee.blogspot.com/2011/12/how-to-resolve-spring-data-neo4j-jersey.html

                             

                            Ultimately I needed to

                             

                            1. exclude jersey-server from my app, and
                            2. use jboss-deployment-structure.xml to prevent loading JBoss's own jackson

                             

                            no change to instance wide standalone.xml needed  :-)

                            • 11. Re: RESTEasy/Jersey conflict on JBoss AS 6
                              manselva

                              Hi Hendy,

                              I am facing a similar issue. Can you share the changes you made in jboss-deployment-structure.xml? How did you exclude jersey-server?

                              Thanks.

                              -Mani

                              • 12. Re: RESTEasy/Jersey conflict on JBoss AS 6
                                jerome110011

                                Hendy Irawan schrieb:

                                 

                                In my case : http://spring-java-ee.blogspot.com/2011/12/how-to-resolve-spring-data-neo4j-jersey.html

                                 

                                Ultimately I needed to

                                 

                                1. exclude jersey-server from my app, and
                                2. use jboss-deployment-structure.xml to prevent loading JBoss's own jackson

                                 

                                no change to instance wide standalone.xml needed  :-)

                                Could you please share your solution with us?

                                What do you mean by 'excluding' the jersey-server? Where do I do this?

                                Should the jboss-deployment-structure.xml look like this? :

                                <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">

                                <deployment>

                                <exclusions>

                                <module name="org.codehaus.jackson.jackson-jaxrs"/>

                                <module name="org.codehaus.jackson.jackson-core-asl"/>

                                <module name="org.codehaus.jackson.jackson-mapper-asl"/>

                                </exclusions>

                                </deployment>

                                </jboss-deployment-structure>