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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com