Allow Java EE components other than MDBs to consume messages asynchronously

[glassfishrobot]

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
   }
  }
}

Affected Versions

[2.0]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jms-spec/issues/100
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@glassfishrobot Commented Reported by miojo

[glassfishrobot]

@glassfishrobot Commented miojo said: Same code o Gist (formatted)

https://gist.github.com/3750788

[glassfishrobot]

@glassfishrobot Commented miojo said: Can someone close this issue as invalid? JMS 2 just got final, so I don't see this going forward.

[glassfishrobot]

@glassfishrobot Commented genomeprjct said: 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.

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: 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.

[glassfishrobot]

@glassfishrobot Commented miojo said: 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

[glassfishrobot]

@glassfishrobot Commented genomeprjct said: 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).

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: 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 #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.

[glassfishrobot]

@glassfishrobot Commented genomeprjct said: 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?

[glassfishrobot]

@glassfishrobot Commented miojo said: 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?

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: 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.

[glassfishrobot]

@glassfishrobot Commented miojo said: 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 #116

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

[glassfishrobot]

@glassfishrobot Commented Issue-Links: depends on EJB_SPEC-60 is related to JMS_SPEC-134

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-100