From dev-return-11748-apmail-activemq-dev-archive=activemq.apache.org@activemq.apache.org Thu Aug 07 00:50:14 2008 Return-Path: Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: (qmail 81220 invoked from network); 7 Aug 2008 00:50:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Aug 2008 00:50:14 -0000 Received: (qmail 92653 invoked by uid 500); 7 Aug 2008 00:50:13 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 92633 invoked by uid 500); 7 Aug 2008 00:50:13 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 92618 invoked by uid 99); 7 Aug 2008 00:50:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Aug 2008 17:50:13 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Aug 2008 00:49:25 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id B9EF2234C18F for ; Wed, 6 Aug 2008 17:49:52 -0700 (PDT) Message-ID: <1824656864.1218070192760.JavaMail.jira@brutus> Date: Wed, 6 Aug 2008 17:49:52 -0700 (PDT) From: "Jim Gomes (JIRA)" To: dev@activemq.apache.org Subject: [jira] Resolved: (AMQNET-94) Use of AcknowledgmentMode enum and boolean for priority limit use of NMS API for vendor extensions In-Reply-To: <2055859937.1216417980331.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/activemq/browse/AMQNET-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-94. ----------------------------- Resolution: Won't Fix It is possible to change the {{IConnection}} interface to use the following generic types to allow passing in a generic enumeration: {code:borderStyle=solid} interface IConnection { //... ISession CreateSession(System.Enum acknowledgementMode); System.Enum AcknowledgementMode { get; set; } //... } {code} However, I think that it will force more code to be written using explicit casting in order to deal with the {{AcknowledgementMode}} property in the most general cases. Since using provider specific acknowledgment modes is the outlyer case, I think using casting to show specific intent to deviate from standard modes is preferred. The C# enum type system is robust enough to support the following using the existing interface definition without reverting to generic {{System.Enum}}: {code:borderStyle=solid|title=Sample of Extant Flexibility} public interface IConnection : IDisposable, IStartable, IStoppable { //... ISession CreateSession(AcknowledgementMode acknowledgementMode); AcknowledgementMode AcknowledgementMode { get; set; } //... } enum MyAckModes { IgnoreDups, Transactional, Explicit } IConnection connection = GetConnection(); // Set the default ack mode connection.AcknowledgementMode = (AcknowledgementMode) MyAckModes.IgnoreDups; // Set session-specific ack mode ISession session = connection.CreateSession((AcknowledgementMode) MyAckModes.Explicit); {code} As can be seen from this snippet of code, the existing code base allows the use of provider specific enumerations while providing type-safety and non-casting for the general case. When a user of NMS wants to have low-level access to a provider's unique acknowledgment modes, then they can do so and the C# enum system will carry their values through, even if that acknowledgment mode value is outside the range of the original {{AcknowledgmentMode}} enumeration. I have created a sample C# app that demonstrates basic casting of enumerations to show that provider specific enumeration values can be "carried" inside the existing {{AcknowledgementMode}} enumeration. Since these values only make sense to the individual providers, they will be the ones who will cast when setting/getting the {{AcknowledgementMode}} property. {code:borderStyle=solid|title=EnumTest.cs} using System; public class EnumTest { enum MyEnum { First, Second, Third } enum ProviderEnum { Fourth, Fifth } static void ShowEnum(System.Enum baseEnum) { Console.WriteLine("base = {0}", baseEnum); ProviderEnum derived = (ProviderEnum) baseEnum; Console.WriteLine("derived = {0}", derived); } static void Main() { ShowEnum(MyEnum.Second); ShowEnum(MyEnum.Third); } } {code} When this sample application is run, the following is output: {panel:title=EnumTest output|borderStyle=solid|bgColor=#FFFFCE} base = Second derived = Fifth base = Third derived = 2 {panel} I hope that this addresses the concerns about using provider specific extensions to the acknowledgment mode enumeration. > Use of AcknowledgmentMode enum and boolean for priority limit use of NMS API for vendor extensions > -------------------------------------------------------------------------------------------------- > > Key: AMQNET-94 > URL: https://issues.apache.org/activemq/browse/AMQNET-94 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: ActiveMQ Client > Reporter: Mark Pollack > Assignee: Jim Gomes > Priority: Minor > Fix For: 1.0 > > > This came up on the dev mailing list. The AcknowledgmentMode enumeration lists the standard JMS ack modes. However, vendors extend that, in particular TIBCO EMS. This should change to either an Enum, int, or string type so that the API will be more portable. > The same issue exists in the IMessageProducer interface with the boolean value for persistent delivery instead of and int for "DeliveryMode". TIBCO EMS offers another value for delivery mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.