On Aug 23, 2012, at 3:14 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 8/23/2012 5:16 AM, Marek Potociar wrote:
>>
>> On Aug 22, 2012, at 11:56 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>>
>>>
>>> On 8/22/2012 4:32 PM, Marek Potociar wrote:
>>>> FYI - the change is in:
>>>> http://java.net/projects/jax-rs-spec/sources/git/revision/a31a86313a42ed5e72162676472839498096a3b6
>>>> I have decided to leave out onError() from CompletionCallback in the end
>>>> as it didn't make sense when I was trying to document the method.
>>>> Perhaps if someone could explain me better when the method would be
>>>> called and why we need it, I can add it.
>>>>
>>>
>>> Its a must, IMO.
>>
>> While I am open to hear any arguments, let's try to agree that callbacks are something extra that we are trying to add on top of the features from JAX-RS 2.0 charter and as such nothing is a must in that area...
>>
>>> Basically it would get called when the server is unable to stream the Response back to the client (socket closed or something).
>>
>> I thought that's something ConnectionCallback.disconnect() would be used for.
>
> Doh!, ya. :) thanks. Forgot about ConnectionCallback.
>
> I think it could be reused, but its not the same as disconnect. I think of disconnect() being called before anybody has called resume(), while onError() would be called after a failed resume(). They both could be combined into one onError() event to make things simpler?
The problem with disconnect() before resume() is that you are not able to detect that unless you try to write something back to the client (before actually invoking the resume()). That's obviously possible, but it's not at the moment supported in the standard JAX-RS API. And I think we need to gain more experience before we standardize anything there.
>
>> That's how this callback is implemented in other frameworks today since trying to use a closed HTTP back-channel is the only reliable way how you can find out that the client disconnected. Alas, there's no "passive" way of finding out about the disconnect event AFAIK.
>>
>
> It isn't clear to me how AsyncListener.onError() is supposed to work in Servlet 3. Just says its a callback for when the operation couldn't complete.
Not sure either, but I'd say its practically usable only as a notification of client disconnect in case of asynchronously executed servlet processing.
>
>> So it seems we may remove the OPTIONAL flag from the ConnectionCallback and use it the same way you would use onError()?
>>
> Or have onError() be called back for both a disconnect or a resume I/O failure?
I have eventually added the onError(Throwable), but for a different use case that Sergey has reminded me of - JAX-RS is required to propagate any unmapped exceptions to the hosting IO container. I think in that case we should invoke the CompletionCallback.onError(...) method. That corresponds well with the existing onComplete(Response).
Marek
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com