jms-spec
  1. jms-spec
  2. JMS_SPEC-100

Allow Java EE components other than MDBs to consume messages asynchronously

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

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

        Issue Links

          Activity

          Hide
          Nigel Deakin added a comment - - 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.

          Show
          Nigel Deakin added a comment - - 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.
          Hide
          John D. Ament added a comment -

          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?

          Show
          John D. Ament added a comment - 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?
          Hide
          Bruno Borges added a comment - - 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?

          Show
          Bruno Borges added a comment - - 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?
          Hide
          Nigel Deakin added a comment - - 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.

          Show
          Nigel Deakin added a comment - - 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.
          Hide
          Bruno Borges added a comment - - 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

          Show
          Bruno Borges added a comment - - edited Perhaps we should consider two things: 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. 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

            People

            • Assignee:
              Unassigned
              Reporter:
              Bruno Borges
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: