Markus, Adam,
feel free to continue in the discussion but kindly move it to a separate thread. I'd like to see this tread remained
focused on the server-side async request processing support proposal.
Many thanks,
Marek
On 08/09/2011 06:48 PM, Markus KARG wrote:
> Adam,
>
> no comment on this? You asked for better integration of JAX-RS and EJB so I wonder that you do not comment this thread.
>
> Regards
> Markus
>
>>>>>>> * 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
>