jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Updated InvocationCallback interface

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 25 Aug 2011 17:20:26 +0200

On 08/25/2011 04:24 PM, Bill Burke wrote:
> Please see my previous email on client exception handling. I think you should change onError to receive an
> InvocationException rather than a throwable. You should be able to extract the HttpResponse from the
> InvocationException. This is useful for the case where you want a callback for a specific entity, an error happens, and
> you want to review the response:
>
> class InvocationException extends ClientException {
>
> HttpResponse getResponse();
>
> }
>
> interface InvocationCallback<T> {
>
> void onComplete(T thing);
> void onError(InvocationException ie);
> }

Done.

Marek

>
> This works for both:
>
> a) class MyCallback implements InvocationCallback<Customer> {...}
> b) class MyCallback implements InvocationCallback<HttpResponse> {...}
>
> In case (a) you can get to the HttpResponse within onError() through InvocationException if you need to do complex error
> handling. In case (b) InvocationException.getResponse() returns null as there was an unforeseen internal error and
> there's no HttpResponse object.
>
> You also might want to consider ditching the whole thing and forcing the user to use an HttpResponse:
>
> interface InvocationCallback<T> {
>
> void onComplete(HttpResponse<T> response);
> void onError(Throwable exception);
> }
>
>
> On 8/25/11 10:11 AM, Marek Potociar wrote:
>> FYI: I reverted the extra events support, but kept the error and normal completion separated.
>>
>> Marek
>>
>> On 08/25/2011 04:01 PM, Santiago Pericas-Geertsen wrote:
>>>
>>> On Aug 25, 2011, at 9:43 AM, Bill Burke wrote:
>>>
>>>> I don't understand why you need all this complexity. If the user needs more control, then they should declare
>>>> InvocationCallback to use an HttpResponse.
>>>>
>>>> As for error conditions, because onComplete() currently takes a Future as a parameter, you could throw the same
>>>> exceptions from Future.get() as SyncInvoker throws.
>>>>
>>>>
>>>> i.e.
>>>>
>>>> public class MyCallback implements InvocationCallback<Customer> {
>>>>
>>>> public void onComplete(Future<Customer> future) {
>>>>
>>>> try {
>>>> Customer cust = future.get();
>>>
>>> Personally, I find this an abuse of the Future type. I can't get around the idea of an "onComplete" method that
>>> gets a "Future" as an argument. It's either complete or it isn't.
>>>
>>> I much prefer the onComplete/onError approach without any Futures, just like a CompletionHandler in JDK 7's NB I/O
>>> API.
>>>
>>> -- Santiago
>>>
>