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

INT-677, INT-682, INT-676 - Modified documentation around added support for inner-bean definition of message handlers within the namespace configuration.

Browse Source
This commit is contained in:
Oleg Zhurakousky
2009-06-26 01:17:39 +00:00
parent 20171072d6
commit 6a47c40dcb
5 changed files with 97 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
spring-integration-reference/src/aggregator.xml
View File

@@ -359,7 +359,20 @@
<emphasis>Optional</emphasis>.</para>
</callout>
</calloutlist>
<para>
Using a "ref" attribute is generally recommended if custom aggregator handler implementation can be reused in other <code>&lt;aggregator&gt;</code> definitions. However
if custom aggregator handler implementation has to be scoped to a concrete definition of the <code>&lt;aggregator&gt;</code>, starting with v1.0.3, Spring Integration supports
inner bean definitions for custom aggregator handlers within the <code>&lt;aggregator&gt;</code> element:
<programlisting language="xml"><![CDATA[<aggregator input-channel="inChannel" method="sum" output-channel="outChannel">
<beans:bean class="org.foo.TestAggregator"/>
</aggregator>]]></programlisting>
</para>
<note>
<para>
Using both "ref" attribute and inner handler definition in the same <code>&lt;aggregator&gt;</code> configuration
is not allowed, as it creates an ambiguous condition and will result in Exception being thrown
</para>
</note>
<para>An implementation of the aggregator bean, for example, looks as
follows:</para>

18
spring-integration-reference/src/router.xml
View File

@@ -123,15 +123,29 @@
<para>
The "router" element provides a simple way to connect a router to an input channel, and also accepts the
optional default output channel. The "ref" may provide the bean name to one of the implementations described
above:
above or custom Router (MessageHandler) implementations:
<programlisting language="xml"><![CDATA[<router ref="payloadTypeRouter" input-channel="input1" default-output-channel="defaultOutput1"/>
<router ref="recipientListRouter" input-channel="input2" default-output-channel="defaultOutput2"/>]]></programlisting>
<router ref="recipientListRouter" input-channel="input2" default-output-channel="defaultOutput2"/>
<router ref="customRouter" input-channel="input3" default-output-channel="defaultOutput3"/>
<beans:bean id="customRouterBean class="org.foo.MyCustomRouter"/>]]></programlisting>
Alternatively, the "ref" may point to a simple Object that contains the @Router annotation (see below), or the
"ref" may be combined with an explicit "method" name. When specifying a "method", the same behavior applies as
described in the @Router annotation section below.
<programlisting language="xml"><![CDATA[<router input-channel="input" ref="somePojo" method="someMethod"/>]]></programlisting>
Using a "ref" attribute is generally recommended if custom router handler implementation can be reused in other <code>&lt;router&gt;</code> definitions. However
if custom router handler implementation has to be scoped to a concrete definition of the <code>&lt;router&gt;</code>, starting with v1.0.3, Spring Integration supports
inner bean definitions for custom router handlers within the <code>&lt;router&gt;</code> element:
<programlisting language="xml"><![CDATA[<router method="someMethod" input-channel="input3" default-output-channel="defaultOutput3">
<beans:bean class="org.foo.MyCustomRouter"/>
</router>]]></programlisting>
</para>
<note>
<para>Using both "ref" attribute and inner handler definition in the same <code>&lt;router&gt;</code> configuration is not allowed, as it creates an ambiguous condition and will result in Exception being thrown</para>
</note>
</section>
<section id="router-annotation">

23
spring-integration-reference/src/service-activator.xml
View File

@@ -40,6 +40,29 @@
<classname>String</classname>, then the endpoint will attempt to resolve the channel name to a channel instance.
If the channel cannot be resolved, then a <classname>ChannelResolutionException</classname> will be thrown.
</para>
<para>
The argument in the service method could be either a Message or an arbitrary type. If the later one, then it will be assumed that it is a Payload source,
which will be extracted from the message and injected into such service method. This is generally the recommended approach as it follows and promotes
a POJO model when working with Spring Integration.
Since v1.0.3 of Spring Integration, the service method does not require to have an argument at all, which means you can now implement event-style Service Activators,
where all you care about is an invocation of the service method not worrying about the contents of the message. Think of it as a NULL JMS message. An example use-case for such implementation
could be a simple counter/monitor of messages deposited on the input channel.
</para>
<para>
Using a "ref" attribute is generally recommended if custom Service Activator handler implementation can be reused in other <code>&lt;service-activator&gt;</code> definitions. However
if custom Service Activator handler implementation has to be scoped to a concrete definition of the <code>&lt;service-activator&gt;</code>, starting with v1.0.3, Spring Integration supports
inner bean definitions for custom Service Activator handlers within the <code>&lt;service-activator&gt;</code> element:
<programlisting language="xml"><![CDATA[<service-activator id="testServiceActivator" input-channel="inChannel"
output-channel = "outChannel" method="foo">
<beans:bean class="org.foo.TestServiceActivator" /> \
</service-activator>]]></programlisting>
</para>
<note>
<para>
Using both "ref" attribute and inner handler definition in the same <code>&lt;service-activator&gt;</code> configuration
is not allowed, as it creates an ambiguous condition and will result in Exception being thrown
</para>
</note>
</section>
</chapter>

21
spring-integration-reference/src/splitter.xml
View File

@@ -97,7 +97,11 @@
<callout arearefs="split2">
<para>A reference to a bean defined in the application context. The
bean must implement the splitting logic as described in the section
above. <emphasis>Required</emphasis>.</para>
above. <emphasis>Optional</emphasis>.
If reference to a bean is not provided, then it is assumed that the <emphasis>payload</emphasis> of the Message that arrived on the <code>input-channel</code> is
an implementation of <emphasis>java.util.Collection</emphasis> and the default splitting logic will be applied on such Collection,
incorporating each individual element into a Message and depositing it on the <code>output-channel</code>.
</para>
</callout>
<callout arearefs="split3">
@@ -117,6 +121,21 @@
messages can specify a reply channel themselves)</emphasis>.</para>
</callout>
</calloutlist></para>
<para>
Using a "ref" attribute is generally recommended if custom splitter handler implementation can be reused in other <code>&lt;splitter&gt;</code> definitions. However
if custom splitter handler implementation has to be scoped to a concrete definition of the <code>&lt;splitter&gt;</code>, starting with v1.0.3, Spring Integration supports
inner bean definitions for custom splitter handlers within the <code>&lt;splitter&gt;</code> element:
<programlisting language="xml"><![CDATA[<splitter id="testSplitter" input-channel="inChannel" method="split"
output-channel="outChannel">
<beans:bean class="org.foo.TestSplitter"/>
</spliter>]]></programlisting>
</para>
<note>
<para>
Using both "ref" attribute and inner handler definition in the same <code>&lt;splitter&gt;</code> configuration
is not allowed, as it creates an ambiguous condition and will result in Exception being thrown.
</para>
</note>
</section>
<section>

24
spring-integration-reference/src/transformer.xml
View File

@@ -35,7 +35,26 @@
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"
method="transform" output-channel="outChannel"/>
<beans:bean id="testTransformerBean" class="org.foo.TestTransformer" />]]></programlisting>
</para>
<para>
Using a "ref" attribute is generally recommended if custom transformer handler implementation can be reused in other <code>&lt;transformer&gt;</code> definitions. However
if custom transformer handler implementation has to be scoped to a concrete definition of the <code>&lt;transformer&gt;</code>, starting with v1.0.3, Spring Integration supports
inner bean definitions for custom transformer handlers within the <code>&lt;transformer&gt;</code> element:
<programlisting language="xml"><![CDATA[<transformer id="testTransformer" input-channel="inChannel" method="transform"
output-channel="outChannel">
<beans:bean class="org.foo.TestTransformer"/>
</transformer>]]></programlisting>
</para>
<note>
<para>
Using both "ref" attribute and inner handler definition in the same <code>&lt;transformer&gt;</code> configuration
is not allowed, as it creates an ambiguous condition and will result in Exception being thrown
</para>
</note>
<para>
The method that is used for transformation may expect either the <interfacename>Message</interfacename> type or
the payload type of inbound Messages. The return value of the method can be any type. If the return value is
@@ -43,6 +62,11 @@
If the return value is <emphasis>null</emphasis>, then no reply Message will be sent (effectively the same
behavior as a Message Filter). Otherwise, the return value will be sent as the payload of a Message.
</para>
<note>
<para>Using both "ref" attribute and inner handler definition in the same <code>&lt;router&gt;</code> configuration is not
allowed, as it creates an ambiguous condition and will result in Exception being thrown</para>
</note>
</section>
<section id="transformer-annotation">