[JMS_SPEC-116] Take advantage of EJB 3.2's RA improvement for MDBs Created: 12/Mar/13 Updated: 02/Jun/15
|Reporter:||John D. Ament||Assignee:||Nigel Deakin|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Tags:||jms21-forreview-major, messagedriven, ra|
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.
|Comment by Nigel Deakin [ 12/Mar/13 ]|
This interesting change comes too late to make any corresponding changes to JMS 2.0. I have added this issue to the list of issues which will be considered for JMS 2.1 and tagged it accordingly.
I'll also start a thread on the expert group to discuss this. Feel free to join in (or to contact me (Nigel) directly).
|Comment by dblevins [ 26/Apr/15 ]|
Hoping I can get some time to work on this in JMS 2.1. Adding some of the examples I've shown in presentations.
Example JMS MDB with what we have up until EJB 3.1. It has some issues:
Example JMS MDB with what we could do now with the changes added to EJB 3.2. Benefits:
The actual annotations we use would of course be defined by the group, but this is just to get the creative juices flowing.
|Comment by rdohna [ 01/May/15 ]|
Most of the annotations you proposed could be optional, all but @MessageDriven.
In the Message-API it's allowed to pass multiple arguments and the name of the method is used also, which is esp. handy when it's a verb with actual semantic (like delete). E.g. if the BuildTask has the properties jobName and revisionNumber and you want to start it, the method signature would be public void start(String jobName, long revisionNumber). If the message is a MapMessage, the names jobName and revisionNumber would be used to read a String and a long. If it's a TextMessage containing a xml body, it would look like <start><jobName>build</jobName><revisionNumber>1234243</revisionNumber></start>.
It's quite short, does it make sense? What do you think?