0

I'm developing an app for Glassfish 4.0, which uses Jersey 2. I want to use Jackson as the JSON provider for Jersey.

I have updated the Jersey version in Glassfish, which helps with the CDI issues.

Ideally, I would like to use the newer (fasterxml) version of Jackson.

Currently, I have the app configured to use the version of Jackson provided by Glassfish (codehaus).

So, I know how to use Glassfish 4 with the provided Jersey and Jackson. I also know how to configure the latest Jersey to use the latest Jackson in a standalone Jersey app.

However, I can't deploy and run an app in Glassfish 4.0 with the latest version of Jersey and Jackson. I tried adding the maven dependencies, with no success. I suspect that Glassfish is somehow using it's own versions, which then conflicts with the ones from maven.

Should this work? I mean, should an application be able to provide its own versions of Jersey and Jackson and have Glassfish use them? I ask because I'm aware of some bugs in Glassfish 4 that may possibly be the cause of my problems.

Rick
  • 362
  • 5
  • 16
  • See the answer provided [here](http://stackoverflow.com/questions/20709827/force-glassfish-4-to-use-jackson-2-3) – Rick Dec 27 '13 at 17:45

1 Answers1

0

It is possible for different applications to use different major version of Jackson; so older code can use Jackson 1.x, and newer 2.x. This because they live in different Java packages and do not conflict.

Jersey (and JAX-RS in general) have flexible extension mechanism, so it is possible to use either Jackson version with both Jersey 1.x and 2.x. But to do that, you usually should use Jackson JAX-RS provider directly, and not via Jersey-specific mechanisms. With Jackson 2, it means getting jar for https://github.com/FasterXML/jackson-jaxrs-providers, adding it in classpath, and letting it use auto-registration. No additional configuration should be needed.

Finally, I don't think Glassfish 4 presents problems.

So this should be completely possible. But configurability has been one of complicated areas for Jersey, partly since documentation is incomplete in places; and also because sometimes explanations do not show the simplest way to achieve what you want.

StaxMan
  • 113,358
  • 34
  • 211
  • 239
  • When I include the jersey dependencies (for 2.4.1) via maven, my app won't deploy because of some CDI issue. I can post my pom.xml if anyone is interested, but there appears to be an issue somewhere in glassfish or weld or cdi or somewhere. – Rick Dec 11 '13 at 17:48
  • Rick, same issue here; did you resolve it? I assume glassfish ships with an older version of jackson and somehow the newer versions that are added to the artifact are ignored? – Paul Bormans Jun 15 '16 at 06:59