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