Clebert,
Clebert Suconic wrote, on 22/07/2011 18:11:
> shouldn't we make a change here. It's a common question in our forums
> about why Message.setPriority is ineffective?
>
> IMO, someone should be able to change the priority at the message
> level also. I.e. if Message.setPriority was called, the provider would
> be able to use that priority instead.
>
> I don't want to open a JIRA without discussing this first.
>
> My suggestion is we either allow Message.setPriority to change the
> priority individually or we deprecate Message.setPriority
The same issue affects several other methods on javax.jms.Message which allow the client to set properties on a message
which have no effect:
setJMSMessageID
setJMSTimeStamp
setJMSDestination
setJMSDeliveryMode
setJMSRedelivered
setJMSExpiration
setJMSPriority
I agree this is very confusing, especially for JMSDeliveryMode and JMSPriority.
I've logged this as
http://java.net/jira/browse/JMS_SPEC-34
The javadoc comment on each of these methods says "This method can be used to change the value for a message that has
been received." though I can't think of when it would serve a useful purpose for the *application* to do this.
I believe these methods are intended to be called by the JMS provider, not by the application. When a message is
received, the application can use the corresponding getter methods to find the value of each property.
The obvious question is: "why doesn't the JMS provider use a private API to set these properties?" I think the answer is
that a JMS provider "must be prepared to accept, from a client, a message whose implementation is not one of its own."
(JMS 1.1 section 3.12) These setter methods are needed to allow the provider to set these properties on a "foreign" message.
So I don't think we can deprecate these methods, though we can certainly make the javadoc comments much more explicit
that they are for provider use only.
So should we redefine these methods so that they *do* have an effect? This probably only makes sense for JMSDeliveryMode
and JMSPriority, so we're probably stuck with the other five methods as they are now.
Would redefining setJMSDeliveryMode and setJMSPriority so that they *do* have an effect break existing applications?
This seems unlikely.
We also need to decide whether values set using Message.setJMSDeliveryMode and Message.setJMSPriority override values
set using MessageProducer.setJMSDeliveryMode and Message.setJMSPriority, or by the arguments to
MessageProducer.send(destination, message, deliveryMode, priority, timeToLive). If so, this would need to be documented
carefully to avoid causing further confusion.
Alternatively, if we decide to stick with the current behaviour, the javadoc comments need to be updated to make it
clear that these methods are intended to be used the JMS provider only.
Comments, please...
Nigel