So a comment from the user side (and JMS EG member).
I like this approach. One feature I've seen requested a few times is the
idea that a listener subscribed to a topic, but scoped within a session.
Would it be possible to implement that using this @Listens approach? My
thought is to have a CDI session scoped MDB that does work. A new one
would be deployed to the container on session startup, and undeployed on
session invalidate.
John
On Fri, Dec 9, 2011 at 12:23 PM, David Blevins <david.blevins_at_gmail.com>wrote:
> Been meaning to post this for a while. Blogged about it last year
> http://blog.dblevins.com/2010/10/ejbnext-connectorbean-api-jax-rs-and.html
>
> The suggestion of @Listener fits right in.
>
> The thesis is to eliminate the Connector-specfic JavaBean which is
> currently the heart of the MDB/Connector model. The
> @ActivationConfigProperty is just a reflection of that Connector JavaBean.
>
> There are several disadvantages to the JavaBean approach and current
> Connector style:
>
> - Metadata is loosely typed in the bean code
> - Only class-level metadata is allowed, not method-level
> - Requiring an interface can limit API expressiveness
>
> For those that aren't intimately familiar with the Connector/MDB
> relationship, see the blog post for explanation and examples. Not going to
> post that here as it's probably more annoying for those that know. Instead
> going to try to focus on the details of pulling this off.
>
> Fundamentally something like JAX-RS could have been done as a connector if
> we simply allowed the Connector to see the bean class.
>
> At that point we don't need the Container to shovel configuration data
> into the Connector, the Connector itself can get the data it needs directly
> from the MDB in the form of annotations on that bean.
>
> When the MBD/Connector relationship was created this was not possible.
> There was no way to "attach" metadata to the bean, so we did the best we
> could. JavaBean+properties was the best fit. We now have better ways to
> do it with annotations.
>
> For the sake of simplicity, getting right down into the guts of the
> Connector/MDB model, we could still require a message listener interface
> and then state the JavaBean and ActivationConfig is now optional. The
> message listener interface does not need to have methods on it. That would
> be the least change to existing Connector xml config and ejb-jar.xml.
>
> Going beyond that if we think we're up for it, we could allow the vendor
> to use an annotation class as the message listener interface. Annotations
> are interfaces after all, just not implemented in the same way. The
> container would check for the annotation class on the bean and hook that
> bean up to the right connector, just as it would with the message listener
> interface.
>
> Further into the guts, we simply tweak the contract for the
> javax.resource.spi.endpoint.MessageEndpoint which currently is the "bean"
> that the connector invokes. It implements the message listener interface
> and the MessageEndpoint interface. For this new approach we definitely
> want that to not be an interface based proxy but a subclass proxy like
> @LocalBean. One idea to drive that altered behavior is to possibly say
> that when the message listener interface is an annotation, the container
> gives an @LocalBean-like reference rather than the traditional interface
> based proxy.
>
> That leaves one last problem to solve, exposing the bean class to the
> connector. We could simply say that when the connector gets the
> "localbean" MessageEndpoint it will have full access to the bean class and
> that is good enough, but probably we want to allow for validation up front.
> So that would be the one truly new aspect of all this. The current
> javabean-based validation can't easily be retrofitted to this, so we'll
> actually have add something here if we want to support up-front validation
> of these modern-style MDBs.
>
>
> The result is that we could do what we're wanting with JMS as well as
> retrofit JAX-RS as a connector -- much the same way we retrofitted JMS as a
> connector.
>
>
> And I'm totally +1 for offering this to more than "EJB" although I laugh
> at how people think this doesn't make those things "EJBs" -- a rose by
> another name and all that -- but I hope we don't let that distract us from
> actually pulling this off at all. Let's get this in and then work on doing
> without the @MessageDriven -- if we feel there's value in that.
>
>
> -David
>
>