jms-spec
  1. jms-spec
  2. JMS_SPEC-134

Declarative Annotation Based JMS Listeners

    Details

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

      Description

      MDB is currently the only declarative way of listening for JMS messages. While the MDB model is adequate, it has a few shortcomings (primarily related to it's true age). The first is that since it is rather generic to JCA, it makes the syntax less than ideal for JMS (ironically, the vast majority of MDB use is for JMS). The MDB model is highly coupled to the EJB component model, which makes generic use in managed beans needlessly difficult. Lastly and perhaps most importantly, reimaging the MDB model using CDI/annotations in a manner specific to JMS introduces the possibility of significant usability improvements/API modernization.

      It is perhaps best to demonstrate these concepts using some simple code examples:

      @Pooled // Documented here: https://java.net/jira/browse/EJB_SPEC-113
      public class MyListenerComponent {
      
        @JmsListener(destinationLookup="...", clientId="...", subsciptionName="...", messageSelector="...", ...)
        @JMSConnectionFactory("...")
        @Transactional
        public void listen (Message message) {
          ...
        }
      }
      
      @ApplicationScoped
      @MaxConcurrency(...) // Documented here: https://java.net/jira/browse/EJB_SPEC-113
      public class MyListenerComponent {
      
        @JmsListener(destinationLookup="...")
        public void listen (String message) { // Message payload automatically type-checked and unwrapped
          ...
        }
      
      }
      
      @RequestScoped // A message received is a "request"
      public class MyListenerComponent {
      
        @JmsListener(destinationLookup="...")
        // Message payload automatically type-checked and unwrapped, 
        // message contents automatically injected, type-checked, unwrapped.
        public void listen (byte[] message, 
                            @JmsMessageProperty boolean myFlag, 
                            @JmsMessageProperty("myFlag2") boolean myFlag2,
                            @JmsCorrelationId String myCorrelationId,
                            ... 
                            ) {
          ...
        }
      
      }
      
      @Pooled
      public class MyListenerComponent {
      
        @JmsListener(destinationLookup="...", batchSize="...", retry="...", retryDelay="...", ...) 
        // Batch delivery, retry, retry delay, DLQ, etc new features.
        public void listen (Message... messages) {
          ...
        }
      
      }
      

      As suggested in the examples above, decoupling from the EJB component model also allows for a great deal of flexibility in putting together the component life-cycle, programming model, features and re-use.

      Although I am entering this in JMS as I feel it is the correct place to get this done, I assume that this body of work will require a great deal of collaboration with the EJB, CDI and platform expert groups.

      Do let me know if anything needs to be explained further - I am happy to help.

      Please note that these are purely my personal views and certainly not of Oracle's as a company.

        Issue Links

          Activity

          No work has yet been logged on this issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              reza_rahman
            • Votes:
              11 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: