[jax-rs-spec users] Re: [jsr339-experts] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

From: Bill Burke <>
Date: Thu, 10 May 2012 10:16:35 -0400

On 5/10/12 6:13 AM, Sergey Beryozkin wrote:
> On 09/05/12 16:43, Bill Burke wrote:
>> On 5/9/12 11:28 AM, Martin Matula wrote:
>>> Perhaps the writeEntity() method should be removed from the request
>>> context - it adds complexity and I haven't found a use-case for it.
>>> Martin
>> I don't know one either and would be in favor of removing it.
> I wonder if ContainerRequestContext should only have the pair of methods
> similar to the ContainerResponseContext has, to do with the consuming
> and replacing the entity stream, specifically
> public InputStream getEntityStream();
> public void setEntityStream(InputStream input);
> I do not understand the case for the filters needing to deserialize the
> streams into specific types other than InputStream, OutputStream or
> possibly some intermediate type like DOM Document, STAX readers/writers,
> etc.

Martin has the case of changing the HTTP Method based on a form
parameter too. I think readEntity() needs to stay.

> I'd also like re-iterate my opposition, for whatever it is worse, to
> having bufferEntity() or any auto-buffering, if we will keep this method
> then it would probably block us from introducing the support for the
> alternative entity stream types which I suggested in the other email.

I missed this email on "alternative entity streams" ...can you forward?
  I'll try and re-read your list posts to find it.

bufferEntity() is a convenience function if get/setEntityStream() exist.
  If these two methods don't exist, then it is a must as long as
readEntity() exists. If I'm making sense.

I think I've buffered often enough using ByteArrayInputStream that
bufferEntity() is a good addition.

> It
> has to be the responsibility of the individual filter to ensure the the
> follow-up filters are operating as required, and if they fail to do so
> as a result of the individual filter messing up the entity stream then
> it is an application issue, not the spec issue.

I agree that it is the responsibility of the filter to make sure things
work properly

Bill Burke
JBoss, a division of Red Hat