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
http://bill.burkecentral.com