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

Fix some Reference Manual typos

Browse Source
This commit is contained in:
Artem Bilan
2016-06-22 14:32:28 -04:00
parent 65261567d2
commit 7b3d57a06e
10 changed files with 114 additions and 126 deletions
Download Patch File Download Diff File Expand all files Collapse all files

87
src/reference/asciidoc/aggregator.adoc
View File

@@ -199,8 +199,7 @@ The second most efficient is a POJO method with a `Collection<Message<?>>` param
The least efficient is a POJO method with a `Collection<Foo>` type - the framework has to copy the payloads from the messages in the group into a new collection (and possibly attempt conversion on the payloads to `Foo`) every time the release strategy is called.
`Collection<?>` avoids the conversion but still requires creating the new `Collection`.
*For these reasons, for large groups, it is recommended that you implement
`ReleaseStrategy`.*
*For these reasons, for large groups, it is recommended that you implement `ReleaseStrategy`.*
=====
When the group is released for aggregation, all its not-yet-released messages are processed and removed from the group.
@@ -265,38 +264,38 @@ Below you can see an example of an aggregator.
<channel id="inputChannel"/>
<int:aggregator id=""myAggregator" <1>
auto-startup="true" <2>
input-channel="inputChannel" <3>
output-channel="outputChannel" <4>
discard-channel="throwAwayChannel" <5>
message-store="persistentMessageStore" <6>
order="1" <7>
send-partial-result-on-expiry="false" <8>
send-timeout="1000" <9>
auto-startup="true" <2>
input-channel="inputChannel" <3>
output-channel="outputChannel" <4>
discard-channel="throwAwayChannel" <5>
message-store="persistentMessageStore" <6>
order="1" <7>
send-partial-result-on-expiry="false" <8>
send-timeout="1000" <9>
correlation-strategy="correlationStrategyBean" <10>
correlation-strategy-method="correlate" <11>
correlation-strategy-expression="headers['foo']" <12>
correlation-strategy="correlationStrategyBean" <10>
correlation-strategy-method="correlate" <11>
correlation-strategy-expression="headers['foo']" <12>
ref="aggregatorBean" <13>
method="aggregate" <14>
ref="aggregatorBean" <13>
method="aggregate" <14>
release-strategy="releaseStrategyBean" <15>
release-strategy-method="release" <16>
release-strategy-expression="size() == 5" <17>
release-strategy="releaseStrategyBean" <15>
release-strategy-method="release" <16>
release-strategy-expression="size() == 5" <17>
expire-groups-upon-completion="false" <18>
empty-group-min-timeout="60000" <19>
expire-groups-upon-completion="false" <18>
empty-group-min-timeout="60000" <19>
lock-registry="lockRegistry" <20>
lock-registry="lockRegistry" <20>
group-timeout="60000" <21>
group-timeout-expression="size() ge 2 ? 100 : -1" <22>
expire-groups-upon-timeout="true" <23>
group-timeout="60000" <21>
group-timeout-expression="size() ge 2 ? 100 : -1" <22>
expire-groups-upon-timeout="true" <23>
scheduler="taskScheduler" > <24>
<expire-transactional/> <25>
<expire-advice-chain/> <26>
scheduler="taskScheduler" > <24>
<expire-transactional/> <25>
<expire-advice-chain/> <26>
</aggregator>
<int:channel id="outputChannel"/>
@@ -304,7 +303,7 @@ Below you can see an example of an aggregator.
<int:channel id="throwAwayChannel"/>
<bean id="persistentMessageStore" class="org.springframework.integration.jdbc.JdbcMessageStore">
<constructor-arg ref="dataSource"/>
<constructor-arg ref="dataSource"/>
</bean>
<bean id="aggregatorBean" class="sample.PojoAggregator"/>
@@ -329,8 +328,7 @@ _Required_.
<4> The channel to which the aggregator will send the aggregation results.
_Optional (because incoming messages can specify a
reply channel themselves via 'replyChannel' Message Header)_.
_Optional (because incoming messages can specify a reply channel themselves via 'replyChannel' Message Header)_.
@@ -344,7 +342,8 @@ _Optional_, by default a volatile in-memory store.
<7> Order of this aggregator when more than one handle is subscribed to the same DirectChannel (use for load balancing purposes)._Optional_.
<7> Order of this aggregator when more than one handle is subscribed to the same DirectChannel (use for load balancing purposes).
_Optional_.
@@ -380,9 +379,7 @@ _Optional (by default, the aggregator will use the `IntegrationMessageHeaderAcce
<11> A method defined on the bean referenced by `correlation-strategy`, that implements the correlation decision algorithm.
_Optional, with
restrictions (requires `correlation-strategy` to be
present)._
_Optional, with restrictions (requires `correlation-strategy` to be present)._
@@ -394,8 +391,7 @@ Only one of `correlation-strategy` or `correlation-strategy-expression` is allow
<13> A reference to a bean defined in the application context.
The bean must implement the aggregation logic as described above.
_Optional (by default the list of aggregated Messages will become a
payload of the output message)._
_Optional (by default the list of aggregated Messages will become a payload of the output message)._
<14> A method defined on the bean referenced by `ref`, that implements the message aggregation algorithm.
@@ -406,15 +402,12 @@ _Optional, depends on `ref` attribute being defined._
<15> A reference to a bean that implements the release strategy.
The bean can be an implementation of the `ReleaseStrategy` interface or a POJO.
In the latter case the release-strategy-method attribute must be defined as well.
_Optional (by default, the
aggregator will use the `IntegrationMessageHeaderAccessor.SEQUENCE_SIZE` header attribute)_.
_Optional (by default, the aggregator will use the `IntegrationMessageHeaderAccessor.SEQUENCE_SIZE` header attribute)_.
<16> A method defined on the bean referenced by `release-strategy`, that implements the completion decision algorithm.
_Optional, with
restrictions (requires `release-strategy` to be
present)._
_Optional, with restrictions (requires `release-strategy` to be present)._
@@ -575,7 +568,7 @@ NOTE: Wherever it makes sense, the release strategy method, correlation strategy
_Aggregators and Spring Expression Language (SpEL)_
Since Spring Integration 2.0, the various strategies (correlation, release, and aggregation) may be handled with http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html[SpEL] which is recommended if the logic behind such _release strategy_ is relatively simple.
Since Spring Integration 2.0, the various strategies (correlation, release, and aggregation) may be handled with http://docs.spring.io/spring/docs/current/spring-framework-reference/html/expressions.html[SpEL] which is recommended if the logic behind such _release strategy_ is relatively simple.
Let's say you have a legacy component that was designed to receive an array of objects.
We know that the default release strategy will assemble all aggregated messages in the List.
So now we have two problems.
@@ -601,7 +594,7 @@ However, with SpEL such a requirement could actually be handled relatively easil
expression="#this.![payload].toArray()"/>
----
In the above configuration we are using a http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html#d0e12113[Collection Projection] expression to assemble a new collection from the payloads of all messages in the list and then transforming it to an Array, thus achieving the same result as the java code above.
In the above configuration we are using a http://docs.spring.io/spring/docs/current/spring-framework-reference/html/expressions.html#expressions-collection-projection[Collection Projection] expression to assemble a new collection from the payloads of all messages in the list and then transforming it to an Array, thus achieving the same result as the java code above.
The same expression-based approach can be applied when dealing with custom _Release_ and _Correlation_ strategies.
@@ -692,12 +685,12 @@ If not present on any method, the aggregator will use the SequenceSizeReleaseStr
<3> 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.
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.
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.
The aggregator can be either referenced explicitly from XML or, if the `@MessageEndpoint` is defined on the class, detected automatically through classpath scanning.
Annotation configuration (`@Aggregator` and others) for the Aggregator component covers only simple use cases,
where most default options are sufficient.
@@ -807,7 +800,7 @@ So it is recommended to set the rate at least equal to the value of the timeout
In addition to the reaper, the expiry callbacks are invoked when the application shuts down via a lifecycle callback in the `AbstractCorrelatingMessageHandler`.
The `AbstractCorrelatingMessageHandler` registers its own expiry callback, and this is the link with the boolean flag` send-partial-result-on-expiry` in the XML configuration of the aggregator.
The `AbstractCorrelatingMessageHandler` registers its own expiry callback, and this is the link with the boolean flag `send-partial-result-on-expiry` in the XML configuration of the aggregator.
If the flag is set to true, then when the expiry callback is invoked, any unmarked messages in groups that are not yet released can be sent on to the output channel.
[IMPORTANT]

14
src/reference/asciidoc/configuration.adoc
View File

@@ -102,7 +102,7 @@ This is also defined as a constant:
IntegrationContextUtils.TASK_SCHEDULER_BEAN_NAME
----
By default Spring Integration relies on an instance of ThreadPoolTaskScheduler as described in the http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/scheduling.html[Task Execution and Scheduling] section of the Spring Framework reference manual.
By default Spring Integration relies on an instance of ThreadPoolTaskScheduler as described in the http://docs.spring.io/spring/docs/current/spring-framework-reference/html/scheduling.html[Task Execution and Scheduling] section of the Spring Framework reference manual.
That default TaskScheduler will startup automatically with a pool of 10 threads, but see <<global-properties>>.
If you provide your own TaskScheduler instance instead, you can set the 'autoStartup' property to _false_, and/or you can provide your own pool size value.
@@ -115,10 +115,8 @@ Also, polling consumers have a default `receiveTimeout` of 1 second; since the p
it is recommended that a task executor be used when many such endpoints exist, again to avoid starvation.
Alternatively, reduce the `receiveTimeout`.
NOTE: An endpoint is a _Polling Consumer_ if its input channel is one of the queue-based (i.e.
pollable) channels.
_Event Driven Consumers_ are those having input channels that have dispatchers instead of queues (i.e.
they are subscribable).
NOTE: An endpoint is a _Polling Consumer_ if its input channel is one of the queue-based (i.e. pollable) channels.
_Event Driven Consumers_ are those having input channels that have dispatchers instead of queues (i.e. they are subscribable).
Such endpoints have no poller configuration since their handlers will be invoked directly.
[IMPORTANT]
@@ -273,9 +271,9 @@ Annotations available in Spring Integration include:
The behavior of each is described in its own chapter or section within this reference.
NOTE: If you are using XML configuration in combination with annotations, the `@MessageEndpoint` annotation is not required.
If you want to configure a POJO reference from the "ref" attribute of a <service-activator/> element,
If you want to configure a POJO reference from the "ref" attribute of a `<service-activator/>` element,
it is sufficient to provide the method-level annotations.
In that case, the annotation prevents ambiguity even when no "method" attribute exists on the <service-activator/> element.
In that case, the annotation prevents ambiguity even when no "method" attribute exists on the `<service-activator/>` element.
In most cases, the annotated handler method should not require the `Message` type as its parameter.
Instead, the method parameter type can match the message's payload type.
@@ -757,7 +755,7 @@ The only difference is that the first argument will be mapped to the Message Pay
[source,java]
----
public String foo(@Headers Map m, @Header("foo")Map f, @Header("bar") String bar)
public String foo(@Headers Map m, @Header("foo") Map f, @Header("bar") String bar)
----
Yet another signature that would definitely be treated as ambiguous without annotations because it has more than 2 arguments.

5
src/reference/asciidoc/filter.adoc
View File

@@ -21,7 +21,8 @@ public interface MessageSelector {
}
----
The `MessageFilter` constructor accepts a selector instance:
The `MessageFilter` constructor accepts a selector instance:
[source,java]
----
MessageFilter filter = new MessageFilter(someSelector);
@@ -97,7 +98,7 @@ It can be used to avoid Java entirely for simple filters.
----
The string passed as the expression attribute will be evaluated as a SpEL expression with the Message available in the evaluation context.
If it is necessary to include the result of an expression in the scope of the application context you can use the #{} notation as defined in thehttp://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html#expressions-beandef[SpEL reference documentation].
If it is necessary to include the result of an expression in the scope of the application context you can use the #{} notation as defined in the http://docs.spring.io/spring/docs/current/spring-framework-reference/html/expressions.html#expressions-beandef[SpEL reference documentation].
[source,xml]
----

14
src/reference/asciidoc/groovy.adoc
View File

@@ -31,7 +31,7 @@ Also note that the `lang` attribute on the `<script>` tag is not valid in this n
_Groovy object customization_
If you need to customize the Groovy object itself, beyond setting variables, you can reference a bean that implements `org.springframework.scripting.groovy.GroovyObjectCustomizer` via the `customizer` attribute.
If you need to customize the Groovy object itself, beyond setting variables, you can reference a bean that implements `GroovyObjectCustomizer` via the `customizer` attribute.
For example, this might be useful if you want to implement a domain-specific language (DSL) by modifying the `MetaClass` and registering functions to be available within the script:
[source,xml]
----
@@ -50,10 +50,10 @@ Also, groovy scripts have the ability to resolve a variable to a bean in the `Be
[source,xml]
----
<int-groovy:script>
<![CDATA[
entityManager.persist(payload)
payload
]]>
<![CDATA[
entityManager.persist(payload)
payload
]]>
</int-groovy:script>
----
@@ -126,7 +126,7 @@ In Spring Integration we build upon the adapters described above so that it's po
One option for those operations is Groovy scripts.
[source,xml]
----
<int-groovy:control-bus input-channel="operationChannel"/>
<int-groovy:control-bus input-channel="operationChannel"/>
----
The Control Bus has an input channel that can be accessed for invoking operations on the beans in the application context.
@@ -141,7 +141,7 @@ IMPORTANT: Be careful about using managed beans with custom scopes (e.g.
If The Control Bus' `MessageProcessor` can't expose a bean from the application context, you may end up with some `BeansException` during _command script's_ executing.
For example, if a custom scope's context is not established, the attempt to get a bean within that scope will trigger a `BeanCreationException`.
If you need to further customize the Groovy objects, you can also provide a reference to a bean that implements `org.springframework.scripting.groovy.GroovyObjectCustomizer` via the `customizer` attribute.
If you need to further customize the Groovy objects, you can also provide a reference to a bean that implements `GroovyObjectCustomizer` via the `customizer` attribute.
[source,xml]
----

12
src/reference/asciidoc/http.adoc
View File

@@ -61,12 +61,12 @@ recommended by `RFC 2616`.
Previously, the body of such messages was ignored.
Starting with _Spring Integration 2.0_, MultiPart File support is implemented.
If the request has been wrapped as a _MultipartHttpServletRequest_, when using the default converters, that request will be converted to a Message payload that is a MultiValueMap containing values that may be byte arrays, Strings, or instances of Spring's `MultipartFile` depending on the content type of the individual parts.
If the request has been wrapped as a `MultipartHttpServletRequest`, when using the default converters, that request will be converted to a Message payload that is a `MultiValueMap` containing values that may be byte arrays, Strings, or instances of Spring's `MultipartFile` depending on the content type of the individual parts.
NOTE: The HTTP inbound Endpoint will locate a MultipartResolver in the context if one exists with the bean name "multipartResolver" (the same name expected by Spring's DispatcherServlet).
NOTE: The HTTP inbound Endpoint will locate a `MultipartResolver` in the context if one exists with the bean name "multipartResolver" (the same name expected by Spring's `DispatcherServlet`).
If it does in fact locate that bean, then the support for MultipartFiles will be enabled on the inbound request mapper.
Otherwise, it will fail when trying to map a multipart-file request to a Spring Integration Message.
For more on Spring's support for MultipartResolvers, refer to the
For more on Spring's support for `MultipartResolver`, refer to the
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html#mvc-multipart[Spring Reference Manual].
[NOTE]
@@ -245,7 +245,7 @@ The parsing of the _HTTP Inbound Gateway_ or the _HTTP Inbound Channel Adapter_
This particular implementation of the http://static.springsource.org/spring/docs/current/javadoc-api/org/springframework/web/servlet/HandlerMapping.html[`HandlerMapping`] delegates its logic to the http://static.springsource.org/spring/docs/current/javadoc-api/org/springframework/web/servlet/mvc/method/RequestMappingInfoHandlerMapping.html[`RequestMappingInfoHandlerMapping`].
The implementation provides similar functionality as the one provided by the http://static.springsource.org/spring/docs/current/javadoc-api/org/springframework/web/bind/annotation/RequestMapping.html[`org.springframework.web.bind.annotation.RequestMapping`] annotation in Spring MVC.
NOTE: For more information, please see http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html#mvc-ann-requestmapping[Mapping Requests With @RequestMapping].
NOTE: For more information, please see http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html#mvc-ann-requestmapping[Mapping Requests With `@RequestMapping`].
For this purpose, _Spring Integration 3.0_ introduces the `<request-mapping>` sub-element.
This optional sub-element can be added to the `<http:inbound-channel-adapter>` and the `<http:inbound-gateway>`.
@@ -642,7 +642,7 @@ With some JVM implementations, the handling of timeouts using the _URLConnection
E.g.
from the _Java™ Platform, Standard Edition 6 API Specification_ on _setConnectTimeout_: [quote]
Some non-standard implmentation of this method may ignore the specified timeout.
Some non-standard implementation of this method may ignore the specified timeout.
To see the connect timeout set, please call getConnectTimeout().
Please test your timeouts if you have specific needs.
@@ -756,7 +756,7 @@ However if you do need further customization you may provide additional configur
You can provide a comma-separated list of header names, and you can also include simple patterns with the '*' character acting as a wildcard.
If you do provide such values, it will override the default behavior.
Basically, it assumes you are in complete control at that point.
However, if you do want to include all of the standard HTTP headers, you can use the shortcut patterns: HTTP_REQUEST_HEADERS and HTTP_RESPONSE_HEADERS.
However, if you do want to include all of the standard HTTP headers, you can use the shortcut patterns: `HTTP_REQUEST_HEADERS` and `HTTP_RESPONSE_HEADERS`.
Here are some examples:
[source,xml]
----

19
src/reference/asciidoc/resequencer.adoc
View File

@@ -68,7 +68,8 @@ _Optional_.
<5> Whether to send out ordered sequences as soon as they are available, or only after the whole message group arrives._Optional (false by default)_.
<5> Whether to send out ordered sequences as soon as they are available, or only after the whole message group arrives.
_Optional (false by default)_.
@@ -77,7 +78,8 @@ _Optional_ with default a volatile in-memory store.
<7> Whether, upon the expiration of the group, the ordered group should be sent out (even if some of the messages are missing)._Optional (false by default)_.
<7> Whether, upon the expiration of the group, the ordered group should be sent out (even if some of the messages are missing).
_Optional (false by default)_.
See <<reaper>>.
@@ -101,9 +103,7 @@ _Optional (by default, the aggregator will use the `IntegrationMessageHeaderAcce
<10> A method defined on the bean referenced by `correlation-strategy`, that implements the correlation decision algorithm.
_Optional, with
restrictions (requires `correlation-strategy` to be
present)._
_Optional, with restrictions (requires `correlation-strategy` to be present)._
@@ -116,15 +116,12 @@ Only one of `correlation-strategy` or `correlation-strategy-expression` is allow
<12> A reference to a bean that implements the release strategy.
The bean can be an implementation of the `ReleaseStrategy` interface or a POJO.
In the latter case the release-strategy-method attribute must be defined as well.
_Optional (by default, the
aggregator will use the `IntegrationMessageHeaderAccessor.SEQUENCE_SIZE` header attribute)_.
_Optional (by default, the aggregator will use the `IntegrationMessageHeaderAccessor.SEQUENCE_SIZE` header attribute)_.
<13> A method defined on the bean referenced by `release-strategy`, that implements the completion decision algorithm.
_Optional, with
restrictions (requires `release-strategy` to be
present)._
_Optional, with restrictions (requires `release-strategy` to be present)._
@@ -134,7 +131,7 @@ Only one of `release-strategy` or `release-strategy-expression` is allowed.
<15> Only applies if a `MessageGroupStoreReaper` is configured for the `<resequcencer>`'s `MessageStore`.
<15> Only applies if a `MessageGroupStoreReaper` is configured for the `<resequcencer>` `MessageStore`.
By default, when a `MessageGroupStoreReaper` is configured to expire partial groups, empty groups are also removed.
Empty groups exist after a group is released normally.
This is to enable the detection and discarding of late-arriving messages.

14
src/reference/asciidoc/router.adoc
View File

@@ -716,8 +716,7 @@ They are available using <<control-bus>> as well as via JMX:
[source,java]
----
messagingTemplate.convertAndSend(controlBus,
"@'simpleRouter.handler'.addRecipient('channel2')");
messagingTemplate.convertAndSend(controlBus, "@'simpleRouter.handler'.addRecipient('channel2')");
----
@@ -975,14 +974,15 @@ But the configuration is still perfectly valid.
So the natural question is what about the mapping in the Step 2?
What this means is that Step 2 is now an optional step.
If `mapping` is not defined then the `channel identifier` value computed in Step 1 will automatically be treated as the `channel name`, which will now be resolved to the actual `MessageChannel` as in Step 3. What it also means is that Step 2 is one of the key steps to provide dynamic characteristics to the routers, since it introduces a process which_allows you to change the way 'channel identifier' resolves to 'channel name'_, thus influencing the process of determining the final instance of the `MessageChannel` from the initial `channel identifier`. 
If `mapping` is not defined then the `channel identifier` value computed in Step 1 will automatically be treated as the `channel name`, which will now be resolved to the actual `MessageChannel` as in Step 3. 
What it also means is that Step 2 is one of the key steps to provide dynamic characteristics to the routers, since it introduces a process which _allows you to change the way 'channel identifier' resolves to 'channel name'_, thus influencing the process of determining the final instance of the `MessageChannel` from the initial `channel identifier`. 
_For Example:_
In the above configuration let's assume that the `testHeader` value is 'kermit' which is now a `channel identifier` (Step 1).
Since there is no mapping in this router, resolving this `channel identifier` to a `channel name` (Step 2) is impossible and this `channel identifier` is now treated as `channel name`.
However what if there was a mapping but for a different value? The end result would still be the same and that is:_if a new value cannot be determined through the process of resolving the 'channel identifier' to a 'channel name',
such 'channel identifier' becomes 'channel name'._
However what if there was a mapping but for a different value?
The end result would still be the same and that is: _if a new value cannot be determined through the process of resolving the 'channel identifier' to a 'channel name', such 'channel identifier' becomes 'channel name'._
So all that is left is for Step 3 to resolve the `channel name` ('kermit') to an actual instance of the `MessageChannel` identified by this name.
That basically involves a bean lookup for the name provided.
@@ -1064,8 +1064,8 @@ Configuration for the _Routing Slip_ is presented as a `HeaderEnricher` option -
<header-enricher input-channel="input" output-channel="process">
<routing-slip
value="${myRoutePath1}; @routingSlipRoutingPojo.get(request, reply);
routingSlipRoutingStrategy; ${myRoutePath2}; finishChannel"/>
value="${myRoutePath1}; @routingSlipRoutingPojo.get(request, reply);
routingSlipRoutingStrategy; ${myRoutePath2}; finishChannel"/>
</header-enricher>
----

17
src/reference/asciidoc/scatter-gather.adoc
View File

@@ -28,7 +28,7 @@ However, this channel can be any `MessageChannel` implementation as is the case
_Distribution_
The _Distribution_`Scatter-Gather` variant is based on the `RecipientListRouter` (see <<router-implementations-recipientlistrouter>>) with all available options for the `RecipientListRouter`.
The _Distribution_ `Scatter-Gather` variant is based on the `RecipientListRouter` (see <<router-implementations-recipientlistrouter>>) with all available options for the `RecipientListRouter`.
This is the second `ScatterGatherHandler` constructor argument.
If you want to rely just on the default `correlationStrategy` for the `recipient-list-router` and the `aggregator`, you should specify `apply-sequence="true"`.
Otherwise, a custom `correlationStrategy` should be supplied for the `aggregator`.
@@ -50,11 +50,11 @@ For Java and Annotation configuration, the bean definition for the `Scatter-Gath
----
@Bean
public MessageHandler distributor() {
RecipientListRouter router = new RecipientListRouter();
router.setApplySequence(true);
router.setChannels(Arrays.asList(distributionChannel1(), distributionChannel2(),
distributionChannel3()));
return router;
RecipientListRouter router = new RecipientListRouter();
router.setApplySequence(true);
router.setChannels(Arrays.asList(distributionChannel1(), distributionChannel2(),
distributionChannel3()));
return router;
}
@Bean
@@ -121,14 +121,13 @@ _Required_.
<4> The channel to which the Scatter-Gather will send the aggregation results.
_Optional (because incoming messages can specify a
reply channel themselves via `replyChannel` Message Header)_.
_Optional (because incoming messages can specify a reply channel themselves via `replyChannel` Message Header)_.
<5> The channel to send the scatter message for the _Auction_ scenario.
_Optional_.
Mutually exclusive with `<scatterer>` sub -element.
Mutually exclusive with `<scatterer>` sub-element.

34
src/reference/asciidoc/scripting.adoc
View File

@@ -83,9 +83,9 @@ You can bind additional variables to a script via `<variable>` sub-elements:
[source,xml]
----
<script:script lang="js" location="foo/bar/MyScript.js">
<script:variable name="foo" value="foo"/>
<script:variable name="bar" value="bar"/>
<script:variable name="date" ref="date"/>
<script:variable name="foo" value="foo"/>
<script:variable name="bar" value="bar"/>
<script:variable name="date" ref="date"/>
</script:script>
----
@@ -99,17 +99,17 @@ Also, since _Spring Integration 3.0_, variable bindings are allowed for inline s
[source,xml]
----
<service-activator input-channel="input">
<script:script lang="ruby" variables="foo=FOO, date-ref=dateBean">
<script:variable name="bar" ref="barBean"/>
<script:variable name="baz" value="bar"/>
<![CDATA[
payload.foo = foo
payload.date = date
payload.bar = bar
payload.baz = baz
payload
]]>
</script:script>
<script:script lang="ruby" variables="foo=FOO, date-ref=dateBean">
<script:variable name="bar" ref="barBean"/>
<script:variable name="baz" value="bar"/>
<![CDATA[
payload.foo = foo
payload.date = date
payload.bar = bar
payload.baz = baz
payload
]]>
</script:script>
</service-activator>
----
@@ -124,7 +124,7 @@ If you need more control over how variables are generated, you can implement you
----
public interface ScriptVariableGenerator {
Map<String, Object> generateScriptVariables(Message<?> message);
Map<String, Object> generateScriptVariables(Message<?> message);
}
----
@@ -136,11 +136,11 @@ All you need to do is provide an implementation of `ScriptVariableGenerator` and
[source,xml]
----
<int-script:script location="foo/bar/MyScript.groovy"
script-variable-generator="variableGenerator"/>
script-variable-generator="variableGenerator"/>
<bean id="variableGenerator" class="foo.bar.MyScriptVariableGenerator"/>
----
If a `script-variable-generator` is not provided, script components use `org.springframework.integration.scripting.DefaultScriptVariableGenerator`, which merges any provided `<variable>` s with _payload_ and _headers_ variables from the `Message` in its `generateScriptVariables(Message)` method.
If a `script-variable-generator` is not provided, script components use `DefaultScriptVariableGenerator`, which merges any provided `<variable>` s with _payload_ and _headers_ variables from the `Message` in its `generateScriptVariables(Message)` method.
IMPORTANT: You cannot provide both the `script-variable-generator` attribute and `<variable>` sub-element(s) as they are mutually exclusive.

24
src/reference/asciidoc/transformer.adoc
View File

@@ -52,13 +52,13 @@ If the return value is itself a `Message`, that will be passed along to the tran
As of Spring Integration 2.0, a Message Transformer's transformation method can no longer return `null`.
Returning `null` will result in an exception since a Message Transformer should always be expected to transform each source Message into a valid target Message.
In other words, a Message Transformer should not be used as a Message Filter since there is a dedicated <filter> option for that.
However, if you do need this type of behavior (where a component might return NULL and that should not be considered an error), a_service-activator_ could be used.
In other words, a Message Transformer should not be used as a Message Filter since there is a dedicated `<filter>` option for that.
However, if you do need this type of behavior (where a component might return NULL and that should not be considered an error), a _service-activator_ could be used.
Its `requires-reply` value is FALSE by default, but that can be set to TRUE in order to have Exceptions thrown for NULL return values as with the transformer.
_Transformers and Spring Expression Language (SpEL)_
Just like Routers, Aggregators and other components, as of Spring Integration 2.0 Transformers can also benefit from SpEL support (http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html) whenever transformation logic is relatively simple.
Just like Routers, Aggregators and other components, as of Spring Integration 2.0 Transformers can also benefit from SpEL support (http://docs.spring.io/spring/docs/current/spring-framework-reference/html/expressions.html) whenever transformation logic is relatively simple.
[source,xml]
----
@@ -76,8 +76,8 @@ There are also a few Transformer implementations available out of the box.
====== Object-to-String Transformer
Because, it is fairly common to use the `toString()` representation of an Object, Spring Integration provides an `ObjectToStringTransformer` 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.
Because, it is fairly common to use the `toString()` representation of an Object, Spring Integration provides an `ObjectToStringTransformer` 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.
[source,xml]
----
<int:object-to-string-transformer input-channel="in" output-channel="out"/>
@@ -102,7 +102,7 @@ For more sophistication (such as selection of the charset dynamically, at runtim
[source,xml]
----
<int:transformer input-channel="in" output-channel="out"
expression="new java.lang.String(payload, headers['myCharset']" />
expression="new java.lang.String(payload, headers['myCharset']" />
----
=====
@@ -132,9 +132,9 @@ public class Parent{
}
public class Child{
   private String name; 
   private List<String> nickNames;
   // setters and getters are omitted
    private String name; 
   private List<String> nickNames;
    // setters and getters are omitted
}
----
@@ -152,9 +152,9 @@ public class Father {
}
public class Kid {
   private String name; 
   private List<String> nickNames;
   // setters and getters are omitted
    private String name; 
   private List<String> nickNames;
   // setters and getters are omitted
}
----