Reza,
On 25/07/2011 18:04, Reza Rahman wrote:
> 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.
I suspect that people who fall into the trap of misunderstanding these methods simply guess the method name, see that it
gets accepted by their IDE, and use it.
Yes, we could have had an additional interface javax.jms.spi.Message with these setter methods on, which would have
prevented this happening. But, as you say, it's too late for that.
Nigel
>
> 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
>>
>>
>