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
concern...
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
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com