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

    The default logic of HTTP context mappers

    Artem Egorkine Newbie



      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:

      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




      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,