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

From: Martin Matula <>
Date: Thu, 10 May 2012 17:45:50 +0200

Hi Sergey,

On 5/10/12 4:55 PM, Sergey Beryozkin wrote:
> 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 :-)

Sure - I can even call the message body reader (and possibly
interceptors) manually by proprietary means, but what is the issue with
having the readEntity() convenience method with well defined semantics
as a standard?

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

Again, sure it is possible. But as Bill said, why would one have to
resort to buffering the stream manually their own way (and have that
code duplicated in multiple filters) if there can be a standard method
for that? What is the issue you are trying to address?
As for the "alternative entity streams", I don't get it. If there is an
alternate stream type, even if there is no bufferEntity method, but the
filter does need to read/buffer the entity, how would it do that if he
is not guaranteed that get/setInputStream actually works with InputStream?