The only problem I see is if you include the MOXy jars, right? The
issues I have with your approach is that (a) it does not allow me to
use a singleton JacksonJsonProvider that uses a single ObjectMapper
for everything, (b) it does not allow me to rev Jackson independent of
Jersey version, and (c) it does not allow me to customize settings on
the provider for example adding the AfterburnerModule to ObjectMapper.
Again, I'm not sure why this isn't pluggable and requires Jersey
specific code (such as the MOXy disable feature setting) to add
different JSON processors.
Also, and maybe I found a bug, but the Service Finder seems to find
ANYTHING in the class path that is annotated with @Provider and load
it. So even with the JacksonFeature implementation in Jersey, any
@Provider annotated classes are still be instantiated in my
deployment. The only way I have been able to suppress them was to
enable CommonProperties.METAINF_SERVICES_LOOKUP_DISABLE. Which I'm
sure is not what is intended. But it's weird having packages outside
of what I registered with "packages()" get scanned.
On Wed, Dec 18, 2013 at 10:27 AM, Marek Potociar
<marek.potociar_at_oracle.com> wrote:
> Just a warning to all Jersey users:
> Please be aware that the approach described bellow is not officially
> supported and may lead you into troubles in the future, esp. wrt. multiple
> JSON providers getting registered in certain setups, which may potentially
> errors caused by conflicting, competing JSON entity providers.
>
> As for Jackson version, it is true that Jersey now still supports 1.9,
> anyone in the community would like to submit a pull request with the Jackson
> lib version upgrade?
> Here's the open task: https://java.net/jira/browse/JERSEY-2107 (I have
> scheduled it for Jersey 2.6)
>
> Marek
>
> On 14 Dec 2013, at 04:03, Robert DiFalco <robert.difalco_at_gmail.com> wrote:
>
> Just a heads up so that people don't have to deal with the craziness I just
> went through.
>
> Setting up Jersey 2.4.1 to work with Jackson is exceedingly simple, that is
> unless you read the Jersey tutorials and documentation.
>
> The JacksonFeature will pull in Jackson 1.9! I don't really think anyone
> uses this version anymore, most of us use fasterxml 2.x.
>
> Just do this:
>
> public class RestApplication extends ResourceConfig {
> public RestApplication() {
> packages( "com.myapp.rest", "com.fasterxml.jackson.jaxrs.base" );
> }
> }
>
> Then add this to your pom.xml:
>
> <dependency>
> <groupId>com.fasterxml.jackson.core</groupId>
> <artifactId>jackson-databind</artifactId>
> <version>${jackson.version}</version>
> </dependency>
> <dependency>
> <groupId>com.fasterxml.jackson.jaxrs</groupId>
> <artifactId>jackson-jaxrs-json-provider</artifactId>
> <version>${jackson.version}</version>
> </dependency>
>
> Completely forget about JacksonFeature AND DO NOT PUT THIS IN YOUR pom.xml:
>
> <dependency>
> <groupId>org.glassfish.jersey.media</groupId>
> <artifactId>jersey-media-json-jackson</artifactId>
> <version>${jersey.version}</version>
> </dependency>
>
> It's super simple, everyone seems to make it complicated. Now, listen, this
> is trial and error so maybe there is a reason for all of the complexity that
> the Jersey docs suggest for Jackson or all the blogs and stack overflow
> answers. But Just the two jackson pom entries and the fasterxml provider
> path is all I needed to use Jackson 2.3.0.
>
>
>
>
>