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
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>
>
>