diff --git a/docs/src/reference/docbook/aggregator.xml b/docs/src/reference/docbook/aggregator.xml index a4c7c9f528..5ef9fe7f33 100644 --- a/docs/src/reference/docbook/aggregator.xml +++ b/docs/src/reference/docbook/aggregator.xml @@ -300,7 +300,10 @@ -
+
+ Configuring Aggregator + +
Configuring an Aggregator with XML 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.
+ +
+ Configuring an Aggregator with Annotations + + An aggregator configured using annotations can look like + this. + + items) { + ... + } + + @ReleaseStrategy ]]>> messages) { + ... + } + + @CorrelationStrategy ]]> + + + + An annotation indicating that this method shall be used as an + aggregator. Must be specified if this class will be used as an + aggregator. + + + + 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. + + + + 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. + + + + All of the configuration options provided by the xml element are + also available for the @Aggregator annotation. + + The aggregator can be either referenced explicitly from XML or, if + the @MessageEndpoint is defined on the class, detected automatically + through classpath scanning. +
+ +
+ +
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 - - An aggregator configured using annotations can look like - this. - - items) { - ... - } - - @ReleaseStrategy ]]>> messages) { - ... - } - - @CorrelationStrategy ]]> - - - - An annotation indicating that this method shall be used as an - aggregator. Must be specified if this class will be used as an - aggregator. - - - - 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. - - - - 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. - - - - All of the configuration options provided by the xml element are - also available for the @Aggregator annotation. - - The aggregator can be either referenced explicitly from XML or, if - the @MessageEndpoint is defined on the class, detected automatically - through classpath scanning. -
diff --git a/docs/src/reference/docbook/channel.xml b/docs/src/reference/docbook/channel.xml index c0617c10a4..4225f81987 100644 --- a/docs/src/reference/docbook/channel.xml +++ b/docs/src/reference/docbook/channel.xml @@ -236,7 +236,7 @@
- Thread-Scoped Channel + Scoped Channel Spring Integration 1.0 provided a ThreadLocalChannel 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. @@ -252,7 +252,16 @@ ]]> - 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 DirectChannels 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 DirectChannels 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. + + + Now, since channel can be scoped, aside from Thread Local you can define yoru own scopes.
diff --git a/docs/src/reference/docbook/filter.xml b/docs/src/reference/docbook/filter.xml index 2ce0087447..04020c44e7 100644 --- a/docs/src/reference/docbook/filter.xml +++ b/docs/src/reference/docbook/filter.xml @@ -31,7 +31,7 @@
- Namespace support for Filter - <filter> Element + Configuring Filter The <filter> 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: diff --git a/docs/src/reference/docbook/splitter.xml b/docs/src/reference/docbook/splitter.xml index 9f60a54202..3f1f568525 100644 --- a/docs/src/reference/docbook/splitter.xml +++ b/docs/src/reference/docbook/splitter.xml @@ -74,7 +74,10 @@ to test, it is the recommended approach.
-
+ +
+ Configuring Splitter +
Configuring a Splitter using XML A splitter can be configured through XML as follows:<channel id="inputChannel"/> @@ -153,5 +156,9 @@ List<LineItem> extractItems(Order order) { return order.getItems() }
+
+ + +