For the XPath Expression Element, you can provide namespace information as configuration parameters. You can define namespaces by using one of the following choices:

All three options are mutually exclusive. Only one option can be set.

The following example shows several different ways to use XPath expressions, including the options for setting the XML namespaces mentioned earlier:

When working with default namespaces, you may run into situations that behave differently than you might expect. Assume we have the following XML document (which represents an order of two books):

This document does not declare a namespace. Therefore, applying the following XPath Expression works as expected:

You might expect that the same expression also works for the following XML file:

The preceding example looks exactly the same as the previous example but declares a default namespace.

However, the previous XPath expression (/order/orderItem) fails in this case.

In order to solve this issue, you must provide a namespace prefix and a namespace URI either by setting the ns-prefix and ns-uri attributes or by setting the namespace-map attribute. The namespace URI must match the namespace declared in your XML document. In the preceding example, that is http://www.example.org/orders.

You can, however, arbitrarily choose the namespace prefix. In fact, providing an empty string actually works. (However, null is not allowed.) In the case of a namespace prefix consisting of an empty string, your Xpath expression must use a colon (":") to indicate the default namespace. If you leave off the colon, the XPath expression does not match. The following XPath Expression matches against the XML document in the preceding example:

You can also provide any other arbitrarily chosen namespace prefix. The following XPath expression (which use the myorder namespace prefix) also matches:

The namespace URI is the really important piece of information, not the prefix. The Jaxen summarizes the point very well:

An UnmarshallingTransformer lets an XML Source be unmarshalled by using implementations of the Spring OXM Unmarshaller. Spring’s Object/XML Mapping support provides several implementations that support marshalling and unmarshalling by using JAXB, Castor, JiBX, and others. The unmarshaller requires an instance of Source. If the message payload is not an instance of Source, conversion is still attempted. Currently, String, File, byte[] and org.w3c.dom.Document payloads are supported. To create a custom conversion to a Source, you can inject an implementation of a SourceFactory.

Starting with version 5.0, the UnmarshallingTransformer also supports an org.springframework.ws.mime.MimeMessage as the incoming payload. This can be useful when we receive a raw WebServiceMessage with MTOM attachments over SOAP . See MTOM Support for more information.

The following example shows how to define an unmarshalling transformer:

The MarshallingTransformer lets an object graph be converted into XML by using a Spring OXM Marshaller. By default, the MarshallingTransformer returns a DomResult. However, you can control the type of result by configuring an alternative ResultFactory, such as StringResultFactory. In many cases, it is more convenient to transform the payload into an alternative XML format. To do so, configure a ResultTransformer. Spring integration provides two implementations, one that converts to String and another that converts to Document. The following example configures a marshalling transformer that transforms to a document:

By default, the MarshallingTransformer passes the payload object to the Marshaller. However, if its boolean extractPayload property is set to false, the entire Message instance is 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 you delegate to any of the various Marshaller implementations.

The XsltPayloadTransformer transforms XML payloads by using Extensible Stylesheet Language Transformations (XSLT). The transformer’s constructor requires an instance of either Resource or Templates to be passed in. Passing in a Templates instance allows for greater configuration of the TransformerFactory used to create the template instance.

As with the UnmarshallingTransformer, the XsltPayloadTransformer does the actual XSLT transformation against instances of Source. Therefore, if the message payload is not an instance of Source, conversion is still attempted. String and Document payloads are supported directly.

To create a custom conversion to a Source, you can inject an implementation of a SourceFactory.

By default, the XsltPayloadTransformer creates a message with a Result payload, similar to the XmlPayloadMarshallingTransformer. You can customize this by providing a ResultFactory or a ResultTransformer.

The following example configures a bean that works as an XSLT payload transformer:

Starting with Spring Integration 3.0, you can specify the transformer factory class name by using a constructor argument. You can do so by using the transformer-factory-class attribute when you use the namespace.

Both the MarshallingTransformer and the XsltPayloadTransformer let you specify a ResultTransformer. Thus, if the marshalling or XSLT transformation returns a Result, you have the option to also use a ResultTransformer to transform the Result into another format. Spring Integration provides two concrete ResultTransformer implementations:

By default, the MarshallingTransformer always returns a Result. By specifying a ResultTransformer, you can customize the type of payload returned.

The behavior is slightly more complex for the XsltPayloadTransformer. By default, if the input payload is an instance of String or Document the resultTransformer property is ignored.

However, if the input payload is a Source or any other type, the resultTransformer property is applied. Additionally, you can set the alwaysUseResultFactory property to true, which also causes the specified resultTransformer to be used.

For more information and examples, see Namespace Configuration and Result Transformers.

The namespace support for the UnmarshallingTransformer is shown below. Since the namespace create an endpoint instance rather than a transformer, you can nest a poller within the element to control the polling of the input channel. The following example shows how to do so:

The namespace support for the marshalling transformer requires an input-channel, an output-channel, and a reference to a marshaller. You can use the optional result-type attribute to control the type of result created. Valid values are StringResult or DomResult (the default). The following example configures a marshalling transformer:

Where the provided result types do not suffice, you can provide a reference to a custom implementation of ResultFactory as an alternative to setting the result-type attribute by using the result-factory attribute. The result-type and result-factory attributes are mutually exclusive.

Namespace support for the XsltPayloadTransformer lets you either pass in a Resource (in order to create the Templates instance) or pass in a pre-created Templates instance as a reference. As with the marshalling transformer, you can control the type of the result output by specifying either the result-factory or the result-type attribute. When you need to convert result before sending, you can use a result-transformer attribute to reference an implementation of ResultTransformer.

The following example configures two XSLT transformers:

You may need to have access to Message data, such as the Message headers, in order to assist with transformation. For example, you may need to get access to certain Message headers and pass them on as parameters to a transformer (for example, transformer.setParameter(..)). Spring Integration provides two convenient ways to accomplish this, as the following example shows:

If message header names match one-to-one to parameter names, you can use the xslt-param-headers attribute. In it, you can use wildcards for simple pattern matching. It supports the following simple pattern styles: xxx*, xxx, *xxx, and xxx*yyy.

You can also configure individual XSLT parameters by using the <xslt-param/> element. On that element, you can set the expression attribute or the value attribute. The expression attribute should be any valid SpEL expression with the Message being the root object of the expression evaluation context. The value attribute (as with any value in Spring beans) lets you specify simple scalar values. You can also use property placeholders (such as ${some.value}). So, with the expression and value attributes, you can map XSLT parameters to any accessible part of the Message as well as any literal value.

Starting with Spring Integration 3.0, you can now specify the transformer factory class name by setting the transformer-factory-class attribute.

<xsl:output method="text"/> tells the XSLT template to produce only text content from the input source. In this particular case, we have no reason to use a DomResult. Therefore, the XsltPayloadTransformer defaults to StringResult if the output property called method of the underlying javax.xml.transform.Transformer returns text. This coercion is performed independently from the inbound payload type. This behavior is available only you set the if the result-type attribute or the result-factory attribute for the <int-xml:xslt-transformer> component.