jsr343-experts@jms-spec.java.net

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

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Mon, 12 Mar 2012 18:13:53 +0000

Now that we've reached the JMS 2.0 Early Draft stage it's time for a review of where we are and what additional changes
we may wish to consider adding between now and the JMS 2.0 Public Draft in Q3 2012.

If you have something in mind which is not already covered in this list, please log it as a new JIRA issue, and I'll add
it to this list. *Please make any new proposals by the end of Friday 23rd March 2012*. (More about this below).

What I've done is to review all the issues in the JIRA issue tracker which have been contributed by me, other expert
group members, or members of the community. I've closed some as being duplicates and ignored (for now) some which do not
provide enough information. Those which remain are listed below. I've divided them into groups. Within each groups the
issues are listed in reverse issue number order.

First of all, here are the issues which we have already discussed, agreed, and incorporated in the Early Draft. These
are still open for public consultation, but in terms of getting them into the spec these are essentially complete:

JMS_SPEC-65 <http://java.net/jira/browse/JMS_SPEC-65> Clarify use of NoLocal arg when using createDurableSubscriber
JMS_SPEC-53 <http://java.net/jira/browse/JMS_SPEC-53> Make Connection and other interfaces implement AutoCloseable
JMS_SPEC-52 <http://java.net/jira/browse/JMS_SPEC-52> Clarify that a message may be sent using a different session from
that used to create the message
JMS_SPEC-51 <http://java.net/jira/browse/JMS_SPEC-51> New methods to replace Session.createDurableSubscriber() and
return a MessageConsumer
JMS_SPEC-50 <http://java.net/jira/browse/JMS_SPEC-50> Clarify that JMS providers must implement both P2P and Pub-Sub
JMS_SPEC-49 <http://java.net/jira/browse/JMS_SPEC-49> Improve specification of ExceptionListener
JMS_SPEC-48 <http://java.net/jira/browse/JMS_SPEC-48> Specify that connection.stop() or close() may not be called from
a MessageListener
JMS_SPEC-45 <http://java.net/jira/browse/JMS_SPEC-45> Clarify and improve Connection.createSession
JMS_SPEC-44 <http://java.net/jira/browse/JMS_SPEC-44> New API to specify delivery delay
JMS_SPEC-43 <http://java.net/jira/browse/JMS_SPEC-43> New API to send a message with async acknowledgement from server
JMS_SPEC-42 <http://java.net/jira/browse/JMS_SPEC-42> Make support for JMSXDeliveryCount mandatory
JMS_SPEC-39 <http://java.net/jira/browse/JMS_SPEC-39> Make clientId optional when creating a durable subscription
JMS_SPEC-34 <http://java.net/jira/browse/JMS_SPEC-34> Calling setJMSDeliveryMode or setJMSPriority on a
javax.jms.Message before it is sent don't have any effect
JMS_SPEC-33 <http://java.net/jira/browse/JMS_SPEC-33> Improving the JMS API with API simplifications, annotations and CDI
JMS_SPEC-27 <http://java.net/jira/browse/JMS_SPEC-27> Clarify the relationship between the JMS and other Java EE
specifications


The following three issues have also been discussed, agreed, and incorporated in the Early Draft. However I think a
little more work is 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 <http://java.net/jira/browse/JMS_SPEC-70> Define annotations for injecting MessagingContext objects
JMS_SPEC-64 <http://java.net/jira/browse/JMS_SPEC-64> Define simplified JMS API
JMS_SPEC-36 <http://java.net/jira/browse/JMS_SPEC-36> Allow messages to be delivered asynchronously in batches


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. One of the reason these didn't make it into the Early Draft was that I wasn't sure exactly what was
needed. 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-57 <http://java.net/jira/browse/JMS_SPEC-57> Add Java EE 7 multi-tenancy support
JMS_SPEC-47 <http://java.net/jira/browse/JMS_SPEC-47> Deprecate domain-specific APIs and propose for removal
JMS_SPEC-46 <http://java.net/jira/browse/JMS_SPEC-46> Define standard API to create and configure a ConnectionFactory
JMS_SPEC-41 <http://java.net/jira/browse/JMS_SPEC-41> Support topic hierarchies
JMS_SPEC-40 <http://java.net/jira/browse/JMS_SPEC-40> Allow multiple consumers to be created on the same topic
subscription
JMS_SPEC-28 <http://java.net/jira/browse/JMS_SPEC-28> Clarify how the JMS provider should interact with Transaction
Managers.
JMS_SPEC-26 <http://java.net/jira/browse/JMS_SPEC-26> Decide on the future of the optional Chapter 8 API "JMS
Application Server Facilities"
JMS_SPEC-25 <http://java.net/jira/browse/JMS_SPEC-25> Standardise the interface between a JMS provider and a Java EE
application server


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. I suggest we aim to handle all of these if
possible, but to work on them in parallel with larger issues.

JMS_SPEC-87 <http://java.net/jira/browse/JMS_SPEC-87> Section 2.5 "Interfaces" needs updating to introduce the
simplified API
JMS_SPEC-86 <http://java.net/jira/browse/JMS_SPEC-86> Chapter 1 "Introduction" is a little dated and requires rewriting
JMS_SPEC-85 <http://java.net/jira/browse/JMS_SPEC-85> Clarify how Message.receiveNoWait() is expected to behave
JMS_SPEC-84 <http://java.net/jira/browse/JMS_SPEC-84> Clarify when acknowledged persistent messages may be dropped
JMS_SPEC-82 <http://java.net/jira/browse/JMS_SPEC-82> Replace GMT with UTC
JMS_SPEC-81 <http://java.net/jira/browse/JMS_SPEC-81> Remove Change History for previous versions from the specification
JMS_SPEC-78 <http://java.net/jira/browse/JMS_SPEC-78> JMS implementation of QueueRequestor and TopicRequestor doesn't
throw correct exception when destination is null
JMS_SPEC-80 <http://java.net/jira/browse/JMS_SPEC-80> Error in example 9.3.3.2 "Reconnect to a topic using a durable
subscription"
JMS_SPEC-77 <http://java.net/jira/browse/JMS_SPEC-77> MapMessage.setBytes API discrepancy found in the javadocs
JMS_SPEC-75 <http://java.net/jira/browse/JMS_SPEC-75> Ambiguous javadocs for Connection.createConnectionConsumer and
createDurableConnectionConsumer
JMS_SPEC-69 <http://java.net/jira/browse/JMS_SPEC-69> Clarify that QueueRequestor and TopicRequestor only work in a
non-transacted session with auto or dups-ok ack
JMS_SPEC-31 <http://java.net/jira/browse/JMS_SPEC-31> change javadoc on session.createQueue and createTopic to make
clearer the provider may create a physical destination
JMS_SPEC-3 <http://java.net/jira/browse/JMS_SPEC-3> Fix JavaDocs to reflect missing NumberFormatException from API methods
JMS_SPEC-2 <http://java.net/jira/browse/JMS_SPEC-2> Fix JavaDocs to reflect missing IllegalStateException from API methods


We now come to the new issues which we have not considered yet, and which we need to put into some kind of priority
order for /consideration/. But before we do I'd like to extend a general invitation for new proposals in addition to
these. So if you have something in mind which is not already covered in this list, please log it as a new JIRA issue,
and I'll add it to this list. Please make any new proposals by the end of Friday 23rd March 2012. Those issues which we
don't have time to review, or include, in JMS 2.0 will be rolled over for consideration for JMS 2.1.

Here are the issues we currently have on the list. I plan to have an informal vote after 23rd March when we'll have the
complete list, but please feel free to express a view before then on any of these (either via email or by commenting on
the JIRA issue itself)..

These issues are *minor API tidy-ups*:

JMS_SPEC-79 New factory methods to create BytesMessage and MapMessage and set the payload
JMS_SPEC-71 <http://java.net/jira/browse/JMS_SPEC-71> Change XAConnectionFactory to extend ConnectionFactory
JMS_SPEC-68 <http://java.net/jira/browse/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 <http://java.net/jira/browse/JMS_SPEC-66> Define how MessageConsumer.receive should handle a thread interrupt
JMS_SPEC-24 <http://java.net/jira/browse/JMS_SPEC-24> Clarify classloader used in ObjectMessage.getObject() or provide
new method getObject(ClassLoader classLoader)
JMS_SPEC-22 <http://java.net/jira/browse/JMS_SPEC-22> Add JMS defined property JMSXGroupLast


These issues are *new features or more significant changes*

JMS_SPEC-83 <http://java.net/jira/browse/JMS_SPEC-83> Tighter specification of Expired Message Handling in Section 4.8
"Message Time-to-Live"
JMS_SPEC-74 <http://java.net/jira/browse/JMS_SPEC-74> Define lifecycle of durable subscriptions used by MDBs
JMS_SPEC-73 <http://java.net/jira/browse/JMS_SPEC-73> Define how messages from a topic are delivered to clustered
application server instances
JMS_SPEC-72 <http://java.net/jira/browse/JMS_SPEC-72> Poison message management
JMS_SPEC-59 <http://java.net/jira/browse/JMS_SPEC-59> Basic metadata/management via JMS
JMS_SPEC-58 <http://java.net/jira/browse/JMS_SPEC-58> New method Message.copyMessage() to create a mutable copy of a
received message
JMS_SPEC-37 <http://java.net/jira/browse/JMS_SPEC-37> Last Value Cache Feature for a topic.
JMS_SPEC-21 <http://java.net/jira/browse/JMS_SPEC-21> Support for pre-acknowledge ack mode
JMS_SPEC-18 <http://java.net/jira/browse/JMS_SPEC-18> Standard set of server JMX MBeans
JMS_SPEC-14 <http://java.net/jira/browse/JMS_SPEC-14> Durable subscription browser
JMS_SPEC-5 <http://java.net/jira/browse/JMS_SPEC-5> Multi-Value Support in Properties


JMS_SPEC-7 <http://java.net/jira/browse/JMS_SPEC-7> Provide HTTP Binding


These issues are *significant changes *which I think we can *reject *immediately

JMS_SPEC-61 <http://java.net/jira/browse/JMS_SPEC-61> Selector on JMS body
JMS_SPEC-4 <http://java.net/jira/browse/JMS_SPEC-4> Properties on Messages should follow builder pattern.


These issues are a bit vague and *need more specific proposals* before we can review them properly.

JMS_SPEC-11 <http://java.net/jira/browse/JMS_SPEC-11> Support for STOMP messaging
JMS_SPEC-9 <http://java.net/jira/browse/JMS_SPEC-9> Support for AMQP messaging
JMS_SPEC-8 <http://java.net/jira/browse/JMS_SPEC-8> Add Reference to URI Scheme
JMS_SPEC-6 <http://java.net/jira/browse/JMS_SPEC-6> Add Reference to SOAP Binding


NIgel