Date: Sat, 9 Mar 2013 05:07:53 +0100
David/all,
Thanks for the incentive.
I see no technical problem with this. The "debt" of Java EE 7 lies in the
licensing of key APIs (that are therefore not frozen or guaranteed even
when the JSR goes Final due to this[?]), but it looks like most decision
makers stick their head in the sand and decide to sit it out for EE 7 until
some "Dumbledore" finally makes a definitive and binding statement,
probably for EE 8, or so?[?]
Cheers,
-- Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDR Skype werner.keil | Google+ gplus.to/wernerkeil * Codemotion III: March 22-23 2013, Rome, Italy. Werner Keil, JCP Executive Committee Member, JSR 354 EG Member will co-present "JSR 354 - Money and Currency API for Java" * Expert Days Berlin: April 5 2013, Berlin, Germany. Werner Keil, JCP Executive Committee Member, JSR 354 EG Member will co-present "JSR 354 - Money and Currency API for Java" * JavaOne Russia: April 23-24 2013, Moscow, Russia. Werner Keil, JCP Executive Committee Member, JSR 354/360 EG Member will present "JSR 321, JSR 354, Standards for the Future of Java Embedded" * GeeCON: May 16-17 2013, Krakow, Poland. Werner Keil, JCP Executive Committee Member, JSR 360 EG Member will present "Standards for the Future of Java Embedded" On Sat, Mar 9, 2013 at 4:27 AM, David Blevins <david.blevins_at_gmail.com>wrote: > I fully support this proposal and want to thank Bill and crew for working > to get this in so late. I've created a few implementations for the RI of > the basic idea using feedback from Bill and Marina and this version of the > proposal is definitely the best by far. > > The getEndpointClass() method is a significant improvement over the > beanClass property. The conditional activation of the new functionality > based on a "no methods" message listener interface is what I would call a > harmless and effective choice that 1) doesn't adversely affect existing > RAs, 2) doesn't eliminate more robust syntax in the future, and 3) doesn't > create any mess or API that would need to be deprecated when better syntax > is created. > > I'd best describe it as a razor sharp change made with a scalpel that > could have huge potential upside. Given the amount we'll learn over the > next 2-3 years about how people find new uses for our old code, this > balance is just right. > > A definite win for EE 7 that opens the door for considerable fun in EE 8. > > > -David > > On Mar 8, 2013, at 11:18 AM, Markus Eisele <myfear_at_web.de> wrote: > > > Hi Bill, > > > > thanks for listening to David's proposal. I support it and I > > understand the limitations given for the EE 7 scope. > > The proposed re-scoping sounds ok to me, but I am interested to read > > David's thought on it, too. > > > > Thanks, > > - Markus > > > > On 8 March 2013 20:11, Bill Shannon <bill.shannon_at_oracle.com> wrote: > >> 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. >
