users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Response.close() required?

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Mon, 30 Jan 2012 15:47:27 -0500

 +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