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

From: Marek Potociar <>
Date: Thu, 16 Feb 2012 11:09:25 +0100

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:

It does the (most basic) caching without a need to use it's own
Response implementation. Let me know if there's anything missing in the


> The problem with this is that this is a *client-only* issue, so I'm not sure the best way to solve it. Here's some
> ideas:
> * Have special support for InputStream. If your ResponseBuilder is created with an entity that is an InputStream on
> the client, then the JAX-RS client internals woudl allow a readEntity() that extracts from that InputStream (that is
> of course if the target type isn't an InputStream)
> * Have a setInputStream() on Response. Probably doesn't fit with the builder architecture.
> * Have a set inputStream on ResponseBuilder. This is weird too as setting an inputStream on the server doesn't make
> sense or would have completely different semantics.