I would echo Keiths point, and also have some other items to consider. I'm not sure I think the spec really is all that loose on this subject, and the bit you quoted was just a natural phrasing and not really intended to implying you can feel free not to overwrite it. For example, I can quote a bit that is fairly specific on the behaviour:
3.4.3 JMSMessageID : "When a message is sent, JMSMessageID is ignored. When the send method returns, the field contains a provider-assigned value." Do we have examples of other providers supporting preservation of the message ID? I didnt look hard but googling on the subject only seemed to return questions on the behaviour, not examples where preservation was supported (though I guess it isnt necessarily a prominent feature people would call out). The closest I noticed was some talk of possibly supporting it in future where the both sides of a bridge were the same provider. If the intention is to preserve an ID across a bridge, is there a reason JMSCorrelationID cant be used, given it is specifically supports application specified IDs whereas JMSMessageID specifically does not? Allowing the client not to overwrite the message ID also seems to open us to the possability of duplicate message IDs on outbound messages. There is nothing stopping someone sending a given message object multiple times, and unlike the intended behaviour of JMSMessageID it would seem that each time it was sent it would get the same ID (unless we did something horrible to prevent that, such as caching IDs). With regards to the special header property, what restriction would there be around that? Presumably we would have to prevent application usage of that property, which might imply it should be a vendor-specific property instead...although the spec says those shouldnt be used for JMS to JMS messaging, so ho hum. Robbie On 17 January 2013 09:31, Keith W <[email protected]> wrote: > Hi Rajith, > > I'm interested to know more background. When exactly is the ability > to preserve JMSMessageIDs in this way useful? Does this change give > us compatibility with particular (bridging) product(s)? If so, which > ones? > > Thanks, Keith. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
