FYI: I've updated the javadoc.
Marek
On 01/30/2012 09:47 PM, Santiago Pericas-Geertsen wrote:
>
> +1
>
> -- Santiago
>
> On Jan 30, 2012, at 9:05 AM, Bill Burke wrote:
>
>> +1
>>
>> On 1/27/12 6:05 AM, Marek Potociar wrote:
>>> After reading the current feedback, and taking into account recent changes in the API to fix #JAX_RS_SPEC-152 I am
>>> inclined to make the close() mandatory for cases when the entity is available, but is not represented by a Java instance
>>> (other than InputStream).
>>>
>>> At the same time, the close() method should be idempotent (multiple calls should have the same effect as a single call)
>>> as well as it should not throw any exception in case the entity is not represented by an input stream or if there is no
>>> entity at all.
>>>
>>> Can we agree on this resolution? Is there a Jira issue filed for this topic?
>>>
>>> Thanks,
>>> Marek
>>>
>>> On 01/24/2012 05:41 PM, Sergey Beryozkin wrote:
>>>> So what is your recommendation ?
>>>>
>>>> Sergey
>>>>
>>>> On 24/01/12 16:03, Bill Burke wrote:
>>>>>
>>>>>
>>>>> On 1/24/12 10:35 AM, Sergey Beryozkin wrote:
>>>>>> Hi Bill,
>>>>>>
>>>>>> On 23/01/12 13:52, Bill Burke wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 1/20/12 4:18 PM, Sergey Beryozkin wrote:
>>>>>>>> On 20/01/12 19:22, Bill Burke wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/20/12 12:31 PM, Sergey Beryozkin wrote:
>>>>>>>>>> On 20/01/12 17:26, Bill Burke wrote:
>>>>>>>>>>> Other than a finalize method, Response has no idea when to close the
>>>>>>>>>>> InputStream (except after a getEntity() or a 204).
>>>>>>>>>>>
>>>>>>>>>>> required then?
>>>>>>>>>>
>>>>>>>>>> Can that interfere somehow with per-request implementations which
>>>>>>>>>> may be
>>>>>>>>>> cleaning up the resources in @PreDestroy ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not following you...
>>>>>>>>
>>>>>>>> Consider a case where a request is completed on the server side, the
>>>>>>>> runtime serializes the response entity and now finishes with
>>>>>>>> response.close().
>>>>>>>>
>>>>>>>> The resource itself is created per every request. In CXF it is possible
>>>>>>>> to configure the runtime to call indirectly via a resource factory a
>>>>>>>> pre-destroy method immediately after the invocation has returned but
>>>>>>>> also optionally after the entity has been written to the output stream.
>>>>>>>>
>>>>>>>> I think Jersey did something similar long before we did it in CXF.
>>>>>>>> Marek, any comments about it ?
>>>>>>>>
>>>>>>>> So what I'm wondering about, what we end up with a double close() call
>>>>>>>> if say a Response entity is InputStream, once - by Response impl, the
>>>>>>>> other one - by the per-request resource instance
>>>>>>>>
>>>>>>>> May be it's not a problem, but raising it just in case
>>>>>>>>
>>>>>>>
>>>>>>> I think you're talking server side, and I'm talking client side? IMO,
>>>>>>> close() should be a no-op on the server side as it doesn't make sense
>>>>>>> there.
>>>>>> I'm wondering then if we have a case of the redundant method if it seems
>>>>>> that it is only usable in one context.
>>>>>> Perhaps getEntityInputStream should be reintroduced, if the user wishes
>>>>>> to close eagerly then getEntityInputStream().close() can be done
>>>>>>
>>>>>
>>>>> Not sure I agree, as with 204 there's no content and doesn't make sense
>>>>> to close the input stream. This is what I hate about Apache Client 4.
>>>>> Its stupid you ahve to do a getInputStream().close() to clean up the
>>>>> connection.
>>>>>
>>>>> Bill
>>>>>
>>>>
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>