On 18 Dec 2013, at 21:18, Robert DiFalco <robert.difalco_at_gmail.com> wrote:
> 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.
At the moment we only support all-or-nothing enabling/disabling of META-INF/services scanning. If Jackson will not give us a hand and remove their entries, we could add support for selective per-implementation class disabling and use it in the JacksonFeature.
>
> 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).
Would the custom OM context resolver that I have mentioned earlier work? You could just implement it to always provide the same instance.
>
> 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.
There is a property to disable META-INF/services scanning (I have already found it IIUC).
>
> 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. :)
No problem at all. :)
Marek
>
> 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?
>>
>>
>>