Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      Since a JMSXDeliveryCount will be part of the JMS 2.0 requirement, also the Message interface should reflect this:

      public long getJMSDeliveryCount() throws JMSException

        Activity

        Hide
        Nigel Deakin added a comment -

        JMS defines two different type of information which can be associated with a message (apart from the body): message headers and message properties. Message headers are accessed using specific javabean-like methods such as getJMSPriority whereas message properties are accessed using generic methods such as getIntProperty(name).

        JMSXDeliveryCount was defined (though not made mandatory) in JMS 1.1 and is a message property, not a message header, which is why it is accessed using setIntProperty and getIntProperty rather than more specific methods. In JMS 2.0 all we are doing is making this existing property mandatory.

        I can see a case for defining specific methods to access the JMS-defined properties (those starting with JMSX), or even just the mandatory one(s), but there is potential confusion in providing two ways to access the same value. And since JMSXDeliveryCount was defined in JMS 1.1 it has to remain a property.

        So I propose we leave things as they are. However I'll leave this issue open for now to allow for other comments either via the issue or via the EG/user alias.

        Show
        Nigel Deakin added a comment - JMS defines two different type of information which can be associated with a message (apart from the body): message headers and message properties. Message headers are accessed using specific javabean-like methods such as getJMSPriority whereas message properties are accessed using generic methods such as getIntProperty(name) . JMSXDeliveryCount was defined (though not made mandatory) in JMS 1.1 and is a message property, not a message header, which is why it is accessed using setIntProperty and getIntProperty rather than more specific methods. In JMS 2.0 all we are doing is making this existing property mandatory. I can see a case for defining specific methods to access the JMS-defined properties (those starting with JMSX ), or even just the mandatory one(s), but there is potential confusion in providing two ways to access the same value. And since JMSXDeliveryCount was defined in JMS 1.1 it has to remain a property. So I propose we leave things as they are. However I'll leave this issue open for now to allow for other comments either via the issue or via the EG/user alias.
        Hide
        axel_podehl added a comment -

        I see - yes, adding this method this would break existing code/be inconsistent (suggesting to close the issue).

        I guess JMSX properties were meant to be provider-specific.

        But with JMS 2.0, some of them are mandatory (=portable), correct?
        Are there 'public static final Strings' for those ?

        Show
        axel_podehl added a comment - I see - yes, adding this method this would break existing code/be inconsistent (suggesting to close the issue). I guess JMSX properties were meant to be provider-specific. But with JMS 2.0, some of them are mandatory (=portable), correct? Are there 'public static final Strings' for those ?
        Hide
        Nigel Deakin added a comment -

        In JMS 1.1 all the JMSX properties were optional, making them provider-specific. In JMS 2.0 we're making one of them mandatory. This leaves it in a slightly anomalous position, but for the reasons mentioned above I think it's best to stick with the existing API for accessing it.

        The JMS API does not define static constants for these properties. If you think it should please log it a separate issue.

        Show
        Nigel Deakin added a comment - In JMS 1.1 all the JMSX properties were optional, making them provider-specific. In JMS 2.0 we're making one of them mandatory. This leaves it in a slightly anomalous position, but for the reasons mentioned above I think it's best to stick with the existing API for accessing it. The JMS API does not define static constants for these properties. If you think it should please log it a separate issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            axel_podehl
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: