-
15. Re: SOAP header properties
dward Feb 8, 2013 5:16 PM (in response to mageshbk)There are "buckets" already. They're called "labels".
-
16. Re: SOAP header properties
dward Feb 8, 2013 6:12 PM (in response to objectiser)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 -
17. Re: SOAP header properties
kcbabo Feb 10, 2013 10:42 AM (in response to 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
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).
-
18. Re: SOAP header properties
dward Feb 11, 2013 9:56 AM (in response to 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
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).