So, the proposals on this issue stand as follows:
1. A new method on Connection with no arguments as follows:
-----------------------------------------------------------------
Session createSession() throws JMSException
This method is particularly intended for use in a Java EE environment,
though it may also be used in a normal Java SE environment.
In a normal Java SE environmentm this is equivalent to calling createSession(Session.AUTO_ACKNOWLEDGE)
In a Java EE transaction, the session will be part of a transaction managed by the container.
In a Java EE undefined transaction context, the session will have a sessionMode of Session.AUTO_ACKNOWLEDGE.
-----------------------------------------------------------------
2. In addition, a new method on Connection with a single argument. There are two alternatives:
Option 2A (proposed by Nigel)
-----------------------------------------------------------------
Session createSession(int sessionMode) throws JMSException
In a normal Java SE environment sessionMode may be set to
Session.AUTO_ACKNOWLEDGE, Session.CLIENT_ACKNOWLEDGE, Session.DUPS_OK_ACKNOWLEDGE
or Session.TRANSACTED
In a Java EE transaction, sessionMode is ignored.
In a Java EE undefined transaction context, sessionMode may be set to
Session.AUTO_ACKNOWLEDGE or Session.DUPS_OK_ACKNOWLEDGE only.
-----------------------------------------------------------------
Option 2B (proposed by Ruediger and John)
-----------------------------------------------------------------
Session createSession(SessionMode sessionMode) throws JMSException
In a normal Java SE environment sessionMode may be set to
SessionMode.AUTO_ACKNOWLEDGE, SessionMode.CLIENT_ACKNOWLEDGE, SessionMode.DUPS_OK_ACKNOWLEDGE
or SessionMode.TRANSACTED
In a Java EE transaction, sessionMode is ignored.
In a Java EE undefined transaction context, sessionMode may be set to
SessionMode.AUTO_ACKNOWLEDGE or SessionMode.DUPS_OK_ACKNOWLEDGE only.
-----------------------------------------------------------------
3. The existing createSession with two arguments would remain unchanged
From the responses received so far, I think there is general consensus support for (1). However I do need views on
whether you prefer (2A) or (2B).
My own preference is for (2A). No doubt if the spec had been written subsequent to Java 5 it would have used enums.
However it wasn't and JMS has used these four integer constants for many years and people have been using them without
any problem. Introducing a set of enums to specify exactly the same thing as these existing constants simply adds
complication and potential confusion to solve a non-existent problem.
But please do give your views.
Nigel