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
Sergey