[jira] Resolved: (AMQNET-94) Use of AcknowledgmentMode enum and boolean for priority limit use of NMS API for vendor extensions

["Jim Gomes (JIRA)" <ji...@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.