[jax-rs-spec users] [jsr339-experts] Re: client filter issue

From: Marek Potociar <>
Date: Thu, 16 Feb 2012 15:50:56 +0100

On 02/16/2012 02:55 PM, Bill Burke wrote:
> On 2/16/12 5:09 AM, Marek Potociar wrote:
>> On Tue 14 Feb 2012 05:56:26 PM CET, Bill Burke wrote:
>>> We have a client cache implementation built on Resteasy interceptor architecture. One thing it does do is cache the
>>> representation and not the unmarshalled entity. In other words, it caches an XML/JSON document, and not the JAXB,
>>> Java object its unmarshalled to. The application code can then unmarshal the cached bits into anything it wants.
>>> Right now, there is no way to portable way to implement that feature other than to create a implementation of Response
>>> which is very non-trivial and something, IMO, we shouldn't force the user to do.
>>> Following me?
>> Not quite :) Why is it not possible to use one of the standard static
>> factory methods on the JAX-RS Response to produce a copy of the
>> original response? I reviewed and updated the client-side cache example:
> Ok, then this means InputStream is a special case, right? That if you do builder.entity( inputStream), then you can
> extract/unmarshall from it with a readEntity(). This needs to be documented.

Yes, input stream is a special case - note the javadoc in readEntity(InputStream.class). What I am not sure about is
whether builder.entity(inputStream) and readEntity(InputStream.class) should operate on exactly same stream instance.

The potential problem is that this would circumvent the handlers. But I cannot think of any problem it could cause at
the moment. Can you?

Btw. Seems to me that with the current set of entity-related methods on the Req/Resp API it might make sense to
introduce a separate core.Entity interface that would host these methods. One way to do it could be to promote
client.Entity to core and add the necessary methods to it. The Request/Response would then contain a new Entity getter,
e.g. getMessageEntity(). The JAX-RS 1.x Response.getEntity() would then be just a shortcut for
Response.getMessageEntity().getValue() (or such). What do you think?


> Bill