<?xml version="1.0" encoding="UTF-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="xml"
    xmlns:xlink="http://www.w3.org/1999/xlink">
  <title>XML Support - Dealing with XML Payloads</title>

  <section id="xml-intro">
    <title>Introduction</title>
    <para>
      Spring Integration's XML support extends the Spring Integration Core with
      implementations of splitter, transformer, selector and router designed
      to make working with xml messages in Spring Integration simple.  The provided messaging
      components are designed to work with xml represented in a range of formats including
      instances of
      <classname>java.lang.String</classname>, <interfacename>org.w3c.dom.Document</interfacename>
      and <interfacename>javax.xml.transform.Source</interfacename>.  It should be noted however that
      where a DOM representation is required, for example in order to evaluate an XPath expression,
      the <classname>String</classname> payload will be converted into the required type and then
      converted back again to <classname>String</classname>.  Components that require an instance of
      <interfacename>DocumentBuilder</interfacename> will create a namespace aware instance if one is
      not provided.  Where greater control of the document being created is required an appropriately
      configured instance of <interfacename>DocumentBuilder</interfacename> should be provided.
      </para>
  </section>
  <section id="xml-transformation">
    <title>Transforming xml payloads</title>
  <para>
      This section will explain the workings of
      <classname>UnmarshallingTransformer</classname>,
      <classname>MarshallingTransformer</classname>,
      <classname>XsltPayloadTransformer</classname>
      and how to configure them as
      <emphasis>beans</emphasis>.  All of the provided xml transformers extend
      <classname>AbstractTransformer</classname> or <classname>AbstractPayloadTransformer</classname>
      and therefore implement <interfacename>Transformer</interfacename>.  When configuring xml
      transformers as beans in Spring Integration you would normally configure the transformer
      in conjunction with either a <classname>MessageTransformingChannelInterceptor</classname> or a
      <classname>MessageTransformingHandler</classname>.  This allows the transformer to be used as either an interceptor,
      which transforms the message as it is sent or received to the channel, or as an endpoint.  Finally the
      namespace support will be discussed which allows for the simple configuration of the transformers as
      elements in XML.
    </para>
    <para>
      <classname>UnmarshallingTransformer</classname> allows an xml <interfacename>Source</interfacename>
      to be unmarshalled using implementations of Spring OXM <interfacename>Unmarshaller</interfacename>.
      Spring OXM provides several implementations supporting marshalling and unmarshalling using JAXB,
      Castor and JiBX amongst others.  Since the unmarshaller requires an instance of
      <interfacename>Source</interfacename> where the message payload is not currently an instance of
      <interfacename>Source</interfacename>, conversion will be attempted.  Currently <classname>String</classname>
      and <interfacename>org.w3c.dom.Document</interfacename> payloads are supported.  Custom conversion to a
      <interfacename>Source</interfacename> is also supported by injecting an implementation of
      <interfacename>SourceFactory</interfacename>.
      <programlisting language="xml"><![CDATA[<bean id="unmarshallingTransformer"
      class="org.springframework.integration.xml.transformer.UnmarshallingTransformer">
    <constructor-arg>
        <bean class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
        <property name="contextPath" value="org.example" />
        </bean>
    </constructor-arg>
</bean>]]></programlisting>
    </para>
    <para>
      The <classname>MarshallingTransformer</classname> allows an object graph to be converted
      into xml using a Spring OXM <interfacename>Marshaller</interfacename>.  By default the
      <classname>MarshallingTransformer</classname> will return a <classname>DomResult</classname>.
      However the type of result can be controlled by configuring an alternative <interfacename>ResultFactory</interfacename>
      such as <classname>StringResultFactory</classname>.  In many cases it will be more convenient to transform
      the payload into an alternative xml format.  To achieve this configure a
      <interfacename>ResultTransformer</interfacename>.  Two implementations are provided, one which converts to
      <classname>String</classname> and another which converts to <interfacename>Document</interfacename>.
      <programlisting language="xml"><![CDATA[<bean id="marshallingTransformer"
      class="org.springframework.integration.xml.transformer.MarshallingTransformer">
    <constructor-arg>
        <bean class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
            <property name="contextPath" value="org.example" />
        </bean>
    </constructor-arg>
    <constructor-arg>
        <bean class="org.springframework.integration.xml.transformer.ResultToDocumentTransformer" />
    </constructor-arg>
</bean>]]></programlisting>
    </para>
    <para>
      By default, the <classname>MarshallingTransformer</classname> will pass the payload Object
      to the <interfacename>Marshaller</interfacename>, but if its boolean <code>extractPayload</code> property
      is set to <code>false</code>, the entire <interfacename>Message</interfacename> instance will be passed
      to the <interfacename>Marshaller</interfacename> instead. That may be useful for certain custom
      implementations of the <interfacename>Marshaller</interfacename> interface, but typically the
      payload is the appropriate source Object for marshalling when delegating to any of the various
      out-of-the-box <interfacename>Marshaller</interfacename> implementations.
    </para>
    <para>
      <classname>XsltPayloadTransformer</classname> transforms xml payloads using xsl.
      The transformer requires an instance of either <interfacename>Resource</interfacename> or
      <interfacename>Templates</interfacename>.  Passing in a <interfacename>Templates</interfacename> instance
      allows for greater configuration of the <interfacename>TransformerFactory</interfacename> used to create
      the template instance.  As in the case of <classname>XmlPayloadMarshallingTransformer</classname>
      by default <classname>XsltPayloadTransformer</classname> will create a message with a
      <interfacename>Result</interfacename> payload.  This can be customised by providing a
      <interfacename>ResultFactory</interfacename> and/or a <interfacename>ResultTransformer</interfacename>.
      <programlisting language="xml"><![CDATA[<bean id="xsltPayloadTransformer"
      class="org.springframework.integration.xml.transformer.XsltPayloadTransformer">
    <constructor-arg value="classpath:org/example/xsl/transform.xsl" />
    <constructor-arg>
        <bean class="org.springframework.integration.xml.transformer.ResultToDocumentTransformer" />
    </constructor-arg>
</bean>]]></programlisting>
    </para>
  </section>
  <section id="xml-transformer-namespace">

    <title>Namespace support for xml transformers</title>
    <para>
      Namespace support for all xml transformers is provided in the Spring Integration xml namespace,
      a template for which can be seen below.  The namespace support for transformers creates an instance of either
      <classname>EventDrivenConsumer</classname> or <classname>PollingConsumer</classname>
      according to the type of the provided input channel.  The namespace support is designed
      to reduce the amount of xml configuration by allowing the creation of an endpoint and transformer
      using one element.
      <programlisting language="xml"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:integration="http://www.springframework.org/schema/integration"
       xmlns:si-xml="http://www.springframework.org/schema/integration/xml"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
           http://www.springframework.org/schema/integration
           http://www.springframework.org/schema/integration/spring-integration-2.0.xsd
           http://www.springframework.org/schema/integration/xml
           http://www.springframework.org/schema/integration/xml/spring-integration-xml-2.0.xsd">
</beans>]]></programlisting>
    The namespace support for <classname>UnmarshallingTransformer</classname> is shown below.
    Since the namespace is now creating an endpoint instance rather than a transformer,
    a poller can also be nested within the element to control the polling of the input channel.
    <programlisting language="xml"><![CDATA[<si-xml:unmarshalling-transformer id="defaultUnmarshaller"
    input-channel="input"
    output-channel="output"
    unmarshaller="unmarshaller"/>

<si-xml:unmarshalling-transformer id="unmarshallerWithPoller"
    input-channel="input"
    output-channel="output"
    unmarshaller="unmarshaller">
    <si:poller fixed-rate="2000"/>
<si-xml:unmarshalling-transformer/>
    ]]></programlisting>
    </para>

    <para>
    The namespace support for the marshalling transformer requires an input channel, output channel and a
    reference to a marshaller.  The optional <code>result-type</code> attribute can be used to control the type of result created,
    valid values are StringResult or DomResult (the default).  Where the provided result types are not sufficient a
    reference to a custom implementation of <interfacename>ResultFactory</interfacename> can be provided as an alternative
    to setting the <code>result-type</code> attribute using the <code>result-factory</code> attribute.  An optional <code>result-transformer</code> can also be
    specified in order to convert the created <interfacename>Result</interfacename> after marshalling.
    <programlisting language="xml"><![CDATA[<si-xml:marshalling-transformer
     input-channel="marshallingTransformerStringResultFactory"
     output-channel="output"
     marshaller="marshaller"
     result-type="StringResult" />

<si-xml:marshalling-transformer
    input-channel="marshallingTransformerWithResultTransformer"
    output-channel="output"
    marshaller="marshaller"
    result-transformer="resultTransformer" />

<bean id="resultTransformer"
      class="org.springframework.integration.xml.transformer.ResultToStringTransformer"/>]]></programlisting>
</para>

  <para>
    Namespace support for the <classname>XsltPayloadTransformer</classname> allows either a resource to be passed in in order to create the
    <interfacename>Templates</interfacename> instance or alternatively a precreated <interfacename>Templates</interfacename>
    instance can be passed in as a reference.  In common with the marshalling transformer the type of the result output can
    be controlled by specifying either the result-factory or <code>result-type</code> attribute.  A <code>result-transfomer</code> attribute can also
    be used to reference an implementation of <interfacename>ResultTransfomer</interfacename> where conversion of the result
    is required before sending.
  <programlisting language="xml"><![CDATA[<si-xml:xslt-transformer id="xsltTransformerWithResource"
    input-channel="withResourceIn"
    output-channel="output"
    xsl-resource="org/springframework/integration/xml/config/test.xsl"/>
<si-xml:xslt-transformer id="xsltTransformerWithTemplatesAndResultTransformer"
    input-channel="withTemplatesAndResultTransformerIn"
    output-channel="output"
    xsl-templates="templates"
    result-transformer="resultTransformer"/>]]></programlisting>
    </para>
    <para>
    Very often to assist with transformation you may need to have access to Message data (e.g., Message Headers). For example; you may need to get access to certain Message Headers
      and pass them on as parameters to a transformer (e.g., transformer.setParameter(..)). 
        Spring Integration provides two convenient ways to accomplish this. Just look at the following XML snippet.
<programlisting language="xml"><![CDATA[<si-xml:xslt-transformer id="paramHeadersCombo"
      input-channel="paramHeadersComboChannel"
    output-channel="output"
    xsl-resource="classpath:transformer.xslt"
    xslt-param-headers="testP*, *foo, bar, baz">

    <int-xml:xslt-param name="helloParameter" value="hello"/>
    <int-xml:xslt-param name="firstName" expression="headers.fname"/>
</int-xml:xslt-transformer>]]></programlisting>
        If message header names match 1:1 to parameter names, you can simply use <code>xslt-param-headers</code> attribute. There you can also use wildcards for
        simple pattern matching which supports the following simple pattern styles: "xxx*", "*xxx", "*xxx*" and "xxx*yyy".
    </para>
    <para>
        You can also configure individual xslt parameters via &lt;xslt-param/&gt; sub element. There you can use <code>expression</code> or <code>value</code> attribute.
        The <code>expression</code> attribute should be any valid SpEL expression with Message being the root object of the expression evaluation context.
        The <code>value</code> attribute just like any <code>value</code> in Spring beans allows you to specify simple scalar vallue. YOu can also use property placeholders (e.g., ${some.value})
        So as you can see, with the <code>expression</code> and <code>value</code> attribute xslt parameters could now be mapped to any accessible part of the Message as well as any literal value.
    </para>
  </section>

  <section id="xpath-splitting">
    <title>Splitting xml messages</title>
    <para>
      <classname>XPathMessageSplitter</classname> supports messages with either
      <classname>String</classname> or <interfacename>Document</interfacename> payloads.
      The splitter uses the provided XPath expression to split the payload into a number of
      nodes.  By default this will result in each <interfacename>Node</interfacename> instance
      becoming the payload of a new message.  Where it is preferred that each message be a Document
      the <methodname>createDocuments</methodname> flag can be set.  Where a <classname>String</classname> payload is passed
      in the payload will be converted then split before being converted back to a number of String
      messages.  The XPath splitter implements <interfacename>MessageHandler</interfacename> and should
      therefore be configured in conjunction with an appropriate endpoint (see the namespace support below
      for a simpler configuration alternative).
      <programlisting language="xml"><![CDATA[<bean id="splittingEndpoint"
      class="org.springframework.integration.endpoint.EventDrivenConsumer">
    <constructor-arg ref="orderChannel" />
    <constructor-arg>
        <bean class="org.springframework.integration.xml.splitter.XPathMessageSplitter">
            <constructor-arg value="/order/items" />
            <property name="documentBuilder" ref="customisedDocumentBuilder" />
            <property name="outputChannel" ref="orderItemsChannel" />
        </bean>
    </constructor-arg>
</bean>]]></programlisting>

    </para>
  </section>

  <section id="xpath-routing">
    <title>Routing xml messages using XPath</title>
 
    <para>
      Similar to SpEL-based routers, Spring Integration provides support for routing messages based on the XPath expressions 
      allowing you to create a Message Endpoint with an input channel but no output channel
      since the output channel(s) is determined dynamically.  
      <programlisting language="xml"><![CDATA[
<si-xml:xpath-router id="orderTypeRouter" input-channel="orderChannel">
    <si-xml:xpath-expression expression="/order/type"/>
</si-xml:xpath-router>	
]]></programlisting>
    </para>
    
    <para>
     Internally XPath expression will be evaluated as <emphasis>NODESET</emphasis> type and converted to a 
      <classname>List&lt;String&gt;</classname> representing channel names. Typically such list will contain a single channel name.
	  However, based on the result of an XPath Expression XPath router can also take on the characteristics of the <emphasis>Recipient List Router</emphasis> 
	  if XPath Expression returns more then one value, thus resulting in the <classname>List&lt;String&gt;</classname> containing more 
	  then one channel name. In that case Message will be sent to all channels in the list.	
	  So assuming that the xml file passed to the router configured below contains many <code>responder</code> sub-elements representing channel names, 
	  the message will be sent to all of those channels.
	  
	  <programlisting language="xml"><![CDATA[<!-- route the order to all responders-->
<si-xml:xpath-router id="responderRouter" input-channel="orderChannel">
    <si-xml:xpath-expression expression="/request/responders"/>
</si-xml:xpath-router>	
]]></programlisting>

    If the returned values do not represent the channel names additional mapping could be specified. For example if 
    the <code>/request/responders</code> expression results in two values <code>responderA</code> and <code>responderB</code> but 
    you don't want to couple the responder names to channel names you may provide additional mapping as such:
    <programlisting language="xml"><![CDATA[<!-- route the order to all responders-->
<si-xml:xpath-router id="responderRouter" input-channel="orderChannel">
    <si-xml:xpath-expression expression="/request/responders"/>
    <int-xml:mapping value="responderA" channel="channelA"/>	
    <int-xml:mapping value="responderB" channel="channelB"/>	
</si-xml:xpath-router>	
]]></programlisting>
    </para>
    
    <para>
    As we already said the default evaluation type for XPath expressions is NODESET which is converted 
	to a List&lt;String&gt; of channel names, thus handling single channel scenarios as well as multiple.
	However certain XPath expressions may evaluate as String type from the very 
	beginning (e.g., 'name(./node())' - which will return the name of the root node) thus resulting in 
	the exception if default evaluation type (NODESET) is used. 
	For these scenarious you may use <code>evaluate-as-string</code> attribute which will allow you to manage the 
	evaluation type. It is FALSE by default, however if set to TRUE, the String evaluation type will be used.
	For example if we want to route based on the name of the root node we can have use the following configuration:
	
	<programlisting language="xml"><![CDATA[<int-xml:xpath-router id="xpathRouterAsString" 
		input-channel="xpathStringChannel" 
		evaluate-as-string="true">
	<int-xml:xpath-expression expression="name(./node())"/>	
</int-xml:xpath-router>	
]]></programlisting>
    </para>

	<para>The XPath Router does support custom implementations of the XmlPayloadConverter strategy, and when configuring
	an 'xpath-router' element in XML, a reference to such an implementation may be provided via the 'converter' attribute.
	However, the DefaultXmlPayloadConverter is used if this reference is not provided, and it
	should be sufficient in most cases since it can convert from Node, Document, Source,
	File, and String typed payloads. If you need to extend beyond the capabilities of
	that default implementation, then an upstream Transformer is probably a better option
	than providing a reference to a custom implementation of this strategy here.</para>
    
  </section>

  <section id="xpath-selector">
    <title>Selecting xml messages using XPath</title>
    <para>
      Two <interfacename>MessageSelector</interfacename> implementations are provided,
      <classname>BooleanTestXPathMessageSelector</classname> and <classname>StringValueTestXPathMessageSelector</classname>.
      <classname>BooleanTestXPathMessageSelector</classname> requires an XPathExpression which evaluates to a boolean,
      for example <emphasis>boolean(/one/two)</emphasis> which will only select messages which have an element named
      two which is a child of a root element named one.  <classname>StringValueTestXPathMessageSelector</classname>
      evaluates any XPath expression as a <classname>String</classname> and compares the result with the provided value.
    </para>


      <programlisting language="xml"><![CDATA[<!-- Interceptor which rejects messages that do not have a root element order  -->
<bean id="orderSelectingInterceptor"
      class="org.springframework.integration.channel.interceptor.MessageSelectingInterceptor">
    <constructor-arg>
        <bean class="org.springframework.integration.xml.selector.BooleanTestXPathMessageSelector">
            <constructor-arg value="boolean(/order)" />
        </bean>
    </constructor-arg>
</bean>

<!--  Interceptor which rejects messages that are not version one orders -->
<bean id="versionOneOrderSelectingInterceptor"
      class="org.springframework.integration.channel.interceptor.MessageSelectingInterceptor">
    <constructor-arg>
        <bean class="org.springframework.integration.xml.selector.StringValueTestXPathMessageSelector">
            <constructor-arg value="/order/@version" index="0"/>
            <constructor-arg value="1" index="1"/>
        </bean>
    </constructor-arg>
</bean>]]></programlisting>
  </section>

  <section id="xpath-transformer">
    <title>Transforming xml messages using XPath</title>
    <para>
      When it comes to message transformation XPath is a great way to transform Messages that have XML
      payloads by defining XPath transformers via &lt;xpath-transformer/&gt; element.
    </para>
    <para>
    <emphasis>Simple XPath transformation</emphasis>
    </para>
    <para>
    Let's look at the following transformer configuration:
    <programlisting language="xml"><![CDATA[<xpath-transformer input-channel="inputChannel" output-channel="outputChannel"
      xpath-expression="/person/@name" />]]></programlisting>

    . . . and Message
    <programlisting language="java"><![CDATA[Message<?> message =
  MessageBuilder.withPayload("<person name='John Doe' age='42' married='true'/>").build();]]></programlisting>
    After sending this message to the 'inputChannel' the XPath transformer configured above will transform
    this XML Message to a simple Message with payload of 'John Doe' all based on
    the simple XPath Expression specified in the <code>xpath-expression</code> attribute.
    </para>
    <para>
    XPath also has capability to perform simple conversion of extracted elements
    to a desired type. Valid return types are defined in <classname>XPathConstants</classname> and follows
    the conversion rules specified by the <classname>XPath</classname>.
    </para>
    <para>
    The following constants are defined by the <classname>XPathConstants</classname>: <emphasis>BOOLEAN, DOM_OBJECT_MODEL, NODE, NODESET, NUMBER, STRING</emphasis>
    </para>
    <para>
    You can configure the desired type by simply using <code>evaluation-type</code>
    attribute of the &lt;xpath-transformer/&gt; element.
    <programlisting language="xml"><![CDATA[<xpath-transformer input-channel="numberInput" xpath-expression="/person/@age"
    evaluation-type="NUMBER_RESULT" output-channel="output"/>

<xpath-transformer input-channel="booleanInput" xpath-expression="/person/@married = 'true'"
    evaluation-type="BOOLEAN_RESULT" output-channel="output"/>
]]></programlisting>
    </para>
    <para>
    <emphasis>Node Mappers</emphasis>
    </para>
    <para>
    If you need to provide custom mapping for the node extracted by the XPath expression simply provide a reference to the
    implementation of the <classname>org.springframework.xml.xpath.NodeMapper</classname> - an interface used by
    <classname>XPathOperations</classname> implementations for mapping Node objects on a per-node basis. To provide a
    reference to a <classname>NodeMapper</classname> simply use <code>node-mapper</code> attribute:
    <programlisting language="xml"><![CDATA[<xpath-transformer input-channel="nodeMapperInput" xpath-expression="/person/@age"
    node-mapper="testNodeMapper" output-channel="output"/>
]]></programlisting>
. . . and Sample NodeMapper implementation:
<programlisting language="java"><![CDATA[class TestNodeMapper implements NodeMapper {
  public Object mapNode(Node node, int nodeNum) throws DOMException {
    return node.getTextContent() + "-mapped";
  }
}]]></programlisting>
    </para>
    <para>
    <emphasis>XML Payload Converter</emphasis>
    </para>
    <para>
    You can also use an implementation of the <classname>org.springframework.integration.xml.XmlPayloadConverter</classname> to
    provide more granular transformation:
    <programlisting language="xml"><![CDATA[<xpath-transformer input-channel="customConverterInput" xpath-expression="/test/@type"
    converter="testXmlPayloadConverter" output-channel="output"/>
]]></programlisting>
. . . and Sample XmlPayloadConverter implementation:
<programlisting language="java"><![CDATA[class TestXmlPayloadConverter implements XmlPayloadConverter {
  public Source convertToSource(Object object) {
    throw new UnsupportedOperationException();
  }
  //
  public Node convertToNode(Object object) {
    try {
      return DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(
          new InputSource(new StringReader("<test type='custom'/>")));
    }
    catch (Exception e) {
      throw new IllegalStateException(e);
    }
  }
  //
  public Document convertToDocument(Object object) {
    throw new UnsupportedOperationException();
  }
}]]></programlisting>
    </para>
	<para>The DefaultXmlPayloadConverter is used if this reference is not provided, and it
	should be sufficient in most cases since it can convert from Node, Document, Source,
	File, and String typed payloads. If you need to extend beyond the capabilities of
	that default implementation, then an upstream Transformer is probably a better option
	than providing a reference to a custom implementation of this strategy here.</para>

    <para>
    <emphasis>Combination of SpEL and XPath expressions</emphasis>
    </para>
    <para>
    You can also combine Spring Expression Language (SpEL) expressions with XPath expression and configure
    them using <code>expression</code> attribute:
    <programlisting language="xml"><![CDATA[xpath-expression id="testExpression" expression="/person/@age * 2"/>]]></programlisting>
    In the above case the overall result of the expression will be the result of the XPath expression multiplied by 2.
    </para>
  </section>


  <section id="xpath-namespace-support">
    <title>XPath components namespace support</title>
    <para>All XPath based components have namespace support allowing them to be configured as
    Message Endpoints with the exception of the XPath selectors which are not designed to act as
    endpoints.  Each component allows the XPath to either be referenced at the top level or configured via a nested
    &lt;xpath-expression/&gt; element.  So the following configurations of an xpath-selector are all valid and represent the general
    form of XPath namespace support.  All forms of XPath expression result in the creation of an
    <interfacename>XPathExpression</interfacename> using the Spring <classname>XPathExpressionFactory</classname>
    <programlisting language="xml"><![CDATA[<si-xml:xpath-selector id="xpathRefSelector"
                       xpath-expression="refToXpathExpression"
                       evaluation-result-type="boolean" />

<si-xml:xpath-selector id="selectorWithNoNS" evaluation-result-type="boolean" >
    <si-xml:xpath-expression expression="/name"/>
</si-xml:xpath-selector>

<si-xml:xpath-selector id="selectorWithOneNS" evaluation-result-type="boolean" >
    <si-xml:xpath-expression expression="/ns1:name"
                             ns-prefix="ns1" ns-uri="www.example.org" />
</si-xml:xpath-selector>

<si-xml:xpath-selector id="selectorWithTwoNS" evaluation-result-type="boolean" >
    <si-xml:xpath-expression expression="/ns1:name/ns2:type">
        <map>
            <entry key="ns1" value="www.example.org/one" />
            <entry key="ns2" value="www.example.org/two" />
        </map>
    </si-xml:xpath-expression>
</si-xml:xpath-selector>

<si-xml:xpath-selector id="selectorWithNamespaceMapRef" evaluation-result-type="boolean" >
    <si-xml:xpath-expression expression="/ns1:name/ns2:type"
                             namespace-map="defaultNamespaces"/>
</si-xml:xpath-selector>

<util:map id="defaultNamespaces">
    <util:entry key="ns1" value="www.example.org/one" />
    <util:entry key="ns2" value="www.example.org/two" />
</util:map>]]></programlisting>
    </para>
    <para>
      XPath splitter namespace support allows the creation of a Message Endpoint with an input channel and output channel.
      <programlisting language="xml"><![CDATA[<!-- Split the order into items creating a new message for each item node -->
<si-xml:xpath-splitter id="orderItemSplitter"
                       input-channel="orderChannel"
                       output-channel="orderItemsChannel">
    <si-xml:xpath-expression expression="/order/items"/>
</si-xml:xpath-splitter>

<!-- Split the order into items creating a new document for each item-->
<si-xml:xpath-splitter id="orderItemDocumentSplitter"
                       input-channel="orderChannel"
                       output-channel="orderItemsChannel"
                       create-documents="true">
    <si-xml:xpath-expression expression="/order/items"/>
    <si:poller fixed-rate="2000"/>
</si-xml:xpath-splitter>]]></programlisting>
    </para>
  </section>

</chapter>
