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.
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
>>>>>>
>>>>>
>>>>>
>>>
>
>