JAX-RS implicit dependencies are no longer implicit, Jackson blows up

[skrooks]

According to the WildFly docs on Implict Module Dependencies, the JAX-RS subsystem has several implicit dependencies that should only get loaded if there are any JAX-RS annotations found in a deployment. Unfortunately, it looks like the trigger condition that checks for those annotations was removed [git commit], citing "we need to add these from all deployments, as they could be using the JAX-RS client". I don't know if the docs need to be updated to reflect this change, or maybe the devs have a better idea.

The thing that bit me was an incompatibility between non-matching versions of jackson-core-asl and jackson-mapper-asl. The war I was trying to deploy had an older version of jackson-core-asl and jackson-mapper-asl (v1.5.6 in this case), but the deployment failed on WildFly 8.1.0.Final due to a Jackson error (java.lang.NoSuchMethodError: org.codehaus.jackson.type.JavaType.<init>(Ljava/lang/Class;)). I updated my standalone.bat file to run java with -verbose:class to see what was being loaded and from where. I noticed jackson-core-asl-1.9.13.jar would be loaded from the WildFly modules, the jackson-core-asl-1.5.6.jar file in my war was ignored, but my jackson-mapper-asl-1.5.6.jar would get loaded. After digging around, I found that the org.jboss.as.jaxrs module pulls in the org.codehaus.jackson.jackson-core-asl module as a "system" dependency (jackson-core-asl v1.9.13 in WildFly v8.1.0.Final) as a fix to bug AS7-1276 [git commit]. Deploying my war on JBoss AS 7.1.1.Final worked since the jaxrs trigger condition was still in place as of that version. I built a custom version of the WildFly jaxrs module with the trigger condition added back in and the war deployment worked (it loaded my jackson-core-asl-1.5.6.jar as expected). To resolve my issue, I'm looking at providing a jboss-deployment-structure.xml file to either 1) exclude the jaxrs module and subsystem since my war doesn't need it, or 2) add a dependency on the jackson-mapper-asl module provided by WildFly and update my jackson dependencies in Maven accordingly.

[ctomc]

Hey,

Your forensics are quite good, but you missed actuall change that caused your problem

the change that is affecting you is this https://github.com/wildfly/wildfly/commit/8510bc122868512aff7744ca027b3c9d5d08dd03

we switched json provider from jackson1 to jackson2, which is the provider & dependency that is not added by default.

Before this change jackson1 dependencies ware added to classpath.

Jackson2 is much better & faster than v1 ever was, I would recommend you to upgrade to jackson2 and all your problems should go away.

see http://wiki.fasterxml.com/JacksonUpgradeFrom19To20 on few hints on how to do upgrade.

if you cannot upgrade to v2, you can still add jboss-deployment-structure.xml and exclude new provider and add old one and your app will still work as before.

[skrooks]

Yes, I saw that it changed to the resteasy-jackson2-provider, but it's still adding a dependency on jackson-core-asl (lines 64 and 86 in the commit you mentioned), so if I understand correctly, it's now loading both Jackson v1 (core only) and Jackson v2.

My war currently uses Spring Web MVC for REST stuff instead of RESTEasy. I tried adding entries to my jboss-deployment-structure.xml file to exclude the jaxrs subsystem and associated module, and it worked ok for WildFly 8.1.0.Final. I tried loading the same on JBoss 7.1.1.Final as well (what we're currently using) but it doesn't support the exclude-subsystems tag. Right now I've got the jboss-deployment-structure.xml set to exclude the jackson-core-asl and jackson-mapper-asl modules so it will use the versions in my war. Not saying it's the best solution, but it seems to work ok on both WildFly and JBoss AS.