On Aug 3, 2009, at 4:47 PM, Marc Hadley wrote:
> On Aug 3, 2009, at 10:22 AM, Paul Sandoz wrote:
>>
>> On Aug 3, 2009, at 3:00 PM, Marc Hadley 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?
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.
Paul.
> 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
>