I have now completed a first pass through the proposed corrections for the JMS 2.0 errata. Please review these changes
and let me know if you have any comments or questions. To make things easier, here's a summary which draw attention to
the main issues.
There's a summary at
https://java.net/projects/jms-spec/pages/JMS20RevA
In all cases, the latest proposals are in the JIRA issue.
There are a number of places where I'd particularly welcome input.
In JMS_SPEC-158 (stop/close in message listener) There is some scope to decide exactly how specific to be about how
these methods should behave if they are implemented to "work" rather than throw an exception.
In JMS_SPEC-157 (restriction on two sessions per connection in Java EE) and JMS_SPEC-155 (behaviour of createSession in
Java EE) I propose changes in a couple of places where JMS 2.0 inadvertently changed non-mandatory behaviour to
mandatory behaviour, and this has introduced an incompatible change which I need to revert. However the issue of
compatibility applies only to the classic API. With the new simplified API we have a choice: (a) changing it too to keep
it consistent with the classic API, or (b) leaving the spec as it is and keeping the tighter, more portable and less
ambiguous definition of JMS 2.0.
Here's a summary of the the significant changes:
Significant changes
-------------------
JMS_SPEC-161 serialVersionUID of JMSException has changed from JMS 1.1 to JMS 2.0
This is a compatibility bug in the exception classes in the JMS API jar. The code changes are described in
https://java.net/jira/browse/MQ-359 . A release candidate of the JMS 2.0 API jar has been released to Maven Central.
JMS_SPEC-158 JMS 2.0 introduced incompatible changes to Connection.stop and close and Session.close
The proposed change will allow JMS providers which want stop and close to "work" rather than throw an exception to do so.
REQUEST: Please review the proposed definition of these methods.
QUESTION: I have tried to be relatively specific about what these methods should do if they "work" rather than throw an
exception. Is this appropriate or should we leave the behavior more loosely-defined? Please pay particular attention to
my proposal for the effect of closing a auto-ack session from a message listener: should we be so specific about whether
the message is acknowledged or not?
JMS_SPEC-157 JMS 2.0 introduced an incompatible restriction on creating two sessions per connection in Java EE
The proposed changes will make it optional for the application server to enforce this restriction.
REQUEST: Please review the proposed definition of these methods.
QUESTION: I think we have no choice in relaxing the mandatory requirement in Java EE that Connection#createSession
throws an exception if the application attempts to create two sessions per connection, since it broke backward
compatibility. However we could leave the equivalent requirement for the simplified API, that JMSContext#createContext
throws an exception if the application tries to use it to create two sessions per connection, unchanged from JMS 2.0 if
we wanted to. What do you think? Please note that despite this change I am not proposing to change the spec requirement
that applications "must not" attempt to create two sessions per connection.
JMS_SPEC-155 JMS 2.0 introduced incompatible changes to createSession(bool,int)
The proposed changes will make it optional for the application server to ignore the supplied session parameters when in
a Java EE application and there is no active JTA transaction.
REQUEST: Please review the proposed definition of these methods.
QUESTION: Once again I think we have no choice in relaxing the definition of createSession since it broke backward
compatibility. However we could leave the definition of createContext unchanged from JMS 2.0 if we wanted to. What do
you think?
JMS_SPEC-156 JMS does not adequately define the behaviour of getAcknowledgeMode, getTransacted and getSessionMode in
Java EE
I have been thinking about this a bit more and think that we can probably defer this to JMS 2.1 or later. So I'm
withdrawing this proposal from the errata.
JMS_SPEC-125 Define whether a JMS provider should call reset after sending a BytesMessage asynchronously Omission in
spec and javadocs
The proposed changes make this a requirement for async (but not sync) send.
REQUEST: Please review the proposed changes
Minor changes
-------------
JMS_SPEC-119 Remove reference to password alias
This removes a reference to Java EE 7 password aliasing, which didn't make it into the final release of Java EE 7. No
particular need to review this.
JMS_SPEC-163 Javadoc for JMSContext#setClientID contains obsolete MessageContext reference
JMS_SPEC-160 JMS API source contains self-closing HTML tags
JMS_SPEC-128 Typo in section 4.14 "Queue"
JMS_SPEC-127 Incorrect HTML in API documentation
JMS_SPEC-120 Typo: in example, change .class() to .class T
These are all very straightforward and uncontroversial typos. No particular need to review these.
Changes proposed for JMS 2.0 errata but not yet drafted
-------------------------------------------------------
JMS_SPEC-133 Update javadoc comments for QueueConnection#createQueueSession and TopicConnection#createTopicSession
These methods need what is essentially a copy of the text for Connection#createSession. I'm therefore waiting for the
final text for JMS_SPEC-155 before drafting this.
JMS_SPEC-122 Typos in javadocs for ConnectionFactory.createContext
This is just a typo, and will be addressed as part of the changes for JMS_SPEC-155.
Nigel