+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