Skip to main content

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

  • From: Bill Burke <bburke@...>
  • To: Sergey Beryozkin <sberyozkin@...>
  • Cc: "jsr339-experts@..." <jsr339-experts@...>
  • Subject: [jax-rs-spec users] [jsr339-experts] Re: The purpose of bufferEntity (Was: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors)
  • Date: Tue, 01 May 2012 11:10:44 -0400
  • List-id: <jsr339-experts.jax-rs-spec.java.net>



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

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


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

Sergey Beryozkin 05/01/2012

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

Bill Burke 05/01/2012
 
 
Close
loading
Please Confirm
Close