[jax-rs-spec users] [jsr339-experts] Re: The purpose of bufferEntity (Was: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors)

From: Bill Burke <>
Date: Tue, 01 May 2012 11:10:44 -0400

On 5/1/12 9:29 AM, Sergey Beryozkin wrote:
> Hi Bill, All
> I thought I'd start a new thread in order to make it easier for Marek
> and Santiago to see the actual feedback on the original request to do
> with the interceptors :-)
> I'd like to understand better the purpose a Response.bufferEntity can
> play, when called directly by the application code or from filters, hope
> it would be useful for all of us...
> So the first case is the application code possibly calling
> Response.bufferEntity. The only reason I can think of for doing it is
> delaying the processing of the Response until some later time.
> It does seem it might be useful but I wonder if it actually does belong
> to Response api or not, I'd rather prefer the optional but explicit
> buffering (vi bufferEntity()) of the Response entity stream to be done
> 'outside' of the spec api. IMHO, buffering the in data in memory is
> usually not a good idea, the alternative means of storing the data on
> the disk, ex, in case of multipart based responses, massive input
> streams, etc, should be explored instead. The preserving of the response
> stream should not be taken lightly, by just casually writing
> bufferEntity().
> In other words, I think bufferEntity() does not belong to the Response
> api, the goal of the Response api is to facilitate the immediate access
> to the response data and not to manage/keep the state which may be
> needed to process the Response at some later time.
> The other case is filters possibly getting the input stream buffered in
> the memory.
> As I said, I think it should be the responsibility of the filters to
> ensure the input stream is available to the next filters, interceptors
> of any, the application code.
> Bill, you said:
> > readEntity() of a byte array would return a set of uncompress (possibly
> > unencrypted too) bytes (possibly altered even more by an interceptor)
> > which is very different than a bufferEntity() that just buffers the
> > entire on-the-wire bytes.
> >
> > The safest thing to do, IMO, is to have a buffereEntity() method that
> > just buffers the entire on-the-wire bytes.
> When would you expect the bufferedEntity method be called by the custom
> filters ?

In PreMatchFilter that called readEntity(). The safest thing to do
would be for the PreMatchFilter to buffer the entity and the call
readEntity() so as not to potentially screw up any other
filters/interceptors that are expecting a non-modified buffer.

On the client side, a caching response filter may want to read the
response body as-is directly from the outputstream so it can store the
on-the-wire bytes into a file for further cache hits. Later on,
application code would probably want to read the actual entity returned.

So, it is useful to be able to buffer the entity.


Bill Burke
JBoss, a division of Red Hat