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
>