On 12/03/2013 12:27, Nigel Deakin wrote:
> Community member "genomeprjct" logged this JIRA issue.
>
> In a late change to the EJB 3.2 spec, a new feature around building MDBs without requiring method-level implementations
> has been added, specifically for use within the RA.
>
> I am proposing that the JMS spec take advantage of this new feature in the following ways:
>
> The description references this email thread from the EJB Spec:
> http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2013-03/message/49
>
> 1. Introduce a new interface "javax.jms.JMSMessageEndpoint" (or similar name) that can be used as a marker interface
> required by MessageEndpointFactory.getEndpointClass(). It shall have no methods, not extend any other interface but
> simply exist to be a marker that the given class will have its public methods exposed as potential targets for messages
> received by the RA.
>
> 2. Introduce a new annotation, or possibly several annotations, to represent the configuration available to these
> methods. I believe we should support something more fluid (e.g. compiler friendly) than the existing
> ActivationConfigProperty set.
>
> 3. Currently, the onMessage method is defined by looking for a method named "onMessage" that takes a "Message" object as
> an argument. This algorithm should be changed to also look for any instance of "JMSMessageEndpoint", find any method
> that is annotated as XXX (whatever is defined in 2) as a possible target, then depending on there being a match between
> that takes anything that derives from "Message" and only pass appropriate messages to it.
>
> Some down sides:
>
> 1. The EG has already voted to not require an RA with every implementation.
> 2. This is a late change, so is the EJB equivalent.
> 3. Currently, MDB behavior and RA aren't necessarily defined within the JMS spec.
I think is unfortunate that the JCA/EJB change referred to here has come so late (just one week from the planned date
for me to submit the JMS 2.0 spec, TCK and RI to the JCP), since it raises some interesting possibilities for JMS MDBs.
I have therefore formally added this issue to the list of issues that we will discuss for JMS 2.1. However I think it
appropriate to have a discussion about this now.
Currently a resource adapter defines the interface class that a MDB must implement. This defines one or more callback
methods that the resource adapter will call. By convention a JMS resource adapter supports the javax.jms.Message
interface which defines a single callback method, onMessage(Message m).
There is already nothing to to prevent the creation of resource adapters now which use other interface classes, and
which use more than one callback method. This is entirely up to the resource adapter developer. However any MDBs would
only work with that particular resource adapter.
The JCA/EJB spec change that is currently being discussed would allow the creation of resource adapters which use an
interface with no methods. The resource adapter would need to define some annotations which the MDB would use to
identify what callback method(s) it would use, and perhaps specify some additional information such as destination,
message selector etc.
Even with no change in JMS there will be nothing to prevent the creation of resource adapters which do just this.
However any MDBs would only work with that particular resource adapter.
So I think the question for JMS is whether it should define a standard marker interface, and some standard annotations,
which a "standard JMS resource adapter" should support. This would allow a MDB which implemented that interface to be
portable between all resource adapters which supported those standards. I think it should.
I think it is possible that this may ultimately need to be defined in the EJB spec rather than the JMS spec, but that's
an issue which can be handled at the appropriate time.
Just as soon as the JCA/EJB change is approved and implemented it will become possible for RA developers to start
experimenting with this. We can then use the experienced gained to define some standard annotations for JMS 2.1 (or EJB
3.3).
Nigel