[dward]

There are "buckets" already. They're called "labels".

[dward]

I've combed through our various (9!) ContextMapper implementations.  I will document here what they currently do, as well as provide a place to document what we want to change it to.  Feel free to edit this table if you want it changed, however just add a note of what you changed.  Thanks!

mapFrom (normally inbound)

ContextMapper	Hardcoded Property	Source	Target Scope (current)	Target Labels (current)	Target Scope (change)	Target Labels (change)
Camel		(Camel) Message headers	IN	camel_message_header
Camel		(Camel) Exchange properties	EXCHANGE	camel_exchange_property
HornetQ		ClientMessage properties	EXCHANGE	hornetq_message_property
Http	status	HTTP response	IN	http_header	OUT
Http	request_info	HTTP request	IN	http_header
Http	(not "status" or "request_info")	HTTP headers	IN	http_header
RESTEasy		RESTEasy headers	IN	http_header
SOAP		SOAP MIME headers	IN	soap_message_mime_header
SOAP		SOAPMessage headers	EXCHANGE	soap_message_header	IN
JMS		(JMS) Message properties	EXCHANGE	jca_message_property
IndexedRecord	recordName	Record name	EXCHANGE	jca_message_property
IndexedRecord	recordShortDescription	Record short description	EXCHANGE	jca_message_property
MappedRecord	recordName	Record name	EXCHANGE	jca_message_property
MappedRecord	recordShortDescription	Record short description	EXCHANGE	jca_message_property
StreamableRecord	recordName	Record name	EXCHANGE	jca_message_property
StreamableRecord	recordShortDescription	Record short description	EXCHANGE	jca_message_property

mapTo (normally outbound)

ContextMapper	Hardcoded Property	Source Scope (current)	Source Labels (current)	Source Scope (change)	Source Labels (change)	Target
Camel		IN	(any)	(remove?)		(Camel) Message headers
Camel		OUT	(any)			(Camel) Message headers
Camel		EXCHANGE	(any)			(Camel) Exchange properties
HornetQ		EXCHANGE	(any)			ClientMessage properties
Http	status	OUT	http_header			HTTP response status
Http	(not "status")	OUT	http_header			HTTP response headers
RESTEasy		OUT	http_header			RESTEAsy headers
SOAP		OUT	(any)	(remove)		SOAP Mime headers
SOAP		EXCHANGE	(any)	OUT		SOAPMessage headers
JMS		EXCHANGE	(any)			(JMS) Message properties
IndexedRecord	recordName	EXCHANGE	(any)			Record name
IndexedRecord	recordShortDescription	EXCHANGE	(any)			Record short description
MappedRecord	recordName	EXCHANGE	(any)			Record name
MappedRecord	recordShortDescription	EXCHANGE	(any)			Record short description
StreamableRecord	recordName	EXCHANGE	(any)			Record name
StreamableRecord	recordShortDescription	EXCHANGE	(any)			Record short description

[kcbabo]

It's a bit tough to edit in the forum post, so I've created an article to hold the information:

https://community.jboss.org/wiki/DefaultMappingsForContextMapper

Some high-level comments:

• I think labels needs to correlate to the binding type in use.  As an example, context properties for HTTP should be "http", File should be "file", etc.  If we find that further distinction is necessary, like distinguishing between SOAP HTTP headers and SOAP:Header elements, the labels can be nested so that a subset of properties can be specified.  For example, the SOAP gateway could use "soap.http" and "soap.header".  If we wanted to get really fancy, we could allow a query for the "soap" label to pick up all of the entries for "soap.http" and "soap.header", but I certainly don't think that's required.
• For outbound mapping, the EXCHANGE and OUT properties are always "in scope" for context mapping.
• For outbound mapping, no headers are mapped by default.  The user-supplied configuration of the context mapper specifies what properties are mapped and where.  We *may* want to relax this slightly to say that properties with labels (e.g. "http", "soap") are automatically mapped on outbound messages.  This allows EXCHANGE scoped properties to be automatically returned on replies and also gives implementations or handlers a bit more flexibility if they want to attach a property programmatically (vs. configuration of the context mapper).

[dward]

It's a bit tough to edit in the forum post, so I've created an article to hold the information:

https://community.jboss.org/wiki/DefaultMappingsForContextMapper

Thanks!

• I think labels needs to correlate to the binding type in use.  As an example, context properties for HTTP should be "http", File should be "file", etc.  If we find that further distinction is necessary, like distinguishing between SOAP HTTP headers and SOAP:Header elements, the labels can be nested so that a subset of properties can be specified.  For example, the SOAP gateway could use "soap.http" and "soap.header".  If we wanted to get really fancy, we could allow a query for the "soap" label to pick up all of the entries for "soap.http" and "soap.header", but I certainly don't think that's required.

Just to be clear, 1 property can have 0..* labels.  So, a single property can have both "soap" and "http" as labels; we don't have to introduce a notation that mixes them.  Thus, a query as described above on propX could be: if (propX.hasLabel("soap") && propX.hasLabel("http")).  The "+hasLabel(caseINsenstitiveString):boolean" method already exists today.

• For outbound mapping, the EXCHANGE and OUT properties are always "in scope" for context mapping.

I have to admit, I don't understand what you mean by this.

• For outbound mapping, no headers are mapped by default.

The purpose of the chart was to show what properties get mapped IF the property names (and possibly namespaces) match the user-configurable regular expressions (includes, excludes, includesNamespaces, excludesNamespaces). Everyone should assume that NOTHING gets mapped - in either direction - unless the regex matches.  I don't see that changing, and we don't have to express that in the chart.  The chart should show what gets mapped if the regex fully matches everything (ie: includes=".*").

• ...  The user-supplied configuration of the context mapper specifies what properties are mapped and where.  ...and also gives implementations or handlers a bit more flexibility if they want to attach a property programmatically (vs. configuration of the context mapper).

There might be some confusion here as to our current capability with regards to context mapper configuration.  Right now, the ONLY configuration that can be done via XML is the regex expressions.  You can't "configure" where property gets mapped to or from.  Only if it will get mapped.  The "where" is what the purpose of the chart is, and is only changeable by code (unless we add fancier configuration attributes to the contextMapper element).