ActiveMQ
  1. ActiveMQ
  2. AMQ-2287

ActiveMQMessage.setXXXProperty() method needs to check if property name is a valid Java identifier.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 5.2.0
    • Fix Version/s: 5.x
    • Component/s: Broker
    • Labels:
      None

      Description

      currently the AMQ implementation of javax.jms.Message.setXXXProperty() does not check if the property name is a valid Java identifier.
      This however is required according to the JMS spec.

      From http://docs.oracle.com/javaee/6/api/javax/jms/Message.html:

      Property names must obey the rules for a message selector identifier.
      ...
      Identifiers:

      • An identifier is an unlimited-length sequence of letters and digits, the first of which must be a letter. A letter is any character for which the method Character.isJavaLetter returns true. This includes '_' and '$'. A letter or digit is any character for which the method Character.isJavaLetterOrDigit returns true.
      • Identifiers cannot be the names NULL, TRUE, and FALSE.
      • Identifiers cannot be NOT, AND, OR, BETWEEN, LIKE, IN, IS, or ESCAPE.
      • Identifiers are either header field references or property references. The type of a property value in a message selector corresponds to the type used to set the property. If a property that does not exist in a message is referenced, its value is NULL.
      • The conversions that apply to the get methods for properties do not apply when a property is used in a message selector expression. For example, suppose you set a property as a string value, as in the following:

      myMessage.setStringProperty("NumberOfOrders", "2");

      The following expression in a message selector would evaluate to false, because a string cannot be used in an arithmetic expression:

      "NumberOfOrders > 1"

      • Identifiers are case-sensitive.
      • Message header field references are restricted to JMSDeliveryMode, JMSPriority, JMSMessageID, JMSTimestamp, JMSCorrelationID, and JMSType. JMSMessageID, JMSCorrelationID, and JMSType values may be null and if so are treated as a NULL value.
      • Any name beginning with 'JMSX' is a JMS defined property name.
      • Any name beginning with 'JMS_' is a provider-specific property name.
      • Any name that does not begin with 'JMS' is an application-specific property name.

      Checks for this need to be added to all ActiveMQMessage.setXXXProperty() methods.

        Activity

        Hide
        Torsten Mielke added a comment -

        Could use the following helper method:

        public boolean isJavaIdentifier() {
              int n = length();
              if (n==0) return false;
              if (!Character.isJavaIdentifierStart(charAt(0)))
                  return false;
              for (int i = 1; i < n; i++)
                  if (!Character.isJavaIdentifierPart(charAt(i)))
                      return false;
              return true;
            }
        
        Show
        Torsten Mielke added a comment - Could use the following helper method: public boolean isJavaIdentifier() { int n = length(); if (n==0) return false ; if (! Character .isJavaIdentifierStart(charAt(0))) return false ; for ( int i = 1; i < n; i++) if (! Character .isJavaIdentifierPart(charAt(i))) return false ; return true ; }
        Hide
        Robert Liguori added a comment - - edited

        Please consider my similar issue as well (https://issues.apache.org/jira/browse/AMQ-3113)... with analysis of this JIRA item.

        Show
        Robert Liguori added a comment - - edited Please consider my similar issue as well ( https://issues.apache.org/jira/browse/AMQ-3113 )... with analysis of this JIRA item.
        Hide
        Torsten Mielke added a comment -

        I am going to close this bug.
        If we decide to fix this, it can likely cause backward compatibility problems.
        Given that there was no demand from the community to have this bug fixed, we will not fix this problem right now in favor of compatibility.

        If there is need to have this fixed in future, this bug can be reopened again.

        Show
        Torsten Mielke added a comment - I am going to close this bug. If we decide to fix this, it can likely cause backward compatibility problems. Given that there was no demand from the community to have this bug fixed, we will not fix this problem right now in favor of compatibility. If there is need to have this fixed in future, this bug can be reopened again.

          People

          • Assignee:
            Torsten Mielke
            Reporter:
            Torsten Mielke
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development