The default logic of HTTP context mappers

[arteme]

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

[kcbabo]

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?

I think we could definitely used finer-grained control over what's returned.  The reason why we don't include just context properties with HTTP labels is that requires code elsewhere to specifically associate (e.g. inside a service implementation) the property with HTTP.

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?

Scope.IN and Scope.OUT don't exist any longer (replaced by Scope.MESSAGE), so that page needs to be updated. 

[ozkin]

>> Scope.IN and Scope.OUT don't exist any longer (replaced by Scope.MESSAGE), so that page needs to be updated.

Will this page be updated?

[kcbabo]

Done