On Mar 11, 2013, at 1:40 PM, "John D. Ament" <john.d.ament_at_gmail.com> wrote:
> David,
>
> Based on what's been discussed, do you anticipate any changes to the structure of the ActivationConfigProperties ?
No changes there. Ultimately there are only 2 small changes and everything else is business as usual:
1. expose the bean class to the RA via MessageEndpointFactory.getEndpointClass()
2. give the RA an @LocalBean-like proxy via MessageEndpointFactory.createEndpoint(..)
This is enough to give the RA the ability to see the annotations on the bean (#1) and the power to invoke all methods of the bean (#2). Everything else is the same. #1 will always be "on" and #2 will only happen if your message listener interface has no methods.
It's not as far as I'd love to see things go, but I think its the right amount for right now. I think we could benefit from more connector experts and implementors before going bigger and we're definitely going to get more of those over the next couple years.
One alternative to enabling it via a "no methods" interface I implemented as a prototype in the RI was to use an annotation instead of a no-method interface. Worked well, but I think even that could use the benefit of more time and more hands.
> I agree, related to the way MDBs work today. That's likely the same way each of the other implementers support it.
>
> The reason I'm asking so many questions is that the JMS EG recently voted to not include a standard adapter API. Introduction of something like this may change that opinion.
Questions are good. I wasn't following the "standard adapter" conversation, so I'm not up to speed on what was discussed there. There's already a standard API that all JMS RAs have to implement, including standard activation config properties. Was this discussion that there should be one implementation of that API that everyone has to use that should support any JMS provider?
-David
> On Mon, Mar 11, 2013 at 4:25 PM, David Blevins <david.blevins_at_gmail.com> wrote:
>
> On Mar 11, 2013, at 10:57 AM, "John D. Ament" <john.d.ament_at_gmail.com> wrote:
>
> > 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.
>
> I suspect there'll be further work here. Having worked on TomEE, Geronimo and now Glassfish for implementing this feature, I can say the behavior here is somewhat varied. Not all containers will create an MDB instance when MessageEndpointFactory.createEndpoint() is called.
>
> > 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.
>
> I can verify that TomEE/Geronimo/WAS CE consider each MDB to be a consumer, not the RA, so 10 MDBs for the same queue act like 10 non-MDB consumers would regardless if those MDBs are in the same application, same server or spread out among other applications or servers.
>
> But you're correct, it's all moot technically. Whatever communication style the RA wants to provide is absolutely ok, so ultimately the answer is yes to any possible option.
>
> As of 1.7, it also has access to the MDBs JNDI environment which includes the BeanManager, so sky is the limit. Pandora's box is now fully open.
>
> > 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?
>
> Considering only the Connector 1.7 and EJB 3.2 specs, it's the RA developer who is in charge of the API the MDB will use.
>
> JMS is a special case in that there is an EG who controls most of that contract. So changes like this could be done in the JMS specification or in some vendor-specific RA for JMS (Seam, DeltaSpike, etc).
>
> I actually hope quite a bit of experimentation is done outside the JMS specification long before Java EE 8 so that we're in a good position to potentially standardize something that has been proven in the JMS spec next time around.
>
>
> -David
>
> >
> > 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
> >
> >
>
>