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 <
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
*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 <
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
*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 <
http://java.net/jira/browse/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 <
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-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
*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 <
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-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-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-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
*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 <
http://java.net/jira/browse/JMS_SPEC-90> Provide simpler mechanism to refer to queues and topics in a
portable way
JMS_SPEC-88 <
http://java.net/jira/browse/JMS_SPEC-88> Bind JMS to CDI events and/or business interfaces
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-7 <
http://java.net/jira/browse/JMS_SPEC-7> Provide HTTP Binding
JMS_SPEC-5 <
http://java.net/jira/browse/JMS_SPEC-5> Multi-Value Support in Properties
Here are the 8 smaller new issues:
JMS_SPEC-91 <
http://java.net/jira/browse/JMS_SPEC-91> New "relaxed message order" option
JMS_SPEC-79 <
http://java.net/jira/browse/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 <
http://java.net/jira/browse/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() and/or
provide new method getObject(ClassLoader classLoader)
JMS_SPEC-22 <
http://java.net/jira/browse/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
<
http://java.net/jira/browse/JMS_SPEC-90> Provide simpler mechanism to refer to queues and topics in a portable way
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-79 <
http://java.net/jira/browse/JMS_SPEC-79> New factory methods to create BytesMessage and MapMessage and set
the payload
JMS_SPEC-68 <
http://java.net/jira/browse/JMS_SPEC-68> Add new method Session.acknowledge()
JMS_SPEC-91
<
http://java.net/jira/browse/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 <
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 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 <
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