Hi Martin
On 10/05/12 16:45, Martin Matula wrote:
> 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?
>
Sure, it makes sense, it is just not clear why one would want to read
the stream into Book class at the filter level, in addition to simpler
form processing, but I can imagine some scenarios can be at least
possible with this readEntity support...
>>>> 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?
well, one would need to extend say an injectable Request context, so for
example, MBR would check that InputStream is null and if yes it would do
Request.getEntityType and then safely cast Request.getEntity to one of
the known types - I'm just talking aloud here without putting much
thought into how it should be better be done...
I'm not going to push this idea further anyway, does not seem like
anyone is interested, so I'm happy to 'close' it...
Cheers, Sergey
> Martin
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com