On 08/09/2011 03:19 PM, Bill Burke wrote:
>
>
> On 8/9/11 9:12 AM, Marek Potociar wrote:
>> 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 s
> e
>> 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.
>>
>
> If you're dealing with locators, then yes, you're right, but SLSBs match exactly to the JAX-RS default lifecycle (minus
> constructor injection).
Those are the examples of corner cases I was talking about. Adding CDI @Singleton into the picture complicates things
even more. Anyway, bottom line is that I'd prefer we do not add MDBs into the picture.
Marek