David,
I discussed your proposal with the JCA spec lead. We agreed that it
sounds very interesting, but would require substantial changes to the
JCA spec. Unfortunately no new version of the JCA spec had been planned
in Java EE 7 time frame, so it will need to wait until EE 8.
Best,
-marina
David Blevins 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
>
>