Hi,
On 05/03/12 15:36, Santiago Pericas-Geertsen wrote:
>
> On Mar 2, 2012, at 11:45 AM, Sergey Beryozkin wrote:
>
>> Hi Bill
>> On 02/03/12 16:35, Bill Burke wrote:
>>> FYI, i don't get the semantics of hasEntity() and isEntityRetrievable().
>>> Can you give some code examples to describe both of these methods?
>>>
>> I can at least imagine that hasEntity() is a convenience utility method which can be used instead of checking the headers, status...
>>
>> But as I've already said few times, bufferEntity()& isEntityRetrievable() overload the Response with the extra responsibility - which is absolutely outside of the scope of Response whose 'job' is to present the information, not to start operating on it.
>
> I think the intent is for hasEntity() to work with readEntity() and for isEntityRetrievable() with getEntity(). In an way, hasEntity() and isEntityRetrievable() are pre-conditions for readEntity() and getEntity(). However, I believe we need work a bit more on the naming as it is a bit confusing right now.
>
> There's an implicit internal state depending on whether the entity has been mapped into a Java type or not. Awareness of this internal state can lead into to more efficient code but adds some complexity.
So I can see bufferEntity() throwing MessageProcessingException.
What do you all think about dropping bufferEntity() and
isEntityRetrievable() from Response.
What is the best case for keeping them in ? IMHO they introduce the
unneeded complexity. I can create a JIRA if agreed
Sergey
>
> -- Santiago
>
>>> On 3/1/12 7:19 AM, Sergey Beryozkin wrote:
>>>> What is the reason for having these two methods added to Response.
>>>> In other words, why anyone would want to call isEntityRetrievable(),
>>>>
>>>> while say Response.hasEntity() is also available ?
>>>>
>>>> Thanks, Sergey
>>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com