How do I deal with Glassfish included libs crashing with application supplied libs?

Question

A CXF JAX-RS application I have uses jackson to marshal POJOs to JSON. This works for the most part, but the other day it failed with a NPE when marshalling a deeply nested object.

After some investigation I found out that Jackson was included in Glassfish 3 (through Jersey) and after removing jackson-core-asl.jar, jackson-jaxrs.jar, jackson-mapper-asl.jar and jackson-xc.jar everything worked beautifully. I guess that Jackson 1.7.1 (included in GF3) had some bug that was fixed in the version shipped with my application (1.8).

Now the question is, why did I even have to do this in the first place? I would have thought libraries that are included in my war files should take presedence over any libraries in Glassfish's /modules directory.

Is there a cleaner way to do this than removing jars from the app server? Maybe there are other applications that depend on these jars ...

On a side note, the problem still exists with our GF2 container, but I cannot find any jackson libraries in the /lib folder (there is no /modules folder like in GF3). Any clues on where Jackson might be hiding in GF2 (if at all)?

Answer 1

consider using : asadmin deploy --libraries ...

Ref: http://blogs.oracle.com/alexismp/entry/more_with_deploy_libraries

Answer 2

Tell the Webapp classloader to prefer JARs provided by your WAR.

Add in your WEB-INF/sun-web.xml (or WEB-INF/glassfish-web.xml):

...
<class-loader delegate="false"/>
...

See http://jersey.java.net/nonav/documentation/latest/glassfish.html#d4e1927

Answer 3

Jackson is included by Jersey and Hadoop, if you might be running Jersey or interact with Hadoop system; and versions included are often old. So this could be one source for "ancient Jackson" problems.