Nigel,
I suppose this could be re-factored at some point if a serious need for
a separate JMS SPI arises in the future. I'm not sure if it is worth
saying something to that effect in the javadoc...
Cheers,
Reza
On 7/25/2011 2:36 PM, Nigel Deakin wrote:
> 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
>>>
>>>
>>
>
>
> -----
> 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
>
>