Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      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:

        public static String getJMSDestinationName(Message msg) throws JMSException
        {
          Destination origDest = msg.getJMSDestination();
          if( origDest==null ) return null;
          
          if( origDest instanceof Topic) {
            return ((Topic)origDest).getTopicName();
          }
          else {
            return ((Queue)origDest).getQueueName();
          }
        }
      

      What I'm proposing is simply a common Destination.getName() method so this code becomes nicer:

        public static String getJMSDestinationName(Message msg) throws JMSException
        {
          return msg.getJMSDestination().getName();
        }
      

      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.

        Activity

        Hide
        Nigel Deakin added a comment -

        I think this is a good proposal (thanks). I don't think it would break backwards compatibility (i.e. existing application code wouldn't need to be changed).

        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.

        Tagging accordingly.

        Show
        Nigel Deakin added a comment - I think this is a good proposal (thanks). I don't think it would break backwards compatibility (i.e. existing application code wouldn't need to be changed). 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. Tagging accordingly.
        Hide
        axel_podehl added a comment -

        Another motivation to use this admittedly non-portable destination name is this:

        Especially when consuming from a wildcard such as TRADE.> you might want to know the actual topic name of the received message (e.g. TRADE.UNSETTLED.SYSTEMA.cusip712321) to log it or to branch on this type/originator or whatever the topic space was designed to contain.

        Show
        axel_podehl added a comment - Another motivation to use this admittedly non-portable destination name is this: Especially when consuming from a wildcard such as TRADE.> you might want to know the actual topic name of the received message (e.g. TRADE.UNSETTLED.SYSTEMA.cusip712321) to log it or to branch on this type/originator or whatever the topic space was designed to contain.
        Hide
        axel_podehl added a comment -

        Ok, thanks for the layout work. I try to remember that trick ('

        
        

        ')

        Show
        axel_podehl added a comment - Ok, thanks for the layout work. I try to remember that trick (' ')

          People

          • Assignee:
            Unassigned
            Reporter:
            axel_podehl
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: