28. XML Support - Dealing with XML Payloads

28.1 Introduction

Spring Integration's XML support extends the core of Spring Integration with the following components:

These components are 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 java.lang.String, org.w3c.dom.Document and javax.xml.transform.Source. It should be noted however that where a DOM representation is required, for example in order to evaluate an XPath expression, the String payload will be converted into the required type and then converted back again to String. Components that require an instance of DocumentBuilder will create a namespace-aware instance if one is not provided. In cases where you require greater control over document creation, you can provide an appropriately configured instance of DocumentBuilder.

28.2 Namespace Support

All components within the Spring Integration XML module provide namespace support. In order to enable namespace support, you need to import the respective schema for the Spring Integration XML Module. A typical setup is shown below:

<?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:int="http://www.springframework.org/schema/integration"
  xmlns:int-xml="http://www.springframework.org/schema/integration/xml"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/integration
    http://www.springframework.org/schema/integration/spring-integration.xsd
    http://www.springframework.org/schema/integration/xml
    http://www.springframework.org/schema/integration/xml/spring-integration-xml.xsd">
</beans>

28.2.1 XPath Expressions

Many of the components within the Spring Integration XML module work with XPath Expressions. Each of those components will either reference an XPath Expression that has been defined as top-level element or via a nested <xpath-expression/> element.

All forms of XPath expressions result in the creation of an XPathExpression using the Spring org.springframework.xml.xpath.XPathExpressionFactory. When creating XPath expressions, the best XPath implementation that is available on the classpath is being used, either JAXP 1.3+ or Jaxen, whereby JAXP is preferred.

[Note]Note
Spring Integration under the covers uses the XPath functionality as provided by the Spring Web Services project (http://www.springsource.org/spring-web-services). Specifically, Spring Web Services' XML module (spring-xml-x.x.x.jar) is being used. Therefore, for a deeper understanding, please refer to the respective documentation as well at:

Here is an overview of all available configuration parameters of the xpath-expression element:

<int-xml:xpath-expression expression=""     1
		          id=""             2
		          namespace-map=""  3
		          ns-prefix=""      4
		          ns-uri="">        5
    <map></map>                           6
</int-xml:xpath-expression>

1

Defines an XPath xpression. Required.

2

The Identifier of the underlying bean definition. Will be an instance of org.springframework.xml.xpath.XPathExpression Optional.

3

Reference to a map containing namespaces. The key of the map defines the namespace prefix and the value of the map sets the namespace URI. It is not valid to specify both this attribute and the map sub element, or setting the ns-prefix and ns-uri attribute. Optional.

4

Allows you to set the namspace prefix directly as and attribute on the XPath expression element. If you set ns-prefix, you must also set the ns-uri attribute. Optional.

5

Allows you to set the namspace URI directly as an attribute on the XPath expression element. If you set ns-uri, you must also set the ns-prefix attribute. Optional.

6

Defines a map containing namespaces. Only one map child element is allowed. The key of the map defines the namespace prefix and the value of the map sets the namespace URI.

It is not valid to specify both this sub-element and the map attribute, or setting the ns-prefix and ns-uri attributes. Optional.

Providing Namespaces (Optional) to XPath Expressions

For the XPath Expression Element, namespace information can be optionally provided as configuration parameters. As such, namespaces can be defined using one of the following 3 choices:

  • Reference a map using the namespace-map attribute
  • Provide a map of namespaces using the map sub-element
  • Specifying the ns-prefix and the ns-uri attribute

All three options are mutially exlusive. Only one option can be set.

Below, please find several different usage examples on how to use XPath expressions using the XML namespace support including the various option for setting the XML namespaces as discussed above.

<int-xml:xpath-filter id="filterReferencingXPathExpression"
                      xpath-expression-ref="refToXpathExpression"/>

<int-xml:xpath-expression id="refToXpathExpression" expression="/name"/>

<int-xml:xpath-filter id="filterWithoutNamespace">
   <int-xml:xpath-expression expression="/name"/>
</int-xml:xpath-filter>

<int-xml:xpath-filter id="filterWithOneNamespace">
    <int-xml:xpath-expression expression="/ns1:name"
                              ns-prefix="ns1" ns-uri="www.example.org"/>
</int-xml:xpath-filter>

<int-xml:xpath-filter id="filterWithTwoNamespaces">
    <int-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>
    </int-xml:xpath-expression>
</int-xml:xpath-filter>

<int-xml:xpath-filter id="filterWithNamespaceMapReference">
    <int-xml:xpath-expression expression="/ns1:name/ns2:type"
                              namespace-map="defaultNamespaces"/>
</int-xml:xpath-filter>

<util:map id="defaultNamespaces">
    <util:entry key="ns1" value="www.example.org/one"/>
    <util:entry key="ns2" value="www.example.org/two"/>
</util:map>

28.3 Transforming XML Payloads

28.3.1 Configuring Transformers as Beans

This section will explain the workings of the following transformers and how to configure them as beans:

  • UnmarshallingTransformer

  • MarshallingTransformer

  • XsltPayloadTransformer

All of the provided XML transformers extend AbstractTransformer or AbstractPayloadTransformer and therefore implement Transformer. When configuring XML transformers as beans in Spring Integration you would normally configure the transformer in conjunction with either a MessageTransformingChannelInterceptor or a MessageTransformingHandler. 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.

UnmarshallingTransformer allows an XML Source to be unmarshalled using implementations of Spring OXM Unmarshaller. Spring OXM provides several implementations supporting marshalling and unmarshalling using JAXB, Castor and JiBX amongst others. Since the unmarshaller requires an instance of Source where the message payload is not currently an instance of Source, conversion will be attempted. Currently String and org.w3c.dom.Document payloads are supported. Custom conversion to a Source is also supported by injecting an implementation of SourceFactory.

<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>

The MarshallingTransformer allows an object graph to be converted into XML using a Spring OXM Marshaller. By default the MarshallingTransformer will return a DomResult. However the type of result can be controlled by configuring an alternative ResultFactory such as StringResultFactory. In many cases it will be more convenient to transform the payload into an alternative XML format. To achieve this configure a ResultTransformer. Two implementations are provided, one which converts to String and another which converts to Document.

<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>

By default, the MarshallingTransformer will pass the payload Object to the Marshaller, but if its boolean extractPayload property is set to false, the entire Message instance will be passed to the Marshaller instead. That may be useful for certain custom implementations of the Marshaller interface, but typically the payload is the appropriate source Object for marshalling when delegating to any of the various out-of-the-box Marshaller implementations.

XsltPayloadTransformer transforms XML payloads using xsl. The transformer requires an instance of either Resource or Templates. Passing in a Templates instance allows for greater configuration of the TransformerFactory used to create the template instance. As in the case of XmlPayloadMarshallingTransformer by default XsltPayloadTransformer will create a message with a Result payload. This can be customised by providing a ResultFactory and/or a ResultTransformer.

<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>

28.3.2 Namespace Support for XML Transformers

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 EventDrivenConsumer or PollingConsumer 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.

The namespace support for UnmarshallingTransformer 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.

<int-xml:unmarshalling-transformer id="defaultUnmarshaller"
    input-channel="input"
    output-channel="output"
    unmarshaller="unmarshaller"/>

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

The namespace support for the marshalling transformer requires an input-channel, output-channel and a reference to a marshaller. The optional result-type 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 ResultFactory can be provided as an alternative to setting the result-type attribute using the result-factory attribute. An optional result-transformer can also be specified in order to convert the created Result after marshalling.

<int-xml:marshalling-transformer
     input-channel="marshallingTransformerStringResultFactory"
     output-channel="output"
     marshaller="marshaller"
     result-type="StringResult" />

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

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

Namespace support for the XsltPayloadTransformer allows either a resource to be passed in in order to create the Templates instance or alternatively a precreated Templates 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 result-type attribute. A result-transfomer attribute can also be used to reference an implementation of ResultTransfomer where conversion of the result is required before sending.

<int-xml:xslt-transformer id="xsltTransformerWithResource"
    input-channel="withResourceIn"
    output-channel="output"
    xsl-resource="org/springframework/integration/xml/config/test.xsl"/>
<int-xml:xslt-transformer id="xsltTransformerWithTemplatesAndResultTransformer"
    input-channel="withTemplatesAndResultTransformerIn"
    output-channel="output"
    xsl-templates="templates"
    result-transformer="resultTransformer"/>

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.

<int-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>

If message header names match 1:1 to parameter names, you can simply use xslt-param-headers attribute. There you can also use wildcards for simple pattern matching which supports the following simple pattern styles: "xxx*", "*xxx", "*xxx*" and "xxx*yyy".

You can also configure individual xslt parameters via <xslt-param/> sub element. There you can use expression or value attribute. The expression attribute should be any valid SpEL expression with Message being the root object of the expression evaluation context. The value attribute just like any value 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 expression and value attribute xslt parameters could now be mapped to any accessible part of the Message as well as any literal value.

28.4 Transforming XML Messages Using XPath

When it comes to message transformation XPath is a great way to transform Messages that have XML payloads by defining XPath transformers via <xpath-transformer/> element.

Simple XPath transformation

Let's look at the following transformer configuration:

<int-xml:xpath-transformer input-channel="inputChannel" output-channel="outputChannel"
      xpath-expression="[email protected]" />

. . . and Message

Message<?> message =
  MessageBuilder.withPayload("<person name='John Doe' age='42' married='true'/>").build();

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 xpath-expression attribute.

XPath also has the capability to perform simple conversion of extracted elements to a desired type. Valid return types are defined in javax.xml.xpath.XPathConstants and follows the conversion rules specified by the javax.xml.xpath.XPath interface.

The following constants are defined by the XPathConstants class: BOOLEAN, DOM_OBJECT_MODEL, NODE, NODESET, NUMBER, STRING

You can configure the desired type by simply using the evaluation-type attribute of the <xpath-transformer/> element.

<int-xml:xpath-transformer input-channel="numberInput" xpath-expression="[email protected]"
                           evaluation-type="NUMBER_RESULT" output-channel="output"/>

<int-xml:xpath-transformer input-channel="booleanInput"
                           xpath-expression="[email protected] = 'true'"
                           evaluation-type="BOOLEAN_RESULT" output-channel="output"/>

Node Mappers

If you need to provide custom mapping for the node extracted by the XPath expression simply provide a reference to the implementation of the org.springframework.xml.xpath.NodeMapper - an interface used by XPathOperations implementations for mapping Node objects on a per-node basis. To provide a reference to a NodeMapper simply use node-mapper attribute:

<int-xml:xpath-transformer input-channel="nodeMapperInput" xpath-expression="[email protected]"
                           node-mapper="testNodeMapper" output-channel="output"/>

. . . and Sample NodeMapper implementation:

class TestNodeMapper implements NodeMapper {
  public Object mapNode(Node node, int nodeNum) throws DOMException {
    return node.getTextContent() + "-mapped";
  }
}

XML Payload Converter

You can also use an implementation of the org.springframework.integration.xml.XmlPayloadConverter to provide more granular transformation:

<int-xml:xpath-transformer input-channel="customConverterInput"
                           output-channel="output" xpath-expression="[email protected]"
                           converter="testXmlPayloadConverter" />

. . . and Sample XmlPayloadConverter implementation:

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();
  }
}

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.

28.5 Splitting XML Messages

XPathMessageSplitter supports messages with either String or Document payloads. The splitter uses the provided XPath expression to split the payload into a number of nodes. By default this will result in each Node instance becoming the payload of a new message. Where it is preferred that each message be a Document the createDocuments flag can be set. Where a String 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 MessageHandler and should therefore be configured in conjunction with an appropriate endpoint (see the namespace support below for a simpler configuration alternative).

<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>

XPath splitter namespace support allows the creation of a Message Endpoint with an input channel and output channel.

<!-- Split the order into items creating a new message for each item node -->
<int-xml:xpath-splitter id="orderItemSplitter"
                       input-channel="orderChannel"
                       output-channel="orderItemsChannel">
    <int-xml:xpath-expression expression="/order/items"/>
</int-xml:xpath-splitter>

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

28.6 Routing XML Messages Using XPath

Similar to SpEL-based routers, Spring Integration provides support for routing messages based on XPath expressions, allowing you to create a Message Endpoint with an input channel but no output channel. Instead, one or more output channels are determined dynamically.

<int-xml:xpath-router id="orderTypeRouter" input-channel="orderChannel">
    <si-xml:xpath-expression expression="/order/type"/>
</int-xml:xpath-router>
[Note]Note
For an overview of attributes that are common among Routers, please see chapter: Common Router Parameters

Internally XPath expressions will be evaluated as NODESET type and converted to a List<String> representing channel names. Typically such a list will contain a single channel name. However, based on the results of an XPath Expression, the XPath router can also take on the characteristics of a Recipient List Router if the XPath Expression returns more then one value. In that case, the List<String> will contain more then one channel name and consequently Messages will be sent to all channels in the list.

Thus, assuming that the XML file passed to the router configured below contains many responder sub-elements representing channel names, the message will be sent to all of those channels.

<!-- route the order to all responders-->
<int-xml:xpath-router id="responderRouter" input-channel="orderChannel">
    <int-xml:xpath-expression expression="/request/responders"/>
</int-xml:xpath-router>

If the returned values do not represent the channel names directly, additional mapping parameters can be specified, in order to map those returned values to actual channel names. For example if the /request/responders expression results in two values responderA and responderB but you don't want to couple the responder names to channel names, you may provide additional mapping configuration such as the following:

<!-- route the order to all responders-->
<int-xml:xpath-router id="responderRouter" input-channel="orderChannel">
    <int-xml:xpath-expression expression="/request/responders"/>
    <int-xml:mapping value="responderA" channel="channelA"/>
    <int-xml:mapping value="responderB" channel="channelB"/>
</int-xml:xpath-router>

As already mentioned, the default evaluation type for XPath expressions is NODESET, which is converted to a List<String> of channel names, therefore handling single channel scenarios as well as multiple ones.

Nonetheless, certain XPath expressions may evaluate as String type from the very beginning. Take for example the following XPath Expression:

name(./node())

This expression will return the name of the root node. It will resulting in an exception, if the default evaluation type NODESET is being used.

For these scenarious, you may use the evaluate-as-string 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.

[Note]Note

To provide some background information: XPath 1.0 specifies 4 data types:

  • Node-sets
  • Strings
  • Number
  • Boolean

When the XPath Router evaluates expressions using the optional evaluate-as-string attribute, the return value is determined per the string() function as defined in the XPath specification. This means that if the expression selects multiple nodes, it will return the string value of the first node.

For further information, please see:

  • Specification: XML Path Language (XPath) Version 1.0: http://www.w3.org/TR/xpath/
  • XPath specification - string() function: http://www.w3.org/TR/xpath/#function-string

For example if we want to route based on the name of the root node, we can use the following configuration:

<int-xml:xpath-router id="xpathRouterAsString"
        input-channel="xpathStringChannel"
        evaluate-as-string="true">
    <int-xml:xpath-expression expression="name(./node())"/>
</int-xml:xpath-router>

28.6.1 XML Payload Converter

For XPath Routers, you can also specify the Converter to use when converting payloads prior to XPath evaluation. As such, the XPath Router supports 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.

If this reference is not explicitly provided, the DefaultXmlPayloadConverter is used. 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 generally a better option in most cases, rather than providing a reference to a custom implementation of this strategy here.

28.7 XPath Header Enricher

The XPath Header Enricher defines a Header Enricher Message Transformer that evaluates XPath expressions against the message payload and inserts the result of the evaluation into a messsage header.

Please see below for an overview of all available configuration parameters:

<int-xml:xpath-header-enricher default-overwrite="true"   1
	                           id=""                      2
	                           input-channel=""           3
	                           output-channel=""          4
	                           should-skip-nulls="true">  5
    <int:poller></int:poller>                             6
    <int-xml:header name=""                               7
                    evaluation-type="STRING_RESULT"       8
                    overwrite="true"                      9
                    xpath-expression=""                   10
                    xpath-expression-ref=""/>             11
</int-xml:xpath-header-enricher>
    

1

Specify the default boolean value for whether to overwrite existing header values. This will only take effect for sub-elements that do not provide their own 'overwrite' attribute. If the 'default- overwrite' attribute is not provided, then the specified header values will NOT overwrite any existing ones with the same header names. Optional.

2

Id for the underlying bean definition. Optional.

3

The receiving Message channel of this endpoint. Optional.

4

Channel to which enriched messages shall be send to. Optional.

5

Specify whether null values, such as might be returned from an expression evaluation, should be skipped. The default value is true. Set this to false if a null value should trigger removal of the corresponding header instead. Optional.

6

Optional.

7

The name of the header to be enriched. Mandatory.

8

The result type expected from the XPath evaluation. This will be the type of the header value. The following values are allowed: BOOLEAN_RESULT, STRING_RESULT, NUMBER_RESULT, NODE_RESULT and NODE_LIST_RESULT. Defaults internally to XPathEvaluationType.STRING_RESULT if not set. Optional.

9

Boolean value to indicate whether this header value should overwrite an existing header value for the same name if already present on the input Message.

10

The XPath Expression as a String. Either this attribute or xpath-expression-ref must be provided, but not both.

11

The XPath Expression reference. Either this attribute or xpath-expression must be provided, but not both.

28.8 Using the XPath Filter

This component defines an XPath-based Message Filter. Under the covers this components uses a MessageFilter that wraps an instance of AbstractXPathMessageSelector.

[Note]Note
Please also refer to the chapter on Message Filters for further details.

In order to use the XPath Filter you must as a minimum provide an XPath Expression either by declaring the xpath-expression sub-element or by referencing an XPath Expression using the xpath-expression-ref attribute.

If the provided XPath expression will evaluate to a boolean value, no further configuration parameters are necessary. However, if the XPath expression will evaluate to a String, the match-value attribute should be specified against which the evaluation result will be matched.

There are three options for the match-type:

  • exact - correspond to equals on java.lang.String. The underlying implementation uses a StringValueTestXPathMessageSelector
  • case-insensitive - correspond to equals-ignore-case on java.lang.String. The underlying implementation uses a StringValueTestXPathMessageSelector
  • regex - matches operations one java.lang.String. The underlying implementation uses a RegexTestXPathMessageSelector

When providing a 'match-type' value of 'regex', the value provided with thos match-value attribute must be a valid Regular Expression.

[Note]Note
In prior versions of Spring Integration the functionality of the XPath Filter was configured using the xpath-selector element. However, in order to provide a more consistent behavior within the Spring Integration Framework, the xpath-selector element is deprecated as of version 2.1. Please use <xpath-filter> instead. It provides the same set of functionality. In fact it still uses the same MessageSelectors internally.
<int-xml:xpath-filter discard-channel=""                     1
                      id=""                                  2
                      input-channel=""                       3
                      match-type="exact"                     4
                      match-value=""                         5
                      output-channel=""                      6
                      throw-exception-on-rejection="false"   7
                      xpath-expression-ref="">               8
    <int-xml:xpath-expression ... />                         9
    <int:poller ... />                                       10
</int-xml:xpath-filter>

1

Message Channel where you want rejected messages to be sent. Optional.

2

Id for the underlying bean definition. Optional.

3

The receiving Message channel of this endpoint. Optional.

4

Type of match to apply between the XPath evaluation result and the match-value. Default is exact. Optional.

5

String value to be matched against the XPath evaluation result. If this attribute is not provided, then the XPath evaluation MUST produce a boolean result directly. Optional.

6

The channel to which Messages that matched the filter criterias shall be dispatched to. Optional.

7

By default, this property is set to false and rejected Messages (Messages that did not match the filter criteria) will be silently dropped. However, if set to true message rejection will result in an error condition and the exception will be propagated upstream to the caller. Optional.

8

Reference to an XPath expression instance to evaluate.

9

This sub-element sets the XPath expression to be evaluated. If this is not defined you MUST define the xpath-expression-ref attribute. Also, only one xpath-expression element can be set.

10

Optional.

28.9 XML Validating Filter

The XML Validating Filter allows you to validate incoming messages against provided schema instances. The following schema types are supported:

  • xml-schema (http://www.w3.org/2001/XMLSchema)
  • relax-ng (http://relaxng.org/ns/structure/1.0)

Messages that fail validation can either be silently dropped or they can be forwarded to a definable discard-channel. Furthermore you can configure this filter to throw an Exception in case validation fails.

Please see below for an overview of all available configuration parameters:

<int-xml:validating-filter discard-channel=""                   1
                           id=""                                2
                           input-channel=""                     3
                           output-channel=""                    4
                           schema-location=""                   5
                           schema-type="xml-schema"             6
                           throw-exception-on-rejection="false" 7
                           xml-validator="">                    8
    <int:poller .../>                                           9
</int-xml:validating-filter>

1

Message Channel where you want rejected messages to be sent. Optional.

2

Id for the underlying bean definition. Optional.

3

The receiving Message channel of this endpoint. Optional.

4

Message Channel where you want accepted messages to be sent. Optional.

5

Sets the location of the schema to validate the Message's payload against. Internally uses the org.springframework.core.io.Resource interface. You can set this attribute or the xml-validator attribute but not both. Optional.

6

Sets the schema type. Can be either xml-schema or relax-ng. Optional. If not set it defaults to xml-schema which internally translates to org.springframework.xml.validation.XmlValidatorFactory#SCHEMA_W3C_XML

7

If true a MessageRejectedException is thrown in case validation fails for the provided Message's payload. Optional. Defaults to false if not set.

8

Reference to a custom sorg.springframework.xml.validation.XmlValidator strategy. You can set this attribute or the schema-location attribute but not both. Optional.

9

Optional.