3 Replies Latest reply on Nov 16, 2014 12:47 PM by Keith Babo

    The default logic of HTTP context mappers

    Artem Egorkine Newbie

      Hi,

       

      I have a SY 1.1.0 application with HTTP bindings and a simple requirement:

      1. read a number of well-known HTTP headers on request, and
      2. set other well-known HTTP headers on reply.

       

      Implementing this, however, I have come to question how HTTP headers are handled by default in HTTPContextMapper and RESTEasyCoontextMapper.

       

      Implementing requirement #2 is easy. Just add a context property and add a HTTP endpoint label to it. This works well enough because the context mapper logic is "matches(name) || property.hasLabel(...)".

       

      Implementing requirement #1 is trickier, as the context mapper logic in this case is only "matches(name)". Okay, so I need to configure the context mapper includes. To make it easy for myself, I'll just collect all HTTP headers:

      <http:contextMapper includes=".*"/>
      

       

      Now I have the HTTP headers collected for requirement 1, but now the context mapper will also leak all context properties as HTTP headers on the reply:

      host: 127.0.0.1:8080
      accept: */*
      org.switchyard.exchangeInitiatedNS: 607083392765785
      user-agent: curl/7.27.0
      org.switchyard.operationName: operation
      x-request-id: 0cc97eb4-fa14-487a-9589-06f3b8342f4b
      breadcrumbid: ID-noir-48260-1399200763256-9-6
      org.switchyard.exchangeGatewayName: route-http-binding
      org.switchyard.relatesTo: ID-noir-48260-1399200763256-9-6
      Content-Type: application/json
      Content-Length: 44
      Date: Tue, 06 May 2014 23:50:55 GMT
      

       

      Yay!

       

      So, the actual behavior I'm looking for is

      1. Collect all HTTP headers on the request, mark them with the HTTP label
      2. Collect all properties with HTTP label and set them as headers on the reply

       

      In fact, before I dug into the implementation, I expected this sort of behavior by default. Is there any rationale for not doing point 1 above by default?

       

      And, while on the subject, reading https://docs.jboss.org/author/display/SWITCHYARD/Message+Composition suggests Scope.IN and Scope.OUT property scoping (for properties, that came from the request and properties that will go to the reply), which I just cannot see in code. Is this documentation for Switchyard trunk, not the official release?

       

      Thank you,

      Artem