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:
http://java.net/projects/jax-rs-spec/sources/git/show/src/examples/src/main/java/jaxrs/examples/client/cache
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
example.
Marek
>
> 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.
>