On 13/12/11 17:03, Marek Potociar wrote:
>
>
> On 12/13/2011 05:22 PM, Sergey Beryozkin wrote:
>> 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
>
> The above shoul be handled by the impl, but I can only repeat that (this being one of the reasons) I would assume that
> retrieving request or response as a stream will by typically done either via message body readers/writers or handlers or
> in the application layer (final destination).
>
> Note that this is also why the req/resp processing pipeline diagram is somewhat complex:
> http://java.net/projects/jax-rs-spec/pages/PreMatchingFilters
>
> In any case, I still think that request.getEntity(InputStream.class) should be exposed.
OK; note I was OK with exposing InputStream and was trying to explore
here what effect replacing getEntityInputStream to a more flexible
getEntity(T) method would have; agreed overall
Sergey
>
> Marek
>
>> 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