2 Replies Latest reply on Jul 24, 2014 6:59 PM by Adam T

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

    Adam T Newbie

      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.

        • 1. Re: JAX-RS implicit dependencies are no longer implicit, Jackson blows up
          Tomaz Cerar Master

          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.

          • 2. Re: JAX-RS implicit dependencies are no longer implicit, Jackson blows up
            Adam T Newbie

            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.