Nick Stuart wrote:
> Looks good. Guessing some of the implantation details are that the
> client thread gets a key of some kind associated to it so that when it
> gets the result using *r.get(String.class).get());* it passes along a
> key and waits (if needed) to get the correct response.
>
Tis all done by java.util.concurrent.Future/FutureTask. Some code:
private <T> Future<T> handle(final Class<T> c,
final ClientRequest ro) {
FutureTask<T> ft = new FutureTask<T>(new Callable<T>() {
public T call() throws Exception {
ClientResponse r = getHeadHandler().handle(ro);
if (c == ClientResponse.class) return c.cast(r);
if (r.getStatus() < 300) return r.getEntity(c);
throw new UniformInterfaceException(r);
}
});
new Thread(ft).start();
return ft;
}
basically Future.get() waits "for the computation to complete, and then
retrieves its result.". I need to double check on the handling of the
exception... as i don't know if it gets propagated.
> For my case this could work alright as I can add my own way to check for
> completion/status by checking an external source (DB lookup in this
> case) which would happen in another thread/request.
>
> The 202/Location URI Marc mentioned earlier would be nice to have as
> well, but I don't see it as necessity right now. (suppose a 202 return
> code would be good though to fit the HTTP model, and this seems to be an
> exact fit for that)
>
> I've noticed some work on the Mavening stuff to, is it possible to get
> snapshot releases of the code yet?
No yet, working on it.
> The latest I found in the maven1 repo
> is the 0.7ea release which I am using for some simple testing right now.
>
Right, this is to the m1 repo. We will start snapshot builds to the m2
repo once we work out how to "mvn deploy".
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109