Take a look at Dispatch<T>, AsyncHandler<T> and Response<T> in JAX-WS,
they do the same kind of thing.
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
>