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