[ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.... ] Michael Clay commented on RTGOV-566: ------------------------------------ - short summary how sy handles SOAP header properties \\ sy sets the incoming soap header properties in {{ContextMapper#mapFrom}} as message property with a soap header label {{context.setProperty(name, value).addLabels(SOAP_HEADER_LABELS);}} and retrieves and appends it on the outgoing soap message within {{ContextMapper#mapTo}} {code:title=ContextMapper.java|borderStyle=solid} for (Property property : context.getProperties()) { Object value = property.getValue(); if (value instanceof Node) { } else if (value instanceof Configuration) { } else { String v = value.toString(); if (SOAPHeadersType.XML.equals(_soapHeadersType)) { try { Element xmlElement = new ElementPuller().pull(new StringReader(v)); Node xmlNode = soapHeader.getOwnerDocument().importNode(xmlElement, true); soapHeader.appendChild(xmlNode); } catch (Throwable t) { soapHeader.addChildElement(qname).setValue(v); } } else { soapHeader.addChildElement(qname).setValue(v); } } } {code} what's also relevant here is the way {{context.getProperties()}} is implemented i.e. ALL exchange and message properties are considered. {code:title=ContextMapper.java|borderStyle=solid} @Override public Set<Property> getProperties() { Set<Property> properties = new HashSet<Property>(); properties.addAll(getProperties(Scope.EXCHANGE)); properties.addAll(getProperties(Scope.MESSAGE)); return properties; } {code} \\ As already mentioned we are using {{SOAPHeadersType#DOM}} on the incoming and outgoing ContextMapper side and therefore would also expect to receive DOM context property instances from Exchange objects originating from SwitchYardRemotingServlet -> but this is no hard constraint since an application can always override/configure those ContextMappers and add the required behaviour. \\ \\ - recap of how rtgov passes those context properties to switchyards remoting servlet: \\ On the rtgov side we are using {{ActivityType#properties}} which could be used to restore the RemoteMessage#context and those properties are string valued since we have to persist them. Therefore we have no way to directly pass/serialize DOM(w3c.Node) property value instance which would be anyway a bad idea since the serialization encoding format is already xml. \\ \\ - comment on Garys suggestion \\ What i don't like on this solution is that it breaks the existing separation of concerns between PropertyEvaluators(extract context properties) and InformationTransformers (message content serialization) in a bad way which mixes the two responsibilities i.e. header/property retrieving is spread over two (main)concepts of the informationprocessor which i think makes it harder to understand/maintain. \\ What about adding an addition resultType (org.w3c.dom.xpath.XPathResult) configuration option to the existing xpath evaluator in the same way as as it is possible with camel Xpath expression's http://camel.apache.org/xpath.html ..of course we still need to serialize the result type into string value. -- This message was sent by Atlassian JIRA (v6.3.1#6329)