Issue Details (XML | Word | Printable)

Key: JMS_SPEC-100
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Bruno Borges
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
jms-spec

Allow Java EE components other than MDBs to consume messages asynchronously

Created: 19/Sep/12 05:02 PM   Updated: 02/Sep/13 03:23 PM
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Dependency
 
Related
 

Tags: jms21-forreview-major
Participants: Bruno Borges, John D. Ament and Nigel Deakin


 Description  « Hide

This proposal suggests the addition of the following annotation: @MessageSelector, to be used on a @MessageDriven bean consumimng a Queue or as Topic Subscriber.

Example:

package sample;

// imports

@MessageDriven(mappedName = "jms/queue0")
public class MessageSelectorBean implements MessageListener {

  @Resource(lookup = "jms/connectionFactory")
  ConnectionFactory connectionFactory;

  @MessageSelector("(StockSector = 'Technology')")
  public void onMessage(Message message) {
    try (JMSContext context = connectionFactory.createContext()) {
      String request = ((TextMessage)message).getText();
      Destination replyDestination = message.getJMSReplyTo();
      TextMessage replyMessage = context.createTextMessage("Reply to: "+request);
      context.createProducer().send(replyDestination, replyMessage);
   } catch (JMSException ex) {
     // log an error here
   }
  }
}


Bruno Borges added a comment - 19/Sep/12 05:07 PM

Same code o Gist (formatted)

https://gist.github.com/3750788


Bruno Borges added a comment - 22/Apr/13 02:04 AM

Can someone close this issue as invalid? JMS 2 just got final, so I don't see this going forward.


John D. Ament added a comment - 22/Apr/13 02:10 AM

Since we now have an updated RA spec, we can make something like this happen. I'd strongly recommend leaving this open, maybe something we can tackle in JMS 2.1.


Nigel Deakin added a comment - 22/Apr/13 08:46 AM

I agree improvements to MDBs (and message listeners in Java SE as well) should be on the agenda for JMS 2.1, so I'll leave this open.


Bruno Borges added a comment - 22/Apr/13 10:09 AM

Extension of this proposal (which I forgot to add when I submitted the issue):

  • allow MDBs to have N "onMessage" methods, annotated with @MessageSelector

Questions to be analyzed:
1) should container create an instance of MDB per "message selector"?
2) should fields be thread-safe?
3) how would this affect concurrency?
4) how should pool size be defined? Per MDB (as it is now), or per message selector?

PS: great to see interest in this


John D. Ament added a comment - 22/Apr/13 01:24 PM

Note: the core MDB work is contained in the EJB spec. JMS does not define an MDB. JMS does define the endpoint interface (potentially the annotations that work with that interface as well).


Nigel Deakin added a comment - 22/Apr/13 04:12 PM - edited

Note that you can already (Java EE 6) specify the message selector of a MDB using annotations (the activation property messageSelector), though this can't be checked by the compiler.

From Bruno's last comment it sounds he is making a more general request, somewhat similar to JMS_SPEC-116 (logged by genomeprjct), of breaking the link between JMS MDBs and the javax.jms.MessageListener interface.

Perhaps we should combine this issue with that one.


John D. Ament added a comment - 25/Apr/13 02:44 AM

I think we generally need an approach for RA handling and how the MDBs will work with that RA. Based on what I'm seeing in the specs, it seems like it's essentially luck that the current JMS MDB even works somewhat consistently across application servers; it's just not clear to me yet that we can move forward with a change like this ourselves. In JMS 2 some standard configuration was added, but this was done by pushing the EJB EG to make the changes. When the JMS spec voted on an RA, it was generally voted down (note: my vote was to make it optional, but if an implementation did decide to provide one it needed to work with a specific interface for app servers).

My vote is to generally start to formulate what the next version of the JMS MDB looks like (based on the new RA structure provided by David and the platform spec); but do we need to officially file for a JMS 2.1 JSR?


Bruno Borges added a comment - 25/Apr/13 06:58 AM - edited

Allowing any method to be defined as a consumer could lead to a new approach at integrating message consumption and business methods. For example, such code could be possible:

package sample;

// imports

@Stateless
public class MySessionBean {

  @Resource(mappedName = "jms/queue0")
  private Queue queue0;

  @Inject
  private JMSContext jmsContext;

  public String retrieveUserPassword(String userEmail) {
    ... // business logic, connection to EntityManager, etc...
    return foundPassword;
  }

  @DestinationConsumer(mappedName = "jms/queue0")
  @MessageSelector("(LostPasswordBy = 'email')")
  public void sendEmailPassword(Message message) {
      String email = ((TextMessage)message).getText();
      String password = retrieveUserPassword(email);
      ... // call mailSession and send an email with recovered password
  }

  // method called by managedbean on UI, etc...
  public void requestLostPassword(String email) {
     TextMessage message = context.createTextMessage(email);
     message..setStringProperty("LostPasswordBy", "email");
     jmsContext.createProducer().send(queue0, message);
  }
}

Comments?


Nigel Deakin added a comment - 25/Apr/13 04:26 PM - edited

When this issue was first logged, the summary was "Support for annotation @MessageSelector on message driven beans".

I think we should change this to make it more general. Bruno's not just asking about message selectors (which you can already define using an annotation). It's about making it possible for Java EE components other than MDBs to consume messages asynchronously, and to replace the existing requirement to implement MessageListener with the ability to annotate individual methods. (I don't think we need to worry too much about the actual annotations just yet, the point is made.)

I'll change the description to "Allow Java EE components other than MDBs to consume messages asynchronously".

Just like JMS MDBs are currently defined in the EJB spec, this would probably end up being defined in the EJB spec. But the JMS expert group and community should "own" the issue and decide what it wants.

Note that we're currently (April 2013) in an interregnum between two versions of JMS currently: this issue may well be one which we want to specifically mention on the JSR for the next version.


Bruno Borges added a comment - 01/May/13 04:51 PM - edited

Perhaps we should consider two things:

  1. Extend the use of @MessageSelector for MDBs as is today, letting a MDB to have N-annotated methods with @MessageSelector
    I think this proposal can be worked for JMS 2.1 without the need for further details and changes over the spec, and it does not involve EJB spec.
  2. Let any component/method connect to a Destination, using Message Selectors, Activation Configs, etc.

This should be considered, IMO, as a proposal for EJB 3.next or EJB 4.0. This change would fit better with what David Blevins proposed on EJB_SPEC-60 and with what has already been discussed with JMS_SPEC-116

Good example of usecase that could benefit of this proposal is described at GLASSFISH-20371