From: Matthew White <WHITEMAT_at_uk.ibm.com>
Date: Tue, 16 Dec 2014 15:40:26 +0000
Hello;
One of the changes I have some concern over, the others I'm happy with.
The only observation is that it is a shame that the very definitive JMS2.0
wording is being weakened but based on the established other
specifications it's a reasonable course of action.
JMS_SPEC-125 Define whether a JMS provider should call reset
after sending a BytesMessage asynchronously
Main observations here:
1) Yes the spec is vague here, and different vendors have gone different
directions. I agree with the observation regarding messages from different
vendors.
2) The statement in JMS_SPEC-125 regarding the de facto implementation.
There is nothing in the spec that says that the message object that is
used for the completion listener should be the same instance of the
message as the one that is sent. It could be a duplicate - therefore the
state of the message could be different in both cases; read-only in the
completion listener. But writeable in the main thread.
2) The spec on async send says that after completion listener has fired,
then the behaviour is as if a sync send had occured. This is a useful
statement to reason about the behaviour of async send. It would be
reasonable I would assert that this should also include the state of the
message. Therefore I do not believe that their should be a difference in
the spec between async and sync send and bytes messages.
The proposal here is that the errata says the spec must be changed to a
specific version; however this itself could present a migration issue.
Could I suggest that in line with the other changes a 'recommended'
approach is used. JMS2.1 could move to a prescriptive model.
Apologise if this should be posted to a different newsgroup.
Regards,
Matthew B. White
Architect: IBM MQ JMS, Connectivity & Integration
Phone: 44-1962-817653
E-mail: WHITEMAT_at_uk.ibm.com
About.me: about.me/matthewbwhite
Find me on: and within IBM on:
Hursley Park
Hursley , SO212JN
United Kingdom
"The wrong answers are the ones you go looking for when the right answers
stare you in the face."
From: Nigel Deakin <nigel.deakin_at_oracle.com>
To: jsr368-experts_at_jms-spec.java.net
Date: 09/12/2014 18:04
Subject: [jsr368-experts] JMS 2.0 errata: Summary of proposed
changes
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU