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

INT-2275: any outbound-channel-adapter in <chain>

Browse Source 
Add re-init logic for nested chains
Add logic about nested element for AbstractChannelAdapterParser
Refactor of DefaultOutboundChannelAdapterParser
Test for non-last nested chain with some outbound-channel-adapter
Improve XSD for chain-type
Manual outbound-channel-adapter ability for chain
Integration tests for all outbound-channel-adapter within <chain>
Remove redundant 'return-value-required' attribute from <stored-proc-outbound-channel-adapter>
Add support 'expectReply' for FileWritingMessageHandler

INT-2275 polishing & refactor FileOutbound*Parser

HttpRequestExecutingMessageHandlerTests polishing

INT-2275: polishing JavaDoc
This commit is contained in:
Artem Bilan
2012-01-03 23:26:16 +02:00
committed by Oleg Zhurakousky
parent 4d5b8d5be1
commit 45c429ee2b
58 changed files with 1302 additions and 318 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/reference/docbook/chain.xml
View File

@@ -57,7 +57,7 @@
<para>
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.
filters, transformers, splitters, and service-activators. The last element may also be a router or an outbound-channel-adapter.
<programlisting language="xml"><![CDATA[ <int:chain input-channel="input" output-channel="output">
<int:filter ref="someSelector" throw-exception-on-rejection="true"/>
<int:header-enricher>
@@ -72,7 +72,18 @@
that touches only header values. You could obtain the same result by implementing a MessageHandler that did the
header modifications and wiring that as a bean, but the header-enricher is obviously a simpler option.
</para>
<para>
The &lt;chain&gt; can be configured as the last 'black-box' consumer of the message flow. For this solution it is
enough to put at the end of the &lt;chain&gt; some &lt;outbound-channel-adapter&gt;:
<programlisting language="xml"><![CDATA[ <int:chain input-channel="input">
<si-xml:marshalling-transformer marshaller="marshaller" result-type="StringResult" />
<int:service-activator ref="someService" method="someMethod"/>
<int:header-enricher>
<int:header name="foo" value="bar"/>
</int:header-enricher>
<int:logging-channel-adapter level="INFO" log-full-message="true"/>
</int:chain>]]></programlisting>
</para>
<para>
Sometimes you need to make a nested call to another chain from within a chain and then come
back and continue execution within the original chain.