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

From: Bill Burke <>
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 <> wrote:
>> On 8/22/2012 4:32 PM, Marek Potociar wrote:
>>> FYI - the change is in:
>>> 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

> 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

Bill Burke
JBoss, a division of Red Hat