jsr343-experts@jms-spec.java.net

[jsr343-experts] (JMS_SPEC-116) Take advantage of EJB 3.2's RA improvement for MDBs

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Tue, 12 Mar 2013 12:27:28 +0000

Community member "genomeprjct" logged this JIRA issue. This is a proposal that JMS takes advantages of the JCA and EJB
changes described in the recent email by Bill Shannon that I forwarded recently.

Here is the genomeprjct's proposal. I'll respond in a follow-up email.

--------------------------------------------------------------------------------------------------------------
Take advantage of EJB 3.2's RA improvement for MDBs
----------------------------------------------------

                  Key: JMS_SPEC-116
                  URL: http://java.net/jira/browse/JMS_SPEC-116
              Project: jms-spec
           Issue Type: New Feature
             Reporter: genomeprjct


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 it unfortunate that this change has