users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Thu, 10 May 2012 11:13:58 +0100

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.

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

Example, in Apache CXF, we can have Logging and XML Sec filters, with
the Logging filters being always in front on the receiving end,
successfully working together

-- 
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com