Hi Mike,
The return of "null" on the server side is an implementation detail.
You could change that to return Response.status(204).build() with out
any modification to what the client receives.
What the client receives sees is either a 204 or a 200 with an XML
document. There is no concept of a Java null communicated from the
server to the client.
The JAXB unmarshalling support in JAX-RS, on the server or client
side, requires that there is an XML document to unmarshall just like
it is required when using the unmarshalling with JAXBContext. That is
the expectations when using JAXB.
If you need to support the case of unmarshalling an XML document when
present or returning null otherwise then you will need to write your
own message body writer overriding the existing JAXB support. However,
EntityHolder was written for the specific purpose you require. You
could look at the implementation of EntityHolderReader [1] and modify
that to support your requirements
However, because there is no easier way to obtain types in Java you
have to do something like this:
EntityHolder<XDictionary> eh =
client.resource(uri).accept(MIME).get(new
GenericType<EntityHolder<XDictionary>() {});
The alternative is to encapsulate the null concept in the entity but i
think it is better to use HTTP status codes.
Paul.
[1]
http://fisheye4.atlassian.com/browse/jersey/trunk/jersey/jersey-core/src/main/java/com/sun/jersey/core/impl/provider/entity/EntityHolderReader.java?r=HEAD
On Aug 5, 2010, at 5:28 PM, Mike Baranczak wrote:
> Paul:
>
> My client code is pretty simple:
>
> XDictionary xmap =
> client.resource(uri).accept(MIME).get(XDictionary.class);
>
> XDictionary is a JAXB-annotated class that extends HashMap<String,
> String>.
>
> I thought about using a wrapper class like EntityHolder, but it
> would be nice if I didn't have to. Here's the way I see it: on the
> server side, I have a resource method that returns null. The Jersey
> server produces an HTTP response that encapsulates the null value.
> However, the Jersey client throws an exception when it sees this
> response. The correct behavior in the above client code would be to
> set xmap to null.
>
> In other words, the Jersey client should be capable of handling
> responses produced by the Jersey server.
>
> -MB
>
>
>> From: Paul Sandoz <Paul.Sandoz_at_oracle.com>
>> Hi Mike, Can you share the client code? If you are defining in a
>> get say a list of JAXB beans then the client will never return
>> null, it will always expect some content to be returned. You need
>> to express the requirements that you may or may not have an entity
>> by wrapping the type in an EntityHolder, see: https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/core/provider/EntityHolder.html
>> Hth, Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>