First, note that the JAX-RS 1.x @Provider scanning has been made "obsolete", so to say as it was causing many weird issues esp. in multi-aplication setups in Java EE containers. Sometimes unexpected providers got picked which has lead to many nasty errors. This approach is therefore discouraged. Instead, in JAX-RS 2.0 we encourage all the JAX-RS extension implementations to use JAX-RS Features. This is a way how to encapsulate the extension and all the related configuration options into a single, type-safe public facade. At the moment (AFAIK) Jackson library does not provide such feature class, which is why we have added the integration module.
One thing is that we should update to Jackson 2.x. That's no question.
Other thing is what about the module and the feature. If Tatu (the Jackson guy) wants to take the responsibility and expose the feature directly in Jackson and maintain it there, I would be fine with that. Other option is to keep the integration module and the feature in Jersey and update it based on community feedback to better serve the needs of you and other Jersey+Jackson users. For instance, we would like to at some point start supporting entity filtering with Jackson. Having the Jackson module and feature in Jersey will make it easier for us to add such support.
I do not have the final answer to the above - I have not contacted Tatu about this at all. So right now we plan to stick to maintaining the Jackson feature in Jersey and updating it based on concrete improvement suggestions from community. Read: if you don't like something, tell us what you don't like or what is missing and we will let you know if we can or cannot fix it (and if yes, then how, and if not, then why) or we may ask you for a contribution if we do want to fix it but will not be able to do it any time soon.
[Tatu, if you can hear me, do you have any comments? :-)]
Marek
On 18 Dec 2013, at 18:38, Robert DiFalco <robert.difalco_at_gmail.com> wrote:
> Thanks for the great explanation. FWIW, I think you are doing too much
> work on your Jackson integration. For example, the code you provide is
> tied to 1.9 which has different package paths. Fortunately, Jackson
> provides what is needed and you only need to instruct users to include
> the jackson json provider jar. Nothing else is needed on the Jersey
> end.
>
> On Wed, Dec 18, 2013 at 9:28 AM, Marek Potociar
> <marek.potociar_at_oracle.com> wrote:
>> We advertise MOXy as the recommended default, because it can support both
>> JSON and XML as well as full set of JAXB annotations and more goodies (e.g.
>> externalized bindings etc.). IOW, you can code your data model POJOs once
>> and have them exposed as both JSON and XML for free. MOXy is also by default
>> available in GlassFish and WebLogic, so you do not need to install any
>> additional libraries in these app servers.
>>
>> That said, you can use Jackson if you prefer it for some reason. Here's how:
>> https://jersey.java.net/documentation/2.4.1/media.html#json.jackson
>>
>> As for other goodies, MOXy has a lot of extra features. From those directly
>> related to Jersey, for example we currently support entity filtering with
>> MOXy JSON providers. (To be fair, this is something we would like to support
>> with Jackson too, sometime soon.)
>>
>> Performance-wise, our internal tests indicate that Jackson is slightly
>> faster at the moment. However, as soon as real network calls are involved,
>> the performance difference is marginal. In general, you want to worry about
>> design of your REST services wrt. latency caused by network and database
>> communication; small server-side processing performance differences are
>> irrelevant (as long as the server is scalable).
>>
>> Marek
>>
>> On 13 Dec 2013, at 22:41, Robert DiFalco <robert.difalco_at_gmail.com> wrote:
>>
>> I'm migrating from Jersey 1.9 to 2.x. Wow, what a lot of odds and ends to
>> relearn. It looks like Moxy is preferred over Jackson (which I use in other
>> parts of my code). I can make this change but before I do I have some
>> questions:
>>
>> 1. Why is MOXy the "preferred" approach for Jersey 2.x?
>> 2. Why was it selected over Jackson?
>> 3. Have there been any speed comparisons between Moxy and Jackson for
>> POJO mapping?
>> 4. Should I just stick with Jackson for Jersey 2.x or will I get some
>> special goodness from MOXy that I wont with Jackson?
>>
>>