Nigel,
Personally, this has not been an issue for me since I do read javadocs
before using any API. In an ideal world, it would have been best to
separate the developer API from the provider "SPI", but it's obviuosly
too late for that now in this particular case. I think it's sufficient
at this point to just clarify the javadocs.
Cheers,
Reza
On 7/25/2011 12:17 PM, Nigel Deakin wrote:
> 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
>
>
>
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1518/3787 - Release Date: 07/25/11
>
>