users@jms-spec.java.net

[jms-spec users] Sending a previously-received Message and supporting JMSXUserID

From: <robbie.gemmell_at_gmail.com>
Date: Thu, 12 Dec 2013 17:01:26 +0000 (UTC)

Hi all,

I wondered if anyone could shed some light on a question I have around
handling of JMSXUserID (and JMSXAppID as well, I guess).

The JMS-defined JMSXUserID property is optional, but if supported is of
the 'set by Provider on Send' variety. The spec says that properties
are read-only when a Message is received. What then is the appropriate
action to take when supporting JMSXUserID and sending a
previously-received Message?

I have searched through the spec and looked at a few implementations to
see what they do, but haven't as yet really been able to settle on an
answer to my question. Is there a clarifying area of the spec that I
have missed? Any other thoughts?

I can see there are various somewhat ugly options, e.g:

1. Since the spec says properties are read-only in that situation,
accept this also includes properties the spec defines a provider itself
sets on send and let the send methods throw
MessageNotWriteableException. Require that users clear and re-set all
the properties of recieved Message objects before trying to send them
if JMSXUserID support is enabled.
2. Copy the Message within the send method to get something writable
and set the property on that (or possibly just set the property
directly on the underlying message being sent, e.g using a specific
field of an underlying protocols native message format), allowing the
value to be sent but not actually setting it on the Message object
originally provided.
3. Try to set the property, catch the MessageNotWriteableException,
continue to send without the value (or potentially with the wrong value
if it already existed).

The JMS 2.0 reference implementation appears to do a combination of 1)
and 2), though I admit I didn't actually test it in practice. If
support for JMSXUserID is enabled (looks to be disabled by default) it
seems like it would throw a MessageNotWriteableException from the send
method, so long as the message was one of its own. If the Message was
from a foreign provider, it seems like it would perform a conversion
and then succeed in setting the property on the converted message and
not even attempt setting it on the original.

Robbie