Announcement Announcement Module
Collapse
No announcement yet.
remove header fields Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • remove header fields

    Hi,

    I would like to be able to remove certain header fields from my Spring Integration Messages, e.g. application-specific fields that may have been added earlier on in my SI "flow". However, it appears that SI's support for routers/filters/service-activators all ends up calling org.springframework.integration.handler.AbstractRe plyProducingMessageHandler.handleMessageInternal() . This has the side-effect of restoring in the outbound message all header fields that are absent with respect to the inbound message, thus undoing any header-removal logic implemented within, say, a bespoke service-activator.

    Is the above analysis correct? If so, any suggestions for working around it? SI seems to be enacting a principle of "thou shalt never remove header fields" -- it that's true, what is the motivation/justification for this stance?

    Many thanks,
    --Mike

  • #2
    This is actually a very good point. Your analysis is correct, and that logic of re-adding any non-overwritten header values from the request Message is necessary for a lot of use-cases where header values must be maintained for the entire flow. The challenge here is that these handler implementations support a wide range of invocation options, and there is not always enough information at the level of AbstractReplyProducingMessageHandler to determine Map values that have been *removed* (as opposed to a returned Map that contains new values only).

    I think we would need to address this by comparing the returned header map with the headers that have been passed in (e.g. to any method with @Headers) in order to determine where explicit removal has occurred. This might need to happen in the message mapping code which is "closer" to the method invocation.

    Could you please open a JIRA issue for this and link to this forum post?

    Thank you,
    Mark

    Comment


    • #3
      Thanks Mark. Raised JIRA INT-923 as a Bug, although you may convincingly argue it as an Improvement request.

      Comment


      • #4
        Thanks Mike. I will keep it as a bug since the case where you actually call remove on the Map and yet still see those header values downstream is definitely counter-intuitive.

        Comment


        • #5
          Normally if you pass a map into a method, this method should not have side effects (i.e. not change the map). I think that a service implementation might expect to always get a copy of the map.

          We do need to address the use case where someone wants to explicitly remove headers, but I think it is an exception to the rule. How about nulling the particular header instead of removing it from the map?

          Comment


          • #6
            I am confused about the importance of header fields. Are there header fields which are needed by Spring Integration? If true, can the header fields be marked user or system defined? Additionally system header fields could be implemented read only and user header fields read/write?

            I ask because I would like to add and remove user defined header fields to control the flow of messages and output rules.

            Comment


            • #7
              Please see the recent comments on the issue here:
              http://jira.springframework.org/browse/INT-923

              Also, the following are relevant:
              http://jira.springframework.org/browse/INT-1133 no longer modifying Message return values

              http://jira.springframework.org/browse/INT-1134 namespace support for 'header-filter'

              http://jira.springframework.org/browse/INT-1135 add HeaderFilter

              Comment

              Working...
              X