[JMS_SPEC-112] add Message.getJMSDeliveryCount() Created: 08/Jan/13 Updated: 11/Jan/13
|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?
|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.