Hi Bill
Many JAX-RS applications will likely be deployed outside of EE environment...
Cheers, Sergey
________________________________________
From: Bill Burke [bburke_at_redhat.com]
Sent: 08 August 2011 13:03
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: Proposal draft for the JAX-RS server-side asynchronous request processing API
On 8/6/11 2:31 PM, Markus KARG wrote:
> 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).
>
-1. I think EE 7 is adding a job service. Also there's JMS and CDI
event mechanism. We don't need an Executor Service. Especially when a)
Async HTTP is an edge case anyways and b) there's a good chance an
Executor Service won't even be used.
> * 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?
>
Marek's proposal does not introduce a pub/sub mechanism, jsut a callback
mechanism. This is why he is using a queue with context.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com