Hey Mike,
We are suspecting that we do indeed have 2 instances, but as the other
reader (Rick) says, the one that we are configuring is the one used and so
it's really only the resources used for an inert/unused instance of it,
right? Is there a reason to be concerned about this approach do you think?
Thanks for your update!
On Sat, Feb 1, 2014 at 4:43 PM, Rick McCallum <discotrix_at_gmail.com> wrote:
> Yeah, I'm pretty sure I do have two copies of the mapper, but the one
> that's being used is the one I configure, so it's just an unused object
> reference, at least, so it seems so far.
>
>
> On Fri, Jan 31, 2014 at 11:36 AM, Michael Iles <michael.iles_at_gmail.com>wrote:
>
>> You're probably ending up with two instances of the Jackson provider.
>> Do you have logging enabled? Have a look at this for illustration:
>> https://github.com/svenwltr/example-grizzly-jersey-jackson/issues/1
>>
>> Mike.
>>
>> On 31 January 2014 14:25, Jack Lista <jackalista_at_gmail.com> wrote:
>> > Hi, thanks for your replies, I found some encouraging things that may
>> help
>> > both Mike and Pedro. Let me outline it and then if you have more
>> questions
>> > give me a yell.
>> >
>> > We have an application class like so:
>> >
>> > public class FooApplication extends ResourceConfig {
>> >
>> > ...
>> > ObjectMapper mapper = new ObjectMapper();
>> > mapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS,
>> false);
>> > mapper.configure(SerializationFeature.INDENT_OUTPUT, true);
>> > JacksonJsonProvider provider = new JacksonJsonProvider();
>> > provider.setMapper(mapper);
>> > // tell Jersey where to find our jax-rs annotated classes
>> > packages("com.foo.bar").
>> > register(provider);
>> >
>> > This seems to work just fine! Here's what I suspect is happening, but I
>> > would love for you guys (Mike, Pedro and Jakub too if we can get his
>> > attention) to validate that my understanding is correct because I'm just
>> > getting my head around the new Jersey 2 implementation and am still
>> pretty
>> > green.
>> >
>> > We didn't mess with the Jackson jars at all and are using the following
>> > dependencies:
>> >
>> > <properties>
>> > <jersey.version>2.5.1</jersey.version>
>> > <jackson.version>2.3.0</jackson.version>
>> > ...
>> > </properties>
>> > ...
>> >
>> >
>> > <dependency>
>> > <groupId>com.fasterxml.jackson.jaxrs</groupId>
>> > <artifactId>jackson-jaxrs-json-provider</artifactId>
>> > <version>${jackson.version}</version>
>> > </dependency>
>> >
>> > Registering the jackson provider seemed to make the difference, and
>> simply
>> > creating and setting the mapper on the provider allowed us to set the
>> > serialization features for not failing on empyty beans and pretty
>> printing
>> > the JSON.
>> >
>> > Jakub, we have a tactially urgent client situation at the moment, and I
>> need
>> > to shift gears to address it so I will not be able to create a pared
>> down
>> > web app that demos the problem with the JacksonFeature registration
>> causing
>> > Jackson to ignore the @JsonIgnore tags in our object model. If I get a
>> > chance after this urgent matter has been resolved, I will come back and
>> do
>> > that for you but right now I have to deal with something else, my
>> apologies.
>> >
>> > -=j=-
>> >
>> >
>> > On Tue, Jan 28, 2014 at 6:35 AM, Michael Iles <michael.iles_at_gmail.com>
>> > wrote:
>> >>
>> >> You don't need a custom ObjectMapper, you just need to be able to
>> >> create the ObjectMapper yourself so that you can then call
>> >> `.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false)` on it,
>> >> as opposed to having the Jersey auto-discovery and the Jackson feature
>> >> create it for you.
>> >>
>> >> Also you don't need `JacksonJaxbJsonProvider`: it's just a small
>> >> subclass of `JacksonJsonProvider` and if you're not using JAXB (i.e.
>> >> you're not using XML) then you should just use `JacksonJsonProvider`.
>> >>
>> >> Again: there isn't any additional code, you don't need to subclass
>> >> ObjectMapper or write a new Feature.
>> >>
>> >> In the example I gave I'm registering things directly in the app class
>> >> derived from `ResourceConfig` but as Pedro says you can probably also
>> >> use a `ContextResolver` to provide the ObjectMapper instance. If you
>> >> get that working then please share with the list: I tried and failed
>> >> at one point to get a `ContextResolver` working but I didn't pursue
>> >> it.
>> >>
>> >> Mike
>> >>
>> >> On 27 January 2014 17:12, Jack Lista <jackalista_at_gmail.com> wrote:
>> >> > Hi Mike,
>> >> >
>> >> > Thanks for the reply, much appreciated. You mean there's no way to
>> >> > configure the Jackson code? OMG, that's unreal... we aren't even
>> using
>> >> > a
>> >> > custom object mapper, and I would prefer not to use any custom things
>> >> > like
>> >> > that unless we have to. So what you're saying is that unless you
>> create
>> >> > a
>> >> > custom object mapper, you won't get a chance to get a reference to
>> the
>> >> > object mapper used internally and therefore won't get a chance to
>> >> > provide
>> >> > any configuration? So, to allow you to configure serialization
>> >> > features,
>> >> > you are opening up that jar, removing the META-INF/services and then
>> >> > re-jarring it to prevent auto-discovery and then are explicitly
>> >> > registering
>> >> > the JAXB provider with your embedded ObjectMapper? Holy crap, this
>> is
>> >> > not
>> >> > good news...
>> >> >
>> >> > Can you share the ObjectMapper code? We are not using a custom
>> object
>> >> > mapper, so I'm not sure what that would look like. Also, where did
>> you
>> >> > get
>> >> > the JacksonJaxbJsonProvider? We're not using JAXB so would just
>> want to
>> >> > use
>> >> > the regular POJO support in Jackson. Can you share that provider
>> code
>> >> > as
>> >> > well, by any chance? Also, is there a POJO Jackson provider as well
>> as
>> >> > the
>> >> > JAXB one? Where did you learn about this stuff, if you don't mind me
>> >> > asking?
>> >> >
>> >> >
>> >> > On Mon, Jan 27, 2014 at 1:48 PM, Michael Iles <
>> michael.iles_at_gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> I don't think it's possible to configure the Jackson feature with
>> the
>> >> >> way Jersey 2 is set up right now.
>> >> >>
>> >> >> If you include the Jackson jar containing the JAX-RS provider
>> >> >> (currently jackson-jaxrs-json-provider-2.2.3.jar) then Jersey will
>> >> >> auto-discover the Jackson provider and register it, and there's no
>> way
>> >> >> for you to configure it.
>> >> >>
>> >> >> I need to do this as well, and my solution right now is to remove
>> the
>> >> >> META-INF/services directory from that Jackson jar.
>> >> >>
>> >> >> Once you've done that you can then create your own ObjectMapper and
>> >> >> register it with Jersey, something like this:
>> >> >>
>> >> >> public class MyApp extends ResourceConfig {
>> >> >> public MyApp() {
>> >> >> ObjectMapper om = new ObjectMapper();
>> >> >> om.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS,
>> >> >> false);
>> >> >> JacksonJaxbJsonProvider provider = new
>> >> >> JacksonJaxbJsonProvider();
>> >> >> provider.setMapper(om);
>> >> >> register(provider);
>> >> >> }
>> >> >> }
>> >> >>
>> >> >> Mike.
>> >> >>
>> >> >> On 27 January 2014 16:30, Jack Lista <jackalista_at_gmail.com> wrote:
>> >> >> > Hi Jakub,
>> >> >> >
>> >> >> > I will try to send you a pared down application so you can see
>> that
>> >> >> > behavior. I need to figure out how to set
>> >> >> > SerializationFeature.FAIL_ON_EMPTY_BEANS to false, but hopefully
>> once
>> >> >> > I
>> >> >> > get
>> >> >> > this stuff working, I can chop the project down to something more
>> >> >> > manageable
>> >> >> > and send it to you.
>> >> >> >
>> >> >> > Basically, the @JsonIgnore tags are ignored when I use the
>> >> >> > register(JacksonFeature) idiom. Also, if I do the same with Moxy,
>> >> >> > i.e.
>> >> >> > register(MoxyJsonFeature), I get 500 server errors on every
>> request.
>> >> >> >
>> >> >> > If you can point me toward how to set:
>> >> >> >
>> >> >> > SerializationFeature.FAIL_ON_EMPTY_BEANS -> False
>> >> >> >
>> >> >> > I may be able to get to this sooner. Thanks Jakub!
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Jan 27, 2014 at 5:44 AM, Jakub Podlesak
>> >> >> > <jakub.podlesak_at_oracle.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hi Jack,
>> >> >> >>
>> >> >> >> It is a good news you found out a working configuration. Thanks
>> for
>> >> >> >> sharing the information.
>> >> >> >>
>> >> >> >> Regarding META-INF/services discovery, there is a serious bug in
>> >> >> >> Jersey
>> >> >> >> (JERSEY-2335) that prevents
>> >> >> >> Jackson provider to lookup customer supplied object mapper. More
>> >> >> >> details
>> >> >> >> including a workaround could be found
>> >> >> >> in another thread here:
>> >> >> >>
>> >> >> >>
>> https://java.net/projects/jersey/lists/users/archive/2014-01/message/91
>> >> >> >>
>> >> >> >> On the Jackson provider does not honour the @JsonIgnore
>> annotation:
>> >> >> >> could
>> >> >> >> you please share
>> >> >> >> a simple reproducible test case, that i can debug locally? I
>> have no
>> >> >> >> idea
>> >> >> >> on what could be causing
>> >> >> >> this odd behaviour, other then a non-Jackson provider has been
>> >> >> >> involved.
>> >> >> >>
>> >> >> >> Please feel free to file a new bug report for that.
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >>
>> >> >> >> ~Jakub
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On 18 Jan 2014, at 01:37, Jack Lista <jackalista_at_gmail.com>
>> wrote:
>> >> >> >>
>> >> >> >> I see... that's frustrating. It seems odd that you can't do that
>> >> >> >> considering how much effort has been put into configuration
>> >> >> >> facilities.
>> >> >> >> So
>> >> >> >> it is the META-INF/services autodiscovery that is how Jackson is
>> >> >> >> getting
>> >> >> >> registered? I have been wondering about that, it sounds like you
>> >> >> >> think
>> >> >> >> that's what's happening in my case. I'm curious about your
>> opinion
>> >> >> >> because
>> >> >> >> I am honestly clueless, when it comes right down to it, but the
>> moxy
>> >> >> >> jars
>> >> >> >> aren't in my war so it couldn't be moxy. It's touchy,
>> >> >> >> configuration-wise,
>> >> >> >> it seems but we've found a configuration that handles our domain
>> >> >> >> model
>> >> >> >> and
>> >> >> >> various uses of generics and whatnot, but damn, we spent a *long*
>> >> >> >> time
>> >> >> >> getting there.
>> >> >> >>
>> >> >> >> If the META-INF/services thing goes away I may have to revisit
>> this,
>> >> >> >> but
>> >> >> >> for now, we seem to be good. I wish I could get it to work by
>> >> >> >> registering
>> >> >> >> the JacksonFeature but it completely ignores all the @JsonIgnore
>> >> >> >> tags
>> >> >> >> in our
>> >> >> >> domain model, and I haven't figured out how to change that so I
>> >> >> >> guess
>> >> >> >> letting it auto-register itself is going to have to suffice. Any
>> >> >> >> idea
>> >> >> >> why
>> >> >> >> Jackson would ignore the @JsonIgnore tags when registered via the
>> >> >> >> JacksonFeature and would honor them when auto-registered? I
>> would
>> >> >> >> love
>> >> >> >> to
>> >> >> >> know that as well...
>> >> >> >>
>> >> >> >> In other news, I just tried using Links embedded in Responses and
>> >> >> >> that's
>> >> >> >> really easy to use and works nicely from what I've seen so far,
>> and
>> >> >> >> that's
>> >> >> >> pretty cool, but I am still a bit in the dark WRT Jackson
>> >> >> >> registration.
>> >> >> >> Thanks for your response...
>> >> >> >>
>> >> >> >> --j
>> >> >> >>
>> >> >> >>
>> >> >> >> On Tue, Jan 14, 2014 at 7:38 PM, Michael Iles
>> >> >> >> <michael.iles_at_gmail.com>
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> FWIW I'm fine with the META-INF/services auto discovery... my
>> >> >> >>> problem
>> >> >> >>> is that Jersey doesn't give me a way to access the Jackson
>> provider
>> >> >> >>> that it auto-discovers so that I can configure it. If Jersey
>> >> >> >>> allowed
>> >> >> >>> me to get a handle to the provider that it discovered then I
>> could
>> >> >> >>> call `setMapper(...)` on the provider and I wouldn't have to
>> munge
>> >> >> >>> the
>> >> >> >>> Jackson provider jar.
>> >> >> >>>
>> >> >> >>> Mike.
>> >> >> >>>
>> >> >> >>> On 14 January 2014 18:46, Jack Lista <jackalista_at_gmail.com>
>> wrote:
>> >> >> >>> > OK, I *think* I sorted this out, since there seems to be much
>> >> >> >>> > confusion
>> >> >> >>> > about configuration, I'll post what I found and hopefully this
>> >> >> >>> > will
>> >> >> >>> > clarify
>> >> >> >>> > things for the next poor sap who comes along.
>> >> >> >>> >
>> >> >> >>> > I tried various mvn dependencies (see my first email on this
>> >> >> >>> > subject
>> >> >> >>> > for the
>> >> >> >>> > initial 2 jackson dep's, for data-bind and annotations) and
>> found
>> >> >> >>> > that
>> >> >> >>> > if I
>> >> >> >>> > just use the provider dep from the jackson github site I have
>> >> >> >>> > *only*
>> >> >> >>> > jackson
>> >> >> >>> > json jars (6 of them), and all from the right version (2.3.0
>> in
>> >> >> >>> > my
>> >> >> >>> > case). I
>> >> >> >>> > have another dep for moxy, and if I add that, then I see moxy
>> >> >> >>> > jars
>> >> >> >>> > in
>> >> >> >>> > WEB-IN/lib, but as long as I use only the dep listed here, I
>> get
>> >> >> >>> > only
>> >> >> >>> > jackson 2.3.0.
>> >> >> >>> >
>> >> >> >>> > From here:
>> >> >> >>> >
>> >> >> >>> > https://github.com/FasterXML/jackson-jaxrs-providers
>> >> >> >>> >
>> >> >> >>> > <dependency>
>> >> >> >>> > <groupId>com.fasterxml.jackson.jaxrs</groupId>
>> >> >> >>> >
>> <artifactId>jackson-jaxrs-json-provider</artifactId>
>> >> >> >>> >
>> >> >> >>> > <version>${jackson.version}</version>
>> >> >> >>> > </dependency>
>> >> >> >>> >
>> >> >> >>> > I have been concerned about the fact that I was not using any
>> >> >> >>> > "Features"
>> >> >> >>> > related to JSON (but it was working anyway...), and also
>> because
>> >> >> >>> > moxy
>> >> >> >>> > is the
>> >> >> >>> > default I was a bit worried that we might be using moxy if not
>> >> >> >>> > providing any
>> >> >> >>> > configuration at all, which I wasn't. However, I found a
>> notice
>> >> >> >>> > on
>> >> >> >>> > the
>> >> >> >>> > Jackson github site above that says that the Jackson (2.2
>> onward)
>> >> >> >>> > provider
>> >> >> >>> > performs (some sort of) auto-registration.
>> >> >> >>> >
>> >> >> >>> > The 6 jars produced by the above dependency are these:
>> >> >> >>> >
>> >> >> >>> > jackson-annotations-2.3.0.jar
>> >> >> >>> > jackson-core-2.3.0.jar
>> >> >> >>> > jackson-databind-2.3.0.jar
>> >> >> >>> > jackson-jaxrs-base-2.3.0.jar
>> >> >> >>> > jackson-jaxrs-json-provider-2.3.0.jar
>> >> >> >>> > jackson-module-jaxb-annotations-2.3.0.jar
>> >> >> >>> >
>> >> >> >>> > It seems I'm using Jackson 2.3.0, no? With only that above
>> json
>> >> >> >>> > dep
>> >> >> >>> > in my
>> >> >> >>> > pom.xml none of the moxy jars appear to be present so I think
>> I
>> >> >> >>> > am
>> >> >> >>> > safely
>> >> >> >>> > using jackson. Please correct me if I'm wrong, you don't
>> need to
>> >> >> >>> > be
>> >> >> >>> > polite! ;)
>> >> >> >>> >
>> >> >> >>> > I was wondering if the reason that Jackson auto-registers
>> itself
>> >> >> >>> > is
>> >> >> >>> > related
>> >> >> >>> > to the current discussion about META-INF services. Does
>> anyone
>> >> >> >>> > know
>> >> >> >>> > if
>> >> >> >>> > these two things are related? I've seen comments about how
>> this
>> >> >> >>> > META-INF
>> >> >> >>> > stuff is breaking some integrations, but I'm not clear on the
>> >> >> >>> > details.
>> >> >> >>> > The
>> >> >> >>> > gist of those conversations seems to be that the META-INF
>> stuff
>> >> >> >>> > should
>> >> >> >>> > be
>> >> >> >>> > removed, and that Tatu (Jackson author) will do this at some
>> >> >> >>> > point.
>> >> >> >>> > Should
>> >> >> >>> > I then expect the auto registration I'm currently enjoying to
>> >> >> >>> > stop
>> >> >> >>> > working
>> >> >> >>> > or are these two things not related? If anyone is clear about
>> >> >> >>> > this
>> >> >> >>> > stuff
>> >> >> >>> > (I'm obviously far from clear) I'd love to hear from you...
>> >> >> >>> >
>> >> >> >>> > --j
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > On Mon, Jan 13, 2014 at 5:06 PM, Jack Lista
>> >> >> >>> > <jackalista_at_gmail.com>
>> >> >> >>> > wrote:
>> >> >> >>> >>
>> >> >> >>> >> I got server side log file tracing turned on, it turns out
>> that
>> >> >> >>> >> in
>> >> >> >>> >> addition to the properties you need to set that I mentioned
>> in
>> >> >> >>> >> my
>> >> >> >>> >> previous
>> >> >> >>> >> post, you also have to register the LoggingFilter. I added
>> this
>> >> >> >>> >> to
>> >> >> >>> >> my
>> >> >> >>> >> application sublass and I now get *minor* amounts of trace
>> info
>> >> >> >>> >> showing up:
>> >> >> >>> >>
>> >> >> >>> >> import import org.glassfish.jersey.filter.LoggingFilter;
>> >> >> >>> >> ...
>> >> >> >>> >> register(LoggingFilter.class);
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> I also tried regsitering like this:
>> >> >> >>> >>
>> >> >> >>> >> import import org.glassfish.jersey.filter.LoggingFilter;
>> >> >> >>> >> import javax.ws.rs.container.ContainerRequestFilter;
>> >> >> >>> >> import javax.ws.rs.container.ContainerResponseFilter;
>> >> >> >>> >> ...
>> >> >> >>> >> register(LoggingFilter.class, ContainerRequestFilter.class).
>> >> >> >>> >> register(LoggingFilter.class, ContainerResponseFilter.class);
>> >> >> >>> >>
>> >> >> >>> >> The effect appears the same with both means of registering
>> the
>> >> >> >>> >> logging
>> >> >> >>> >> filter. Unfortunately, none of the tracing, even at the
>> VERBOSE
>> >> >> >>> >> level
>> >> >> >>> >> of
>> >> >> >>> >> detail, is telling me what JSON marshalling / unmarshalling
>> is
>> >> >> >>> >> being
>> >> >> >>> >> used.
>> >> >> >>> >> I have it set to verbose, but that's not very verbose in my
>> >> >> >>> >> view,
>> >> >> >>> >> it's
>> >> >> >>> >> just
>> >> >> >>> >> giving me a little bit about the HTTP request/response. In
>> >> >> >>> >> fact,
>> >> >> >>> >> the
>> >> >> >>> >> runtime is barely even mentioning JSON beyond what's in
>> accept
>> >> >> >>> >> headers
>> >> >> >>> >> (request) and content type (response). On the response side,
>> >> >> >>> >> this
>> >> >> >>> >> is
>> >> >> >>> >> all I
>> >> >> >>> >> see:
>> >> >> >>> >>
>> >> >> >>> >> Jan 13, 2014 4:11:09 PM
>> >> >> >>> >> org.glassfish.jersey.filter.LoggingFilter
>> >> >> >>> >> log
>> >> >> >>> >> INFO: 3 * Server responded with a response on thread
>> >> >> >>> >> http-bio-8080-exec-6
>> >> >> >>> >> 3 < 201
>> >> >> >>> >> 3 < Content-Type: application/json
>> >> >> >>> >> 3 < Location: http://blahblahblah...
>> >> >> >>> >>
>> >> >> >>> >> There's also mention of the accept header in the request
>> >> >> >>> >> tracing:
>> >> >> >>> >>
>> >> >> >>> >> 4 > accept: application/json
>> >> >> >>> >>
>> >> >> >>> >> That's it, no other mention of JSON in any form. How do I
>> get
>> >> >> >>> >> the
>> >> >> >>> >> runtime
>> >> >> >>> >> to tell me what JSON infrastructure I'm using?? Is there a
>> >> >> >>> >> different
>> >> >> >>> >> means
>> >> >> >>> >> of registering the LoggingFilter that will make it spit out
>> more
>> >> >> >>> >> info?
>> >> >> >>> >>
>> >> >> >>> >> I am getting bi-directional databinding, I can serialize my
>> >> >> >>> >> POJOs
>> >> >> >>> >> to
>> >> >> >>> >> JSON
>> >> >> >>> >> and can deserialize them back into java objects, but I want
>> to
>> >> >> >>> >> see
>> >> >> >>> >> what JSON
>> >> >> >>> >> processing I'm using, as I haven't registered any JSON
>> provider
>> >> >> >>> >> or
>> >> >> >>> >> feature,
>> >> >> >>> >> all I did was put the 2.3.1 Jackson dependencies in my
>> pom.xml.
>> >> >> >>> >> I
>> >> >> >>> >> want to
>> >> >> >>> >> do a sanity check on what I'm doing and make sure I'm not
>> using
>> >> >> >>> >> a
>> >> >> >>> >> horked
>> >> >> >>> >> configuration. How do I get more info on my JSON
>> configuration?
>> >> >> >>> >>
>> >> >> >>> >> I tried registering the following in my App (ResourceConfig)
>> >> >> >>> >> subclass,
>> >> >> >>> >> but
>> >> >> >>> >> I'm explicitly *not* using either of these, as they both
>> threw
>> >> >> >>> >> exceptions
>> >> >> >>> >> when I registered them (individually, I didn't register them
>> >> >> >>> >> both
>> >> >> >>> >> at
>> >> >> >>> >> once):
>> >> >> >>> >>
>> >> >> >>> >> ...
>> >> >> >>> >> register(JacksonFeature.class);
>> >> >> >>> >> register(MoxyJsonFeature.class);
>> >> >> >>> >>
>> >> >> >>> >> I'd like to figure out how I can validate that my JSON
>> >> >> >>> >> processing
>> >> >> >>> >> stuff is
>> >> >> >>> >> properly configured, but so far I can't seem to get any
>> >> >> >>> >> visibility
>> >> >> >>> >> into it.
>> >> >> >>> >> How do you get more info on this? Is there deeper tracing?
>> Is
>> >> >> >>> >> there
>> >> >> >>> >> some
>> >> >> >>> >> other means?
>> >> >> >>> >>
>> >> >> >>> >> You know how you can set a flag in hibernate and you get more
>> >> >> >>> >> gory
>> >> >> >>> >> detail
>> >> >> >>> >> on the SQL it's using than you could ever want? *That's*
>> what I
>> >> >> >>> >> want
>> >> >> >>> >> here,
>> >> >> >>> >> some module is marshaling this stuff and unmarshaling it and
>> I
>> >> >> >>> >> want
>> >> >> >>> >> to
>> >> >> >>> >> turn
>> >> >> >>> >> on logging in that module so I can see what module it is and
>> >> >> >>> >> what's
>> >> >> >>> >> going
>> >> >> >>> >> on... How do you do that?
>> >> >> >>> >>
>> >> >> >>> >> Thanks...
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> On Mon, Jan 13, 2014 at 3:24 PM, Jack Lista
>> >> >> >>> >> <jackalista_at_gmail.com>
>> >> >> >>> >> wrote:
>> >> >> >>> >>>
>> >> >> >>> >>> Hi Jakub, Jersey folks,
>> >> >> >>> >>>
>> >> >> >>> >>> I'm trying to turn on server side log file tracing to see
>> what
>> >> >> >>> >>> JSON
>> >> >> >>> >>> databinding I'm using and am having trouble finding out how
>> to
>> >> >> >>> >>> successfully
>> >> >> >>> >>> get actual logs to show up in a log file.
>> >> >> >>> >>>
>> >> >> >>> >>> I set these properties in my Application class:
>> >> >> >>> >>>
>> >> >> >>> >>> property("jersey.config.server.tracing", "ALL").
>> >> >> >>> >>> property("jersey.config.server.tracing.threshold", "TRACE");
>> >> >> >>> >>>
>> >> >> >>> >>> Next I got an error related to headers buffer space, so I
>> added
>> >> >> >>> >>> the
>> >> >> >>> >>> following to my tomcat's server.xml:
>> >> >> >>> >>>
>> >> >> >>> >>> <Connector port="8080" protocol="HTTP/1.1"
>> >> >> >>> >>> connectionTimeout="20000"
>> >> >> >>> >>> maxHttpHeaderSize="16384"
>> <------------I
>> >> >> >>> >>> added
>> >> >> >>> >>> this, and the error stopped
>> >> >> >>> >>> redirectPort="8443" />
>> >> >> >>> >>>
>> >> >> >>> >>> I'm pretty sure now that logging/tracing is now turned on,
>> but
>> >> >> >>> >>> I
>> >> >> >>> >>> still
>> >> >> >>> >>> don't see anything. Where is this logging supposed to show
>> up?
>> >> >> >>> >>> I'm
>> >> >> >>> >>> not
>> >> >> >>> >>> seeing it in catalina.out, is this stuff directed to a
>> >> >> >>> >>> different
>> >> >> >>> >>> log
>> >> >> >>> >>> file?
>> >> >> >>> >>>
>> >> >> >>> >>> I've seen chapter 19 (Tracing and Monitoring) here:
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>>
>> https://jersey.java.net/documentation/latest/monitoring_tracing.html#tracing
>> >> >> >>> >>>
>> >> >> >>> >>> It says that that there's a "dedicated logger" for java for
>> >> >> >>> >>> server
>> >> >> >>> >>> side
>> >> >> >>> >>> log file tracing, but what do you actually have to do to
>> make
>> >> >> >>> >>> it
>> >> >> >>> >>> log
>> >> >> >>> >>> things?
>> >> >> >>> >>> I have been scouring the web for details and there are a few
>> >> >> >>> >>> pages
>> >> >> >>> >>> but they
>> >> >> >>> >>> all seem to be relevant to Jersey 1.x and don't seem
>> >> >> >>> >>> applicable.
>> >> >> >>> >>> What do
>> >> >> >>> >>> you have to do to get the trace info to show up in a server
>> >> >> >>> >>> side
>> >> >> >>> >>> log
>> >> >> >>> >>> file?
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>> On Thu, Jan 9, 2014 at 8:53 AM, Jakub Podlesak
>> >> >> >>> >>> <jakub.podlesak_at_oracle.com> wrote:
>> >> >> >>> >>>>
>> >> >> >>> >>>> Hi Jack,
>> >> >> >>> >>>>
>> >> >> >>> >>>> ad 1) it is hard to tell from the information you provided.
>> >> >> >>> >>>> Anyway, you should be able to determine the
>> effective
>> >> >> >>> >>>> worker
>> >> >> >>> >>>> used
>> >> >> >>> >>>> if you set Jersey's server side config property,
>> >> >> >>> >>>> jersey.config.server.tracing,
>> >> >> >>> >>>> to "ALL". Then the actual worker used at runtime
>> >> >> >>> >>>> should
>> >> >> >>> >>>> get
>> >> >> >>> >>>> logged.
>> >> >> >>> >>>>
>> >> >> >>> >>>> ad 2) i guess this is rather a question for Jackson mailing
>> >> >> >>> >>>> list,
>> >> >> >>> >>>> if
>> >> >> >>> >>>> it
>> >> >> >>> >>>> turns out one of the Jackson
>> >> >> >>> >>>> providers is used and the annotation is not mandated.
>> >> >> >>> >>>> Let's
>> >> >> >>> >>>> clarify the first thing first.
>> >> >> >>> >>>>
>> >> >> >>> >>>> Cheers,
>> >> >> >>> >>>>
>> >> >> >>> >>>> ~Jakub
>> >> >> >>> >>>>
>> >> >> >>> >>>>
>> >> >> >>> >>>> On 08 Jan 2014, at 17:53, Jack Lista <jackalista_at_gmail.com
>> >
>> >> >> >>> >>>> wrote:
>> >> >> >>> >>>>
>> >> >> >>> >>>> And yes, your more compact syntax works nicely, thank you
>> very
>> >> >> >>> >>>> much!
>> >> >> >>> >>>> If
>> >> >> >>> >>>> you wouldn't mind, would you please answer those two dumb
>> >> >> >>> >>>> questions
>> >> >> >>> >>>> about
>> >> >> >>> >>>> 1.) which databinding I'm actually using and 2.) the
>> question
>> >> >> >>> >>>> about
>> >> >> >>> >>>> @JsonIgnore?
>> >> >> >>> >>>>
>> >> >> >>> >>>> Much thanks sir...
>> >> >> >>> >>>>
>> >> >> >>> >>>> -=j=-
>> >> >> >>> >>>>
>> >> >> >>> >>>>
>> >> >> >>> >>>> On Wed, Jan 8, 2014 at 8:20 AM, Jack Lista
>> >> >> >>> >>>> <jackalista_at_gmail.com>
>> >> >> >>> >>>> wrote:
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> Ah, yes! Sweet! So *that's* how you submit a generic
>> type
>> >> >> >>> >>>>> to
>> >> >> >>> >>>>> this
>> >> >> >>> >>>>> infrastructure!! I had stumbled across something very
>> >> >> >>> >>>>> similar,
>> >> >> >>> >>>>> although a
>> >> >> >>> >>>>> bit more long winded, as the last thing I tried last
>> night,
>> >> >> >>> >>>>> but
>> >> >> >>> >>>>> I
>> >> >> >>> >>>>> just
>> >> >> >>> >>>>> happened across it based on a comment of the guy I'm
>> working
>> >> >> >>> >>>>> with
>> >> >> >>> >>>>> on this
>> >> >> >>> >>>>> and I tried it and it actually then gave me my wrapper
>> >> >> >>> >>>>> envelope
>> >> >> >>> >>>>> back with my
>> >> >> >>> >>>>> domain class(es) inside it. Here's the syntax I tried
>> last
>> >> >> >>> >>>>> night
>> >> >> >>> >>>>> which
>> >> >> >>> >>>>> worked (& I'm going to try your more compact form
>> >> >> >>> >>>>> immediately):
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> GenericType<ResponseEnvelope<FooBar>> fooResponseEnvType =
>> >> >> >>> >>>>> new
>> >> >> >>> >>>>> GenericType<ResponseEnvelope<FooBar>>() {};
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> // then pass fooResponseEnvType to the get(...) method
>> like
>> >> >> >>> >>>>> so:
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> ResponseEnvelope<FooBar> envelope4ReuseMkt =
>> >> >> >>> >>>>> client.target("http://localhost:8080/v1.1/rs")
>> >> >> >>> >>>>>
>> .path("foobar")
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> .path(fooBarId.toString())
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> .request(MediaType.APPLICATION_JSON_TYPE)
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> .get(fooResponseEnvType);
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> Thanks so much for your comment, however, as your code is
>> >> >> >>> >>>>> much
>> >> >> >>> >>>>> more
>> >> >> >>> >>>>> compact which I like. Where, pray tell, is this stuff
>> >> >> >>> >>>>> documented?
>> >> >> >>> >>>>> Almost
>> >> >> >>> >>>>> *everyone* is using domain objects (or DTOs, etc.) with
>> these
>> >> >> >>> >>>>> services, so
>> >> >> >>> >>>>> the examples with simple String data types aren't
>> >> >> >>> >>>>> representative
>> >> >> >>> >>>>> of
>> >> >> >>> >>>>> the
>> >> >> >>> >>>>> techniques needed to work with domain objects, generic
>> types
>> >> >> >>> >>>>> and
>> >> >> >>> >>>>> other
>> >> >> >>> >>>>> things commonly found in enterprise environments (like the
>> >> >> >>> >>>>> GenericType
>> >> >> >>> >>>>> utility class you pointed out). We have a pretty crazy
>> >> >> >>> >>>>> domain
>> >> >> >>> >>>>> model, so I
>> >> >> >>> >>>>> am going to need to get much more deeply into things like
>> >> >> >>> >>>>> this,
>> >> >> >>> >>>>> where is
>> >> >> >>> >>>>> this GenericType utility discussed, beyond a javadoc?
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> I would also *really* love to understand what such
>> facilities
>> >> >> >>> >>>>> exist,
>> >> >> >>> >>>>> how they're intended to be used, what kids of
>> functionality
>> >> >> >>> >>>>> is
>> >> >> >>> >>>>> currently
>> >> >> >>> >>>>> support and even, if you guys know, what direction things
>> are
>> >> >> >>> >>>>> headed in.
>> >> >> >>> >>>>> I've been over (I think) most of the
>> >> >> >>> >>>>> https://jersey.java.net/documentation/latest... site but
>> I
>> >> >> >>> >>>>> haven't
>> >> >> >>> >>>>> found
>> >> >> >>> >>>>> discussion of things like GenericType, sorry if I'm being
>> >> >> >>> >>>>> dense
>> >> >> >>> >>>>> but
>> >> >> >>> >>>>> can you
>> >> >> >>> >>>>> point that out? (Thanks again.)
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> While I have your ear, can you answer two relatively
>> simple
>> >> >> >>> >>>>> questions?
>> >> >> >>> >>>>> My services are working when I don't explicitly register
>> any
>> >> >> >>> >>>>> JSON
>> >> >> >>> >>>>> Features
>> >> >> >>> >>>>> at all, but I do have these mvn dependencies in my
>> pom.xml:
>> >> >> >>> >>>>>
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> <dependency>
>> >> >> >>> >>>>> <groupId>com.fasterxml.jackson.core</groupId>
>> >> >> >>> >>>>> <artifactId>jackson-databind</artifactId>
>> >> >> >>> >>>>> <version>${jackson.version}</version>
>> >> >> >>> >>>>> </dependency>
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> <dependency>
>> >> >> >>> >>>>> <groupId>com.fasterxml.jackson.core</groupId>
>> >> >> >>> >>>>> <artifactId>jackson-annotations</artifactId>
>> >> >> >>> >>>>> <version>${jackson.version}</version>
>> >> >> >>> >>>>> </dependency>
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> What JSON databinding am I using? If I explicitly enable
>> the
>> >> >> >>> >>>>> JacsonFeature, I get very different behavior
>> (stackoverflow
>> >> >> >>> >>>>> errors).
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> The second dumb question is, is the @JsonIgnore
>> annotation in
>> >> >> >>> >>>>> domain
>> >> >> >>> >>>>> classes still how you are supposed to prevent recursive
>> >> >> >>> >>>>> stackoverflow JSON
>> >> >> >>> >>>>> serialization errors? I ask because if I explicitly
>> enable
>> >> >> >>> >>>>> the
>> >> >> >>> >>>>> JacksonFeature as I described in my post, I would assume
>> that
>> >> >> >>> >>>>> I
>> >> >> >>> >>>>> am
>> >> >> >>> >>>>> definitely using Jackson but the @JsonIgnore annotations
>> >> >> >>> >>>>> within
>> >> >> >>> >>>>> my
>> >> >> >>> >>>>> domain
>> >> >> >>> >>>>> classes appear to be ignored themselves and I suffer
>> >> >> >>> >>>>> stackoverflow
>> >> >> >>> >>>>> errors.
>> >> >> >>> >>>>> We have a very complex domain model so I want to stay on
>> top
>> >> >> >>> >>>>> of
>> >> >> >>> >>>>> the
>> >> >> >>> >>>>> best
>> >> >> >>> >>>>> techniques for managing domain classes that have a lot of
>> >> >> >>> >>>>> relationships
>> >> >> >>> >>>>> among them.
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> Thanks Jakub, appreciate your help *immensely*!
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> -=j=-
>> >> >> >>> >>>>>
>> >> >> >>> >>>>>
>> >> >> >>> >>>>>
>> >> >> >>> >>>>> On Wed, Jan 8, 2014 at 5:30 AM, Jakub Podlesak
>> >> >> >>> >>>>> <jakub.podlesak_at_oracle.com> wrote:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> Hi Jack,
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> Please try to use the following type when reading the
>> >> >> >>> >>>>>> entity:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> ResponseEnvelope<FooBar> envelope =
>> >> >> >>> >>>>>> svcResponse.readEntity(new
>> >> >> >>> >>>>>>
>> javax.ws.rs.core.GenericType<ResponseEnvelope<FooBar>>(){});
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> Does it help?
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> ~Jakub
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> On 07 Jan 2014, at 22:05, Jack Lista <
>> jackalista_at_gmail.com>
>> >> >> >>> >>>>>> wrote:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> Hi,
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> I'm trying to get a composition working in which I'm
>> having
>> >> >> >>> >>>>>> trouble
>> >> >> >>> >>>>>> getting my entity back from the Response even though the
>> >> >> >>> >>>>>> actual
>> >> >> >>> >>>>>> service
>> >> >> >>> >>>>>> request seems to have succeeded. I'm using Jersey 2.5.1
>> and
>> >> >> >>> >>>>>> am
>> >> >> >>> >>>>>> using the
>> >> >> >>> >>>>>> client API to have one service call another 2 services
>> and
>> >> >> >>> >>>>>> then
>> >> >> >>> >>>>>> do
>> >> >> >>> >>>>>> some
>> >> >> >>> >>>>>> processing based on the results of the 2 composed
>> services.
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> I'm having no trouble getting the two services being
>> >> >> >>> >>>>>> composed
>> >> >> >>> >>>>>> to
>> >> >> >>> >>>>>> work,
>> >> >> >>> >>>>>> marshaling the POJO service payload as JSON. If I call
>> >> >> >>> >>>>>> either
>> >> >> >>> >>>>>> service in a
>> >> >> >>> >>>>>> browser they both work and spit out the appropriate JSON
>> >> >> >>> >>>>>> content.
>> >> >> >>> >>>>>> Additionally, when I call them from within the composing
>> >> >> >>> >>>>>> service,
>> >> >> >>> >>>>>> it appears
>> >> >> >>> >>>>>> that the calls have succeeded. Printing the Response
>> via a
>> >> >> >>> >>>>>> logger
>> >> >> >>> >>>>>> shows the
>> >> >> >>> >>>>>> following:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> svcResponse:
>> InboundJaxrsResponse{ClientResponse{method=GET,
>> >> >> >>> >>>>>> uri=http://localhost:8080/v1.1/rs/foobar/1, status=200,
>> >> >> >>> >>>>>> reason=OK}}
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> Additionally, if I call (Response)
>> svcResponse.hasEntity() I
>> >> >> >>> >>>>>> get a
>> >> >> >>> >>>>>> result of true.
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> However, when I try to call readEntity(), I get a class
>> cast
>> >> >> >>> >>>>>> exception:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> java.lang.ClassCastException: java.util.LinkedHashMap
>> cannot
>> >> >> >>> >>>>>> be
>> >> >> >>> >>>>>> cast
>> >> >> >>> >>>>>> to com.baz.domain.FooBar
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> A few details of my implementation that may be relevant
>> are
>> >> >> >>> >>>>>> that
>> >> >> >>> >>>>>> we
>> >> >> >>> >>>>>> are using an application class that subclasses
>> >> >> >>> >>>>>> ResourceConfig
>> >> >> >>> >>>>>> (without a
>> >> >> >>> >>>>>> web.xml). This app class also uses the following package
>> >> >> >>> >>>>>> scanning
>> >> >> >>> >>>>>> call to
>> >> >> >>> >>>>>> find our annotated classes:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> packages("com.baz.rest");
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> The POJO domain model classes being returned are not in
>> that
>> >> >> >>> >>>>>> package,
>> >> >> >>> >>>>>> as the above snippet of stacktrace shows, but they are
>> being
>> >> >> >>> >>>>>> marshaled to
>> >> >> >>> >>>>>> JSON without issue, so I suspect that's not a problem.
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> I'm not registering any JSON provider, but have the
>> >> >> >>> >>>>>> following
>> >> >> >>> >>>>>> in
>> >> >> >>> >>>>>> my
>> >> >> >>> >>>>>> pom.xml which seems to have enabled Jackson:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> <dependency>
>> >> >> >>> >>>>>> <groupId>com.fasterxml.jackson.core</groupId>
>> >> >> >>> >>>>>> <artifactId>jackson-databind</artifactId>
>> >> >> >>> >>>>>> <version>${jackson.version}</version>
>> >> >> >>> >>>>>> </dependency>
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> <dependency>
>> >> >> >>> >>>>>> <groupId>com.fasterxml.jackson.core</groupId>
>> >> >> >>> >>>>>> <artifactId>jackson-annotations</artifactId>
>> >> >> >>> >>>>>> <version>${jackson.version}</version>
>> >> >> >>> >>>>>> </dependency>
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> I have also tried using the following in my pom.xml but
>> it
>> >> >> >>> >>>>>> seems
>> >> >> >>> >>>>>> to
>> >> >> >>> >>>>>> make no difference whether it's present or not:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> <dependency>
>> >> >> >>> >>>>>> <groupId>org.glassfish.jersey.media</groupId>
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> <artifactId>jersey-media-json-jackson</artifactId>
>> >> >> >>> >>>>>> </dependency>
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> It is necessary for compilation if I explicitly register
>> the
>> >> >> >>> >>>>>> JacksonFeature, but seems to have no effect otherwise.
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> I'm using a simple unadorned client created in the
>> composing
>> >> >> >>> >>>>>> service
>> >> >> >>> >>>>>> (the one that is calling the other two services):
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> Client client = ClientBuilder.newClient();
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> I'm also creating a webTarget and an invocation in the
>> >> >> >>> >>>>>> following
>> >> >> >>> >>>>>> manner:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> WebTarget webTarget =
>> >> >> >>> >>>>>> client.target("http://localhost:8080/v1.1/rs");
>> >> >> >>> >>>>>> Invocation.Builder invocationBuilder = webTarget
>> >> >> >>> >>>>>> .path("foobar")
>> >> >> >>> >>>>>> .path(foobarId.toString())
>> >> >> >>> >>>>>>
>> .request(MediaType.APPLICATION_JSON_TYPE);
>> >> >> >>> >>>>>> Response svcResponse =
>> >> >> >>> >>>>>> invocationBuilder.get(Response.class);
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> I've tried explicitly enabling Jackson by adding the
>> >> >> >>> >>>>>> following
>> >> >> >>> >>>>>> call in
>> >> >> >>> >>>>>> my application subclass:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> register(JacksonFeature.class);
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> and adding a similar call in the client code like this:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> Client client =
>> >> >> >>> >>>>>> ClientBuilder.newClient().register(JacksonFeature.class);
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> However, when I configure the server and client that way,
>> >> >> >>> >>>>>> the
>> >> >> >>> >>>>>> Jackson
>> >> >> >>> >>>>>> databinding doesn't respect the @JsonIgnore annotations
>> in
>> >> >> >>> >>>>>> our
>> >> >> >>> >>>>>> domain model
>> >> >> >>> >>>>>> and suffers a stackoverflow error. Without that explicit
>> >> >> >>> >>>>>> configuration, I
>> >> >> >>> >>>>>> get nice decent sized chunks of JSON which do respect the
>> >> >> >>> >>>>>> @JsonIgnore
>> >> >> >>> >>>>>> annotations in our domain model. I've also tried to
>> switch
>> >> >> >>> >>>>>> to
>> >> >> >>> >>>>>> the
>> >> >> >>> >>>>>> Moxy JSON
>> >> >> >>> >>>>>> code by adding "register(MoxyJsonFeature.class);" to the
>> >> >> >>> >>>>>> application class
>> >> >> >>> >>>>>> and calling "Client client =
>> >> >> >>> >>>>>>
>> ClientBuilder.newClient().register(MoxyJsonFeature.class);"
>> >> >> >>> >>>>>> in
>> >> >> >>> >>>>>> the
>> >> >> >>> >>>>>> client
>> >> >> >>> >>>>>> code but this simply results in 500 errors even when
>> calling
>> >> >> >>> >>>>>> the 2
>> >> >> >>> >>>>>> composed
>> >> >> >>> >>>>>> services in a browser. When I do no configuration in
>> either
>> >> >> >>> >>>>>> the
>> >> >> >>> >>>>>> application
>> >> >> >>> >>>>>> subclass or in the client code in the calling service as
>> >> >> >>> >>>>>> originally shown
>> >> >> >>> >>>>>> above, I get the proper JSON representation in a browser
>> >> >> >>> >>>>>> from
>> >> >> >>> >>>>>> each
>> >> >> >>> >>>>>> of the
>> >> >> >>> >>>>>> two composed services.
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> The problem occurs when I try to access the entity from
>> the
>> >> >> >>> >>>>>> response.
>> >> >> >>> >>>>>> This first call succeeds:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> ResponseEnvelope<FooBar> envelope =
>> >> >> >>> >>>>>> svcResponse.readEntity(ResponseEnvelope.class);
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> However, I get the class cast exception referencing a
>> >> >> >>> >>>>>> LinkedHashMap
>> >> >> >>> >>>>>> (?!?) when I try the following call:
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> FooBar fooBar = envelope.getPayload();
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> Perhaps the problem is related to our envelope class that
>> >> >> >>> >>>>>> has a
>> >> >> >>> >>>>>> generic domain class embedded in it? However, Jackson
>> has
>> >> >> >>> >>>>>> no
>> >> >> >>> >>>>>> trouble
>> >> >> >>> >>>>>> marshaling the ResponseEnvelope to JSON, so why would it
>> >> >> >>> >>>>>> fail
>> >> >> >>> >>>>>> in
>> >> >> >>> >>>>>> the
>> >> >> >>> >>>>>> opposite direction?
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> I'm utterly confused (obvious? lol), any help would be
>> >> >> >>> >>>>>> *greatly*
>> >> >> >>> >>>>>> appreciated!
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>> --j
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>>
>> >> >> >>> >>>>>
>> >> >> >>> >>>>
>> >> >> >>> >>>>
>> >> >> >>> >>>
>> >> >> >>> >>
>> >> >> >>> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>>
>
>