Re: [jackson-user] Configure ObjectMapper using Jersey and Guice

[Christopher Currie]

[Cross posting to the new user list, which may provide more responses.]

Caveat: I've not used Jersey 2.x, as I use dropwizard (a framework you may want to look at) which is still on 1.x.

But from what I've read, Jersey decided that it would remove the built-in dependency management it had in the 1.x branch and move to HK2 [1] (unsurprising, as it is another Glassfish project). HK2 *does* have a Guice bridge [2], so from the Jersey point of view, they have "solved" this issue.

That said, I've no idea how hard it is to set up, so YMMV. But if you can get Guice to provide Resource classes to Jersey, you shouldn't need any more Guice configuration. You need to make sure you have a dependency on 'jackson-jaxrs-json-provider' [3] that matches the version of Jackson you're using, and that you bind your instance of ObjectMapper in the way that the HK2 bridge expects so that Jersey can find it.

HTH,

Christopher

[1] https://hk2.java.net/

[2] https://hk2.java.net/guice-bridge/

[3] https://github.com/FasterXML/jackson-jaxrs-providers

On Sun, Sep 22, 2013 at 5:39 PM, Danilo Reinert <danilo...@gmail.com> wrote:

Nathan, you're right about that. Configuring anything with Guice is as simple as bind the abstraction to the implementation. It's not different with Jersey. In Jersey 1.x it worked like that. The actual problem is that Jersey 2 does not provide integration with Guice yet. I'm stuned that Jersey just released the version 2.4 (yesterday) and they did not solved this issue yet! I'm considering changing to Resteasy...

--
D. Reinert

On Sun, Sep 22, 2013 at 8:43 PM, Jones, Nathan <Nathan...@airnz.co.nz> wrote:

I haven't had experience with both Guice and Jersey but for Guice and CXF we manually registered a JacksonJsonPovider using the CXF Guice module (https://code.google.com/p/guice-cxf/). Doing something like this should be very straight forward with Jersey since this is a more populate JAX-RS implementation. The Javadoc on com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider might give you some hints.

Note that we never use an object mapper directly; we only create an instance once to be used by the JacksonJsonPovider and then just return Jackson-annotated objects from our JAX-RS endpoints.

 - Nathan

________________________________________
From: Danilo Reinert [mailto:danilo...@gmail.com]
Sent: Saturday, 21 September 2013 8:57 a.m.
To: us...@jackson.codehaus.org
Subject: [jackson-user] Configure ObjectMapper using Jersey and Guice

I'm trying to customize the ObjectMapper and Reader to be used in my Jersey/Guice Application.

I've already create a Guice Provider for ObjectMapper and Reader based on this topic http://stackoverflow.com/questions/16757724/how-to-hook-jackson-objectmapper-with-guice-jersey , but it didn't work.

I'm using jackson 2.2.3, jersey 2.2 and guice 3.0.

How can I accomplish that?


--
D. Reinert

Good planets are hard to find - please think of the environment before you print this email.
____________________________________________________________________
CAUTION - This message may contain privileged and confidential
information intended only for the use of the addressee named above.
If you are not the intended recipient of this message you are hereby
notified that any use, dissemination, distribution or reproduction
of this message is prohibited. If you have received this message in
error please notify Air New Zealand immediately. Any views expressed
in this message are those of the individual sender and may not
necessarily reflect the views of Air New Zealand.
_____________________________________________________________________
For more information on the Air New Zealand Group, visit us online
at http://www.airnewzealand.com
_____________________________________________________________________


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Danilo Reinert]

Christopher, I've read about the H2K integration. It seems too "workaround" to me adding a whole project only for the integration.

But I didn't know that "from the Jersey point of view, they have 'solved' this issue." Now, I'm horrified!.

I've asked on Jersey forum about this. In this issue, it has been said that "development [of Guice integration] is being held up on the Jersey end of things, not on H2K" 

I'll wait some official response about this question.

Thank you all for helping.

--
D. Reinert

[Danilo Reinert]

Just to stress my indignation...

H2K is a dependency injection framework, and if you use it along with Guice you'll be forced to use a particular H2KInject annotation when injecting by H2K is desired/necessary. This is annoying!!!!

Who had the idea of two injection dependency frameworks working together?!

From guice-bridge documentation, "Any Guice service that can be created with this Injector will now search the provided ServiceLocator when it encounters a service that is injected with the HK2Inject annotation". 

I.e, you're not using Guice, you're using H2K with Guice packing.

--
D. Reinert

[Christopher Currie]

On Mon, Sep 23, 2013 at 8:42 AM, Danilo Reinert <danilo...@gmail.com> wrote:

Christopher, I've read about the H2K integration. It seems too "workaround" to me adding a whole project only for the integration.

Jersey 2 already depends on HK2, so I don't think you're actually adding another project. AFAICT, HK2 is what makes all of the mechanics of method interception for @QueryParam and @Context arguments work, as opposed to their own implementation that was used in Jersey 1.

That said, it looks like the HK2 bridge is not sufficient for Guice integration to work, because, as you say, it's held up by the Jersey team. [1][2]

But I didn't know that "from the Jersey point of view, they have 'solved' this issue." Now, I'm horrified!.

I apologize, I didn't mean to speak for the Jersey team. I was simply extrapolating from what I observed, and how I would build a similar system. It's similar to choosing a logging API; at some point you either have to pick one, or abstract them all into a common API. The fact that their choice has compatibility challenges they haven't solved was a point I had missed.

They may have plans to do the abstraction, in order support Guice directly; or they may feel that the solution is to refactor their code to allow the HK2 bridge to work. It's impossible to say at this time, since the amount of feedback coming from the development team is fairly low.

H2K is a dependency injection framework, and if you use it along with Guice you'll be forced to use a particular H2KInject annotation when injecting by H2K is desired/necessary. This is annoying!!!!

This does appear to be a significant weakness, but without it I would expect you'd run into circular dependencies (HK2 can't find a binding, so it asks Guice, who doesn't have it either, and around you go).

The point seems moot, though, since the Guice bridge doesn't appear to be enough at this time.

 

All this to say: this is a bit off-topic for the Jackson list. Guice is supported by other JAX-RS implementations, including Jersey 1. It appears you're faced with a choice between Guice and Jersey 2, unless you want to volunteer the time to work in the Jersey 2 code base for the support that you need.

CC

[1] https://java.net/jira/browse/JERSEY-1950

[2] https://java.net/jira/browse/HK2-121

[Tatu Saloranta]

Also: although moving to another JAX-RS implementation has its costs, you could also consider RESTeasy, or CXF. The only (?) concern I would have is that DropWizard is based on Jersey, but it uses Jersey 1 anyway.

As much as I respect Jersey for its past work as RI & high-quality general-purpose implementation, I am beginning to feel that it's been "Oracleized", meaning that it's become more of a pawn of corporate strategy, victim of Not-Invented-Here & mandates on components to use.

Instead of trail-blazing using best available components; not just ones that Mother Corporation provides. Things like using MOXy as default JSON provider, some DI framework no one else uses; java.utl.logging (ditto), and the list goes on.

Given this, investigating other less-visible JAX-RS choices does not seem like a bad idea.

I would personally be interested in how other choices compare. Choice is good; as is exercising it.

-+ Tatu +-

 

[Danilo Reinert]

Tatu, I have this same feeling about Jersey. In the transition period, it was not been updated for at least 4 months. And now, significant changes are happening, for worse. This centralizing corporate path Jersey is tracking is harmful.

About my question on jersey forum, no answers were given yet. This unfortunate behavior is forcing me to try other projects.

Resteasy has been evolving in a great rhythm. As I'm not a dropwizard user, I'll try to migrate my JAX-RS impl to Resteasy and experiment it for a few months. I've read good things about this new version 3. The documentation is fair well. And it supports Guice! =)

Yeah, choice is good.

--
D. Reinert

[Tatu Saloranta]

On Tue, Sep 24, 2013 at 2:55 PM, Danilo Reinert <danilo...@gmail.com> wrote:

Tatu, I have this same feeling about Jersey. In the transition period, it was not been updated for at least 4 months. And now, significant changes are happening, for worse. This centralizing corporate path Jersey is tracking is harmful.

About my question on jersey forum, no answers were given yet. This unfortunate behavior is forcing me to try other projects.

Ok. As unfortunate as this direction is, at least it's not just my imagination regarding direction Jersey seems to go. Part of it may also been due to departure of original author(s).

 

Resteasy has been evolving in a great rhythm. As I'm not a dropwizard user, I'll try to migrate my JAX-RS impl to Resteasy and experiment it for a few months. I've read good things about this new version 3. The documentation is fair well. And it supports Guice! =)

I will be interested in hearing about your experiences; and perhaps on longer term it could even help DropWizard's strategic planning.

 

Yeah, choice is good.

 

Hooray for choice!

-+ Tatu +-

--
D. Reinert

On Tue, Sep 24, 2013 at 4:10 PM, Tatu Saloranta <ta...@fasterxml.com> wrote:

On Mon, Sep 23, 2013 at 9:35 AM, Christopher Currie <chris...@currie.com> wrote:

On Mon, Sep 23, 2013 at 8:42 AM, Danilo Reinert <danilo...@gmail.com> wrote:

Christopher, I've read about the H2K integration. It seems too "workaround" to me adding a whole project only for the integration.

Jersey 2 already depends on HK2, so I don't think you're actually adding another project. AFAICT, HK2 is what makes all of the mechanics of method interception for @QueryParam and @Context arguments work, as opposed to their own implementation that was used in Jersey 1.

That said, it looks like the HK2 bridge is not sufficient for Guice integration to work, because, as you say, it's held up by the Jersey team. [1][2]

But I didn't know that "from the Jersey point of view, they have 'solved' this issue." Now, I'm horrified!.

I apologize, I didn't mean to speak for the Jersey team. I was simply extrapolating from what I observed, and how I would build a similar system. It's similar to choosing a logging API; at some point you either have to pick one, or abstract them all into a common API. The fact that their choice has compatibility challenges they haven't solved was a point I had missed.

They may have plans to do the abstraction, in order support Guice directly; or they may feel that the solution is to refactor their code to allow the HK2 bridge to work. It's impossible to say at this time, since the amount of feedback coming from the development team is fairly low.

H2K is a dependency injection framework, and if you use it along with Guice you'll be forced to use a particular H2KInject annotation when injecting by H2K is desired/necessary. This is annoying!!!!

This does appear to be a significant weakness, but without it I would expect you'd run into circular dependencies (HK2 can't find a binding, so it asks Guice, who doesn't have it either, and around you go).

The point seems moot, though, since the Guice bridge doesn't appear to be enough at this time.

 

All this to say: this is a bit off-topic for the Jackson list. Guice is supported by other JAX-RS implementations, including Jersey 1. It appears you're faced with a choice between Guice and Jersey 2, unless you want to volunteer the time to work in the Jersey 2 code base for the support that you need.

Also: although moving to another JAX-RS implementation has its costs, you could also consider RESTeasy, or CXF. The only (?) concern I would have is that DropWizard is based on Jersey, but it uses Jersey 1 anyway.

As much as I respect Jersey for its past work as RI & high-quality general-purpose implementation, I am beginning to feel that it's been "Oracleized", meaning that it's become more of a pawn of corporate strategy, victim of Not-Invented-Here & mandates on components to use.

Instead of trail-blazing using best available components; not just ones that Mother Corporation provides. Things like using MOXy as default JSON provider, some DI framework no one else uses; java.utl.logging (ditto), and the list goes on.

Given this, investigating other less-visible JAX-RS choices does not seem like a bad idea.

I would personally be interested in how other choices compare. Choice is good; as is exercising it.

-+ Tatu +-

 

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To post to this group, send email to jackso...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Danilo Reinert]

Thanks for sharing Pascal!

I've noticed Bill Burke's active participation, being one of the leaders of the project.

It is good to know that experienced people are taking responsibility in a project and moving it ahead.

Regarding to Jersey, I've just remember what a old colleague of my always says: "Sun never finishes what she starts". 

--
D. Reinert

On Wed, Sep 25, 2013 at 2:34 PM, Pascal Gélinas <pascal....@nuecho.com> wrote:

I thought I might share my experience with RESTEasy in this discussion. We've been using RESTEasy with Jackson for the past 2 years and a half, since 2.0.1. We've rarely had any issues with its integration with Jackson or DI framework (we have our own DI framework). In the 2 year history, we've upgraded to Jackson 2 and RESTEasy 3 without any major hurdle.

We didn't have any problem using new features, like GZIP support, pre-emptive authentication and other things that are not necessarily implemented by RESTEasy. Also, its client-side implementation using dynamic proxy is a charm to work with, given that you use an interface to declare your JAX-RS Annotations.

Hope this helps,
Pascal.

[Ted M. Young]

Forgive me if this has been answered/documented elsewhere, but I'm working on a project that, for the foreseeable future, is using Jersey 2.x. This thread went down the road of discussing the DI issues, but in my case we're using the JAX-RS provider[1], and we're not using Guice, so it's not clear to me from the JavaDoc how to configure the ObjectMapper that then gets provided to Jersey. In other words, I don't want to provide a new ObjectMapper (which is what is implied by the JavaDoc for JacksonJsonProvider [2]) , I just want to configure the one already provided by JacksonJsonProvider. The common answers that I could find was subclassing JacksonJsonProvider here[3] and here [4]. This seems kludgy. The Jersey docs mention a ContextResolver<ObjectMapper> here[5], but that would seem to be a substiture for the JAX-RS provider. Perhaps that's the right thing to do? But I'm not sure, so any guidance here would be appreciated.

;ted

[1] https://github.com/FasterXML/jackson-jaxrs-providers

[2] http://fasterxml.github.io/jackson-jaxrs-providers/javadoc/2.3.0/com/fasterxml/jackson/jaxrs/json/JacksonJsonProvider.html

[3] https://gist.github.com/mpellegrini/7572274

[4] http://jackson-users.ning.com/forum/topics/configuring-custom-modules-when-using-jaxrs-provider?commentId=5286555%3AComment%3A27807

[5] https://jersey.java.net/documentation/latest/media.html#json.jackson

[Tatu Saloranta]

It should be fine to inject ObjectMapper instance: JAX-RS provider is sort of orthogonal to configuration of ObjectMapper, so using differently configured instance is a supported (and anticipated) use case.

-+ Tatu +-

[Ted M. Young [@jitterted]]

On Fri, Jan 3, 2014 at 3:33 PM, Tatu Saloranta <tsalo...@gmail.com> wrote:

It should be fine to inject ObjectMapper instance

Do you mean by using @Provider as described in [1], or did I misunderstand? I just found out that [1] only works for Jackson 1.x (I think there's a JIRA for making it work with Jackson 2.x, but until then...).

JAX-RS provider is sort of orthogonal to configuration of ObjectMapper, so using differently configured instance is a supported (and anticipated) use case.

Someone else noted that we'd end up with two differently configured instances [2], when I think we want just one? 

[1] https://jersey.java.net/documentation/latest/media.html#d0e6652

[2] https://github.com/svenwltr/example-grizzly-jersey-jackson/issues/1

;ted

 

 

--
You received this message because you are subscribed to a topic in the Google Groups "jackson-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jackson-user/PUicZLhZ8jg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jackson-user...@googlegroups.com.

[Tatu Saloranta]

I honestly do not know. I don't use JAX-RS directly much more.
I hope others can comment on this.

One related development is that of possibly publishing two kinds of flavors of provider jars: one with SPI registration, and one without. Use of latter should at least prevent double registration, and let you construct provider with necessary ObjectMapper.

-+ Tatu +-

--

You received this message because you are subscribed to the Google Groups "jackson-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.

[Ted M. Young [@jitterted]]

Interesting about the provider JARs and preventing automatic registration. Is this what you were referring to in http://jira.codehaus.org/browse/JACKSON-127? If so, has the situation changed with JAX-RS 2.0? I'm finding the configuration/startup process of JAX-RS (well, Jersey) and how it loads the implementations of the MessageBodyReader/Writer confusing (i.e., not well-documented).

;ted

[Tatu Saloranta]

Yes, that is pre-cursor to inclusion. My thinking with 1.x was that legacy impls based on Jettison et al might still be useful, but that users would migrate away from those.

And as such, Jackson 2.x should be able to use auto-registration.

Jackson versions at the time of that issue still used Ant, I think, which made it slightly easier to build different jars.

-+ Tatu +-