Hello Marek,
thank you for the proposal. Here are my comments:
* As I expect Java EE servers to contain a highly optimized executor service, and as I suspect that least programmers will be able to provide even better ones, I would love to have access to the server's. So it would be great if (in addition to your proposal) JAX-RS would define a way to inject an ExecutorService into a JAX-RS resource. On Java SE there are ExecutorServices included in various ways so the JAX-RS vendor has no need to program his own one. On Java EE a server must contain one anyways, as JCA enforces work management, which is just another word for execution service in the end. This allows simpler code in the JAX-RS application (no need to create an instance of ExecutorService), and it has the potential to scale with the server itself (e. g. improved algorithms in the server will be available to the JAX-RS application automatically then).
* You know my preference for not inventing new things if not needed. Unfortunately it turns out that the java.util.concurrent package does not contain callback support (wouldn't it be nice if there would be something like "SemaphorListener" in that package that gets fired when a semaphor changes state?). Also I do not assume that people really want to return java.util.Observable to indicate asynchronous processing. But still I am not a friend of introducing a special JAX-RS AsyncContext solely for the need of saying "suspend now and resume later, but don't block my thread", as this kind of scenario just shouts for a generic interface (like "Resumeable" or whathever). Unfortunately Java doesn't have this. Sad.
* Will AsyncContext be injectable into a message driven bean (MDB)? This is needed for integrating EJB with JAX-RS in the most simple way. If the MDB gets triggered (e. g. by JMS or by a ERP JCA connector) it must be able to propagate this event to the AsyncContext. Or do you plan to extend support for MDBs in a way that MDBs can be JAX-RS resources, just like SLSBs?
* I wonder why your event sample is using both, a queue and a context, in parallel. Why not just doing ctx.resume(eventMessageObject) to forward the incoming message to the waiting client?
Regards
Markus
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Freitag, 5. August 2011 18:26
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Proposal draft for the JAX-RS server-side
> asynchronous request processing API
>
> Hello *,
>
> Based on the recent discussion in the EG, I have checked in a proposed
> API code including a couple of sample resources
> to demonstrate the intended usage:
>
> http://java.net/projects/jax-rs-
> spec/sources/git/revision/e8a964aaa0e8af2febd551660d07df3bbb903bcc
>
> Based on the EG feedback, I have focused on simplicity and addressing
> the most basic scenarios. The API consists of
> @Suspend method-level annotation and AsyncContext interface.
>
> Please review the examples to see how the API is supposed to be used:
>
> http://java.net/projects/jax-rs-
> spec/sources/git/content/src/examples/src/main/java/jaxrs/examples/asyn
> c/LongRunningAsyncOperationResource.java
>
> http://java.net/projects/jax-rs-
> spec/sources/git/content/src/examples/src/main/java/jaxrs/examples/asyn
> c/AsyncEventResource.java
>
> Looking forward to your feedback.
>
> Kind regards,
> Marek