Announcement Announcement Module
Collapse
No announcement yet.
Bug in DefaultJmsHeaderMapper (v1.0.0 and v1.0.1) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bug in DefaultJmsHeaderMapper (v1.0.0 and v1.0.1)

    It appears that headers prefixed with JmsHeaders.PREFIX are *not* set on the outgoing JMS message by the DefaultJmsHeaderMapper.

    According to the Javadocs, the intent of JmsHeaders.PREFIX is "for any message header that should be passed for usage by the JMS transport."

    However, the DefaultJmsHeaderMapper in v1.0.0 and v1.0.1 include the following code in the fromHeaders(...) method:

    Code:
    Set<String> attributeNames = headers.keySet();
    for (String attributeName : attributeNames) {
      if (!attributeName.startsWith(JmsHeaders.PREFIX)) {
      ...
      }
    which means that headers prefixed with it won't get set on the JmsMessage. Also, this is the opposite behavior of the RC2 release with its JmsHeaders.USER_PREFIX which did this:

    Code:
    String prefix = JmsHeaders.USER_PREFIX;
    Set<String> attributeNames = headers.keySet();
    for (String attributeName : attributeNames) {
      if (attributeName.startsWith(prefix)) {
      ...
      }
    A quick test also shows that a header not prefixed with JmsHeaders.PREFIX does get placed on the outgoing JmsMessage.

    If this is indeed a bug, I'll go ahead and open a JIRA case, but I wanted to run it by the forum first to make sure I'm not misunderstanding something.

  • #2
    Just go ahead and attach your test to a JIRA. It's a surprise that a bug like this would go untested and unnoticed for so long, but better an invalid bug than missing something like this.

    Also, if you have done your homework, you don't need to be shy to create a bugreport. If you read and understand http://ejohn.org/blog/a-web-developers-responsibility/ you know how to make framework developers happy.

    Comment


    • #3
      This behavior did change based on user feedback. Basically, other users expressed that the Spring Integration Message headers should be propagated automatically by default rather than requiring the use of a "USER_PREFIX". After this was supported by several use-cases, we decided to indeed change that default behavior. Now, we are using JMS_PREFIX for the internal headers that really do map to those properties defined directly in the JMS API (e.g. JMSCorrelationId). Because those values map to those properties directly, they are not also added as generic object properties - hence the if (!...) expression that you showed. Does this make sense?

      The documentation definitely needs to be updated to reflect these changes, so please do submit the JIRA issue.

      Comment


      • #4
        Thanks for the information and update, that was very helpful.

        I've created a JIRA case for fixing the Javadoc: INT-539

        Kevin

        Comment


        • #5
          Thanks Kevin. I've added this to the list for 1.0.2.

          Regards,
          Mark

          Comment

          Working...
          X