I like the direction this has taken. I wasn't particularly fond of
providing a beanClass activation property and the possibility of an MDB
exposing a NIV in prior revs. I have a few comments regarding the
proposed update to the MEF.
1. I think the getEndpointClass method name should be changed to
emphasize that this method is not returning the endpoint interface or the
endpoint implementation class, but some class that backs the endpoint and
might not exist for some MEFs.
/**
* Return the Class object corresponding to the message
* endpoint bean implementation class, or null if no specific
* implementation class is available. 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<?> getEndpointBeanClass();
2. This proposal puts the burden of bean class method <-> interface
method mapping on the RA. This mapping has proven to be complicated for
session interfaces for generics. Some method like the following could be
added to aid with this mapping within the RA...
/**
* Return the Method object that can be invoked on the result
* of createEndpoint for a declared method of the bean
* implementation class.
*
* @param beanClassMethod a declared method of {_at_link
#getEndpointBeanClass}
*/
public Method getEndpointMethod(Method beanClassMethod);
-Jeremy
From: Marina Vatkina <marina.vatkina_at_oracle.com>
To: jsr345-experts_at_ejb-spec.java.net,
Date: 03/08/2013 01:23 PM
Subject: [jsr345-experts] Fwd: [jsr342-experts] proposed MDB
improvements
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.