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?

[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?

[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

[alesj]

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

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

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

[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?

[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

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

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

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

[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  :-)

[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

[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>