On 08/08/2011 07:54 PM, Markus KARG wrote:
> 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.
>
It would be unfortunate to make JAX-RS to be a delivery vehicle for a workaround in case the the JSR236 fails to deliver
all the features. Suggestion to "cut a hole in JAX-RS to expose the guts of JavaEE container" opens a can of worms in
added long-term API maintenance cost due to the reduced cohesion of the API.
Let's not spend any more effort on discussing this and let's focus at the core topics again.
Marek