[JMS_SPEC-112] add Message.getJMSDeliveryCount() Created: 08/Jan/13  Updated: 11/Jan/13

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: axel_podehl Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


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

public long getJMSDeliveryCount() throws JMSException

Comment by Nigel Deakin [ 09/Jan/13 ]

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.

Comment by axel_podehl [ 09/Jan/13 ]

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 ?

Comment by Nigel Deakin [ 11/Jan/13 ]

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.

Generated at Tue Nov 24 22:45:27 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.