jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: Proposal draft for the JAX-RS server-side asynchronous request processing API

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 09 Aug 2011 15:12:47 +0200

On 08/08/2011 08:36 PM, Markus KARG wrote:
>>> * 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?
>>
>> No. But MDB should be able to directly call EJBs or send HTTP requests
>> to arbitrary JAX-RS resources, which seems enough.
>
> We're having a rather long history using EJB, especially MDBs, so I need to say that we are heavily interested in interoperability of any kind of new event APIs with MDB (here: JAX-RS events). That means in particular, that we would vote for some kind of merge between JAX-RS resource and MDB. An MDB should be able to get triggered by @POST for example (which technically is rather simple, as the message passing interface of an MDB is not defined, so defining any arbitrary message passing method with @POST will do it), and any kind of EJB (particularly MDBs triggered by JMS) should be able to trigger a a JAX-RS event to resume those request that is waiting on it. I actually do not insist of events support in JAX-RS as you know, but my strong belief is that IF we're gonna do it, we should do it RIGHT. Which means, as JAX-RS is part of Java EE, it should be more integrated with EJB. It looks odd that an EJB must use HTTP to resume a suspended request, as for example embedded se
rvers will potentially run both in the same VM. There is a merger between JSF managed beans and SBs already, so why not a merger between JAX-RS resources and MDBs?
>
FWIW, I'd like to point out that support for EJBs as JAX-RS resources is actually rather painful to implement and
certainly not "technically rather simple". EJBs are managed by a different container and often have a lifecycle that
collides with the default JAX-RS resource lifecycle. This alone causes lots of issues around EJB instance management,
provisioning and injection which are very hard to solve in a way that works for all the corner cases. Personally, I
think it was a mistake from the very beginning to allow exposing EJBs as JAX-RS resources directly. Unlike JAX-RS
resources, EJBs are primarily meant to be back-end objects IMHO. One should be able to inject other JavaEE artifacts
including EJBs into JAX-RS resources, but as for this mixed mode, it seems that was not really thought through well.

Marek