Thanks Mark, makes sense. I think then that updating JacksonFeature to
use 2.3.0 will be problematic as the provider jar defines
META-INF.services that automatically load JacksonJsonProvider.
As for options, I would like to be able to register it as an Object
(rather than a class) so that it can be a singleton and that I can add
things to the ObjectMapper such as the AfterburnerModule. The
currently feature not only uses 1.9 but it is instantiated for every
request (which is not necessary for ObjectMapper which is a heavy
weight object).
Right now I am just copying the classes that make up
JacksonJsonProvider and putting it into my own feature that registers
it as a singleton. Then I don't have to include the Jackson jar that
has the META-INF.services defined. I also not that Jersey uses
META-INF.services for its own internal stuff. I'm not super familiar
with this functionality but it seems like an all or nothing approach.
Those classes in services are ALWAYS instantiated (regardless of the
jar) by ServiceFinder. Or they are all NOT instantiated if the DISABLE
meta inf is enabled.
Again, I'm just learning all this stuff so I apologize if my questions
or approaches are naive. All I want ultimately is to configure my own
Json Provider using the settings I like (singleton or otherwise) and
that uses the implementation I like and not mess things up. :)
On Wed, Dec 18, 2013 at 12:08 PM, Marek Potociar
<marek.potociar_at_oracle.com> wrote:
> 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?
>
>
>