David,
Based on what's been discussed, do you anticipate any changes to the
structure of the ActivationConfigProperties ?
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.
John
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
> >
> >
>
>