users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: callbacks continued...

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 23 Aug 2012 09:14:26 -0400

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?


> 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.


> 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?


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com