-- 
--------------------
 Software Innovation Driver
 Researcher & Executive Director / WAS Lab / TmaxSoft R&D Center
 PGP  http://www.javadom.com/personal/yoonforhatgmaildotcom.asc
2013. 3. 9., 오전 4:11, Bill Shannon <bill.shannon_at_oracle.com> 작성:
> 
> 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.