All,
Sorry, I responded only to David RE this. Here's my email, but with an
extra line.
David,
Thanks. I think the big issue is that the RA is stuck taking ownership of
instantiating the MDB. It would be ideal if it's moved up a level.
Probably not a big push for this in this given iteration.
Also, I think your point RE queues is somewhat moot. I haven't checked
with all app servers, but I believe I can consistently define multiple MDBs
that point to the same queue, with the limitation that the message only
gets delivered once. I think the difference is that it's delivered to the
RA once now, and now the RA has to distribute the message to an appropriate
listener. Might be none, in which nothing happens or it could be several
and now they all receive it. Since we might consider these MDBs as
components in the same application it's not in conflict with the JMS spec
to distribute to multiple listeners.
Also, need to reiterate a point. Who would be responsible for defining
annotations if say we wanted to create a JMS RA based on this approach for
MDBs?
John
On Mon, Mar 11, 2013 at 1:09 PM, David Blevins <david.blevins_at_gmail.com>wrote:
>
> On Mar 11, 2013, at 4:07 AM, John D. Ament <john.d.ament_at_gmail.com> wrote:
>
> > Thank you for clarifying why we cannot use CDI observers here, makes
> sense (though I'll always be disappointed).
>
> There may actually be a way for an RA to do this via new text in the
> latest connector 1.7 PFD. Section 13.4.4 now states:
>
> The application server must make the application component environment
> namespace of the endpoint (that is being activated), available to the
> resource adapter
> during the call to the endpointActivation and endpointDeactivation
> methods. The resource adapter may use this JNDI context to access
> other resources.
>
> So theoretically the RA could lookup the BeanManager at
> java:comp/BeanManager in endpointActivation and use that to dispatch calls.
>
> I don't think it'd be as easy as one might think to actually write an RA
> that uses this approach, though. I see where you're coming from in that
> selecting the right method using qualifiers is in many ways superior to
> things like JMS selectors. The selection part is just about perfect, the
> invoking part is not. CDI has a one-to-many relationship between events
> and beans. One event could cause several, or no, beans to be invoked.
> While this might fit a JMS Topic fairly closely, it'd be hard to do for a
> Queue without inadvertently turning it into a topic. When it comes to
> doing something like JAX-RS or the command line application from my
> example, the one-to-many paradigm really breaks down.
>
> I definitely see what motivates the idea though.
>
> > Based on David's doc, it seems like the annotation on the message
> listener method plays a significant role. How can the container manage a
> method that has no clear use (no annotation present)? Should the container
> ignore it, or throw a deployment exception?
>
> The container just exposes all public, non-static, non-final, non-abstract
> methods just as is done with @LocalBean. It's up to the RA to decide what
> to invoke and when. It may use annotations to do this (such a thing was
> impossible before), but that's up to the RA.
>
>
> -David
>
>