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.