Nigel,
I consider this a trivial change, however I am not sure if all providers
support a DestinationImpl, but this could be implemented in their
QueueImpl/TopicImpl equivalent classes. I would support it for a JMS 2.0
change, even though we're in PDR.
John
On Wed, Jan 9, 2013 at 1:08 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> "axel_podehl" logged the following JIRA issue a couple of days ago:
>
> -------- Original Message --------
> (JMS_SPEC-109) add method Destination.getName()
> http://java.net/jira/browse/**JMS_SPEC-109<http://java.net/jira/browse/JMS_SPEC-109>
>
> JMS topics and queues both have names that are accessible with
> getTopicName() and getQueueName(), but for applications where the type of
> destination (topic or queue) is configurable - which I would consider a
> good application - it's difficult to get the actual destination's name.
>
> An ugly typecast or something similar must be used:
>
> (snip example)
>
> What I'm proposing is simply a common Destination.getName() method so this
> code becomes nicer:
>
> (snip example)
>
> The implementation of Destination.getName() is trivial for Topic and Queue.
>
> I can understand the objection of saying: "'Destination' is just a marker
> interface and JMS abstracts from the actual topic/queue name, these names
> shouldn't matter."
> But then, why is there getQueueName()/getTopicName() in the first place?
>
> I find this name very useful in order to debug or sort message streams
> into buckets and it would be nice if this name will be simpler to get by.
>
> ------------------------------**------------------------------**
> ------------------------------**------
>
> (Nigel adds) I think this is a good proposal (thanks). It wouldn't break
> backwards compatibility.
>
> Any comments?
>
> I'm happy to have a discussion about this now. However now JMS 2.0 has
> reached the public draft stage we need to avoid adding new features if at
> all possible and as this feature is unrelated to any of the changes in JMS
> 2.0, and can be added to the next version without introducing any
> compatibility problems, I propose we defer adding it to the API until JMS
> 2.1.
>
> I'm starting a list of JMS 2.1 issues here
> http://java.net/projects/jms-**spec/pages/JSR343Planning#**
> Minor_issues_to_be_considered_**for_JMS_2.1<http://java.net/projects/jms-spec/pages/JSR343Planning#Minor_issues_to_be_considered_for_JMS_2.1>
>
> Nigel
>