> > * 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 misunderstood what I want to say. So let me rephrase: If Java EE 7 is
providing a Job Service, the user will use THAT instead of creating his own
executor. But if Java EE 7 will NOT define it, it would be great if JAX-RS
could provide an ExecutorService which is nothing else but an access
interface to the job manager already contained in any Java EE 6 server
implicitly. Got it? See, maybe I am the last unicorn, but we ARE using
JAX-RS INSIDE Java EE and do not like the idea of having two distinct thread
pools, one managed by the server, and one totally unmanaged. I mean, in EJB
it is still forbidden to use self-managed threading models, and in JAX-RS we
will allow it? This makes no sense, as both just are components, and Java EE
components should be more and more aligned.
> > * 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.
Never talked about pub/sub in my comment but just proposed using ONE call to
resume the call and pass the data instead of TWO.