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

From: Sergey Beryozkin <>
Date: Thu, 10 May 2012 15:55:52 +0100

Hi Bill
On 10/05/12 15:16, Bill Burke wrote:
> 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.
If it is the only then it is pretty easy to address without having a
generic support for deserializing the stream, even I can type a code in
the follow up email which will parse the stream into a sequence of name
& value pairs :-)
>> 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.

If we settle on always restricting the entity stream type to
OutputStream then yes, I can why it can be handy. Still, seems that
having a setInputStream on the Request context is enough to address the

Cheers, Sergey

>> 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

Sergey Beryozkin
Talend Community Coders