May I try to summarise what I think is being proposed here?
1. We define a new enum javax.jms.SessionType
public enum SessionType { AUTO_ACKNOWLEDGXE, CLIENT_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE, SESSION_TRANSACTED }
(Note, I'm deliberately not calling this an acknowledgement type since local transacted sessions are for sending
messages as well)
2. We add a new method to the interface javax.jms.Connection:
Session createSession(SessionType sessionType) throws JMSException;
3. Applications could create a Session using
connection.createSession(SessionType.CLIENT_ACKNOWLEDGE);
4. Implementations could implement the new method however they like, but they could do using something like:
@Override
public Session createSession(SessionType sessionType) throws JMSException {
if (sessionType==SessionType.AUTO_ACKNOWLEDGE){
return createSession(false,Session.AUTO_ACKNOWLEDGE);
} else if (sessionType==SessionType.CLIENT_ACKNOWLEDGE){
return createSession(false,Session.CLIENT_ACKNOWLEDGE);
} else if (sessionType==SessionType.DUPS_OK_ACKNOWLEDGE){
return createSession(false,Session.DUPS_OK_ACKNOWLEDGE);
} else if (sessionType==SessionType.SESSION_TRANSACTED){
return createSession(true,Session.SESSION_TRANSACTED);
}
throw new JMSException("Invalid sessionType");
}
5. Client applications would look something like:
Session session = connection.createSession(SessionType.CLIENT_ACKNOWLEDGE);
Do we need anything apart from that?
(Note that I think we're still undecided about whether we want to define these enums, but that doesn't stop us working
on what they might look like)
Nigel
On 27/09/2011 07:54, Rüdiger zu Dohna wrote:
> John,
>
> the constants are:
> public static final int AUTO_ACKNOWLEDGE = 1;
> public static final int CLIENT_ACKNOWLEDGE = 2;
> public static final int DUPS_OK_ACKNOWLEDGE = 3;
> public static final int SESSION_TRANSACTED = 0;
>
> So it would match the enum:
>
> public AcknowledgeType {
> SESSION_TRANSACTED, AUTO_ACKNOWLEDGE, CLIENT_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE;
> }
>
> I understand, though, that ordinals should generally not be used to transport semantics (cf. Effective Java, Item 31),
> but as this use is deprecated _and_ was stable for 9 years, I'd say we are safe to ignore that warning ;)
>
>
> Rüdiger
>
> On 27.09.2011 01:58, John D. Ament wrote:
>> Rudiger,
>>
>> Perhaps, though not guaranteed. I would presume that each value in the
>> enum set would have a numeric value matching the ordinal as defined in
>> Session.
>>
>> John
>>
>> On Mon, Sep 26, 2011 at 10:30 AM, Rüdiger zu Dohna
>> <ruediger.dohna_at_1und1.de <mailto:ruediger.dohna_at_1und1.de>> wrote:
>>
>> John,
>>
>> the valueOf(int) method is a synonym for values()[i], isn't it?
>>
>> And should we really declare this method:
>> > Connection.createSession(__boolean,EnumClassName);
>>
>> The "transacted" boolean is redundant to the EnumValue
>> SESSION_TRANSACTED, isn't it?
>>
>>
>> Rüdiger
>>
>>
>> On 26.09.2011 11 <tel:26.09.2011%2011>:44, John D. Ament wrote:
>>
>> Thanks Rudiger for pushing this. I was trying to avoid "force" but
>> figure I should pitch in; here's my attempt at clarifying my
>> request,
>> hopefully I don't mess it up :-)
>>
>> The way I see it, for backwards compatibility, we leave the int
>> method
>> in place:
>>
>> Connection.createSession(__boolean,int);
>>
>> In the enum we introduce a valueOf method, taking the int value
>> as an
>> argument and returning the enum. We then add the following
>> methods, and
>> mark the current int method as deprecated:
>>
>> Connection.createSession(__boolean,EnumClassName);
>> Connection.createSession(); //for use in EE
>> Connection.createSession(__EnumClassName);
>>
>> We're not introducing four enums, we're introducing one enum
>> that has 4
>> values within it. The valueOf method helps us bridge the old
>> way for
>> calling and the new one. Here's how I figure each method
>> would be used:
>>
>> Connection.createSession(__boolean,int);
>> just returns createSession(boolean, EnumClassName.valueOf(int));
>>
>> Connection.createSession();
>> Just creates a default transacted session for EE use, with
>> behavior in
>> EE and SE as defined by Nigel below.
>>
>> Connection.createSession(__EnumClassName);
>> Transactional state as noted by Nigel above.
>>
>> Connection.createSession(__boolean,EnumClassName);
>> Same behavior as today.
>>
>> John
>>
>>
>> On Mon, Sep 26, 2011 at 2:55 AM, Rüdiger zu Dohna
>> <ruediger.dohna_at_1und1.de <mailto:ruediger.dohna_at_1und1.de>
>> <mailto:ruediger.dohna_at_1und1.__de
>> <mailto:ruediger.dohna_at_1und1.de>>> wrote:
>>
>> On 23.09.2011 16:34, Nigel Deakin wrote:
>>
>> ...further new method ... Session createSession()
>> Any comments?
>>
>>
>> Exquisit simplification... +1
>>
>>
>> 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?
>>
>>
>> I'd prefer the enum, too. The old constants could be marked as
>> deprecated and eventually removed. All other methods that
>> take such
>> an int, would have to be marked as deprecated as well and
>> get a new
>> variant with the enum. I'm all for cleaning up APIs!
>>
>>
>>