Hi,
First of all let me say that I like the idea of giving the resource
adapter more information to work from an endpoint point of view.
Adding the
MessageEndpointFactory::getEndpointClass()
method fits this nicely.
However, we can't break the existing contracts defined in the message
inflow chapter. So chapter 13 needs to updated in the spirit of the
compromise text - empty message listener interface and business methods.
One thing to be careful about is not to tie the resource adapter
implementation to a specific endpoint implementation. Also the expected
use-case of having the resource adapter using reflection to "resolve"
the interaction pattern needs to be discussed in more detail in a future
specification. Using different message listeners and mandatory config
properties for the activation spec is a more strict contract, which is
better.
So lets start by adding the method, updating all of chapter 13 to take
it into account and update 13.7 with a new JMS scenario where the spec
text targets the compromise scenario.
Then we can get feedback from JMS and other inflow vendors on how we
should proceed from here in the next spec update.
We should mandate that the returned Class<?> is the actual endpoint, and
not the proxy. And that its ClassLoader has visibility to the needed
class definitions.
Looking at message inflow in general is also a good candidate for a
possible JCA 2.0 specification.
Best regards,
Jesper
P.S. In 13.4.4 the JNDI access for endpointDeactivation() got left out.
On 03/09/2013 11:11 AM, Sivakumar Thyagarajan wrote:
> Hello connector EG members,
>
> Please find attached a proposal [1] that Bill had sent to the platform
> expert group. There has been a discussion on enhancing the current MDB
> semantics in the EJB expert group for a while, and we recently had a
> discussion on this in our users alias as well.
>
> Please review the proposal below and share your comments by Wednesday,
> March 13 (as indicated below). There is a new method that is
> proposed to be added to the MessageEndpointFactory interface, and allow
> a resource adapter to introspect the MessageEndpoint to deliver to other
> methods in the MDB.
>
> Thanks
> --Siva.
> [1] available online at
> http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-03/message/2
>
>
> -------- 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.
>
>