As for the conflicts, in Jersey 2.x we support following JSON providers:
Java EE JSON Processing, Jackson, Jettison and MOXy (See also
https://jersey.java.net/documentation/latest/media.html#json)
As for the single object mapper, you can supply a custom ObjectMapper ContextResolver.
As for independent Jackson version (b), well, Jackson 2.x, quite naturally, has decided to polish up the packages and APIs which make our module Jackson 1.x incompatible with it. We can and will fix this and update to Jackson 2.x (soonish). You can also give it a try and contribute a patch yourself to expedite the upgrade if you feel so strongly about this - but certainly no pressure :)
Alternatively, you can just go "wild" :) and register the Jackson providers on your own. But then you are really on your own. If you run into an issue, unless you provide a self-contained, easily compilable and runnable project with source code that reproduces your issue, we will not be able to help. Why self contained? Because in such case every bit of configuration may matter.
Ad (c), I think that the custom context resolver for the object mapper can work. We can also improve the Feature API based on your CONCRETE suggestions (or pull requests).
As for the bug - it's not a Jersey bug. It's actually a problem in Jackson. JAX-RS spec mandates us to look for providers by default in META-INF/services. So we do. This is not to be mistaken for package scanning though. If Jackson 2.x has META-INF/services entries and you put in on class path, we will find these (unless you explicitly disable the META-INF/services scanning, of course). See - how quickly one can get into troubles with unmanaged automatic provider discovery... Please ask Jackson leads to consider removing these entries from their jars - or at least produce additional jar artifacts that would not contain these entries.
Marek
On 18 Dec 2013, at 20:21, Robert DiFalco <robert.difalco_at_gmail.com> wrote:
> 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.
>>
>>
>>
>>
>>