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