On Aug 3, 2009, at 11:16 AM, Paul Sandoz wrote:
>>>
>>>> Take a look at Dispatch<T>, AsyncHandler<T> and Response<T> in
>>>> JAX-WS, they do the same kind of thing.
>>>>
>>>
>>> Thanks.
>>>
>>> The use of Future<?> is really handy, thus CallBackStatus is not
>>> really required.
>>>
>>> In the AsyncHandler.handleResponse why is the parameter
>>> Response<T> that extends from Future<T>. Is that just for
>>> convenience as a holder of T and to get the response context ? or
>>> can this handler get called if the request is cancelled ?
>>>
>>
>> The parameter is a Response<T> so that any exceptions can be thrown
>> from the get method just as they would using a sync API. If you
>> just pass T to the handler then you lose the ability to throw
>> exceptions.
>>
>
> OK. In this context not all methods on Future make sense, e.g. get
> with a timeout or cancel ? and i suppose isDone should return true?
>
Right. The AsyncHadler method isn't called until the op completes so
get with a timeout is just the same as a get without and returns right
away. Cancel won't work as its too late but one thing you need to
decide is whether cancel on the Future<?> returned from the
invokeAsync method equivalent should result in a call to the handler
with isCancelled returning true, or no call to the handler - I can't
recall without looking which way we jumped in JAX-WS.
> I was proposing a separate method to handle exceptions. But from the
> perspective of the synchronous API i wonder if it make sense to keep
> the same pattern of catching exceptions.
>
I think catching exceptions is more natural and lets the developer
easily do different things for different exceptions without a lot of
instanceof checking. It also aligns the callback and polling variants
better IMO.
Marc.
>>>>
>>>> On Aug 3, 2009, at 5:53 AM, Paul Sandoz wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Async support on the server-side is important for scalability.
>>>>>
>>>>> Equally important is a client side solution, which if services
>>>>> are clients, is also important for scalability, or for good
>>>>> interaction with UIs that need to process stuff asynchronously
>>>>> to avoid pauses.
>>>>>
>>>>> There is the AsyncWebResource class that supports Future<T>, but
>>>>> we need to extend this to support callbacks.
>>>>>
>>>>> So we could do the following:
>>>>>
>>>>> AsyncWebResource r = ...
>>>>>
>>>>> CallBackStatus s = r.get(new CallBack<String>() {
>>>>> void onError(Throwable e) { ... }
>>>>>
>>>>> void onResponse(String s) { ... }
>>>>> });
>>>>>
>>>>>
>>>>> The CallBackStatus instance can be used to check the status and
>>>>> also cancel.
>>>>>
>>>>> (CallBack and CallBackStatus are not very good names).
>>>>>
>>>>>
>>>>> Because of type erasure, the "String" type in the above example
>>>>> needs to be known. It seems appropriate to make CallBack an
>>>>> abstract class from which the type T can be determined:
>>>>>
>>>>> public abstract class CallBack<T> {
>>>>> protected CallBack() {
>>>>> // Determine concrete Type of T
>>>>> }
>>>>>
>>>>> protected CallBack(Class<T> c) {
>>>>> this.type = c;
>>>>> }
>>>>>
>>>>> Type getType() { ... }
>>>>>
>>>>> public abstract void onError(Throwable e);
>>>>>
>>>>> public abstract void onResponse(T t);
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> Then we require the ability to utilize async client APIs if they
>>>>> are available from the underlying client implementation or a
>>>>> default implementation that utilizes its own threading logic if
>>>>> there is no async support in the underlying implementation.
>>>>>
>>>>> Paul.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>