On 04/04/2012 12:18, John D. Ament wrote:
> So what exactly is the plan with the proposed high priority items (from the EG's perspective)? I know a few of mine
> need some more concrete proposals (e.g. APIs, specifications on what happens), should we just start throwing them around
> and see what sticks?
I've received three sets of "votes" for the P3 "New Issues" (including one set from John). More "votes" welcome.
As for your question: the "top" (P1) priority was the three unresolved issues from the Early Draft:
JMS_SPEC-70 Define annotations for injecting MessagingContext objects
There are quite a few unresolved aspects to this, but the biggest was what the scope of the injected objects should be.
The Early Draft proposed request scope, but I subsequently proposed a combined request/transaction scope as an
alternative. This was put on hold pending any possible new transaction scope being added to CDI, but nothing seems to be
happening and I suspect we should simply define whatever scope *we* need.
JMS_SPEC-64 Define simplified JMS API
The main unresolved aspect to this was the API for async message delivery, which I felt was getting too complicated. I
think we've largely resolved this by reinstating a separate JMSConsumer object.
JMS_SPEC-36 Allow messages to be delivered asynchronously in batches
This issue is receiving decidedly mixed views, with some EG members asking that this be deferred until Java EE 8 allows
a more flexible async message delivery mechanism. In the absence of a clear need for this feature I'm inclined to defer
it too (and remove it from the spec) though I've simply left this for now.
John - are all the topics of interest to you captured as JIRA issues now? (I think Ruediger's JMS_SPEC-88
<
http://java.net/jira/browse/JMS_SPEC-88> proposal for linking incoming messages to CDI events is somewhat different
from what you have advocated in the past, so you may want to log this as a separate issue).
Which were the topics that you were thinking of providing more concrete proposals? if it's a topic we haven't started
discussing yet, then I would suggest updating the JIRA issue first of all.
Does this answer your question?
Nigel
On 28/03/2012 15:13, Nigel Deakin 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
>