diff --git a/spring-integration-reference/src/xml.xml b/spring-integration-reference/src/xml.xml index 528ea362a1..eb4fc1123b 100644 --- a/spring-integration-reference/src/xml.xml +++ b/spring-integration-reference/src/xml.xml @@ -8,27 +8,39 @@ Spring Integration XML extends the Spring Integration Core with implementations of splitter, transformer, selector and routers designed - to make working with XML in Spring Integration simple. The provided messaging - components are designed to work with XML represented in a range of formats including + 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 - + and javax.xml.transform.Source. It should be noted however that + where a Document or Node 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 which may incur significant + computational cost. Components that require an instance of + DocumentBuilder 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 DocumentBuilder should be provided.
- Transforming XML payloads + Transforming xml payloads This section will explain the workings of XmlPayloadUnmarshallingTransformer, XmlPayloadMarshallingTransformer XsltPayloadTransformer and how to configure them as - beans. - Also how to customise which implementation of - javax.xml.transfrom.Source - and javax.xml.Result - Finally the namespace support will be discussed. + beans. All of the provided xml transformers extend + 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 + MessageTransformingConsumer in order to connect the transformer instance to + a channel. + Finally the namespace support will be discussed which allows simple configuration of the transformers as consumers. + + + XmlPayloadUnmarshallingTransformer allows an XML Source @@ -53,12 +65,12 @@ The XmlPayloadMarshallingTransformer allows an Object graph to be - converted into XML using a Spring OXM Marshaller. + converted into xml using a Spring OXM Marshaller. By default the XmlPayloadMarshallingTransformer will return a DomResult. However this 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 + 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 @@ -73,7 +85,7 @@ ]]> - XsltPayloadTransformer transforms XML payloads using XSL. + XsltPayloadTransformer transforms xml payloads using XSL. The transformer requires an instance of either Resource or Templates. Passing in a Templates allows for greater configuration of the Transformer used to create @@ -81,8 +93,7 @@ XmlPayloadMarshallingTransformer by default XsltPayloadTransformer will create a message with a Result payload. This can be customised by providing a ResultFactory and or a ResultTransformer. - - + @@ -90,54 +101,167 @@ ]]> - Namespace support for all these transformers is provided in the Sprint Integration XML namespace - a template for which is below. The namespace support creates an instance of either SubscribingConsumerEndpoint - or PollingConsumerEndpoint 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. + Namespace support for all these transformers is provided in the Sprint Integration xml namespace + a template for which can be seen below. The namespace support creates an instance of either + SubscribingConsumerEndpoint or PollingConsumerEndpoint + 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. + 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-2.5.xsd + http://www.springframework.org/schema/integration + http://www.springframework.org/schema/integration/spring-integration-1.0.xsd + http://www.springframework.org/schema/integration/xml + http://www.springframework.org/schema/integration/xml/spring-integration-xml-1.0.xsd"> ]]> So for example an XmlPayloadMarshallingTransformer can be configured as below. ]]> + input-channel="input" + output-channel="output" + unmarshaller="unmarshaller"/>]]> + + + The namespace support for the marshalling transformer allows creation of an endpoint ]]> + input-channel="marshallingTransformerStringResultFactory" + output-channel="output" + marshaller="marshaller" + result-type="StringResult" /> + + + +]]> + + + + + ]]> + +
+ +
+ Splitting xml messages + + XPathMessageSplitter support 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 MessageConsumer and should + therefore be configured in conjunction with an appropriate endpoint. + + + + + + + + + +]]>
- -
- Routing XML payloads using XPath - - - -
-
- Splitting XML payloads using XPath +
+ Routing xml messages using XPath + Two Router implementations based on XPath are provided XPathSingleChannelRouter and + XPathMultiChannelRouter. The implementations differ in respect of how many channels + any given message may be routed to, exactly one in the case of the single channel version + or zero or more in the case of the multichannel router. Both evaluate an XPath + expression against the xml payload of the message, supported payload types by default + are Node, Document and + String. For other payload types a custom implementation + of XmlPayloadConverter can be provided. The router + implementations use ChannelNameResolver to convert the + result(s) of the XPath expression to a channel name. By default a + BeanFactoryChannelName meaning that the string returned by the XPath + evaluation should correspond directly to the name of a channel. Where this is not the case + an alternative implementation of ChannelNameResolver can + be used, where there is a simple mapping from Xpath result to channel name + the provided MapBasedChannelName can be used. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]]> -
- Splitting XML payloads using XPath + Selecting xml messages use XPath + Two MessageSelector implementations are provided + BooleanTestXPathMessageSelector and + StringValueTestXPathMessageSelector. + BooleanTestXPathMessageSelector requires an XPathExpression which + evaluates to a boolean, for example boolean(/one/two) which will only + select messages which have an element named two which is a child of a root element named one. + StringValueTestXPathMessageSelector evaluates any XPath expression as + a Stringand compares the result with the provided + String value. + + + + + + + + + + + + + + + + + + + +]]>