From: Matthew White <WHITEMAT_at_uk.ibm.com>
Date: Wed, 17 Dec 2014 16:34:17 +0000

Hello;

I would vote for the definitive option in all cases; having a
specification that has vague or unclear isn't helpful for anybody in the
long-term. Even in the cases where there is a implicit conclusion it
doesn't help to spell it out - 'For the avoidance of doubt'

On a similar note is there an assumption in the JCP process which of the
reference implementation, compliance tests, written specification or API
JavaDoc has precedence in the case of conflict?


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: 16/12/2014 17:08
Subject: [jsr368-experts] Re: [jms-spec users] Re: JMS 2.0 errata:
Summary of proposed changes



Matthew,

> Apologise if this should be posted to a different newsgroup.

Thanks for your response. This is exactly the right place.

On 16/12/2014 15:40, Matthew White wrote:
> 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.

Thanks. It's very useful to know that you see value in the "definitive JMS
2.0 wording". We do have some options to
minimise the extent to which the spec will be "weakened" by these changes,
and I'd be interested to know what your views
are.

By definition, the requirement that JMS 2.0 must maintain compatibility
with previous versions of JMS only applies to
interfaces and methods which were defined in previous versions of JMS. It
doesn't apply to interfaces and methods which
were defined for the first time in JMS 2.0. Specifically:

JMS_SPEC-157: We have a compatibility issue regarding JMS 2.0's
requirement that Connection#createSession(bool,int) in a
Java EE application is required to throw an exception when an attempt is
made to create two sessions on the same connection.

Even if we accept that the definition of this method needs to be changed
to match the looser definition in Java EE 6, we
still need to decide whether the same change needs to be made to (a)
Connection#createSession(int) and
Connection#createSession() and to (b) JMSContext#createContext(int).

Which is more important, consistency (especially for (a)), or making the
new methods as definitive and portable as possible?

JMS_SPEC-155: We have a compatibility issue regarding the behaviour of
Connection#createSession(bool,int) in a Java EE
application when there is no JTA transaction and the parameters (true,*)
or (false,CLIENT_ACKNOWLEDGE) are specified.
JMS 2.0 requires that the specified parameters must be ignored.

Again, if we accept that the definition of this method needs to be changed
to match the looser definition in EJB 3.1, we
still need to decide whether the same change needs to be made to (a)
Connection#createSession(int) and to (b)
ConnectionFactory#createContext(int).

Which is more important, consistency (especially for (a)), or making the
new methods as definitive and portable as possible?

JMS_SPEC-158: We have a compatibility issue regarding the behaviour of
Session#close(), Connection#stop() and
Connection#close when called from a message listener on its own session or
connection. JMS 2.0 requires that this must
throw an exception.

Even we accept that the definition of these methods needs to be changed to
allow implementations which didn't throw an
exception to continue unchanged, we still need to decide whether or not
the same change needs to be made to
JMSContext#stop() and JMSContext#close().

Which is more important, keeping these new methods consistent with the
older methods, or making the new methods as
definitive and portable as possible?

(I'd welcome comments on these questions from anyone)

>
> JMS_SPEC-125 Define whether a JMS provider should call reset after
sending a BytesMessage asynchronously

You make some good points on this issue, to which I'll reply separately.

Thanks,

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