jsr343-experts@jms-spec.java.net

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

From: John D. Ament <john.d.ament_at_gmail.com>
Date: Wed, 28 Mar 2012 11:48:12 -0400

Nigel,

Here are my 6

JMS_SPEC-73 Define how messages from a topic are delivered to clustered
application server instances
- I would like this to be expanded to discuss queues

JMS_SPEC-88 Bind JMS to CDI events and/or business interfaces
JMS_SPEC-7 Provide HTTP Binding
JMS_SPEC-68 Add new method Session.acknowledge()
JMS_SPEC-24 Clarify classloader used in ObjectMessage.getObject()
and/or provide new method getObject(ClassLoader classLoader)
JMS_SPEC-72 Poison message management


John


On Wed, Mar 28, 2012 at 10:13 AM, Nigel Deakin <nigel.deakin_at_oracle.com>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 <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
>
>