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

INT-1552 renamed sections in aggregator, channel, filter and splitter

Browse Source
This commit is contained in:
Oleg Zhurakousky
2010-11-18 17:01:42 -05:00
parent a1487c6659
commit 9b85a2f550
4 changed files with 84 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files

121
docs/src/reference/docbook/aggregator.xml
View File

@@ -300,7 +300,10 @@
</section>
</section>
<section id="aggregator-xml">
<section id="aggregator-config">
<title>Configuring Aggregator</title>
<section id="aggregator-xml">
<title>Configuring an Aggregator with XML</title>
<para>Spring Integration supports the configuration of an aggregator via
@@ -577,6 +580,66 @@
that as soon as there are more then 5 messages in this group release the group.
</para>
</section>
<section id="aggregator-annotations">
<title>Configuring an Aggregator with Annotations</title>
<para>An aggregator configured using annotations can look like
this.</para>
<programlisting language="java"><![CDATA[public class Waiter {
...
@Aggregator ]]><co id="aggann" /><![CDATA[
public Delivery aggregatingMethod(List<OrderItem> items) {
...
}
@ReleaseStrategy ]]><co id="agganncs" /><![CDATA[
public boolean releaseChecker(List<Message<?>> messages) {
...
}
@CorrelationStrategy ]]><co id="agganncorrs" /><![CDATA[
public String correlateBy(OrderItem item) {
...
}
}]]></programlisting>
<calloutlist>
<callout arearefs="aggann">
<para>An annotation indicating that this method shall be used as an
aggregator. Must be specified if this class will be used as an
aggregator.</para>
</callout>
<callout arearefs="agganncs">
<para id="aggann2">An annotation indicating that this method shall be
used as the release strategy of an aggregator. If not present on any
method, the aggregator will use the
SequenceSizeCompletionStrategy.</para>
</callout>
<callout arearefs="agganncorrs">
<para id="agann3">An annotation indicating that this method shall be
used as the correlation strategy of an aggregator. If no correlation
strategy is indicated, the aggregator will use the
HeaderAttributeCorrelationStrategy based on CORRELATION_ID.</para>
</callout>
</calloutlist>
<para>All of the configuration options provided by the xml element are
also available for the @Aggregator annotation.</para>
<para>The aggregator can be either referenced explicitly from XML or, if
the @MessageEndpoint is defined on the class, detected automatically
through classpath scanning.</para>
</section>
</section>
<section>
<title id="reaper">Managing State in an Aggregator:
@@ -650,60 +713,4 @@
invoked then any unmarked messages in groups that are not yet released can
be sent on to the downstream channel.</para>
</section>
<section id="aggregator-annotations">
<title>Configuring an Aggregator with Annotations</title>
<para>An aggregator configured using annotations can look like
this.</para>
<programlisting language="java"><![CDATA[public class Waiter {
...
@Aggregator ]]><co id="aggann" /><![CDATA[
public Delivery aggregatingMethod(List<OrderItem> items) {
...
}
@ReleaseStrategy ]]><co id="agganncs" /><![CDATA[
public boolean releaseChecker(List<Message<?>> messages) {
...
}
@CorrelationStrategy ]]><co id="agganncorrs" /><![CDATA[
public String correlateBy(OrderItem item) {
...
}
}]]></programlisting>
<calloutlist>
<callout arearefs="aggann">
<para>An annotation indicating that this method shall be used as an
aggregator. Must be specified if this class will be used as an
aggregator.</para>
</callout>
<callout arearefs="agganncs">
<para id="aggann2">An annotation indicating that this method shall be
used as the release strategy of an aggregator. If not present on any
method, the aggregator will use the
SequenceSizeCompletionStrategy.</para>
</callout>
<callout arearefs="agganncorrs">
<para id="agann3">An annotation indicating that this method shall be
used as the correlation strategy of an aggregator. If no correlation
strategy is indicated, the aggregator will use the
HeaderAttributeCorrelationStrategy based on CORRELATION_ID.</para>
</callout>
</calloutlist>
<para>All of the configuration options provided by the xml element are
also available for the @Aggregator annotation.</para>
<para>The aggregator can be either referenced explicitly from XML or, if
the @MessageEndpoint is defined on the class, detected automatically
through classpath scanning.</para>
</section>
</section>

13
docs/src/reference/docbook/channel.xml
View File

@@ -236,7 +236,7 @@
</para>
</section>
<section id="channel-implementations-threadlocalchannel">
<title>Thread-Scoped Channel</title>
<title>Scoped Channel</title>
<para>
Spring Integration 1.0 provided a <classname>ThreadLocalChannel</classname> implementation, but that has been removed as of 2.0. Now, there is a more general way for handling the same requirement by simply adding a "scope" attribute to a channel. The value of the attribute can be any name of a Scope that is available within the context. For example, in a web environment, certain Scopes are available, and any custom Scope implementations can be registered with the context. Here's an example of a ThreadLocal-based scope being applied to a channel, including the registration of the Scope itself.</para>
<programlisting language="xml"><![CDATA[ <int:channel id="threadScopedChannel" scope="thread">
@@ -252,7 +252,16 @@
</bean>
]]></programlisting>
<para>
The channel above also delegates to a queue internally, but the channel is bound to the current thread, so the contents of the queue are as well. That way the thread that sends to the channel will later be able to receive those same Messages, but no other thread would be able to access them. While thread-scoped channels are rarely needed, they can be useful in situations where <classname>DirectChannels</classname> are being used to enforce a single thread of operation but any reply Messages should be sent to a "terminal" channel. If that terminal channel is thread-scoped, the original sending thread can collect its replies from it.
The channel above also delegates to a queue internally, but the channel is bound
to the current thread, so the contents of the queue are as well. That way the thread that
sends to the channel will later be able to receive those same Messages, but no other thread
would be able to access them. While thread-scoped channels are rarely needed, they can be
useful in situations where <classname>DirectChannels</classname> are being used to enforce a
single thread of operation but any reply Messages should be sent to a "terminal" channel.
If that terminal channel is thread-scoped, the original sending thread can collect its replies from it.
</para>
<para>
Now, since channel can be scoped, aside from Thread Local you can define yoru own scopes.
</para>
</section>
</section>

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

@@ -31,7 +31,7 @@
</section>
<section id="filter-namespace">
<title>Namespace support for Filter - &lt;filter&gt; Element</title>
<title>Configuring Filter</title>
<para>
The &lt;filter&gt; element is used to create a Message-selecting endpoint. In addition to "input-channel"
and "output-channel" attributes, it requires a "ref". The "ref" may point to a MessageSelector implementation:

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

@@ -74,7 +74,10 @@
to test, it is the recommended approach.</para>
</section>
<section>
<section id="splitter-config">
<title>Configuring Splitter</title>
<section>
<title>Configuring a Splitter using XML</title>
<para>A splitter can be configured through XML as follows:<programlisting>&lt;channel id="inputChannel"/&gt;
@@ -153,5 +156,9 @@ List&lt;LineItem&gt; extractItems(Order order) {
return order.getItems()
}</programlisting></para>
</section>
</section>
</section>