users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: restrict Request.getEntityInputStream()?

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 13 Dec 2011 16:22:25 +0000

On 13/12/11 15:51, Marek Potociar wrote:
>
>
> On 12/13/2011 04:13 PM, Sergey Beryozkin wrote:
>> On 13/12/11 15:11, Marek Potociar wrote:
>>>
>>>
>>> On Tue 13 Dec 2011 04:01:44 PM CET, Sergey Beryozkin wrote:
>>>> Hi
>>>> On 13/12/11 14:59, Bill Burke wrote:
>>>>>
>>>>>
>>>>> On 12/13/11 9:48 AM, Marek Potociar wrote:
>>>>>> Not sure we are on the same page. My question is, whether you think
>>>>>> that (on the server side) the following 2 methods
>>>>>> are interchangeable:
>>>>>>
>>>>>> request.getEntity(InputStream.class);
>>>>>> request.getEntityInputStream();
>>>>>>
>>>>>
>>>>> No we weren't on the same page :) Thanks for clarifying.
>>>>>
>>>>> Yes, you're right, they are interchangeable. So, yes,
>>>>> getEntityInputStream() isn't needed.
>>>>
>>>> Will
>>>>
>>>> request.getEntity(Book.class);
>>>>
>>>> work ?
>>>
>>> Assuming there is a readable (e.g. in terms of applicable
>>> MessageBodyReader) Book representation in the entity, the above should,
>>> of course, work.
>>
>> And do we really want to let it happen, to get the input stream consumed by custom providers ?
>
> Yes, I believe we do. Btw. resources may also want to consume the entity as an input stream.
>
>> What will need to be done
>> after it for the application code to get Book too ?
>
> Interesting question. I would say that once you consume the input stream content, you either need produce a new request
> and set a new entity into the Request or you the app code accessing the request may be doomed. But that's all right IMO
> as long as we properly document it (filed a new issue so that we don't forget -
> http://java.net/jira/browse/JAX_RS_SPEC-148 ). Our job is not to prevent any possible stupid provider implementation.
>

Sure that makes sense. My concern was about opening this option to read
InputStreams into typed beans from non-MBRs and I'm still slightly
concerned if it's a bit too much, because such handlers would then need
to use Providers to find an appropriate writer to re-create the in
stream - that is doable but I'm wondering if if we 'duplicating' here
what MBRs can do, we can easily have a composite MBR which will modify
the in stream and then delegate to the best MBW to serialize again and
then copy it to input stream
Sergey



> In any case, I would guess that the vast majority of stream consuming providers will be naturally implemented as reader
> Handlers or MBRs.
>
> Marek
>
>>
>> Sergey
>>
>>>
>>> Marek
>>>
>>>>
>>>> Cheers, Sergey
>>>>
>>>>>
>>>>> Bill
>>>>>
>>>>
>>>>
>>


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