9

I have been trying to know if JacksonFeature.class is still needed for Jersey 2.17. I can't see any difference between the outputs between codes that JacksonFeature.class is registered or not.

Then, I forked a code from codingpedia codingpedia, removed JacksonFeature.class, upgraded to Spring 4.1.2 and jersey 2.17, updated the codes and the test still passed.

So I created a very simple web service to test this again github link, having in mind to remove all the moving parts and still worked. So do we still need to register JacksonFeature?

Paul Samsotha
  • 205,037
  • 37
  • 486
  • 720
Francis Zabala
  • 1,037
  • 2
  • 11
  • 30

1 Answers1

11

Yeah I don't know why that tutorial they are using Jersey 2.9, but for the jersey-media-json-jackson artifact, they are using 2.4.1. Generally you should keep the Jersey (related artifact) versions the same. In the actual Github Project, the author changed this to use the project's ${jersey.version} (which is 2.14), which makes more sense.

But to answer your main concern, starting from version 2.9 the jersey-media-json-jackson module, takes part in the AutoDiscoverable classpath scanning, which involves Java's Service Provider mechanism. You can see this change by switching back and forth to the 2.8 version and and 2.9 (an upward) version of this module. You will see in the META-INF/services, the file org.glassfish.jersey.internal.spi.Autodiscoverable (which list the JacksonAutoDiscoverable implementation), in version 2.9 (and up). With this, the feature does not need to be explicitly configured, unless the the auto-discoverable feature is disabled (which is possible to explicitly do).

And just for completeness, when you have MOXy on the classpath, and you don't explicitly register the Jackson feature, MOXy will be used, as MOXy is the default provider. Even though you may not have a explicit dependency on MOXy, in situations like the case of using Glassfish server, it has the MOXy artifact, in which case we can either explicitly register the Jackson Feature, which automatically disables MOXy, or we can explicitly disable MOXy with the property ServerProperties.MOXY_JSON_FEATURE_DISABLE set to true

Paul Samsotha
  • 205,037
  • 37
  • 486
  • 720
  • 1
    ah... now it all makes sense. Thanks! So registering the feature class in the application would be part of optimizing the project. But of course, the autodiscoverable classpath scanning should be disabled to notice the difference. Thanks peeskillet! – Francis Zabala Mar 25 '15 at 04:46
  • Thanks again! That latest edit you added is valuable. I would've never guessed how MOXy much it is involved in a Jersey based project. Good stuff! – Francis Zabala Mar 25 '15 at 05:09