jsr343-experts@jms-spec.java.net

[jsr343-experts] Re: JMS 2.0: Planning the next stage

From: <reza_rahman_at_lycos.com>
Date: Thu, 5 Apr 2012 23:53:17 +0000 (GMT)

My list. Only feel strongly about #1.

JMS_SPEC-79 New factory methods to create BytesMessage and MapMessage and set the payload
JMS_SPEC-71 Change XAConnectionFactory to extend ConnectionFactory
JMS_SPEC-90 Provide simpler mechanism to refer to queues and topics in a portable way
JMS_SPEC-74 Define lifecycle of durable subscriptions used by MDBs
JMS_SPEC-72 Poison message management
JMS_SPEC-18 Standard set of server JMX MBeans


Mar 28, 2012 10:14:18 AM, jsr343-experts_at_jms-spec.java.net wrote:

===========================================

      I'd like to move to the next stage in planning the next stage of our work on JMS 2.0, and for this I would like your help in selecting the order in which we discuss the various proposals that have been made.
    
    If you don't feel like reading the whole thing, please jump to "Priority 3: New Issues" below and read on to the Action:
    
    I have reviewed all the issues in JIRA, including those added in the last two weeks, and sorted them into groups.
    
    I'm managing this using tags: if you're interested in this please look at
    http://java.net/projects/jms-spec/pages/JIRAUsage
    which contains the queries I used to generate the lists below.
    
    Issues incorporated in the Early Draft and complete
    
    Here are the issues which we have already discussed, agreed, and incorporated in the Early Draft, and appear to be essentially complete. I don't think we need to discuss them further, though I expect the engineers working on the RI and TCK may uncover errors or ambiguities which we may need to resolve.
    
                    
          JMS_SPEC-65 Clarify use of NoLocal arg when using createDurableSubscriber
        
          JMS_SPEC-53 Make Connection and other interfaces implement AutoCloseable
        
          JMS_SPEC-52 Clarify that a message may be sent using a different session from that used to create the message
        
          JMS_SPEC-51 New methods to replace Session.createDurableSubscriber() and return a MessageConsumer
        
          JMS_SPEC-50 Clarify that JMS providers must implement both P2P and Pub-Sub
        
          JMS_SPEC-49 Improve specification of ExceptionListener
        
          JMS_SPEC-48 Specify that connection.stop() or close() may not be called from a MessageListener
        
          JMS_SPEC-45 Clarify and improve Connection.createSession
        
          JMS_SPEC-44 New API to specify delivery delay
        
          JMS_SPEC-43 New API to send a message with async acknowledgement from server
        
          JMS_SPEC-42 Make support for JMSXDeliveryCount mandatory
        
          JMS_SPEC-39 Make clientId optional when creating a durable subscription
        
          JMS_SPEC-34 Calling setJMSDeliveryMode or setJMSPriority on a javax.jms.Message before it is sent don't have any effect
        
          JMS_SPEC-33 Improving the JMS API with API simplifications, annotations and CDI
        
          JMS_SPEC-27 Clarify the relationship between the JMS and other Java EE specifications
              
    Priority 1: Issues incorporated in the Early Draft which are not complete
    
    The following three issues have also been discussed, agreed, and incorporated in the Early Draft. However during the process of preparing the Early Draft I realised that more work was needed on them, as I explicitly described in Section A.2 of the Early Draft. Completing these issues is our highest priority for the Public Draft.
    
                    
          JMS_SPEC-70 Define annotations for injecting MessagingContext objects
        
          JMS_SPEC-64 Define simplified JMS API
        
          JMS_SPEC-36 Allow messages to be delivered asynchronously in batches
              
    Priority 2: Issues which were planned for the early Draft but which couldn't be completed in time
    
    The next priority, I would suggest, is the following issues which were planned for the Early Draft but which couldn't be completed in time, either because we ran out of time or because they turned out to be difficult. Considering these issues, and deciding what changes, if any, are needed, is (I would suggest) our next-highest priority for the Public Draft.
    
                    
          JMS_SPEC-89 Define standard API to create and configure a ConnectionFactory in Java SE applications and by a Java EE container
        
          JMS_SPEC-57 Add Java EE 7 multi-tenancy support
        
          JMS_SPEC-47 Deprecate domain-specific APIs and propose for removal
        
          JMS_SPEC-41 Support topic hierarchies
        
          JMS_SPEC-40 Allow multiple consumers to be created on the same topic subscription
        
          JMS_SPEC-28 Clarify how the JMS provider should interact with Transaction Managers.
        
          JMS_SPEC-26 Decide on the future of the optional Chapter 8 API "JMS Application Server Facilities"
        
          JMS_SPEC-25 Standardise the interface between a JMS provider and a Java EE application server
              
    Background tasks: Very minor issues which can be discussed in parallel to other issues
    
    The following issues are clarifications, documentation tidy-ups or minor changes to exception handling etc. These involve none or few code changes, and I believe they are generally uncontroversial. They are all low priority but because they are very minor I think we should be able to handle them all in parallel with larger issues. I don't think there's any need to spend time putting these in order of priority: I'll just work my way through them.
    
                    
          JMS_SPEC-87 Section 2.5 "Interfaces" needs updating to introduce the simplified API
        
          JMS_SPEC-86 Chapter 1 "Introduction" is a little dated and requires rewriting
        
          JMS_SPEC-85 Clarify how Message.receiveNoWait() is expected to behave
        
          JMS_SPEC-84 Clarify when acknowledged persistent messages may be dropped
        
          JMS_SPEC-82 Replace GMT with UTC
        
          JMS_SPEC-81 Remove Change History for previous versions from the specification
        
          JMS_SPEC-80 Error in example 9.3.3.2 "Reconnect to a topic using a durable subscription"
        
          JMS_SPEC-78 JMS implementation of QueueRequestor and TopicRequestor doesn't throw correct exception when destination is null
        
          JMS_SPEC-77 MapMessage.setBytes API discrepancy found in the javadocs
        
          JMS_SPEC-75 Ambiguous javadocs for Connection.createConnectionConsumer and createDurableConnectionConsumer
        
          JMS_SPEC-69 Clarify that QueueRequestor and TopicRequestor only work in a non-transacted session with auto or dups-ok ack
        
          JMS_SPEC-31 change javadoc on session.createQueue and createTopic to make clearer the provider may create a physical destination
        
          JMS_SPEC-3 Fix JavaDocs to reflect missing NumberFormatException from API methods
        
          JMS_SPEC-2 Fix JavaDocs to reflect missing IllegalStateException from API methods
              
    Priority 3: New Issues
    
    We now come to the new issues which we have not formally considered yet. I think we should plan to discuss all of them, even if the conclusion is to do nothing. However, bearing in mind the Priority 2 issues above, I don't think we are going to have time to discuss all of them in time for JMS 2.0 so we decide which ones to discuss first:
    
    Here are the 14 larger new issues:
    
                    
          JMS_SPEC-90 Provide simpler mechanism to refer to queues and topics in a portable way
        
          JMS_SPEC-88 Bind JMS to CDI events and/or business interfaces
        
          JMS_SPEC-83 Tighter specification of Expired Message Handling in Section 4.8 "Message Time-to-Live"
        
          JMS_SPEC-74 Define lifecycle of durable subscriptions used by MDBs
        
          JMS_SPEC-73 Define how messages from a topic are delivered to clustered application server instances
        
          JMS_SPEC-72 Poison message management
        
          JMS_SPEC-59 Basic metadata/management via JMS
        
          JMS_SPEC-58 New method Message.copyMessage() to create a mutable copy of a received message
        
          JMS_SPEC-37 Last Value Cache Feature for a topic.
        
          JMS_SPEC-21 Support for pre-acknowledge ack mode
        
          JMS_SPEC-18 Standard set of server JMX MBeans
        
          JMS_SPEC-14 Durable subscription browser
        
          JMS_SPEC-7 Provide HTTP Binding
        
          JMS_SPEC-5 Multi-Value Support in Properties
              
    Here are the 8 smaller new issues:
    
                    
          JMS_SPEC-91 New "relaxed message order" option
        
          JMS_SPEC-79 New factory methods to create BytesMessage and MapMessage and set the payload
        
          JMS_SPEC-71 Change XAConnectionFactory to extend ConnectionFactory
        
          JMS_SPEC-68 Add new method Session.acknowledge()
        
          JMS_SPEC-67 Relaxing the requirement to throw an exception if a message is sent to a deleted temp destination
        
          JMS_SPEC-66 Define how MessageConsumer.receive should handle a thread interrupt
        
          JMS_SPEC-24 Clarify classloader used in ObjectMessage.getObject() and/or provide new method getObject(ClassLoader classLoader)
        
          JMS_SPEC-22 Add JMS defined property JMSXGroupLast
              
    Action: I would like to invite everyone to select up to 6 issues from the 22 issues listed in the two tables above that you think we should discuss. I'll then combine our choices into a single shortlist. Anything not shortlisted will stay on the list for later.
    
    If there are only a handful of replies I will assume that no-one else has any particular views and is happy leaving me to decide. (Though if you're happy leaving me to decide, please say so anyway!)
    
    Here is my shortlist: I've reviewed these within Oracle and we would pick out the following 5 as worth considering first:
    
                  
          JMS_SPEC-90
                       Provide simpler mechanism to refer to queues and topics in a portable way
                            
          JMS_SPEC-73
                       Define how messages from a topic are delivered to clustered application server instances
                            
          JMS_SPEC-79 New factory methods to create BytesMessage and MapMessage and set the payload
                  
                            
          JMS_SPEC-68 Add new method Session.acknowledge()
                            
          JMS_SPEC-91
                      New "relaxed message order" option
              
     Other issues
    
    These issues are significant changes which I propose to reject . I'll start a (hopefully brief) email thread to confirm this before I do so.
    
                    
          JMS_SPEC-61 Selector on JMS body
        
          JMS_SPEC-4 Properties on Messages should follow builder pattern.
              
    These issues may well have merit, but they're just one-liners with no details, and I don't think we can take them further unless the submitter, or someone else, makes some more specific proposals. I therefore propose to simply leave these open at the present.
    
                    
          JMS_SPEC-11 Support for STOMP messaging
        
          JMS_SPEC-9 Support for AMQP messaging
        
          JMS_SPEC-8 Add Reference to URI Scheme
        
          JMS_SPEC-6 Add Reference to SOAP Binding
              
    Nigel