Announcement Announcement Module
No announcement yet.
GA: DefaultJMSHeaderMapper invalid property names? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • GA: DefaultJMSHeaderMapper invalid property names?

    Just upgraded to GA release and I'm finding that I now get exceptions from my JMS provider when DefaultJmsHeaderMapper.fromHeaders is called.

    It seems that the logic has changed such that SI internal properties are being set on the outgoing messages (eg, and more importantly I am fairly sure these are not valid JMS Property Identifiers ('.' is not allowed according to the jms spec).

    Errors are not causing my app to fail and valid properties would be set ok (I think), it's just noise/possibly not what you intended.

    My JMS Provider is WS MQ. My application is a simple adaptor polling for files and sending file contents to a JMS Queue.


    WARN 1209-133611.382 task-scheduler-2 org.springframework.integration.jms.DefaultJmsHead erMapper: failed to map Message header '' to JMS property
    javax.jms.MessageFormatException: MQJMS1058: Invalid message property name:
    at org.springframework.integration.jms.DefaultJmsHead erMapper.fromHeaders( 1)
    at org.springframework.integration.jms.HeaderMappingM essageConverter.toMessage(HeaderMappingMessageConv
    at org.springframework.jms.core.JmsTemplate$5.createM essage(
    Last edited by ndw; Dec 9th, 2008, 08:02 AM. Reason: Qualify the problem

  • #2
    Thanks for the information. I have created INT-511


    • #3
      There are a few ways we could address this.

      1) provide bi-directional conversion in the JMS header mapper
      2) enforce legal java identifiers for all header names throwing IllegalArgumentException anytime a non-legal name is provided
      3) continue to log at WARN level for illegal headers but change all internal headers to use underscore delimiters instead of dots

      Option #1 would necessitate escaping (in order to handle actual underscores differently than dots-converted-to-underscores) and therefore may become complicated and confusing

      Option #2 would be very simple but might be artificially limiting (e.g. prevents someone from providing a URI as the header name)

      Option #3 seems to be a decent compromise in my opinion. It's relatively trivial for us to change the internal names, and anyone relying on these should be using the constants for access anyways. If a user wants to provide a non-legal java identifier, they can, but the value would simply be dropped when passing through a JMS adapter.

      Please weigh in on these options. I will probably go ahead with #3 for now, since it is fully backwards compatible (assuming users are relying on the constants as they should).


      • #4
        FYI: I'm getting a similar invalid property warning when using JBoss Messaging as the Jms provider. I agree with your solution option #3.

        CUBRC, Inc.


        • #5
          Yesterday, I committed the changes for option #3, and that will be included within version 1.0.1.

          If either of you could possibly test against a snapshot or build from trunk that would be great.



          • #6
            I was having trouble finding the maven snapshots for spring integration. Can you point me to the right repository, and artifact/group/version for your latest spanshot?

            CUBRC, Inc.


            • #7
              The snapshots are available in the same Maven repository as described here:

              You will just need to replace 'release' with 'snapshot'.

              Non-final artifacts are browse-able via S3. For example:


              • #8
                I tested version 1.0.1.BUILD-SNAPSHOT and saw the following headers:


                JBoss is now happy.

                Many thanks...


                • #9
                  Thank you for testing it so quickly!