Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

#INT-1967 Standardize namespace pre-fixes in documentation

Browse Source
This commit is contained in:
Gunnar Hillert
2011-07-31 15:28:21 -04:00
parent 78c479eb05
commit 3887f55055
36 changed files with 415 additions and 411 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@@ -20,3 +20,4 @@ spring-integration-jms/activemq-data/
spring-integration-samples/loanshark/application.log*
target
build.log
.DS_Store

14
docs/src/reference/docbook/bridge.xml
View File

@@ -31,22 +31,22 @@
<para>
The &lt;bridge&gt; element is used to create a Messaging Bridge between two Message Channels or Channel Adapters.
Simply provide the "input-channel" and "output-channel" attributes:
<programlisting language="xml"><![CDATA[ <bridge input-channel="input" output-channel="output"/>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int:bridge input-channel="input" output-channel="output"/>]]></programlisting>
As mentioned above, a common use case for the Messaging Bridge is to connect a
<interfacename>PollableChannel</interfacename> to a <interfacename>SubscribableChannel</interfacename>, and when
performing this role, the Messaging Bridge may also serve as a throttler:
<programlisting language="xml"><![CDATA[ <bridge input-channel="pollable" output-channel="subscribable">
<poller max-messages-per-poll="10" fixed-rate="5000"/>
</bridge>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int:bridge input-channel="pollable" output-channel="subscribable">
<int:poller max-messages-per-poll="10" fixed-rate="5000"/>
</int:bridge>]]></programlisting>
</para>
<para>
Connecting Channel Adapters is just as easy. Here is a simple echo example between the "stdin" and "stdout"
adapters from Spring Integration's "stream" namespace.
<programlisting language="xml"><![CDATA[ <stream:stdin-channel-adapter id="stdin"/>
<programlisting language="xml"><![CDATA[ <int-stream:stdin-channel-adapter id="stdin"/>
<stream:stdout-channel-adapter id="stdout"/>
<int-stream:stdout-channel-adapter id="stdout"/>
<bridge id="echo" input-channel="stdin" output-channel="stdout"/>]]></programlisting>
<int:bridge id="echo" input-channel="stdin" output-channel="stdout"/>]]></programlisting>
Of course, the configuration would be similar for other (potentially more useful) Channel Adapter bridges, such
as File to JMS, or Mail to File. The various Channel Adapters will be discussed in upcoming chapters.
</para>

60
docs/src/reference/docbook/chain.xml
View File

@@ -58,13 +58,13 @@
The &lt;chain&gt; element provides an <code>input-channel</code> attribute, and if the last element in the chain is capable
of producing reply messages (optional), it also supports an <code>output-channel</code> attribute. The sub-elements are then
filters, transformers, splitters, and service-activators. The last element may also be a router.
<programlisting language="xml"><![CDATA[ <chain input-channel="input" output-channel="output">
<filter ref="someSelector" throw-exception-on-rejection="true"/>
<header-enricher>
<header name="foo" value="bar"/>
</header-enricher>
<service-activator ref="someService" method="someMethod"/>
</chain>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int:chain input-channel="input" output-channel="output">
<int:filter ref="someSelector" throw-exception-on-rejection="true"/>
<int:header-enricher>
<int:header name="foo" value="bar"/>
</int:header-enricher>
<int:service-activator ref="someService" method="someMethod"/>
</int:chain>]]></programlisting>
</para>
<para>
The &lt;header-enricher&gt; element used in the above example will set a message header named "foo" with a value
@@ -78,34 +78,34 @@
back and continue execution within the original chain.
To accomplish this you can utilize a Messaging Gateway by including a &lt;gateway&gt; element.
For example:
<programlisting language="xml"><![CDATA[ <si:chain id="main-chain" input-channel="in" output-channel="out">
<si:header-enricher>
<si:header name="name" value="Many" />
</si:header-enricher>
<si:service-activator>
<programlisting language="xml"><![CDATA[ <int:chain id="main-chain" input-channel="in" output-channel="out">
<int:header-enricher>
<int:header name="name" value="Many" />
</int:header-enricher>
<int:service-activator>
<bean class="org.foo.SampleService" />
</si:service-activator>
<si:gateway request-channel="inputA"/>  
</si:chain>
</int:service-activator>
<int:gateway request-channel="inputA"/>  
</int:chain>
<si:chain id="nested-chain-a" input-channel="inputA">
<si:header-enricher>
<si:header name="name" value="Moe" />
</si:header-enricher>
<si:gateway request-channel="inputB"/> 
<si:service-activator>
<int:chain id="nested-chain-a" input-channel="inputA">
<int:header-enricher>
<int:header name="name" value="Moe" />
</int:header-enricher>
<int:gateway request-channel="inputB"/> 
<int:service-activator>
<bean class="org.foo.SampleService" />
</si:service-activator>
</si:chain>
</int:service-activator>
</int:chain>
<si:chain id="nested-chain-b" input-channel="inputB">
<si:header-enricher>
<si:header name="name" value="Jack" />
</si:header-enricher>
<si:service-activator>
<int:chain id="nested-chain-b" input-channel="inputB">
<int:header-enricher>
<int:header name="name" value="Jack" />
</int:header-enricher>
<int:service-activator>
<bean class="org.foo.SampleService" />
</si:service-activator>
</si:chain>]]></programlisting>
</int:service-activator>
</int:chain>]]></programlisting>
In the above example the <emphasis>nested-chain-a</emphasis> will be called at the end of
<emphasis>main-chain</emphasis> processing by the 'gateway' element configured there. While in

32
docs/src/reference/docbook/channel-adapter.xml
View File

@@ -21,13 +21,13 @@
poller will be scheduled with the <interfacename>TaskScheduler</interfacename> according to the provided
configuration. To configure the polling interval or cron expression for an individual channel-adapter,
provide a 'poller' element with one of the scheduling attributes, such as 'fixed-rate' or 'cron'.
<programlisting language="xml"><![CDATA[<inbound-channel-adapter ref="source1" method="method1" channel="channel1">
<poller fixed-rate="5000"/>
</inbound-channel-adapter>
<programlisting language="xml"><![CDATA[<int:inbound-channel-adapter ref="source1" method="method1" channel="channel1">
<int:poller fixed-rate="5000"/>
</int:inbound-channel-adapter>
<inbound-channel-adapter ref="source2" method="method2" channel="channel2">
<poller cron="30 * 9-17 * * MON-FRI"/>
</channel-adapter>]]></programlisting>
<int:inbound-channel-adapter ref="source2" method="method2" channel="channel2">
<int:poller cron="30 * 9-17 * * MON-FRI"/>
</int:channel-adapter>]]></programlisting>
</para>
<note>
<para>
@@ -45,16 +45,16 @@
</para>
<para>For example:
<programlisting language="xml"><![CDATA[<poller max-messages-per-poll="1" fixed-rate="1000"/>
<programlisting language="xml"><![CDATA[<int:poller max-messages-per-poll="1" fixed-rate="1000"/>
<poller max-messages-per-poll="10" fixed-rate="1000"/>]]></programlisting>
<int:poller max-messages-per-poll="10" fixed-rate="1000"/>]]></programlisting>
In the the first configuration the polling task will be invoked once per poll and during such task (poll)
the method (which results in the production of the Message) will be invoked once based on the
<code>max-messages-per-poll</code> attribute value. In the second configuration the polling task will be invoked
10 times per poll or until it returns 'null' thus possibly producing 10 Messages per poll while each poll happens
at 1 second intervals.
However what if the configuration looks like this:
<programlisting language="xml"><![CDATA[<poller fixed-rate="1000"/>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:poller fixed-rate="1000"/>]]></programlisting>
Note there is no <code>max-messages-per-poll</code> specified. As you'll learn later the identical poller configuration
in the <classname>PollingConsumer</classname> (e.g., service-activator, filter, router etc.) would have a default
value of -1 for <code>max-messages-per-poll</code> which means "execute poling task non-stop unless polling method
@@ -71,7 +71,7 @@
However if you are sure that your method can return null and you need the behavior where you want to poll
for as many sources as available per each poll, then you should explicitly set <code>max-messages-per-poll</code>
to negative value.
<programlisting language="xml"><![CDATA[<poller max-messages-per-poll="-1" fixed-rate="1000"/>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:poller max-messages-per-poll="-1" fixed-rate="1000"/>]]></programlisting>
</para>
@@ -83,16 +83,16 @@
<para>
An "outbound-channel-adapter" element can also connect a <interfacename>MessageChannel</interfacename> to any POJO consumer
method that should be invoked with the payload of Messages sent to that channel.
<programlisting language="xml"><![CDATA[<outbound-channel-adapter channel="channel1" ref="target" method="handle"/>
<programlisting language="xml"><![CDATA[<int:outbound-channel-adapter channel="channel1" ref="target" method="handle"/>
<beans:bean id="target" class="org.Foo"/>]]>
</programlisting>
If the channel being adapted is a <interfacename>PollableChannel</interfacename>, provide a poller sub-element:
<programlisting language="xml"><![CDATA[<outbound-channel-adapter channel="channel2" ref="target" method="handle">
]]><emphasis><![CDATA[<poller fixed-rate="3000"/>
<programlisting language="xml"><![CDATA[<int:outbound-channel-adapter channel="channel2" ref="target" method="handle">
]]><emphasis><![CDATA[<int:poller fixed-rate="3000"/>
]]></emphasis><![CDATA[
</outbound-channel-adapter>
</int:outbound-channel-adapter>
<beans:bean id="target" class="org.Foo"/>
]]></programlisting>
@@ -102,10 +102,10 @@
in other <code>&lt;outbound-channel-adapter&gt;</code> definitions. However if the consumer implementation
is only referenced by a single definition of the <code>&lt;outbound-channel-adapter&gt;</code>, you
can define it as inner bean:
<programlisting language="xml"><![CDATA[<outbound-channel-adapter channel="channel" method="handle">
<programlisting language="xml"><![CDATA[<int:outbound-channel-adapter channel="channel" method="handle">
<beans:bean class="org.Foo"/>
]]><![CDATA[
</outbound-channel-adapter>
</int:outbound-channel-adapter>
]]></programlisting>
</para>
<note>

4
docs/src/reference/docbook/claim-check.xml
View File

@@ -59,7 +59,7 @@
<para>
An <emphasis>Outgoing Claim Check Transformer</emphasis> allows you to transform a Message with a Claim Check payload
into a Message with the original content as its payload.
<programlisting language="xml"><![CDATA[<claim-check-out id="checkout"
<programlisting language="xml"><![CDATA[<int:claim-check-out id="checkout"
input-channel="checkoutChannel"
message-store="testMessageStore"
output-channel="output"/>]]></programlisting>
@@ -80,7 +80,7 @@
especially in the case of the in-memory Map-based <classname>SimpleMessageStore</classname> where failing to remove the Messages
could ultimately lead to an <classname>OutOfMemoryException</classname>. If you don't expect multiple claims to be made, it's
recommended that you set the <code>remove-message</code> attribute's value to <code>false</code>.
<programlisting language="xml"><![CDATA[<claim-check-out id="checkout"
<programlisting language="xml"><![CDATA[<int:claim-check-out id="checkout"
input-channel="checkoutChannel"
message-store="testMessageStore"
output-channel="output"

30
docs/src/reference/docbook/configuration.xml
View File

@@ -28,14 +28,14 @@
namespace reference and schema mapping in your top-level 'beans' element:
<programlisting language="xml"><![CDATA[<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
]]><emphasis>xmlns:integration="http://www.springframework.org/schema/integration"</emphasis><![CDATA[
]]><emphasis>xmlns:int="http://www.springframework.org/schema/integration"</emphasis><![CDATA[
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
]]><emphasis>http://www.springframework.org/schema/integration
http://www.springframework.org/schema/integration/spring-integration-2.0.xsd"</emphasis>&gt;</programlisting>
</para>
<para>
You can choose any name after "xmlns:"; <emphasis>integration</emphasis> is used here for clarity, but you might
You can choose any name after "xmlns:"; <emphasis>int</emphasis> is used here for clarity, but you might
prefer a shorter abbreviation. Of course if you are using an XML-editor or IDE support, then the availability of
auto-completion may convince you to keep the longer name for clarity. Alternatively, you can create configuration
files that use the Spring Integration schema as the primary namespace:
@@ -64,12 +64,12 @@
<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:file="http://www.springframework.org/schema/integration/file"
xmlns:jms="http://www.springframework.org/schema/integration/jms"
xmlns:mail="http://www.springframework.org/schema/integration/mail"
xmlns:rmi="http://www.springframework.org/schema/integration/rmi"
xmlns:ws="http://www.springframework.org/schema/integration/ws"
xmlns:int="http://www.springframework.org/schema/integration"
xmlns:int-file="http://www.springframework.org/schema/integration/file"
xmlns:int-jms="http://www.springframework.org/schema/integration/jms"
xmlns:int-mail="http://www.springframework.org/schema/integration/mail"
xmlns:int-rmi="http://www.springframework.org/schema/integration/rmi"
xmlns:int-ws="http://www.springframework.org/schema/integration/ws"
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
@@ -159,9 +159,9 @@
Whenever relying on Spring Integration's XML namespace support, a default "errorChannel" bean will be
created behind the scenes. However, you can just as easily define your own if you want to control the
settings.
<programlisting language="xml"><![CDATA[ <channel id="errorChannel">
<queue capacity="500"/>
</channel>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int:channel id="errorChannel">
<int:queue capacity="500"/>
</int:channel>]]></programlisting>
<note>
The default "errorChannel" is a PublishSubscribeChannel.
</note>
@@ -438,9 +438,9 @@ Below are some of the examples of ambiguous conditions which result in an Except
could be mapped to 'str'  and Message Headers could be mapped to 'm'. The second method could easily also be a candidate where
only Message Headers are mapped to 'm'. To make meters worse both methods have the same name which at first might look very
ambiguous considering the following configuration:</para>
<programlisting language="xml"><![CDATA[<si:service-activator input-channel="input" output-channel="output" method="foo">
<programlisting language="xml"><![CDATA[<int:service-activator input-channel="input" output-channel="output" method="foo">
<bean class="org.bar.Foo"/>
</si:service-activator>]]></programlisting>
</int:service-activator>]]></programlisting>
<para>At this point it would be important to understand Spring Integration mapping Conventions where at the very core,
mappings are based on Payload first and everything else next. In other words the method whose argument could be mapped
to a Payload will take precedence over all other methods.</para>
@@ -460,9 +460,9 @@ However if the method names were different you could influence the mapping with
public String bar(String str);
}</programlisting>
<programlisting language="xml"><![CDATA[<si:service-activator input-channel="input" output-channel="output" method="bar">
<programlisting language="xml"><![CDATA[<int:service-activator input-channel="input" output-channel="output" method="bar">
<bean class="org.bar.Foo"/>
</si:service-activator>]]></programlisting>
</int:service-activator>]]></programlisting>
<para>Now there is no ambiguity since the configuration explicitly maps to the 'bar' method which has no name conflicts.</para>
</section>

2
docs/src/reference/docbook/control-bus.xml
View File

@@ -14,7 +14,7 @@
Integration we build upon the adapters described above so that it's possible
to send Messages as a means of invoking exposed operations.</para>
<programlisting language="xml">&lt;control-bus input-channel="operationChannel"/&gt;</programlisting>
<programlisting language="xml">&lt;int:control-bus input-channel="operationChannel"/&gt;</programlisting>
<para>The Control Bus has an input channel that can be accessed for invoking
operations on the beans in the application context. It also has all the

6
docs/src/reference/docbook/delayer.xml
View File

@@ -23,10 +23,10 @@
As with the other endpoints, you can provide the "input-channel" and "output-channel" attributes,
but the delayer also requires at least the 'default-delay' attribute with the number of milliseconds
that each Message should be delayed.
<programlisting language="xml"><![CDATA[ <delayer input-channel="input" default-delay="3000" output-channel="output"/>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int:delayer input-channel="input" default-delay="3000" output-channel="output"/>]]></programlisting>
If you need per-Message determination of the delay, then you can also provide the name of a header
within the 'delay-header-name' attribute:
<programlisting language="xml"><![CDATA[ <delayer input-channel="input" output-channel="output"
<programlisting language="xml"><![CDATA[ <int:delayer input-channel="input" output-channel="output"
default-delay="3000" delay-header-name="delay"/>]]></programlisting>
In the example above the 3 second delay would only apply in the case that the header value is
not present for a given inbound Message. If you only want to apply a delay to Messages that have
@@ -50,7 +50,7 @@
The default scheduler used by the delayer is a <classname>ThreadPoolTaskScheduler</classname> instance with a pool size of 1.
If you want to delegate to a different scheduler, you can provide a reference through the delayer element's
'scheduler' attribute:
<programlisting language="xml"><![CDATA[ <delayer input-channel="input" output-channel="output"
<programlisting language="xml"><![CDATA[ <int:delayer input-channel="input" output-channel="output"
default-delay="0" delay-header-name="delay"
scheduler="exampleTaskScheduler"/>

66
docs/src/reference/docbook/endpoint.xml
View File

@@ -166,20 +166,20 @@ consumer.setTransactionManager(txManager);</programlisting>
referenced: <interfacename>PollableChannel</interfacename> or <interfacename>SubscribableChannel</interfacename>
respectively. When the channel is pollable, then the polling behavior is determined based on the endpoint
element's "poller" sub-element and its attributes. For example, a simple interval-based poller with a 1-second interval would be
configured like this: <programlisting language="xml"><![CDATA[ <transformer input-channel="pollable"
configured like this: <programlisting language="xml"><![CDATA[ <int:transformer input-channel="pollable"
ref="transformer"
output-channel="output">
<poller fixed-rate="1000"/>
</transformer>]]></programlisting>
<int:poller fixed-rate="1000"/>
</int:transformer>]]></programlisting>
As an alternative to 'fixed-rate' you can also use the 'fixed-delay' attribute.
</para>
<para>
For a poller based on a Cron expression, use the "cron" attribute instead:
<programlisting language="xml"><![CDATA[ <transformer input-channel="pollable"
<programlisting language="xml"><![CDATA[ <int:transformer input-channel="pollable"
ref="transformer"
output-channel="output">
<poller cron="*/10 * * * * MON-FRI"/>
</transformer>]]></programlisting>
<int:poller cron="*/10 * * * * MON-FRI"/>
</int:transformer>]]></programlisting>
</para>
<para>
If the input channel is a <interfacename>PollableChannel</interfacename>, then the poller configuration is
@@ -190,13 +190,13 @@ consumer.setTransactionManager(txManager);</programlisting>
</para>
<para>
It is also possible to create top-level pollers in which case only a "ref" is required:
<programlisting language="xml"><![CDATA[ <poller id="weekdayPoller" cron="*/10 * * * * MON-FRI"/>
<programlisting language="xml"><![CDATA[ <int:poller id="weekdayPoller" cron="*/10 * * * * MON-FRI"/>
<transformer input-channel="pollable"
<int:transformer input-channel="pollable"
ref="transformer"
output-channel="output">
<poller ref="weekdayPoller"/>
</transformer>]]></programlisting>
<int:poller ref="weekdayPoller"/>
</int:transformer>]]></programlisting>
<note>
The "ref" attribute is only allowed on the inner-poller definitions. Defining this attribute on a top-level
poller will result in a configuration exception thrown during initialization of the Application Context.
@@ -205,25 +205,25 @@ consumer.setTransactionManager(txManager);</programlisting>
an ApplicationContext may have the <code>default</code> attribute with a value of "true". In that case, any
endpoint with a PollableChannel for its input-channel that is defined within the same ApplicationContext and has
no explicitly configured 'poller' sub-element will use that default.
<programlisting language="xml"><![CDATA[ <poller id="defaultPoller" default="true" max-messages-per-poll="5" fixed-rate="3000"/>
<programlisting language="xml"><![CDATA[ <int:poller id="defaultPoller" default="true" max-messages-per-poll="5" fixed-rate="3000"/>
<!-- No <poller/> sub-element is necessary since there is a default -->
<transformer input-channel="pollable"
ref="transformer"
output-channel="output"/>]]></programlisting>
<int:transformer input-channel="pollable"
ref="transformer"
output-channel="output"/>]]></programlisting>
</para>
<para>
Spring Integration also provides transaction support for the pollers so that each receive-and-forward
operation can be performed as an atomic unit-of-work. To configure transactions for a poller, simply add the
&lt;transactional/&gt; sub-element. The attributes for this element should be familiar to anyone who has
experience with Spring's Transaction management:
<programlisting language="xml"><![CDATA[<poller fixed-delay="1000">
<transactional transaction-manager="txManager"
propagation="REQUIRED"
isolation="REPEATABLE_READ"
timeout="10000"
read-only="false"/>
</poller>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:poller fixed-delay="1000">
<int:transactional transaction-manager="txManager"
propagation="REQUIRED"
isolation="REPEATABLE_READ"
timeout="10000"
read-only="false"/>
</int:poller>]]></programlisting>
</para>
<para>
@@ -234,16 +234,16 @@ consumer.setTransactionManager(txManager);</programlisting>
behavior of the message flow initiated by the poler, some times there is a need to provide extra Advice(s) to handle other
cross cutting behavior associated with the poller. For that poller defines an 'advice-chain' element allowing you to add
more advices - class that  implements <classname>MethodInterceptor</classname> interface.. 
<programlisting language="xml"><![CDATA[<service-activator id="advicedSa" input-channel="goodInputWithAdvice" ref="testBean"
<programlisting language="xml"><![CDATA[<int:service-activator id="advicedSa" input-channel="goodInputWithAdvice" ref="testBean"
method="good" output-channel="output">
<poller max-messages-per-poll="1" fixed-rate="10000">
<transactional transaction-manager="txManager" />
<advice-chain>
<int:poller max-messages-per-poll="1" fixed-rate="10000">
<int:transactional transaction-manager="txManager" />
<int:advice-chain>
<ref bean="adviceA" />
<beans:bean class="org.bar.SampleAdvice"/>
</advice-chain>
</poller>
</service-activator>]]></programlisting>
</int:advice-chain>
</int:poller>
</int:service-activator>]]></programlisting>
For more information on how to implement MethodInterceptor please refer to AOP sections of Spring
reference manual (section 7 and 8). Advice chain can also be applied on the poller that does not have
any transaction configuration essentially allowing you to enhance the behavior of the message flow initiated by the poller.
@@ -258,7 +258,7 @@ any transaction configuration essentially allowing you to enhance the behavior o
(the other major factor being the expected volume on the channel to which the endpoint subscribes). To enable
concurrency for a polling endpoint that is configured with the XML namespace support, provide the 'task-executor'
reference on its &lt;poller/&gt; element and then provide one or more of the properties shown below:
<programlisting language="xml"><![CDATA[ <poller task-executor="pool" fixed-rate="1000"/>
<programlisting language="xml"><![CDATA[ <int:poller task-executor="pool" fixed-rate="1000"/>
<task:executor id="pool"
pool-size="5-25"
@@ -280,11 +280,11 @@ any transaction configuration essentially allowing you to enhance the behavior o
hand when using Spring Integration's own queue-based channels, the timeout value does have a chance to
participate. The following example demonstrates how a Polling Consumer will receive Messages nearly
instantaneously.
<programlisting language="xml"><![CDATA[ <service-activator input-channel="someQueueChannel"
<programlisting language="xml"><![CDATA[ <int:service-activator input-channel="someQueueChannel"
output-channel="output">
<poller receive-timeout="30000" fixed-rate="10"/>
<int:poller receive-timeout="30000" fixed-rate="10"/>
</service-activator>]]></programlisting>
</int:service-activator>]]></programlisting>
Using this approach does not carry much overhead since internally it is nothing more then a timed-wait thread
which does not require nearly as much CPU resource usage as a thrashing, infinite while loop for example.
</para>
@@ -333,7 +333,7 @@ any transaction configuration essentially allowing you to enhance the behavior o
<programlisting language="xml"><![CDATA[<int:service-activator input-channel="publishChannel" ref="myService">
<int:poller receive-timeout="5000" task-executor="taskExecutor" fixed-rate="50"/>
</si:service-activator>
</int:service-activator>
<task:executor id="taskExecutor" pool-size="20" queue-capacity="20"/>]]></programlisting>

20
docs/src/reference/docbook/filter.xml
View File

@@ -36,7 +36,7 @@
The &lt;filter&gt; element is used to create a Message-selecting endpoint. In addition to "<code>input-channel</code>
and <code>output-channel</code> attributes, it requires a <code>ref</code>. The <code>ref</code> may point to a
<interfacename>MessageSelector</interfacename> implementation:
<programlisting language="xml"><![CDATA[ <filter input-channel="input" ref="selector" output-channel="output"/>
<programlisting language="xml"><![CDATA[ <int:filter input-channel="input" ref="selector" output-channel="output"/>
<bean id="selector" class="example.MessageSelectorImpl"/>]]></programlisting>
</para>
@@ -45,7 +45,7 @@
The referenced method may expect either the <interfacename>Message</interfacename> type or the payload type of
inbound Messages. The method must return a boolean value. If the method returns 'true',
the Message <emphasis>will</emphasis> be sent to the output-channel.
<programlisting language="xml"><![CDATA[ <filter input-channel="input" output-channel="output"
<programlisting language="xml"><![CDATA[ <int:filter input-channel="input" output-channel="output"
ref="exampleObject" method="someBooleanReturningMethod"/>
<bean id="exampleObject" class="example.SomeObject"/>]]></programlisting>
@@ -55,10 +55,10 @@
handling of the rejected Message. By default (if configured like the example above), rejected Messages will
be silently dropped. If rejection should instead result in an error condition, then set the
<code>throw-exception-on-rejection</code> attribute to <code>true</code>:
<programlisting language="xml"><![CDATA[ <filter input-channel="input" ref="selector"
<programlisting language="xml"><![CDATA[ <int:filter input-channel="input" ref="selector"
output-channel="output" throw-exception-on-rejection="true"/> ]]></programlisting>
If you want rejected messages to be routed to a specific channel, provide that reference as the <code>discard-channel</code>:
<programlisting language="xml"><![CDATA[ <filter input-channel="input" ref="selector"
<programlisting language="xml"><![CDATA[ <int:filter input-channel="input" ref="selector"
output-channel="output" discard-channel="rejectedMessages"/> ]]></programlisting>
</para>
<note>
@@ -72,7 +72,7 @@
Using a <code>ref</code> attribute is generally recommended if the custom filter implementation is referenced in other
<code>&lt;filter&gt;</code> definitions. However if the custom filter implementation is scoped to a
single <code>&lt;filter&gt;</code> element, provide an inner bean definition:
<programlisting language="xml"><![CDATA[<filter method="someMethod" input-channel="inChannel" output-channel="outChannel">
<programlisting language="xml"><![CDATA[<int:filter method="someMethod" input-channel="inChannel" output-channel="outChannel">
<beans:bean class="org.foo.MyCustomFilter"/>
</filter>]]></programlisting>
</para>
@@ -86,7 +86,7 @@
With the introduction of SpEL support, Spring Integration added the <code>expression</code> attribute to the filter
element. It can be used to avoid Java entirely for simple filters.
<programlisting language="xml">
<![CDATA[<filter input-channel="input" expression="payload.equals('nonsense')"/>]]>
<![CDATA[<int:filter input-channel="input" expression="payload.equals('nonsense')"/>]]>
</programlisting>
The string passed as the expression attribute will be evaluated as a SpEL expression with the Message available in
the evaluation context.
@@ -96,7 +96,7 @@
SpEL reference documentation
</ulink>.
<programlisting language="xml">
<![CDATA[<filter input-channel="input" expression="payload.matches(#{filterPatterns.nonsensePattern})"/>]]>
<![CDATA[<int:filter input-channel="input" expression="payload.matches(#{filterPatterns.nonsensePattern})"/>]]>
</programlisting>
If the Expression itself needs to be dynamic, then an 'expression' sub-element may be used. That provides a level of
indirection for resolving the Expression by its key from an ExpressionSource. That is a strategy interface that you
@@ -107,9 +107,9 @@
<code>source</code> attribute on the &lt;expression&gt; element, but in this case it's shown for completeness.
<programlisting language="xml">
<![CDATA[
<filter input-channel="input" output-channel="output">
<expression key="filterPatterns.example" source="myExpressions"/>
</filter>
<int:filter input-channel="input" output-channel="output">
<int:expression key="filterPatterns.example" source="myExpressions"/>
</int:filter>
<beans:bean id="myExpressions" id="myExpressions"
class="org.springframework.integration.expression.ReloadableResourceBundleExpressionSource">

2
docs/src/reference/docbook/ftp.xml
View File

@@ -24,7 +24,7 @@
</para>
<para>
To use the <emphasis>FTP</emphasis> namespace, add the following to the header of your XML file:
<programlisting language="xml"><![CDATA[xmlns:ftp="http://www.springframework.org/schema/integration/ftp"
<programlisting language="xml"><![CDATA[xmlns:int-ftp="http://www.springframework.org/schema/integration/ftp"
xsi:schemaLocation="http://www.springframework.org/schema/integration/ftp
http://www.springframework.org/schema/integration/ftp/spring-integration-ftp-2.0.xsd"
]]></programlisting>

16
docs/src/reference/docbook/gateway.xml
View File

@@ -22,7 +22,7 @@ public interface Cafe {
Namespace support is also
provided which allows you to configure such an interface as a service as demonstrated by the following example.
<programlisting language="xml"><![CDATA[<gateway id="cafeService"
<programlisting language="xml"><![CDATA[<int:gateway id="cafeService"
service-interface="org.cafeteria.Cafe"
default-request-channel="requestChannel"
default-reply-channel="replyChannel"/>]]></programlisting>
@@ -82,12 +82,12 @@ public interface Cafe {
<para>
If you prefer the XML approach of configuring Gateway methods, you can provide <emphasis>method</emphasis> sub-elements
to the gateway configuration.
<programlisting language="xml"><![CDATA[<si:gateway id="myGateway" service-interface="org.foo.bar.TestGateway"
<programlisting language="xml"><![CDATA[<int:gateway id="myGateway" service-interface="org.foo.bar.TestGateway"
default-request-channel="inputC">
<si:method name="echo" request-channel="inputA" reply-timeout="2" request-timeout="200"/>
<si:method name="echoUpperCase" request-channel="inputB"/>
<si:method name="echoViaDefault"/>
</si:gateway>]]></programlisting>
<int:method name="echo" request-channel="inputA" reply-timeout="2" request-timeout="200"/>
<int:method name="echoUpperCase" request-channel="inputB"/>
<int:method name="echoViaDefault"/>
</int:gateway>]]></programlisting>
</para>
<para>
You can also provide individual headers per method invocation via XML.
@@ -123,12 +123,12 @@ public interface Cafe {
that a 'transformer' is used to create a reply Message from the Exception.
</para>
<para>
<programlisting language="xml"><![CDATA[<si:gateway id="sampleGateway"
<programlisting language="xml"><![CDATA[<int:gateway id="sampleGateway"
default-request-channel="gatewayChannel"
service-interface="foo.bar.SimpleGateway"
error-channel="exceptionTransformationChannel"/>
<si:transformer input-channel="exceptionTransformationChannel"
<int:transformer input-channel="exceptionTransformationChannel"
ref="exceptionTransformer" method="createErrorResponse"/>
]]></programlisting>

32
docs/src/reference/docbook/groovy.xml
View File

@@ -29,15 +29,15 @@
write a script that uses those
variables. Below are a couple of sample configurations:</para>
<para><emphasis>Filter</emphasis> <programlisting language="xml">&lt;filter input-channel="referencedScriptInput"&gt;
&lt;groovy:script location="some/path/to/groovy/file/GroovyFilterTests.groovy"/&gt;
&lt;/filter&gt;
<para><emphasis>Filter</emphasis> <programlisting language="xml">&lt;int:filter input-channel="referencedScriptInput"&gt;
&lt;int-groovy:script location="some/path/to/groovy/file/GroovyFilterTests.groovy"/&gt;
&lt;/int:filter&gt;
&lt;filter input-channel="inlineScriptInput"&gt;
&lt;groovy:script&gt;&lt;![CDATA[
&lt;int:filter input-channel="inlineScriptInput"&gt;
&lt;int-groovy:script&gt;&lt;![CDATA[
return payload == 'good'
]]&gt;&lt;/groovy:script&gt;
&lt;/filter&gt;</programlisting>
]]&gt;&lt;/int-groovy:script&gt;
&lt;/int:filter&gt;</programlisting>
Here, you see that the script can be included inline
or via the <code>location</code> attribute using the groovy namespace
@@ -53,7 +53,7 @@
the <code>refresh-check-delay</code> attribute on the <emphasis>script</emphasis>
element.
<programlisting language="xml">&lt;groovy:script location="..." refresh-check-delay="5000"/&gt;</programlisting>
<programlisting language="xml">&lt;int-groovy:script location="..." refresh-check-delay="5000"/&gt;</programlisting>
In the above example any invocations that occur within the 5 seconds immediately following the
updating of the script would still be using the old script. However, any invocation that occurs
@@ -61,13 +61,13 @@
result in execution of the new script. This is a good example where 'near real
time' is acceptable.
<programlisting language="xml">&lt;groovy:script location="..." refresh-check-delay="0"/&gt;</programlisting>
<programlisting language="xml">&lt;int-groovy:script location="..." refresh-check-delay="0"/&gt;</programlisting>
In the above example the context will be updated with any script modifications
as soon as such modification occurs. Basically this is an example of
'real-time' configuration and might not be the most efficient option (but could be useful during development).
<programlisting language="xml">&lt;groovy:script location="..." refresh-check-delay="-1"/&gt;</programlisting>
<programlisting language="xml">&lt;int-groovy:script location="..." refresh-check-delay="-1"/&gt;</programlisting>
Any negative number value means the script will never be refreshed after
initial initialization of the application context. This is the default behavior.
@@ -106,7 +106,7 @@
If you need more control over how a particular variable is generated, then all you need to do is
provide your own implementation of ScriptVariableGenerator and reference it with the <code>script-variable-generator</code>
attribute:
<programlisting language="xml"><![CDATA[<groovy:script location="foo/bar/MyScript.groovy"
<programlisting language="xml"><![CDATA[<int-groovy:script location="foo/bar/MyScript.groovy"
script-variable-generator="variableGenerator"/>
<bean id="variableGenerator" class="foo.bar.MyScriptVariableGenerator"/>]]></programlisting>
@@ -122,9 +122,9 @@
<code>customizer</code> attribute. For example, this might be useful if you want to configure a domain-specific
language (DSL) by modifying the MetaClass and registering functions to be available within the script.
<programlisting language="xml"><![CDATA[<service-activator input-channel="groovyChannel">
<groovy:script location="foo/SomeScript.groovy" customizer="groovyCustomizer"/>
</service-activator>
<programlisting language="xml"><![CDATA[<int:service-activator input-channel="groovyChannel">
<int-groovy:script location="foo/SomeScript.groovy" customizer="groovyCustomizer"/>
</int:service-activator>
<beans:bean id="groovyCustomizer" class="org.foo.MyGroovyObjectCustomizer"/>]]></programlisting>
@@ -143,7 +143,7 @@
"application-level" messaging. In Spring Integration we build upon the
adapters described above so that it's possible to send Messages as a means
of invoking exposed operations. One option for those operations is Groovy scripts.
<programlisting language="xml"> &lt;groovy:control-bus input-channel="operationChannel"/&gt;</programlisting></para>
<programlisting language="xml"> &lt;int-groovy:control-bus input-channel="operationChannel"/&gt;</programlisting></para>
<para>The Control Bus has an input channel that can be accessed for
invoking operations on the beans in the application context.</para>
@@ -161,7 +161,7 @@
that implements <code>org.springframework.scripting.groovy.GroovyObjectCustomizer</code> via
the <code>customizer</code> attribute.
<programlisting language="xml"><![CDATA[<groovy:control-bus input-channel="input"
<programlisting language="xml"><![CDATA[<int-groovy:control-bus input-channel="input"
output-channel="output"
customizer="groovyCustomizer"/>

14
docs/src/reference/docbook/http.xml
View File

@@ -113,12 +113,12 @@ In the case of the Outbound Gateway, the reply message produced by the gateway w
<para>
To configure an inbound http channel adapter which is an instance of <classname>HttpInboundEndpoint</classname> configured
not to expect a response.
<programlisting language="xml"><![CDATA[<http:inbound-channel-adapter id="httpChannelAdapter" channel="requests"
<programlisting language="xml"><![CDATA[<int-http:inbound-channel-adapter id="httpChannelAdapter" channel="requests"
supported-methods="PUT, DELETE"/>]]></programlisting>
</para>
<para>
To configure an inbound http gateway which expects a response.
<programlisting language="xml"><![CDATA[ <http:inbound-gateway id="inboundGateway"
<programlisting language="xml"><![CDATA[ <int-http:inbound-gateway id="inboundGateway"
request-channel="requests"
reply-channel="responses"/>]]></programlisting>
</para>
@@ -127,7 +127,7 @@ In the case of the Outbound Gateway, the reply message produced by the gateway w
default http-method is POST, and the default response type is <emphasis>null</emphasis>. With a null response type, the payload of the reply Message would only
contain the status code (e.g. 200) as long as it's a successful status (non-successful status codes will throw Exceptions). If you are expecting a different
type, such as a <classname>String</classname>, then provide that fully-qualified class name as shown below.
<programlisting language="xml"><![CDATA[<http:outbound-gateway id="example"
<programlisting language="xml"><![CDATA[<int-http:outbound-gateway id="example"
request-channel="requests"
url="http://localhost/test"
http-method="POST"
@@ -141,7 +141,7 @@ In the case of the Outbound Gateway, the reply message produced by the gateway w
<para>If your outbound adapter is to be used in a unidirectional way, then you can use an outbound-channel-adapter instead. This means that
a successful response will simply execute without sending any Messages to a reply channel. In the case of any non-successful response
status code, it will throw an exception. The configuration looks very similar to the gateway:
<programlisting language="xml"><![CDATA[<http:outbound-channel-adapter id="example"
<programlisting language="xml"><![CDATA[<int-http:outbound-channel-adapter id="example"
url="http://localhost/example"
http-method="GET"
channel="requests"
@@ -159,13 +159,13 @@ In the case of the Outbound Gateway, the reply message produced by the gateway w
If your URL contains URI variables you can map them using <code>uri-variable</code> sub element in
<emphasis>Http Outbound Gateway</emphasis> configuration.
<programlisting language="xml"><![CDATA[<http:outbound-gateway id="trafficGateway"
<programlisting language="xml"><![CDATA[<int-http:outbound-gateway id="trafficGateway"
url="http://local.yahooapis.com/trafficData?appid=YdnDemo&amp;zip={zipCode}"
request-channel="trafficChannel"
http-method="GET"
expected-response-type="java.lang.String">
<http:uri-variable name="zipCode" expression="payload.getZip()"/>
</http:outbound-gateway>]]></programlisting>
<int-http:uri-variable name="zipCode" expression="payload.getZip()"/>
</int-http:outbound-gateway>]]></programlisting>
The <code>uri-variable</code> defines two attributes <code>expression</code> and <code>value</code>. You generally use
the <code>value</code> attribute for literal values, but if the value you are trying to inject is dynamic and requires

4
docs/src/reference/docbook/httpinvoker.xml
View File

@@ -82,7 +82,7 @@
</para>
<para>
To configure the inbound gateway you can choose to use the namespace support for it. The following code snippet shows the different configuration options that are supported.
<programlisting language="xml"><![CDATA[<httpinvoker:inbound-gateway id="inboundGateway"
<programlisting language="xml"><![CDATA[<int-httpinvoker:inbound-gateway id="inboundGateway"
request-channel="requestChannel"
request-timeout="10000"
expect-reply="false"
@@ -94,7 +94,7 @@
</para>
<para>
To configure the outbound gateway you can use the namespace support as well. The following code snippet shows the different configuration for an outbound HttpInvoker gateway. Only the 'url' and 'request-channel' are required.
<programlisting language="xml"><![CDATA[<httpinvoker:outbound-gateway id="outboundGateway"
<programlisting language="xml"><![CDATA[<int-httpinvoker:outbound-gateway id="outboundGateway"
url="http://localhost:8080/example"
request-channel="requestChannel"
request-timeout="5000"

24
docs/src/reference/docbook/ip.xml
View File

@@ -44,7 +44,7 @@
<section id="udp-adapters">
<title>UDP Adapters</title>
<para>
<programlisting language="xml"><![CDATA[ <ip:udp-outbound-channel-adapter id="udpOut"
<programlisting language="xml"><![CDATA[ <int-ip:udp-outbound-channel-adapter id="udpOut"
host="somehost"
port="11111"
multicast="false"
@@ -62,7 +62,7 @@
short the contain the packet, the packet can be truncated. The length header provides a mechanism to detect this.
</para>
<para>
<programlisting language="xml"><![CDATA[ <ip:udp-outbound-channel-adapter id="udpOut"
<programlisting language="xml"><![CDATA[ <int-ip:udp-outbound-channel-adapter id="udpOut"
host="somehost"
port="11111"
multicast="false"
@@ -80,7 +80,7 @@
must send an acknowledgment to the sender within a specified time.
</para>
<para>
<programlisting language="xml"><![CDATA[ <ip:udp-outbound-channel-adapter id="udpOut"
<programlisting language="xml"><![CDATA[ <int-ip:udp-outbound-channel-adapter id="udpOut"
host="somehost"
port="11111"
multicast="false"
@@ -105,7 +105,7 @@
For even more reliable networking, TCP can be used.
</para>
<para>
<programlisting language="xml"><![CDATA[ <ip:udp-inbound-channel-adapter id="udpReceiver"
<programlisting language="xml"><![CDATA[ <int-ip:udp-inbound-channel-adapter id="udpReceiver"
channel="udpOutChannel"
port="11111"
receive-buffer-size="500"
@@ -114,7 +114,7 @@
A basic unicast inbound udp channel adapter.
</para>
<para>
<programlisting language="xml"><![CDATA[ <ip:udp-inbound-channel-adapter id="udpReceiver"
<programlisting language="xml"><![CDATA[ <int-ip:udp-inbound-channel-adapter id="udpReceiver"
channel="udpOutChannel"
port="11111"
receive-buffer-size="500"
@@ -176,7 +176,7 @@
</para>
<para>
<programlisting language="xml"><![CDATA[
<ip:tcp-connection-factory id="server"
<int-ip:tcp-connection-factory id="server"
type="server"
port="1234"
/>]]></programlisting>
@@ -185,7 +185,7 @@
</para>
<para>
<programlisting language="xml"><![CDATA[
<ip:tcp-connection-factory id="server"
<int-ip:tcp-connection-factory id="server"
type="server"
port="1234"
using-nio="true"
@@ -195,7 +195,7 @@
</para>
<para>
<programlisting language="xml"><![CDATA[
<ip:tcp-connection-factory id="client"
<int-ip:tcp-connection-factory id="client"
type="client"
host="localhost"
port="1234"
@@ -207,7 +207,7 @@
</para>
<para>
<programlisting language="xml"><![CDATA[
<ip:tcp-connection-factory id="client"
<int-ip:tcp-connection-factory id="client"
type="client"
host="localhost"
port="1234"
@@ -309,7 +309,7 @@
<bean id="javaDeserializer"
class="org.springframework.core.serializer.DefaultDeserializer" />
<ip:tcp-connection-factory id="server"
<int-ip:tcp-connection-factory id="server"
type="server"
port="1234"
deserializer="javaDeserializer"
@@ -497,7 +497,7 @@
</para>
<para>
<programlisting language="xml"><![CDATA[
<ip:tcp-inbound-gateway id="inGateway"
<int-ip:tcp-inbound-gateway id="inGateway"
request-channel="tcpChannel"
reply-channel="replyChannel"
connection-factory="cfServer"
@@ -509,7 +509,7 @@
</para>
<para>
<programlisting language="xml"><![CDATA[
<ip:tcp-outbound-gateway id="outGateway"
<int-ip:tcp-outbound-gateway id="outGateway"
request-channel="tcpChannel"
reply-channel="replyChannel"
connection-factory="cfClient"

24
docs/src/reference/docbook/jdbc.xml
View File

@@ -37,7 +37,7 @@
defines an inbound Channel Adapter with an update query and a
<classname>DataSource</classname> reference.
<programlisting language="xml"><![CDATA[<jdbc:inbound-channel-adapter query="select * from item where status=2"
<programlisting language="xml"><![CDATA[<int-jdbc:inbound-channel-adapter query="select * from item where status=2"
channel="target" data-source="dataSource"
update="update item set status=10 where id in (:id)" />]]></programlisting>
<note>
@@ -55,12 +55,12 @@
controlled. A very important feature of the poller for JDBC usage is the
option to wrap the poll operation in a transaction, for example:</para>
<programlisting language="xml"><![CDATA[<jdbc:inbound-channel-adapter query="..."
<programlisting language="xml"><![CDATA[<int-jdbc:inbound-channel-adapter query="..."
channel="target" data-source="dataSource" update="...">
<poller fixed-rate="1000">
<transactional/>
</poller>
</jdbc:inbound-channel-adapter>]]></programlisting>
<int:poller fixed-rate="1000">
<int:transactional/>
</int:poller>
</int-jdbc:inbound-channel-adapter>]]></programlisting>
<para><note>
If a poller is not explicitly specified, a default value will be used (and as per normal with Spring Integration can be defined as a top level bean).
@@ -84,7 +84,7 @@
payload and headers are available by default as input parameters to the
query, for instance:
<programlisting language="xml"><![CDATA[<jdbc:outbound-channel-adapter
<programlisting language="xml"><![CDATA[<int-jdbc:outbound-channel-adapter
query="insert into foos (id, status, name) values (:headers[id], 0, :payload[foo])"
data-source="dataSource"
channel="input"/>]]></programlisting>
@@ -116,7 +116,7 @@
SQL query and then respond with the result sending it to a reply channel.
The message payload and headers are available by default as input
parameters to the query, for instance:
<programlisting language="xml"><![CDATA[<jdbc:outbound-gateway
<programlisting language="xml"><![CDATA[<int-jdbc:outbound-gateway
update="insert into foos (id, status, name) values (:headers[id], 0, :payload[foo])"
request-channel="input" reply-channel="output" data-source="dataSource" />]]></programlisting></para>
@@ -130,7 +130,7 @@
the default because it is not supported by some database platforms). For
example:</para>
<programlisting language="xml"><![CDATA[<jdbc:outbound-gateway
<programlisting language="xml"><![CDATA[<int-jdbc:outbound-gateway
update="insert into foos (status, name) values (0, :payload[foo])"
request-channel="input" reply-channel="output" data-source="dataSource"
keys-generated="true"/>]]></programlisting>
@@ -139,7 +139,7 @@
provide a select query to execute and generate a reply message from the result
(like the inbound adapter), e.g:</para>
<programlisting language="xml"><![CDATA[<jdbc:outbound-gateway
<programlisting language="xml"><![CDATA[<int-jdbc:outbound-gateway
update="insert into foos (id, status, name) values (:headers[id], 0, :payload[foo])"
query="select * from foos where id=:headers[$id]"
request-channel="input" reply-channel="output" data-source="dataSource"/>]]></programlisting>
@@ -168,7 +168,7 @@
implemented by the JdbcMessageStore, and there is also support for
configuring store instances in XML. For example:</para>
<programlisting language="xml"><![CDATA[<jdbc:message-store id="messageStore" data-source="dataSource"/>
<programlisting language="xml"><![CDATA[<int-jdbc:message-store id="messageStore" data-source="dataSource"/>
]]></programlisting>
<para>A <classname>JdbcTemplate</classname> can be specified instead of a
@@ -176,7 +176,7 @@
<para>Other optional attributes are show in the next example:</para>
<para><programlisting language="xml"><![CDATA[<jdbc:message-store id="messageStore" data-source="dataSource"
<para><programlisting language="xml"><![CDATA[<int-jdbc:message-store id="messageStore" data-source="dataSource"
lob-handler="lobHandler" table-prefix="MY_INT_"/>]]></programlisting>
Here we have specified a <classname>LobHandler</classname> for dealing with

32
docs/src/reference/docbook/jms.xml
View File

@@ -32,9 +32,9 @@
instance or both <interfacename>ConnectionFactory</interfacename> and <interfacename>Destination</interfacename>
(a 'destinationName' can be provided in place of the 'destination' reference). The following example defines an
inbound Channel Adapter with a <classname>Destination</classname> reference.
<programlisting language="xml"><![CDATA[ <jms:inbound-channel-adapter id="jmsIn" destination="inQueue" channel="exampleChannel">
<integration:poller fixed-rate="30000"/>
</jms:inbound-channel-adapter>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int-jms:inbound-channel-adapter id="jmsIn" destination="inQueue" channel="exampleChannel">
<int:poller fixed-rate="30000"/>
</int-jms:inbound-channel-adapter>]]></programlisting>
<tip>
Notice from the configuration that the inbound-channel-adapter is a Polling Consumer. That means that
it invokes receive() when triggered. This should only be used in situations where polling is done relatively
@@ -55,12 +55,12 @@
String-based payload, a JMS BytesMessage will produce a byte array payload, and a JMS ObjectMessage's
Serializable instance will become the Spring Integration Message's payload. If instead you prefer to have
the raw JMS Message as the Spring Integration Message's payload, then set 'extract-payload' to false.
<programlisting language="xml"><![CDATA[ <jms:inbound-channel-adapter id="jmsIn"
<programlisting language="xml"><![CDATA[ <int-jms:inbound-channel-adapter id="jmsIn"
destination="inQueue"
channel="exampleChannel"
extract-payload="false"/>
<integration:poller fixed-rate="30000"/>
</jms:inbound-channel-adapter>]]></programlisting>
<int:poller fixed-rate="30000"/>
</int-jms:inbound-channel-adapter>]]></programlisting>
</para>
</section>
@@ -72,7 +72,7 @@
<interfacename>ConnectionFactory</interfacename> and <interfacename>Destination</interfacename>
(a 'destinationName' can be provided in place of the 'destination' reference). The following example defines a
message-driven Channel Adapter with a <classname>Destination</classname> reference.
<programlisting language="xml"><![CDATA[ <jms:message-driven-channel-adapter id="jmsIn" destination="inQueue" channel="exampleChannel"/>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int-jms:message-driven-channel-adapter id="jmsIn" destination="inQueue" channel="exampleChannel"/>]]></programlisting>
<note>
The Message-Driven adapter also accepts several properties that pertain to the MessageListener container.
These values are only considered if you do not provide an actual 'container' reference. In that case,
@@ -91,7 +91,7 @@
</para>
<para>Finally, the &lt;message-driven-channel-adapter&gt; also accepts the 'error-channel' attribute. This
provides the same basic functionality as described in <xref linkend="gateway-proxy"/>.
<programlisting language="xml"><![CDATA[ <jms:message-driven-channel-adapter id="jmsIn" destination="inQueue"
<programlisting language="xml"><![CDATA[ <int-jms:message-driven-channel-adapter id="jmsIn" destination="inQueue"
channel="exampleChannel"
error-channel="exampleErrorChannel"/>
]]></programlisting>
@@ -113,7 +113,7 @@
inbound Channel Adapter, the easiest way to configure this adapter is with the namespace support. The following
configuration will produce an adapter that receives Spring Integration Messages from the "exampleChannel" and then
converts those into JMS Messages and sends them to the JMS Destination reference whose bean name is "outQueue".
<programlisting language="xml"><![CDATA[<jms:outbound-channel-adapter id="jmsOut" destination="outQueue" channel="exampleChannel"/>]]></programlisting>
<programlisting language="xml"><![CDATA[<int-jms:outbound-channel-adapter id="jmsOut" destination="outQueue" channel="exampleChannel"/>]]></programlisting>
</para>
<para>
As with the inbound Channel Adapters, there is an 'extract-payload' property. However, the meaning is reversed
@@ -141,7 +141,7 @@
<interfacename>ConnectionFactory</interfacename>, and a request <interfacename>Destination</interfacename> (or
'requestDestinationName'). The following example defines a JMS "inbound-gateway" that receives from the JMS
queue referenced by the bean id "inQueue" and sends to the Spring Integration channel named "exampleChannel".
<programlisting language="xml"><![CDATA[ <jms:inbound-gateway id="jmsInGateway"
<programlisting language="xml"><![CDATA[ <int-jms:inbound-gateway id="jmsInGateway"
request-destination="inQueue"
request-channel="exampleChannel"/>]]></programlisting>
</para>
@@ -174,7 +174,7 @@
request-channel="jmsinputchannel"
error-channel="errorTransformationChannel"/>
<si:transformer input-channel="exceptionTransformationChannel"
<int:transformer input-channel="exceptionTransformationChannel"
ref="exceptionTransformer" method="createErrorResponse"/>
]]></programlisting>
You might notice that this example looks very similar to that included
@@ -193,7 +193,7 @@
'request-destination'. It will then handle the JMS reply Message either by using a selector to
receive from the 'reply-destination' that you configure, or if no 'reply-destination' is provided,
it will create JMS TemporaryQueues. Notice that the "reply-channel" is also provided.
<programlisting language="xml"><![CDATA[ <jms:outbound-gateway id="jmsOutGateway"
<programlisting language="xml"><![CDATA[ <int-jms:outbound-gateway id="jmsOutGateway"
request-destination="outQueue"
request-channel="outboundJmsRequests"
reply-channel="jmsReplies"/>]]></programlisting>
@@ -280,7 +280,7 @@
required even though conceptually the goal is to have a single Message Channel. A better option is
supported as of Spring Integration version 2.0. Now it is possible to define a single "channel" when
using the JMS namespace.
<programlisting language="xml"><![CDATA[ <jms:channel id="jmsChannel" queue="exampleQueue"/>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int-jms:channel id="jmsChannel" queue="exampleQueue"/>]]></programlisting>
</para>
<para>
The channel in the above example will behave much like a normal &lt;channel/&gt; element from the main
@@ -304,11 +304,11 @@
Since the example above is referencing a JMS Queue instance, it will act as a point-to-point channel. If
on the other hand, publish/subscribe behavior is needed, then a separate element can be used, and a JMS
Topic can be referenced instead.
<programlisting language="xml"><![CDATA[ <jms:publish-subscribe-channel id="jmsChannel" topic="exampleTopic"/>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int-jms:publish-subscribe-channel id="jmsChannel" topic="exampleTopic"/>]]></programlisting>
</para>
<para>
For either type of JMS-backed channel, the name of the destination may be provided instead of a reference.
<programlisting language="xml"><![CDATA[ <jms:channel id="jmsQueueChannel" queue-name="exampleQueueName"/>
<programlisting language="xml"><![CDATA[ <int-jms:channel id="jmsQueueChannel" queue-name="exampleQueueName"/>
<jms:publish-subscribe-channel id="jmsTopicChannel" topic-name="exampleTopicName"/>]]></programlisting>
</para>
@@ -319,7 +319,7 @@
<interfacename>ConnectionFactory</interfacename> is a required property of the channel, but by default
the expected bean name would be "connectionFactory". The example below provides both a custom instance
for resolution of the JMS Destination names and a different name for the ConnectionFactory.
<programlisting language="xml"><![CDATA[ <jms:channel id="jmsChannel" queue-name="exampleQueueName"
<programlisting language="xml"><![CDATA[ <int-jms:channel id="jmsChannel" queue-name="exampleQueueName"
destination-resolver="customDestinationResolver"
connection-factory="customConnectionFactory"/>]]></programlisting>
</para>

20
docs/src/reference/docbook/jmx.xml
View File

@@ -18,7 +18,7 @@
<para>The Notification-listening Channel Adapter requires a JMX ObjectName
for the MBean that publishes Notifications to which this listener should
be registered. A very simple configuration might look like this:
<programlisting language="xml"> &lt;jmx:notification-listening-channel-adapter id="adapter"
<programlisting language="xml"> &lt;int-jmx:notification-listening-channel-adapter id="adapter"
channel="channel"
object-name="example.domain:name=publisher"/&gt;</programlisting>
<tip> The <emphasis>notification-listening-channel-adapter</emphasis>
@@ -30,7 +30,7 @@
"handback" Object to provide some context that is passed back with each
Notification. Both of those attributes are optional. Extending the above
example to include those attributes as well as an explicit MBeanServer
bean name would produce the following: <programlisting language="xml"> &lt;jmx:notification-listening-channel-adapter id="adapter"
bean name would produce the following: <programlisting language="xml"> &lt;int-jmx:notification-listening-channel-adapter id="adapter"
channel="channel"
mbean-server="someServer"
object-name="example.domain:name=somePublisher"
@@ -48,7 +48,7 @@
only requires a JMX ObjectName in its configuration as shown below.
<programlisting language="xml"> &lt;context:mbean:export/&gt;
&lt;jmx:notification-publishing-channel-adapter id="adapter"
&lt;int-jmx:notification-publishing-channel-adapter id="adapter"
channel="channel"
object-name="example.domain:name=publisher"/&gt;</programlisting>
It does also require that an MBeanExporter be present in the context. That
@@ -68,7 +68,7 @@
fallback "default-notification-type" attribute provided in the
configuration. <programlisting language="xml"> &lt;context:mbean:export/&gt;
&lt;jmx:notification-publishing-channel-adapter id="adapter"
&lt;int-jmx:notification-publishing-channel-adapter id="adapter"
channel="channel"
object-name="example.domain:name=publisher"
default-notification-type="some.default.type"/&gt;</programlisting></para>
@@ -85,12 +85,12 @@
An MBeanServer reference is also required, but it will automatically check
for a bean named "mbeanServer" by default just like the
notification-listening-channel-adapter described above. <programlisting
language="xml"> &lt;jmx:attribute-polling-channel-adapter id="adapter"
language="xml"> &lt;int-jmx:attribute-polling-channel-adapter id="adapter"
channel="channel"
object-name="example.domain:name=someService"
attribute-name="InvocationCount"&gt;
&lt;si:poller max-messages-per-poll="1" fixed-rate="5000"/&gt;
&lt;/jmx:attribute-polling-channel-adapter&gt;</programlisting></para>
&lt;int:poller max-messages-per-poll="1" fixed-rate="5000"/&gt;
&lt;/int-jmx:attribute-polling-channel-adapter&gt;</programlisting></para>
</section>
<section id="jmx-operation-invoking-channel-adapter">
@@ -100,7 +100,7 @@
Message-driven invocation of any managed operation exposed by an MBean.
Each invocation requires the operation name to be invoked and the
ObjectName of the target MBean. Both of these must be explicitly provided
via adapter configuration: <programlisting language="xml"> &lt;jmx:operation-invoking-channel-adapter id="adapter"
via adapter configuration: <programlisting language="xml"> &lt;int-jmx:operation-invoking-channel-adapter id="adapter"
object-name="example.domain:name=TestBean"
operation-name="ping"/&gt;</programlisting> Then the adapter
only needs to be able to discover the "mbeanServer" bean. If a different
@@ -128,7 +128,7 @@
<emphasis>operation-invoking-outbound-gateway</emphasis> which could be
used when dealing with non-void operations and return value is required.
Such return value will be sent as message payload to the 'reply-channel'
specified by this Gateway. <programlisting language="xml"> &lt;jmx:operation-invoking-outbound-gateway request-channel="requestChannel"
specified by this Gateway. <programlisting language="xml"> &lt;int-jmx:operation-invoking-outbound-gateway request-channel="requestChannel"
reply-channel="replyChannel"
object-name="org.springframework.integration.jmx.config:type=TestBean,name=testBeanGateway"
operation-name="testWithReturn"/&gt;</programlisting> Another way of
@@ -145,7 +145,7 @@
create an instance of the <classname>IntegrationMBeanExporter</classname>,
define a bean and provide a reference to an MBeanServer and a domain name
(if desired). The domain can be left out in which case the default domain
is "org.springframework.integration". <programlisting language="xml"> &lt;jmx:mbean-exporter default-domain="my.company.domain" server="mbeanServer"/&gt;
is "org.springframework.integration". <programlisting language="xml"> &lt;int-jmx:mbean-exporter default-domain="my.company.domain" server="mbeanServer"/&gt;
&lt;bean id="mbeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean"&gt;
&lt;property name="locateExistingServerIfPossible" value="true"/&gt;

8
docs/src/reference/docbook/mail.xml
View File

@@ -70,7 +70,7 @@
locations.<programlisting language="xml"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mail="http://www.springframework.org/schema/integration/mail"
xmlns:int-mail="http://www.springframework.org/schema/integration/mail"
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/mail
@@ -78,10 +78,10 @@
</para>
<para>
To configure an outbound Channel Adapter, provide the channel to receive from, and the MailSender:
<programlisting language="xml"><![CDATA[<mail:outbound-channel-adapter channel="outboundMail"
<programlisting language="xml"><![CDATA[<int-mail:outbound-channel-adapter channel="outboundMail"
mail-sender="mailSender"/>]]></programlisting>
Alternatively, provide the host, username, and password:
<programlisting language="xml"><![CDATA[<mail:outbound-channel-adapter channel="outboundMail"
<programlisting language="xml"><![CDATA[<int-mail:outbound-channel-adapter channel="outboundMail"
host="somehost" username="someuser" password="somepassword"/>]]></programlisting>
<note>
Keep in mind, as with any outbound Channel Adapter, if the referenced channel is a PollableChannel, a
@@ -183,7 +183,7 @@
When using the namespace support, a <emphasis>header-enricher</emphasis> Message Transformer is also available.
This simplifies the application of the headers mentioned above to any Message prior to sending to the
Mail-sending Channel Adapter.
<programlisting language="xml"><![CDATA[<mail:header-enricher subject="Example Mail"
<programlisting language="xml"><![CDATA[<int-mail:header-enricher subject="Example Mail"
to="to@example.org"
cc="cc@example.org"
bcc="bcc@example.org"

36
docs/src/reference/docbook/message-publishing.xml
View File

@@ -125,7 +125,7 @@ public String argumentAsPayload(@Payload String fname, @Header String lname) {
<programlisting language="xml">&lt;bean class="org.springframework.integration.aop.PublisherAnnotationBeanPostProcessor"/&gt;</programlisting>
You can instead use namespace support for a more concise configuration:
<programlisting language="xml">&lt;si:annotation-config default-publisher-channel="defaultChannel"/&gt;</programlisting>
<programlisting language="xml">&lt;int:annotation-config default-publisher-channel="defaultChannel"/&gt;</programlisting>
</para>
<para>
@@ -327,39 +327,39 @@ static class BankingOperationsImpl implements BankingOperations {
</para>
<para>
<programlisting language="xml"><![CDATA[<inbound-channel-adapter id="fixedDelayProducer"
<programlisting language="xml"><![CDATA[<int:inbound-channel-adapter id="fixedDelayProducer"
expression="'fixedDelayTest'"
channel="fixedDelayChannel">
<poller fixed-delay="1000"/>
</inbound-channel-adapter>]]></programlisting>
<int:poller fixed-delay="1000"/>
</int:inbound-channel-adapter>]]></programlisting>
In the above example an inbound Channel Adapter will be created which will construct a Message with its payload being the result of the expression 
defined in the <code>expression</code> attribute. Such messages will be created and sent every time the delay specified by the <code>fixed-delay</code> attribute occurs.
<programlisting language="xml"><![CDATA[<inbound-channel-adapter id="fixedRateProducer"
<programlisting language="xml"><![CDATA[<int:inbound-channel-adapter id="fixedRateProducer"
expression="'fixedRateTest'"
channel="fixedRateChannel">
<poller fixed-rate="1000"/>
</inbound-channel-adapter>]]></programlisting>
<int:poller fixed-rate="1000"/>
</int:inbound-channel-adapter>]]></programlisting>
This example is very similar to the previous one, except that we are using the <code>fixed-rate</code> attribute which will allow us to send messages at a fixed rate (measuring from the start time of each task).
<programlisting language="xml"><![CDATA[<inbound-channel-adapter id="cronProducer"
<programlisting language="xml"><![CDATA[<int:inbound-channel-adapter id="cronProducer"
expression="'cronTest'"
channel="cronChannel">
<poller cron="7 6 5 4 3 ?"/>
</inbound-channel-adapter>]]></programlisting>
<int:poller cron="7 6 5 4 3 ?"/>
</int:inbound-channel-adapter>]]></programlisting>
This example demonstrates how you can apply a Cron trigger with a value specified in the <code>cron</code> attribute.
<programlisting language="xml"><![CDATA[<inbound-channel-adapter id="headerExpressionsProducer"
<programlisting language="xml"><![CDATA[<int:inbound-channel-adapter id="headerExpressionsProducer"
expression="'headerExpressionsTest'"
channel="headerExpressionsChannel"
auto-startup="false">
<poller fixed-delay="5000"/>
<header name="foo" expression="6 * 7"/>
<header name="bar" value="x"/>
</inbound-channel-adapter>]]></programlisting>
<int:poller fixed-delay="5000"/>
<int:header name="foo" expression="6 * 7"/>
<int:header name="bar" value="x"/>
</int:inbound-channel-adapter>]]></programlisting>
Here you can see that in a way very similar to the Message publishing feature we are enriching a newly constructed Message with
extra Message headers which can take scalar values or the results of evaluating Spring expressions.
@@ -369,10 +369,10 @@ static class BankingOperationsImpl implements BankingOperations {
If you need to implement your own custom trigger you can use the <code>trigger</code> attribute to provide a reference to any spring configured
bean which implements the <classname>org.springframework.scheduling.Trigger</classname> interface.
<programlisting language="xml"><![CDATA[<inbound-channel-adapter id="triggerRefProducer"
<programlisting language="xml"><![CDATA[<int:inbound-channel-adapter id="triggerRefProducer"
expression="'triggerRefTest'" channel="triggerRefChannel">
<poller trigger="customTrigger"/>
</inbound-channel-adapter>
<int:poller trigger="customTrigger"/>
</int:inbound-channel-adapter>
<beans:bean id="customTrigger" class="org.springframework.scheduling.support.PeriodicTrigger">
<beans:constructor-arg value="9999"/>

6
docs/src/reference/docbook/resequencer.xml
View File

@@ -32,11 +32,11 @@
<para>A sample resequencer configuration is shown below.</para>
<programlisting language="xml"><![CDATA[<channel id="inputChannel"/>
<programlisting language="xml"><![CDATA[<int:channel id="inputChannel"/>
<channel id="outputChannel"/>
<int:channel id="outputChannel"/>
<resequencer id="completelyDefinedResequencer" ]]><co id="resxml1-co"
<int:resequencer id="completelyDefinedResequencer" ]]><co id="resxml1-co"
linkends="resxml1" /><![CDATA[
input-channel="inputChannel" ]]><co id="resxml2-co" linkends="resxml2" /><![CDATA[
output-channel="outputChannel" ]]><co id="resxml3-co" linkends="resxml3" /><![CDATA[

12
docs/src/reference/docbook/rmi.xml
View File

@@ -40,23 +40,23 @@
<title>RMI namespace support</title>
<para>
To configure the inbound gateway you can choose to use the namespace support for it. The following code snippet shows the different configuration options that are supported.
<programlisting language="xml"><![CDATA[ <rmi:inbound-gateway id="gatewayWithDefaults" request-channel="testChannel"/>
<programlisting language="xml"><![CDATA[ <int-rmi:inbound-gateway id="gatewayWithDefaults" request-channel="testChannel"/>
<rmi:inbound-gateway id="gatewayWithCustomProperties" request-channel="testChannel"
<int-rmi:inbound-gateway id="gatewayWithCustomProperties" request-channel="testChannel"
expect-reply="false" request-timeout="123" reply-timeout="456"/>
<rmi:inbound-gateway id="gatewayWithHost" request-channel="testChannel"
<int-rmi:inbound-gateway id="gatewayWithHost" request-channel="testChannel"
registry-host="localhost"/>
<rmi:inbound-gateway id="gatewayWithPort" request-channel="testChannel"
<int-rmi:inbound-gateway id="gatewayWithPort" request-channel="testChannel"
registry-port="1234"/>
<rmi:inbound-gateway id="gatewayWithExecutorRef" request-channel="testChannel"
<int-rmi:inbound-gateway id="gatewayWithExecutorRef" request-channel="testChannel"
remote-invocation-executor="invocationExecutor"/>]]></programlisting>
</para>
<para>
To configure the outbound gateway you can use the namespace support as well. The following code snippet shows the different configuration for an outbound rmi gateway.
<programlisting language="xml"><![CDATA[ <rmi:outbound-gateway id="gateway"
<programlisting language="xml"><![CDATA[ <int-rmi:outbound-gateway id="gateway"
request-channel="localChannel"
remote-channel="testChannel"
host="localhost"/>]]></programlisting>

56
docs/src/reference/docbook/router.xml
View File

@@ -33,10 +33,10 @@
The example below demonstrates a <classname>PayloadTypeRouter</classname> configuration which is equivalent to the one above using the namespace support:
</para>
<para>
<programlisting language="xml"><![CDATA[<payload-type-router input-channel="routingChannel">
<mapping type="java.lang.String" channel="stringChannel" />
<mapping type="java.lang.Integer" channel="integerChannel" />
</payload-type-router>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:payload-type-router input-channel="routingChannel">
<int:mapping type="java.lang.String" channel="stringChannel" />
<int:mapping type="java.lang.Integer" channel="integerChannel" />
</int:payload-type-router>]]></programlisting>
</para>
</section>
<section id="router-implementations-headervaluerouter">
@@ -60,10 +60,10 @@
</para>
<para><emphasis>1. Configuration where mapping of header values to channels is required</emphasis> </para>
<para>
<programlisting language="xml"><![CDATA[<header-value-router input-channel="routingChannel" header-name="testHeader">
<mapping value="someHeaderValue" channel="channelA" />
<mapping value="someOtherHeaderValue" channel="channelB" />
</header-value-router>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:header-value-router input-channel="routingChannel" header-name="testHeader">
<int:mapping value="someHeaderValue" channel="channelA" />
<int:mapping value="someOtherHeaderValue" channel="channelB" />
</int:header-value-router>]]></programlisting>
</para>
<para>
During the resolution process this router may encounter channel resolution failures, causing an
@@ -78,7 +78,7 @@
<para> <emphasis>2. Configuration where mapping of header values to channel names
is not required since header values themselves represent channel names</emphasis> </para>
<para>
<programlisting language="xml"><![CDATA[<header-value-router input-channel="routingChannel" header-name="testHeader"/>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:header-value-router input-channel="routingChannel" header-name="testHeader"/>]]></programlisting>
</para>
<note>
@@ -112,13 +112,13 @@
as the example below demonstrates.
</para>
<para>
<programlisting language="xml"><![CDATA[<recipient-list-router id="customRouter" input-channel="routingChannel"
<programlisting language="xml"><![CDATA[<int:recipient-list-router id="customRouter" input-channel="routingChannel"
timeout="1234"
ignore-send-failures="true"
apply-sequence="true">
<recipient channel="channel1"/>
<recipient channel="channel2"/>
</recipient-list-router>]]></programlisting>
<int:recipient channel="channel1"/>
<int:recipient channel="channel2"/>
</int:recipient-list-router>]]></programlisting>
</para>
<note>
The 'apply-sequence' flag here has the same effect as it does for a publish-subscribe-channel,
@@ -176,24 +176,24 @@
The "router" element provides a simple way to connect a router to an input channel and also accepts the
optional <code>default-output-channel</code> attribute. The <code>ref</code> attribute references the bean name of a custom Router implementation
(extending <classname>AbstractMessageRouter</classname>):
<programlisting language="xml"><![CDATA[<router ref="payloadTypeRouter" input-channel="input1" default-output-channel="defaultOutput1"/>
<programlisting language="xml"><![CDATA[<int:router ref="payloadTypeRouter" input-channel="input1" default-output-channel="defaultOutput1"/>
<router ref="recipientListRouter" input-channel="input2" default-output-channel="defaultOutput2"/>
<int:router ref="recipientListRouter" input-channel="input2" default-output-channel="defaultOutput2"/>
<router ref="customRouter" input-channel="input3" default-output-channel="defaultOutput3"/>
<int:router ref="customRouter" input-channel="input3" default-output-channel="defaultOutput3"/>
<beans:bean id="customRouterBean class="org.foo.MyCustomRouter"/>]]></programlisting>
Alternatively, <code>ref</code> may point to a simple POJO that contains the @Router annotation (see below), or the
<code>ref</code> may be combined with an explicit <code>method</code> name. Specifying a <code>method</code> applies the same behavior
described in the @Router annotation section below.
<programlisting language="xml"><![CDATA[<router input-channel="input" ref="somePojo" method="someMethod"/>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:router input-channel="input" ref="somePojo" method="someMethod"/>]]></programlisting>
Using a <code>ref</code> attribute is generally recommended if the custom router implementation is referenced in other
<code>&lt;router&gt;</code> definitions. However if the custom router implementation should be scoped to a
single definition of the <code>&lt;router&gt;</code>, you may provide an inner bean definition:
<programlisting language="xml"><![CDATA[<router method="someMethod" input-channel="input3" default-output-channel="defaultOutput3">
<programlisting language="xml"><![CDATA[<int:router method="someMethod" input-channel="input3" default-output-channel="defaultOutput3">
<beans:bean class="org.foo.MyCustomRouter"/>
</router>]]></programlisting>
</int:router>]]></programlisting>
</para>
<note>
<para>
@@ -343,10 +343,10 @@ public List&lt;String&gt; route(@Header("orderStatus") OrderStatus status)</prog
<emphasis>Payload Type Router</emphasis>
</para>
<para>
<programlisting language="xml"><![CDATA[<payload-type-router input-channel="routingChannel">
<mapping type="java.lang.String" channel="channel1" />
<mapping type="java.lang.Integer" channel="channel2" />
</payload-type-router>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:payload-type-router input-channel="routingChannel">
<int:mapping type="java.lang.String" channel="channel1" />
<int:mapping type="java.lang.Integer" channel="channel2" />
</int:payload-type-router>]]></programlisting>
</para>
<para>
Within the context of the Payload Type Router the 3 steps mentioned above would be realized as:
@@ -373,10 +373,10 @@ public List&lt;String&gt; route(@Header("orderStatus") OrderStatus status)</prog
<emphasis>Header Value Router</emphasis>
</para>
<para>
<programlisting language="xml"><![CDATA[<header-value-router input-channel="inputChannel" header-name="testHeader">
<mapping value="foo" channel="fooChannel" />
<mapping value="bar" channel="barChannel" />
</header-value-router>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:header-value-router input-channel="inputChannel" header-name="testHeader">
<int:mapping value="foo" channel="fooChannel" />
<int:mapping value="bar" channel="barChannel" />
</int:header-value-router>]]></programlisting>
</para>
<para>
Similar to the PayloadTypeRouter:
@@ -402,7 +402,7 @@ public List&lt;String&gt; route(@Header("orderStatus") OrderStatus status)</prog
The above two configurations of two different router types look almost identical.
However if we look at the alternate configuration of the <classname>HeaderValueRouter</classname> we clearly see that
there is no <code>mapping</code> sub element:
<programlisting language="xml"><![CDATA[<header-value-router input-channel="inputChannel" header-name="testHeader">]]></programlisting>
<programlisting language="xml"><![CDATA[<int:header-value-router input-channel="inputChannel" header-name="testHeader">]]></programlisting>
But the configuration is still perfectly valid. So the natural question is what about the mapping in the Step 2?
</para>
<para>

77
docs/src/reference/docbook/samples.xml
View File

@@ -249,13 +249,13 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
XML <emphasis>&lt;gateway&gt;</emphasis> element or via annotation and use it as any other Spring bean. SI will take care of
delegating and mapping method invocations to the Messaging infrastructure by generating a <emphasis>Message</emphasis> (payload is mapped to an
input parameter of the method) and sending it to the designated channel.
<programlisting language="xml"><![CDATA[<gateway id="loanBrokerGateway"
<programlisting language="xml"><![CDATA[<int:gateway id="loanBrokerGateway"
default-request-channel="loanBrokerPreProcessingChannel"
service-interface="org.springframework.integration.samples.loanbroker.LoanBrokerGateway">
<method name="getBestLoanQuote">
<header name="RESPONSE_TYPE" value="BEST"/>
</method>
</gateway>]]></programlisting>
<int:method name="getBestLoanQuote">
<int:header name="RESPONSE_TYPE" value="BEST"/>
</int:method>
</int:gateway>]]></programlisting>
</para>
<para>
Our current <emphasis>Gateway</emphasis> provides two methods that could be invoked. One that will return the best single quote and another one that
@@ -334,11 +334,11 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
An <emphasis>Aggregator</emphasis> pattern describes an endpoint which groups related <emphasis>Messages</emphasis> into a single
<emphasis>Message</emphasis>. Criteria and rules can be provided to determine an aggregation and correlation strategy.
SI provides several implementations of the <emphasis>Aggregator</emphasis> pattern as well as a convenient name-space based configuration.
<programlisting language="xml"><![CDATA[<aggregator id="quotesAggregator"
<programlisting language="xml"><![CDATA[<int:aggregator id="quotesAggregator"
input-channel="quotesAggregationChannel"
method="aggregateQuotes">
<beans:bean class="org.springframework.integration.samples.loanbroker.LoanQuoteAggregator"/>
</aggregator>]]></programlisting>
</int:aggregator>]]></programlisting>
</para>
<para>
@@ -412,10 +412,10 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
<para>
Here is the XML configuration:
<programlisting language="xml"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/integration"
<beans:beans xmlns:int="http://www.springframework.org/schema/integration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:stream="http://www.springframework.org/schema/integration/stream"
xmlns:int-stream="http://www.springframework.org/schema/integration/stream"
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
@@ -423,31 +423,31 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
http://www.springframework.org/schema/integration/stream
http://www.springframework.org/schema/integration/stream/spring-integration-stream-2.0.xsd">
<gateway id="cafe" service-interface="org.springframework.integration.samples.cafe.Cafe"/>
<int:gateway id="cafe" service-interface="org.springframework.integration.samples.cafe.Cafe"/>
<channel id="orders"/>
<splitter input-channel="orders" ref="orderSplitter" method="split" output-channel="drinks"/>
<int:channel id="orders"/>
<int:splitter input-channel="orders" ref="orderSplitter" method="split" output-channel="drinks"/>
<channel id="drinks"/>
<router input-channel="drinks" ref="drinkRouter" method="resolveOrderItemChannel"/>
<int:channel id="drinks"/>
<int:router input-channel="drinks" ref="drinkRouter" method="resolveOrderItemChannel"/>
<channel id="coldDrinks">
<queue capacity="10"/>
</channel>
<service-activator input-channel="coldDrinks" ref="barista"
<int:channel id="coldDrinks">
<int:queue capacity="10"/>
</int:channel>
<int:service-activator input-channel="coldDrinks" ref="barista"
method="prepareColdDrink" output-channel="preparedDrinks"/>
<channel id="hotDrinks">
<queue capacity="10"/>
</channel>
<service-activator input-channel="hotDrinks" ref="barista"
<int:channel id="hotDrinks">
<int:queue capacity="10"/>
</int:channel>
<int:service-activator input-channel="hotDrinks" ref="barista"
method="prepareHotDrink" output-channel="preparedDrinks"/>
<channel id="preparedDrinks"/>
<aggregator input-channel="preparedDrinks" ref="waiter"
<int:channel id="preparedDrinks"/>
<int:aggregator input-channel="preparedDrinks" ref="waiter"
method="prepareDelivery" output-channel="deliveries"/>
<stream:stdout-channel-adapter id="deliveries"/>
<int-stream:stdout-channel-adapter id="deliveries"/>
<beans:bean id="orderSplitter"
class="org.springframework.integration.samples.cafe.xml.OrderSplitter"/>
@@ -459,7 +459,7 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
<beans:bean id="waiter" class="org.springframework.integration.samples.cafe.xml.Waiter"/>
<poller id="poller" default="true" fixed-rate="1000"/>
<int:poller id="poller" default="true" fixed-rate="1000"/>
</beans:beans>]]></programlisting>
As you can see, each Message Endpoint is connected to input and/or output channels. Each endpoint will manage
@@ -576,18 +576,18 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
This is to be expected based on their respective delays of 1000 and 5000 milliseconds. However, by configuring a
poller with a concurrent task executor, you can dramatically change the results. For example, you could use a
thread pool executor with 5 workers for the hot drink barista while keeping the cold drink barista as it is:
<programlisting language="xml"><![CDATA[<service-activator input-channel="hotDrinks"
<programlisting language="xml"><![CDATA[<int:service-activator input-channel="hotDrinks"
ref="barista"
method="prepareHotDrink"
output-channel="preparedDrinks"/>
<service-activator input-channel="hotDrinks"
<int:service-activator input-channel="hotDrinks"
ref="barista"
method="prepareHotDrink"
output-channel="preparedDrinks">
]]><emphasis><![CDATA[<poller task-executor="pool" fixed-rate="1000"/>
]]><emphasis><![CDATA[<int:poller task-executor="pool" fixed-rate="1000"/>
]]></emphasis><![CDATA[
</service-activator>
</int:service-activator>
]]><emphasis><![CDATA[<task:executor id="pool" pool-size="5"/>]]></emphasis></programlisting>
</para>
@@ -613,10 +613,11 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
<para>
First the order is split into a number of messages, each one representing a single order item using
the XPath splitter component.
<programlisting language="xml"><![CDATA[<si-xml:xpath-splitter id="orderItemSplitter" input-channel="ordersChannel"
<programlisting language="xml"><![CDATA[<int-xml:xpath-splitter id="orderItemSplitter" input-channel="ordersChannel"
output-channel="stockCheckerChannel" create-documents="true">
<si-xml:xpath-expression expression="/orderNs:order/orderNs:orderItem" namespace-map="orderNamespaceMap" />
</si-xml:xpath-splitter>
<int-xml:xpath-expression expression="/orderNs:order/orderNs:orderItem"
namespace-map="orderNamespaceMap" />
</int-xml:xpath-splitter>
]]></programlisting>
</para>
<para>
@@ -624,9 +625,10 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
from the stock checker about order item stock level. This enriched order item message is then used to route the message. In the
case where the order item is in stock the message is routed to the warehouse. The XPath router makes use of the default
<classname>ChannelResolver</classname> strategy which maps the XPath evaluation result to a channel reference in the <classname>ApplicationContext</classname>.
<programlisting language="xml"><![CDATA[<si-xml:xpath-router id="instockRouter" channel-resolver="mapChannelResolver"
<programlisting language="xml"><![CDATA[<int-xml:xpath-router id="instockRouter" channel-resolver="mapChannelResolver"
input-channel="orderRoutingChannel" resolution-required="true">
<si-xml:xpath-expression expression="/orderNs:orderItem/@in-stock" namespace-map="orderNamespaceMap" />
<int-xml:xpath-expression expression="/orderNs:orderItem/@in-stock"
namespace-map="orderNamespaceMap" />
</si-xml:xpath-router>
]]></programlisting>
@@ -634,8 +636,9 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
<para>
Where the order item is not in stock the message is transformed using
xslt into a format suitable for sending to the supplier.
<programlisting language="xml"><![CDATA[<si-xml:xslt-transformer input-channel="outOfStockChannel" output-channel="resupplyOrderChannel"
xsl-resource="classpath:org/springframework/integration/samples/xml/bigBooksSupplierTransformer.xsl"/>
<programlisting language="xml"><![CDATA[<int-xml:xslt-transformer input-channel="outOfStockChannel"
output-channel="resupplyOrderChannel"
xsl-resource="classpath:org/springframework/integration/samples/xml/bigBooksSupplierTransformer.xsl"/>
]]></programlisting>
</para>
</section>

20
docs/src/reference/docbook/security.xml
View File

@@ -26,8 +26,8 @@
definition of one or more channel name patterns in conjunction with a definition of the security configuration for send and receive. The pattern
is a <interfacename>java.util.regexp.Pattern</interfacename>.
<programlisting language="xml"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/integration"
xmlns:si-security="http://www.springframework.org/schema/integration/security"
<beans:beans xmlns:int="http://www.springframework.org/schema/integration"
xmlns:int-security="http://www.springframework.org/schema/integration/security"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:security="http://www.springframework.org/schema/security"
@@ -40,21 +40,21 @@
http://www.springframework.org/schema/integration/security
http://www.springframework.org/schema/integration/security/spring-integration-security-2.0.xsd">
<si-security:secured-channels>
<si-security:access-policy pattern="admin.*" send-access="ROLE_ADMIN"/>
<si-security:access-policy pattern="user.*" receive-access="ROLE_USER"/>
</si-security:secured-channels>]]>
<int-security:secured-channels>
<int-security:access-policy pattern="admin.*" send-access="ROLE_ADMIN"/>
<int-security:access-policy pattern="user.*" receive-access="ROLE_USER"/>
</int-security:secured-channels>]]>
</programlisting>
By default the secured-channels namespace element expects a bean named <emphasis>authenticationManager</emphasis> which implements
<interfacename>AuthenticationManager</interfacename> and a bean named <emphasis>accessDecisionManager</emphasis> which implements
<interfacename>AccessDecisionManager</interfacename>. Where this is not the case references to the appropriate beans can be configured
as attributes of the <emphasis>secured-channels</emphasis> element as below.
<programlisting language="xml"><![CDATA[<si-security:secured-channels access-decision-manager="customAccessDecisionManager"
<programlisting language="xml"><![CDATA[<int-security:secured-channels access-decision-manager="customAccessDecisionManager"
authentication-manager="customAuthenticationManager">
<si-security:access-policy pattern="admin.*" send-access="ROLE_ADMIN"/>
<si-security:access-policy pattern="user.*" receive-access="ROLE_USER"/>
</si-security:secured-channels>]]>
<int-security:access-policy pattern="admin.*" send-access="ROLE_ADMIN"/>
<int-security:access-policy pattern="user.*" receive-access="ROLE_USER"/>
</int-security:secured-channels>]]>
</programlisting>
</para>

10
docs/src/reference/docbook/service-activator.xml
View File

@@ -19,19 +19,19 @@
<title>Configuring Service Activator</title>
<para>
To create a Service Activator, use the 'service-activator' element with the 'input-channel' and 'ref' attributes:
<programlisting language="xml">&lt;service-activator input-channel="exampleChannel" ref="exampleHandler"/&gt;</programlisting>
<programlisting language="xml">&lt;int:service-activator input-channel="exampleChannel" ref="exampleHandler"/&gt;</programlisting>
</para>
<para>
The configuration above assumes that "exampleHandler" either contains a single method annotated with the
@ServiceActivator annotation or that it contains only one public method at all. To delegate to an explicitly
defined method of any object, simply add the "method" attribute.
<programlisting language="xml">&lt;service-activator input-channel="exampleChannel" ref="somePojo" method="someMethod"/&gt;</programlisting>
<programlisting language="xml">&lt;int:service-activator input-channel="exampleChannel" ref="somePojo" method="someMethod"/&gt;</programlisting>
</para>
<para>
In either case, when the service method returns a non-null value, the endpoint will attempt to send the reply
message to an appropriate reply channel. To determine the reply channel, it will first check if an
"output-channel" was provided in the endpoint configuration:
<programlisting language="xml">&lt;service-activator input-channel="exampleChannel" output-channel="replyChannel"
<programlisting language="xml">&lt;int:service-activator input-channel="exampleChannel" output-channel="replyChannel"
ref="somePojo" method="someMethod"/&gt;</programlisting>
If no "output-channel" is available, it will then check the Message's <literal>replyChannel</literal> header
value. If that value is available, it will then check its type. If it is a
@@ -57,10 +57,10 @@
Using a "ref" attribute is generally recommended if the custom Service Activator handler implementation can be reused
in other <code>&lt;service-activator&gt;</code> definitions. However if the custom Service Activator handler implementation
is only used within a single definition of the <code>&lt;service-activator&gt;</code>, you can provide an inner bean definition:
<programlisting language="xml"><![CDATA[<service-activator id="exampleServiceActivator" input-channel="inChannel"
<programlisting language="xml"><![CDATA[<int:service-activator id="exampleServiceActivator" input-channel="inChannel"
output-channel = "outChannel" method="foo">
<beans:bean class="org.foo.ExampleServiceActivator"/>
</service-activator>]]></programlisting>
</int:service-activator>]]></programlisting>
</para>
<note>
<para>

8
docs/src/reference/docbook/sftp.xml
View File

@@ -21,7 +21,7 @@
<emphasis>Inbound Channel Adapters</emphasis> and <emphasis>Outbound Channel Adapters</emphasis> as well as convenient
namespace configuration to define these <emphasis>client</emphasis>s.
<programlisting language="xml"><![CDATA[xmlns:sftp="http://www.springframework.org/schema/integration/sftp"
<programlisting language="xml"><![CDATA[xmlns:int-sftp="http://www.springframework.org/schema/integration/sftp"
xsi:schemaLocation="http://www.springframework.org/schema/integration/sftp
http://www.springframework.org/schema/integration/sftp/spring-integration-sftp-2.0.xsd"
]]></programlisting>
@@ -71,7 +71,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/sftp
The <emphasis>SFTP Inbound Channel Adapter</emphasis> is a special listener that will connect to the server and listen for
the remote directory events (e.g., new file created) at which point it will initiate a file transfer.
<programlisting language="xml"><![CDATA[<sftp:inbound-channel-adapter id="sftpAdapterAutoCreate"
<programlisting language="xml"><![CDATA[<int-sftp:inbound-channel-adapter id="sftpAdapterAutoCreate"
session-factory="sftpSessionFactory"
channel="requestChannel"
filename-pattern="*.txt"
@@ -79,8 +79,8 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/sftp
local-directory="file:target/foo"
auto-create-local-directory="true"
delete-remote-files="false">
<poller fixed-rate="1000"/>
</sftp:inbound-channel-adapter>]]></programlisting>
<int:poller fixed-rate="1000"/>
</int-sftp:inbound-channel-adapter>]]></programlisting>
As you can see from the configuration above you can configure the <emphasis>SFTP Inbound Channel Adapter</emphasis> via the
<code>inbound-channel-adapter</code> element while also providing values for various attributes such as <code>local-directory</code>

12
docs/src/reference/docbook/splitter.xml
View File

@@ -84,15 +84,15 @@
<section>
<title>Configuring a Splitter using XML</title>
<para>A splitter can be configured through XML as follows:<programlisting language="xml">&lt;channel id="inputChannel"/&gt;
<para>A splitter can be configured through XML as follows:<programlisting language="xml">&lt;int:channel id="inputChannel"/&gt;
&lt;splitter id="splitter" <co id="split1" />
&lt;int:splitter id="splitter" <co id="split1" />
ref="splitterBean" <co id="split2" />
method="split" <co id="split3" />
input-channel="inputChannel" <co id="split4" />
output-channel="outputChannel" <co id="split5" />/&gt;
&lt;channel id="outputChannel"/&gt;
&lt;int:channel id="outputChannel"/&gt;
&lt;beans:bean id="splitterBean" class="sample.PojoSplitter"/&gt;</programlisting><calloutlist>
<callout arearefs="split1">
@@ -133,14 +133,14 @@
Using a <code>ref</code> attribute is generally recommended if the custom splitter implementation may be referenced in other
<code>&lt;splitter&gt;</code> definitions. However if the custom splitter handler implementation should be scoped to a
single definition of the <code>&lt;splitter&gt;</code>, configure an inner bean definition:
<programlisting language="xml"><![CDATA[<splitter id="testSplitter" input-channel="inChannel" method="split"
<programlisting language="xml"><![CDATA[<int:splitter id="testSplitter" input-channel="inChannel" method="split"
output-channel="outChannel">
<beans:bean class="org.foo.TestSplitter"/>
</spliter>]]></programlisting>
</int:spliter>]]></programlisting>
</para>
<note>
<para>
Using both a <code>ref</code> attribute and an inner handler definition in the same <code>&lt;splitter&gt;</code>
Using both a <code>ref</code> attribute and an inner handler definition in the same <code>&lt;int:splitter&gt;</code>
configuration is not allowed, as it creates an ambiguous condition and will result in an Exception being thrown.
</para>
</note>

14
docs/src/reference/docbook/stream.xml
View File

@@ -62,7 +62,7 @@
<para>
To reduce the configuration needed for stream related channel adapters there is a namespace defined. The following schema locations are needed to use it.
<programlisting language="xml"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/integration/stream"
<beans:beans xmlns:int-stream="http://www.springframework.org/schema/integration/stream"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans
@@ -72,19 +72,19 @@
</para>
<para>
To configure the inbound channel adapter the following code snippet shows the different configuration options that are supported.
<programlisting language="xml"><![CDATA[<stdin-channel-adapter id="adapterWithDefaultCharset"/>
<programlisting language="xml"><![CDATA[<int-stream:stdin-channel-adapter id="adapterWithDefaultCharset"/>
<stdin-channel-adapter id="adapterWithProvidedCharset" charset="UTF-8"/>]]></programlisting>
<int-stream:stdin-channel-adapter id="adapterWithProvidedCharset" charset="UTF-8"/>]]></programlisting>
</para>
<para>
To configure the outbound channel adapter you can use the namespace support as well. The following code snippet shows the different configuration for an outbound channel adapters.
<programlisting language="xml"><![CDATA[<stdout-channel-adapter id="stdoutAdapterWithDefaultCharset" channel="testChannel"/>
<programlisting language="xml"><![CDATA[<int-stream:stdout-channel-adapter id="stdoutAdapterWithDefaultCharset" channel="testChannel"/>
<stdout-channel-adapter id="stdoutAdapterWithProvidedCharset" charset="UTF-8" channel="testChannel"/>
<int-stream:stdout-channel-adapter id="stdoutAdapterWithProvidedCharset" charset="UTF-8" channel="testChannel"/>
<stderr-channel-adapter id="stderrAdapter" channel="testChannel"/>
<int-stream:stderr-channel-adapter id="stderrAdapter" channel="testChannel"/>
<stdout-channel-adapter id="newlineAdapter" append-newline="true" channel="testChannel"/>
<int-stream:stdout-channel-adapter id="newlineAdapter" append-newline="true" channel="testChannel"/>
]]></programlisting>
</para>
</section>

4
docs/src/reference/docbook/transactions.xml
View File

@@ -106,7 +106,7 @@
<title>Poller Transaction Support</title>
<para>
Any time you configure a Poller you can provide transactional configuration via the <emphasis>transactional</emphasis> sub-element and its attributes:
<programlisting language="xml"><![CDATA[<poller max-messages-per-poll="1" fixed-rate="1000">
<programlisting language="xml"><![CDATA[<int:poller max-messages-per-poll="1" fixed-rate="1000">
<transactional transaction-manager="txManager" 
isolation="DEFAULT"
propagation="REQUIRED" 
@@ -134,7 +134,7 @@
The rationale behind this is that if you need more than one advice, and one of them is Transaction advice, then you can simply
include it in the <emphasis>&lt;advice-chain&gt;</emphasis> with the same convenience as before but with much more control
since you now have an option to position any advice in the desired order.
<programlisting language="xml"><![CDATA[<poller max-messages-per-poll="1" fixed-rate="10000">
<programlisting language="xml"><![CDATA[<int:poller max-messages-per-poll="1" fixed-rate="10000">
<advice-chain>
<ref bean="txAdvice"/>
<ref bean="someAotherAdviceBean" />

12
docs/src/reference/docbook/transformer.xml
View File

@@ -38,7 +38,7 @@
and "output-channel" attributes, it requires a "ref". The "ref" may either point to an Object that contains the
@Transformer annotation on a single method (see below) or it may be combined with an explicit method name value
provided via the "method" attribute.
<programlisting language="xml"><![CDATA[<transformer id="testTransformer" ref="testTransformerBean" input-channel="inChannel"
<programlisting language="xml"><![CDATA[<int:transformer id="testTransformer" ref="testTransformerBean" input-channel="inChannel"
method="transform" output-channel="outChannel"/>
<beans:bean id="testTransformerBean" class="org.foo.TestTransformer" />]]></programlisting>
</para>
@@ -46,7 +46,7 @@
Using a "ref" attribute is generally recommended if the custom transformer handler implementation can be reused in
other <code>&lt;transformer&gt;</code> definitions. However if the custom transformer handler implementation should
be scoped to a single definition of the <code>&lt;transformer&gt;</code>, you can define an inner bean definition:
<programlisting language="xml"><![CDATA[<transformer id="testTransformer" input-channel="inChannel" method="transform"
<programlisting language="xml"><![CDATA[<int:transformer id="testTransformer" input-channel="inChannel" method="transform"
output-channel="outChannel">
<beans:bean class="org.foo.TestTransformer"/>
</transformer>]]></programlisting>
@@ -101,7 +101,7 @@
<classname>ObjectToStringTransformer</classname> whose output is a Message with a String payload. That String
is the result of invoking the toString() operation on the inbound Message's payload.
<programlisting language="xml"><![CDATA[ <object-to-string-transformer input-channel="in" output-channel="out"/>]]></programlisting>
<programlisting language="xml"><![CDATA[ <int:object-to-string-transformer input-channel="in" output-channel="out"/>]]></programlisting>
A potential example for this would be sending some arbitrary object to the 'outbound-channel-adapter' in the
<emphasis>file</emphasis> namespace. Whereas that Channel Adapter only supports String, byte-array, or
@@ -120,9 +120,9 @@
by default, but you can provide an implementation of Spring 3.0's Serializer or Deserializer strategies via the
'serializer' and 'deserializer' attributes, respectively.
<programlisting language="xml"><![CDATA[ <payload-serializing-transformer input-channel="objectsIn" output-channel="bytesOut"/>
<programlisting language="xml"><![CDATA[ <int:payload-serializing-transformer input-channel="objectsIn" output-channel="bytesOut"/>
<payload-deserializing-transformer input-channel="bytesIn" output-channel="objectsOut"/>]]></programlisting>
<int:payload-deserializing-transformer input-channel="bytesIn" output-channel="objectsOut"/>]]></programlisting>
</para>
<para>
<emphasis>Object-to-Map Transformer</emphasis>
@@ -171,7 +171,7 @@ public class Kid {
<para>
To configure these transformers, Spring Integration provides namespace support
Object-to-Map:
<programlisting language="xml"><![CDATA[<object-to-map-transformer input-channel="directInput" output-channel="output"/>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:object-to-map-transformer input-channel="directInput" output-channel="output"/>]]></programlisting>
Map-to-Object
<programlisting language="xml"><![CDATA[<int:map-to-object-transformer input-channel="input" 
                       output-channel="output" 

42
docs/src/reference/docbook/twitter.xml
View File

@@ -27,7 +27,7 @@
<para>
Spring Integration provides a convenient namespace configuration to define Twitter artifacts. You can enable it by adding
the following within your XML header.
<programlisting language="xml"><![CDATA[xmlns:twitter="http://www.springframework.org/schema/integration/twitter"
<programlisting language="xml"><![CDATA[xmlns:int-twitter="http://www.springframework.org/schema/integration/twitter"
xsi:schemaLocation="http://www.springframework.org/schema/integration/twitter
http://www.springframework.org/schema/integration/twitter/spring-integration-twitter-2.0.xsd"]]></programlisting>
</para>
@@ -160,11 +160,11 @@ received.
<title>Inbound Message Channel Adapter</title>
<para>
This adapter allows you to receive updates from everyone you follow. It's essentially the "Timeline Update" adapter.
<programlisting language="xml"><![CDATA[<twitter:inbound-channel-adapter
<programlisting language="xml"><![CDATA[<int-twitter:inbound-channel-adapter
twitter-template="twitterTemplate"
channel="inChannel">
<poller fixed-rate="5000" max-messages-per-poll="3"/>
</twitter:inbound-channel-adapter>]]></programlisting>
<int:poller fixed-rate="5000" max-messages-per-poll="3"/>
</int-twitter:inbound-channel-adapter>]]></programlisting>
</para>
</section>
@@ -172,11 +172,11 @@ received.
<title>Direct Inbound Message Channel Adapter</title>
<para>
This adapter allows you to receive Direct Messages that were sent to you from other Twitter users.
<programlisting language="xml"><![CDATA[<twitter:dm-inbound-channel-adapter
<programlisting language="xml"><![CDATA[<int-twitter:dm-inbound-channel-adapter
twitter-template="twiterTemplate"
channel="inboundDmChannel">
<poller fixed-rate="5000" max-messages-per-poll="3"/>
</twitter:dm-inbound-channel-adapter>]]></programlisting>
<int-poller fixed-rate="5000" max-messages-per-poll="3"/>
</int-twitter:dm-inbound-channel-adapter>]]></programlisting>
</para>
</section>
@@ -184,11 +184,11 @@ received.
<title>Mentions Inbound Message Channel Adapter</title>
<para>
This adapter allows you to receive Twitter Messages that Mention you via @user syntax.
<programlisting language="xml"><![CDATA[<twitter:mentions-inbound-channel-adapter
<programlisting language="xml"><![CDATA[<int-twitter:mentions-inbound-channel-adapter
twitter-template="twiterTemplate"
channel="inboundMentionsChannel">
<poller fixed-rate="5000" max-messages-per-poll="3"/>
</twitter:mentions-inbound-channel-adapter>]]></programlisting>
<int:poller fixed-rate="5000" max-messages-per-poll="3"/>
</int-twitter:mentions-inbound-channel-adapter>]]></programlisting>
</para>
</section>
@@ -197,11 +197,11 @@ received.
<para>
This adapter allows you to perform searches. As you can see it is not necessary to define twitter-template
since a search can be performed anonymously, however you must define a search query.
<programlisting language="xml"><![CDATA[<twitter:search-inbound-channel-adapter
<programlisting language="xml"><![CDATA[<int-twitter:search-inbound-channel-adapter
query="#springintegration"
channel="inboundMentionsChannel">
<poller fixed-rate="5000" max-messages-per-poll="3"/>
</twitter:search-inbound-channel-adapter>]]></programlisting>
<int:poller fixed-rate="5000" max-messages-per-poll="3"/>
</int-twitter:search-inbound-channel-adapter>]]></programlisting>
</para>
<para>
@@ -240,7 +240,7 @@ received.
<para>
This adapter allows you to send regular status updates by simply sending a Message to the channel
identified by the <code>channel</code> attribute.
<programlisting language="xml"><![CDATA[<twitter:outbound-channel-adapter
<programlisting language="xml"><![CDATA[<int-twitter:outbound-channel-adapter
twitter-template="twitterTemplate"
channel="twitterChannel"/>]]></programlisting>
The only extra configuration that is required for this adapter is the <code>twitter-template</code> reference.
@@ -252,7 +252,7 @@ received.
<para>
This adapter allows you to send Direct Twitter Messages (i.e., @user) by simply sending a Message to the channel
identified by the <code>channel</code> attribute.
<programlisting language="xml"><![CDATA[<twitter:dm-outbound-channel-adapter
<programlisting language="xml"><![CDATA[<int-twitter:dm-outbound-channel-adapter
twitter-template="twitterTemplate"
channel="twitterChannel"/>]]></programlisting>
The only extra configuration that is required for this adapter is the <code>twitter-template</code> reference.
@@ -269,16 +269,16 @@ received.
<para>
The above approach works well if you are creating the Message programmatically. However it's more common to
provide the header value within a messaging flow. The value can be provided by an upstream &lt;header-enricher&gt;.
<programlisting language="xml"><![CDATA[<header-enricher input-channel="in" output-channel="out">
<header name="twitter_dmTargetUserId" value="z_oleg"/>
</header-enricher>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
<int:header name="twitter_dmTargetUserId" value="z_oleg"/>
</int:header-enricher>]]></programlisting>
</para>
<para>It's quite common that the value must be determined dynamically. For those cases you can take advantage
of SpEL support within the &lt;header-enricher&gt;.
<programlisting language="xml"><![CDATA[<header-enricher input-channel="in" output-channel="out">
<header name="twitter_dmTargetUserId" expression="@twitterIdService.lookup(headers.username)"/>
</header-enricher>]]></programlisting>
<programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
<int:header name="twitter_dmTargetUserId" expression="@twitterIdService.lookup(headers.username)"/>
</int:header-enricher>]]></programlisting>
</para>
</section>

8
docs/src/reference/docbook/ws.xml
View File

@@ -68,7 +68,7 @@ as per standard Spring Web Services configuration.
<title>Web Service Namespace Support</title>
<para>
To configure an outbound Web Service Gateway, use the "outbound-gateway" element from the "ws" namespace:
<programlisting language="xml"><![CDATA[<ws:outbound-gateway id="simpleGateway"
<programlisting language="xml"><![CDATA[<int-ws:outbound-gateway id="simpleGateway"
request-channel="inputChannel"
uri="http://example.org"/>]]></programlisting>
<note>
@@ -91,17 +91,17 @@ as per standard Spring Web Services configuration.
</tip>
To set up an inbound Web Service Gateway, use the "inbound-gateway":
<programlisting language="xml"><![CDATA[<ws:inbound-gateway id="simpleGateway"
<programlisting language="xml"><![CDATA[<int-ws:inbound-gateway id="simpleGateway"
request-channel="inputChannel"/>]]></programlisting>
To use Spring OXM Marshallers and/or Unmarshallers, provide bean references. For outbound:
<programlisting language="xml"><![CDATA[<ws:outbound-gateway id="marshallingGateway"
<programlisting language="xml"><![CDATA[<int-ws:outbound-gateway id="marshallingGateway"
request-channel="requestChannel"
uri="http://example.org"
marshaller="someMarshaller"
unmarshaller="someUnmarshaller"/>]]></programlisting>
And for inbound:
<programlisting language="xml"><![CDATA[<ws:inbound-gateway id="marshallingGateway"
<programlisting language="xml"><![CDATA[<int-ws:inbound-gateway id="marshallingGateway"
request-channel="requestChannel"
marshaller="someMarshaller"
unmarshaller="someUnmarshaller"/>]]></programlisting>

92
docs/src/reference/docbook/xml.xml
View File

@@ -119,8 +119,8 @@
<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"
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-3.0.xsd
http://www.springframework.org/schema/integration
@@ -131,17 +131,17 @@
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"
<programlisting language="xml"><![CDATA[<int-xml:unmarshalling-transformer id="defaultUnmarshaller"
input-channel="input"
output-channel="output"
unmarshaller="unmarshaller"/>
<si-xml:unmarshalling-transformer id="unmarshallerWithPoller"
<int-xml:unmarshalling-transformer id="unmarshallerWithPoller"
input-channel="input"
output-channel="output"
unmarshaller="unmarshaller">
<si:poller fixed-rate="2000"/>
<si-xml:unmarshalling-transformer/>
<int:poller fixed-rate="2000"/>
<int-xml:unmarshalling-transformer/>
]]></programlisting>
</para>
@@ -152,13 +152,13 @@
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
<programlisting language="xml"><![CDATA[<int-xml:marshalling-transformer
input-channel="marshallingTransformerStringResultFactory"
output-channel="output"
marshaller="marshaller"
result-type="StringResult" />
<si-xml:marshalling-transformer
<int-xml:marshalling-transformer
input-channel="marshallingTransformerWithResultTransformer"
output-channel="output"
marshaller="marshaller"
@@ -175,11 +175,11 @@
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"
<programlisting language="xml"><![CDATA[<int-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"
<int-xml:xslt-transformer id="xsltTransformerWithTemplatesAndResultTransformer"
input-channel="withTemplatesAndResultTransformerIn"
output-channel="output"
xsl-templates="templates"
@@ -189,7 +189,7 @@
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"
<programlisting language="xml"><![CDATA[<int-xml:xslt-transformer id="paramHeadersCombo"
input-channel="paramHeadersComboChannel"
output-channel="output"
xsl-resource="classpath:transformer.xslt"
@@ -245,9 +245,9 @@
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">
<int-xml:xpath-router id="orderTypeRouter" input-channel="orderChannel">
<si-xml:xpath-expression expression="/order/type"/>
</si-xml:xpath-router>
</int-xml:xpath-router>
]]></programlisting>
</para>
@@ -261,20 +261,20 @@
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>
<int-xml:xpath-router id="responderRouter" input-channel="orderChannel">
<int-xml:xpath-expression expression="/request/responders"/>
</int-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: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"/>
</si-xml:xpath-router>
</int-xml:xpath-router>
]]></programlisting>
</para>
@@ -345,7 +345,7 @@
</para>
<para>
Let's look at the following transformer configuration:
<programlisting language="xml"><![CDATA[<xpath-transformer input-channel="inputChannel" output-channel="outputChannel"
<programlisting language="xml"><![CDATA[<int-xml:xpath-transformer input-channel="inputChannel" output-channel="outputChannel"
xpath-expression="/person/@name" />]]></programlisting>
. . . and Message
@@ -366,10 +366,10 @@
<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"
<programlisting language="xml"><![CDATA[<int-xml: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'"
<int-xml:xpath-transformer input-channel="booleanInput" xpath-expression="/person/@married = 'true'"
evaluation-type="BOOLEAN_RESULT" output-channel="output"/>
]]></programlisting>
</para>
@@ -381,7 +381,7 @@
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"
<programlisting language="xml"><![CDATA[<int-xml:xpath-transformer input-channel="nodeMapperInput" xpath-expression="/person/@age"
node-mapper="testNodeMapper" output-channel="output"/>
]]></programlisting>
. . . and Sample NodeMapper implementation:
@@ -397,7 +397,7 @@
<para>
You can also use 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"
<programlisting language="xml"><![CDATA[<int-xml:xpath-transformer input-channel="customConverterInput" xpath-expression="/test/@type"
converter="testXmlPayloadConverter" output-channel="output"/>
]]></programlisting>
. . . and Sample XmlPayloadConverter implementation:
@@ -427,7 +427,7 @@
<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>
<programlisting language="xml"><![CDATA[int-xml: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>
@@ -441,32 +441,32 @@
&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"
<programlisting language="xml"><![CDATA[<int-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>
<int-xml:xpath-selector id="selectorWithNoNS" evaluation-result-type="boolean" >
<int-xml:xpath-expression expression="/name"/>
</int-xml:xpath-selector>
<si-xml:xpath-selector id="selectorWithOneNS" evaluation-result-type="boolean" >
<si-xml:xpath-expression expression="/ns1:name"
<int-xml:xpath-selector id="selectorWithOneNS" evaluation-result-type="boolean" >
<int-xml:xpath-expression expression="/ns1:name"
ns-prefix="ns1" ns-uri="www.example.org" />
</si-xml:xpath-selector>
</int-xml:xpath-selector>
<si-xml:xpath-selector id="selectorWithTwoNS" evaluation-result-type="boolean" >
<si-xml:xpath-expression expression="/ns1:name/ns2:type">
<int-xml:xpath-selector id="selectorWithTwoNS" evaluation-result-type="boolean" >
<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>
</si-xml:xpath-expression>
</si-xml:xpath-selector>
</int-xml:xpath-expression>
</int-xml:xpath-selector>
<si-xml:xpath-selector id="selectorWithNamespaceMapRef" evaluation-result-type="boolean" >
<si-xml:xpath-expression expression="/ns1:name/ns2:type"
<int-xml:xpath-selector id="selectorWithNamespaceMapRef" evaluation-result-type="boolean" >
<int-xml:xpath-expression expression="/ns1:name/ns2:type"
namespace-map="defaultNamespaces"/>
</si-xml:xpath-selector>
</int-xml:xpath-selector>
<util:map id="defaultNamespaces">
<util:entry key="ns1" value="www.example.org/one" />
@@ -476,20 +476,20 @@
<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"
<int-xml:xpath-splitter id="orderItemSplitter"
input-channel="orderChannel"
output-channel="orderItemsChannel">
<si-xml:xpath-expression expression="/order/items"/>
</si-xml:xpath-splitter>
<int-xml:xpath-expression expression="/order/items"/>
</int-xml:xpath-splitter>
<!-- Split the order into items creating a new document for each item-->
<si-xml:xpath-splitter id="orderItemDocumentSplitter"
<int-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>
<int-xml:xpath-expression expression="/order/items"/>
<int:poller fixed-rate="2000"/>
</int-xml:xpath-splitter>]]></programlisting>
</para>
</section>

6
docs/src/reference/docbook/xmpp.xml
View File

@@ -32,7 +32,7 @@
convenient namespace-based configuration.
To configure the XMPP namespace, include the following elements in the headers of your XML configuration file:
<programlisting language="xml"><![CDATA[xmlns:xmpp="http://www.springframework.org/schema/integration/xmpp"
<programlisting language="xml"><![CDATA[xmlns:int-xmpp="http://www.springframework.org/schema/integration/xmpp"
xsi:schemaLocation="http://www.springframework.org/schema/integration/xmpp
http://www.springframework.org/schema/integration/xmpp/spring-integration-xmpp-2.0.xsd"]]></programlisting>
@@ -48,7 +48,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/xmpp
To create a basic XMPP connection, you can utilize the convenience of the namespace.
<programlisting lang="xml"><![CDATA[<xmpp:xmpp-connection
<programlisting lang="xml"><![CDATA[<int-xmpp:xmpp-connection
id="myConnection"
user="user"
password="password"
@@ -85,7 +85,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/xmpp
when configuring an adapter.
Configuration support for the XMPP <emphasis>Inbound Message Channel Adapter</emphasis> is provided via the <code>inbound-channel-adapter</code> element.
<programlisting language="xml"><![CDATA[<xmpp:inbound-channel-adapter id="xmppInboundAdapter"
<programlisting language="xml"><![CDATA[<int-xmpp:inbound-channel-adapter id="xmppInboundAdapter"
channel="xmppInbound"
xmpp-connection="testConnection"
extract-payload="false"