[jax-rs-spec users] [jsr339-experts] Re: Re: Response.isEntityRetrievable() and Response.bufferEntity()

From: Sergey Beryozkin <>
Date: Wed, 7 Mar 2012 16:21:25 +0000


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


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