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