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. 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.
So it seems we may remove the OPTIONAL flag from the ConnectionCallback and use it the same way you would use onError()?
> Use Case(for the 3rd time I'll repeat myself):
> You ahve a transaction that if the response is *successfully* sent back to the client (over the wire) commit the transaction. If the response failed to be streamed back to the client (socket closed or some other IOException), the rollback the transaction.
>
> "transaction" doesn't necessarily have to be a JTA transaction, but rather a service that needs to know whether or not the response was streamed back to the client so that it can perform accordingly.
>
> FYI, this callback exists in Servlet 3 async listener too.
Again, that looks EXACTLY like the ConnectionCallback.disconnect() I had in mind. Note that the IO exception thrown in this case bears no useful information from the end user perspective. The only relevant information is that the connection to the client has been lost. Thus I prefer the ConnectionCallback.disconnect() over ErrorCallback.onError(...) or CompletionCallback.onError(...).
Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com