I uploaded the MDB chapter " MDB chapter with no-method message listener
interface
<
http://java.net/projects/ejb-spec/downloads/download/mdb.no-method.interface.pdf>"
to the ejb-spec download area. It is the same chapter as in the PFD
candidate available in the same location.
-marina
On 3/8/13 11:22 AM, Marina Vatkina wrote:
> Experts,
>
> This is our chance at modernizing MDBs in the Java EE 7 release.
>
> Obviously at this late stage in the release, the approach taken is to
> cause least disruption to all the specs (and the Connector spec is
> already way in its MR process). So consider it as the 1st step in the
> modernization process.
>
> Please review the proposed changes and voice your opinion ASAP. You
> can reply here or on the Platform aliases.
>
> thanks,
> -marina
>
> -------- Original Message --------
> Subject: [javaee-spec users] [jsr342-experts] proposed MDB improvements
> Date: Fri, 08 Mar 2013 11:11:40 -0800
> From: Bill Shannon <bill.shannon_at_oracle.com>
> Reply-To: jsr342-experts_at_javaee-spec.java.net
> To: jsr342-experts_at_javaee-spec.java.net
>
>
>
> Expert group members,
>
> I need your feedback by Wednesday, March 13.
>
> David Blevins has proposed some changes to the Message Driven Bean support:
> https://github.com/dblevins/mdb-improvements
> This Jira entry tracks this proposal:
> http://java.net/jira/browse/EJB_SPEC-60
> As you can see from the number of votes, this proposal has received quite a
> bit of support, so we've been looking into what it would take to implement
> it for Java EE 7.
>
> Given how late we are in the release, we need to carefully manage the
> risk associated with such a change, and limit the scope accordingly.
> At this point we have proposed spec changes and a prototype implementation
> that we're comfortable with. I'd like to describe the spec changes and
> get your feedback as to whether this is a reasonable and safe addition
> to Java EE 7. It will be helpful to read David's background proposal
> above.
>
>
> The first change is a minor addition to the Connectors spec:
>
> - Add a method to MessageEndpointFactory:
>
> /**
> * Return the Class object corresponding to the message
> * endpoint class. The resource adapter may use this to
> * introspect the message endpoint class to discover
> * annotations, interfaces implemented, etc. and modify
> * the behavior of the resource adapter accordingly.
> */
> public Class<?> getEndpointClass();
>
> This ability for the resource adapter to introspect the MDB class
> seems useful independent of any other change, and it's a simple,
> localized change to the Connector spec.
>
> This would require updating the in-progress Connector spec Maintenance
> Review.
>
>
> The second change is a change to the EJB spec to require that the
> MessageEndpointFactory.createEndpoint class behave differently in
> certain situations. To support the use cases in David's proposal,
> the resource adapter needs access to a proxy that implements all of
> the public methods of the MDB class, not just the methods of the
> message listener interface.
>
> The simple approach would be to require that the proxy returned by
> the createEndpoint method always include all the public methods, as
> well as implementing the message listener interface. That change is
> too risky for this release.
>
> In the expected use cases, the resource adapter will use reflection
> to invoke the methods of the MDB, based on annotations on those methods.
> The message listener interface is unnecessary in these use cases.
> Ultimately, we would like to remove the need for a message listener
> interface, and provide another mechanism for associating an MDB class
> with a resource adapter (e.g., based on annotations). That too is too
> risky for this release.
>
> As a compromise, our proposal for now is this:
>
> - If the message listener interface has no methods, the EJB container
> must provide a proxy returned from the createEndpoint method that
> implements all the public methods of the MDB class, as well as the
> message listener interface. (Perhaps that should be all the public
> *business* methods, so that Object methods need not be exposed?)
>
> This preserves the existing algorithm for associating a resource
> adapter with an MDB, and redefines a currently useless case to be useful.
> We can enhance this in a future release to provide more flexible binding
> between an MDB and a resource adapter.
>
> If you think these changes are reasonable and it's appropriate to add
> them to Java EE 7 at this late date, please speak up. As usual we'll
> interpret silence as consent, but we'd greatly prefer to have vocal
> support.
>
> And of course if you see any problems at all with this proposal, I'm
> confident that you'll speak up immediately.
>
> Lacking serious issues or objections by Wednesday, March 13, we'll
> proceed with this proposal.
>
> Thanks.
>
>