+1. I agree with you.
On 9/23/2011 10:34 AM, Nigel Deakin wrote:
> I'd like to propose a modification to this issue:
>
> On 09/08/2011 11:35, Nigel Deakin wrote:
>> I have logged the following JIRA issue:
>> http://java.net/jira/browse/JMS_SPEC-45
>
> I have updated the description field of this issue to include this
> proposal.
>
> My previous proposal was to add a new method on Session:
>
> -----------------------------------------------------------------
> 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.
> -----------------------------------------------------------------
>
> This proposal appears to have received the tacit approval of the
> expert group.
>
> However I think an additional simplification would be useful for use
> in a Java EE environment, where the sessionMode is in many cases
> ignored and so the need to supply a value makes the application is an
> unnecessary complication. I would therefore like to extend this
> proposal to add a further new method on Session:
>
> -----------------------------------------------------------------
> 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.
> -----------------------------------------------------------------
>
> Any comments?
>
> Separately, John suggested:
> > Could your spec change perhaps use an enum to describe the
> sessionMode as well?
>
> If this has been a new API then an enum would have definitely been the
> right thing, and my initial reaction was to agree with John's
> proposal. However another EG member has pointed out that since we
> already have four static constants (Session.AUTO_ACKNOWLEDGE etc)
> adding four enum values which would effectively duplicate these would
> unnecessarily complicate the API. I'm therefore inclined to stick
> with the existing four static constants. Does anyone else have any
> particular views on this?
>
> Nigel
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1410 / Virus Database: 1520/3913 - Release Date: 09/22/11
>
>