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

Removed the troublesome backticks

Browse Source 
Removed the backticks that were making links not render. Fixed a few typoes, too.

Integrating feedback from Artem

Artem caught some errors that I had made (and that my editor, Atom, had made - grrr). I fixed them.

Thanks, Artem. :)

Removing duplicate content

I caught that duplicate content somehow got added to preface.adoc. I removed one set of it to make that content not be duplicated.

* Fix `jdbc.adoc` typos
This commit is contained in:
Jay Bryant
2018-06-28 13:43:24 -05:00
committed by Artem Bilan
parent 5c1c82efd7
commit 997183bee2
70 changed files with 633 additions and 610 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -97,7 +97,7 @@ However, there are better solutions, less coupled to the API, for implementing t
In general, any POJO can implement the aggregation algorithm if it provides a method that accepts a single `java.util.List` as an argument (parameterized lists are supported as well).
This method is invoked for aggregating messages as follows:
* If the argument is a `java.util.Collection<T>`, and the parameter type T is assignable to `Message`, the whole list of messages accumulated for aggregation is sent to the aggregator.
* If the argument is a `java.util.Collection<T>` and the parameter type T is assignable to `Message`, the whole list of messages accumulated for aggregation is sent to the aggregator.
* If the argument is a non-parameterized `java.util.Collection` or the parameter type is not assignable to `Message`, the method receives the payloads of the accumulated messages.
* If the return type is not assignable to `Message`, it is treated as the payload for a `Message` that is automatically created by the framework.
@@ -142,7 +142,7 @@ public interface ReleaseStrategy {
In general, any POJO can implement the completion decision logic if it provides a method that accepts a single `java.util.List` as an argument (parameterized lists are supported as well) and returns a boolean value.
This method is invoked after the arrival of each new message, to decide whether the group is complete or not, as follows:
* If the argument is a `java.util.List<T>`, and the parameter type `T` is assignable to `Message`, the whole list of messages accumulated in the group is sent to the method.
* If the argument is a `java.util.List<T>` and the parameter type `T` is assignable to `Message`, the whole list of messages accumulated in the group is sent to the method.
* If the argument is a non-parametrized `java.util.List` or the parameter type is not assignable to `Message`, the method receives the payloads of the accumulated messages.
* The method must return `true` if the message group is ready for aggregation or false otherwise.
@@ -197,7 +197,7 @@ IMPORTANT: To facilitate discarding of late-arriving messages, the aggregator mu
This can eventually cause out-of-memory conditions.
To avoid such situations, you should consider configuring a `MessageGroupStoreReaper` to remove the group metadata.
The expiry parameters should be set to expire groups once a point has been reach after after which late messages are not expected to arrive.
For information about configuring a reaper, see "`<<reaper>>`".
For information about configuring a reaper, see <<reaper>>.
Spring Integration provides an implementation for `ReleaseStrategy`: `SimpleSequenceSizeReleaseStrategy`.
This implementation consults the `SEQUENCE_NUMBER` and `SEQUENCE_SIZE` headers of each arriving message to decide when a message group is complete and ready to be aggregated.
@@ -215,7 +215,7 @@ The 4.3 release changed the default `Collection` for messages in a `SimpleMessag
This was expensive when removing individual messages from large groups (an O(n) linear scan was required).
Although the hash set is generally much faster to remove, it can be expensive for large messages, because the hash has to be calculated on both inserts and removes.
If you have messages that are expensive to hash, consider using some other collection type.
As discussed in "`<<message-group-factory>>`", a `SimpleMessageGroupFactory` is provided so that you can select the `Collection` that best suits your needs.
As discussed in <<message-group-factory>>, a `SimpleMessageGroupFactory` is provided so that you can select the `Collection` that best suits your needs.
You can also provide your own factory implementation to create some other `Collection<Message<?>>`.
The following example shows how to configure an aggregator with the previous implementation and a `SimpleSequenceSizeReleaseStrategy`:
@@ -269,12 +269,12 @@ If you have a custom header name you would like to use for correlation, you can
Changes to groups are thread safe.
A `LockRegistry` is used to obtain a lock for the resolved correlation ID.
A `DefaultLockRegistry` is used by default (in-memory).
For synchronizing updates across servers, where a shared `MessageGroupStore` is being used, you must configure a shared lock registry.
For synchronizing updates across servers where a shared `MessageGroupStore` is being used, you must configure a shared lock registry.
[[aggregator-java-dsl]]
==== Configuring an Aggregator in Java DSL
See "`<<java-dsl-aggregators>>`" for how to configure an aggregator in Java DSL.
See <<java-dsl-aggregators>> for how to configure an aggregator in Java DSL.
[[aggregator-xml]]
===== Configuring an Aggregator with XML
@@ -349,7 +349,7 @@ Optional.
<6> A reference to a `MessageGroupStore` used to store groups of messages under their correlation key until they are complete.
Optional.
By default, it is a volatile in-memory store.
See "`<<message-store>>`" for more information.
See <<message-store>> for more information.
<7> The order of this aggregator when more than one handle is subscribed to the same `DirectChannel` (use for load-balancing purposes).
Optional.
<8> Indicates that expired messages should be aggregated and sent to the 'output-channel' or 'replyChannel' once their containing `MessageGroup` is expired (see https://docs.spring.io/spring-integration/api/org/springframework/integration/store/MessageGroupStore.html#expireMessageGroups-long[`MessageGroupStore.expireMessageGroups(long)`]).
@@ -407,7 +407,7 @@ Note that the actual time to expire an empty group is also affected by the reape
It used to obtain a `Lock` based on the `groupId` for concurrent operations on the `MessageGroup`.
By default, an internal `DefaultLockRegistry` is used.
Use of a distributed `LockRegistry`, such as the `ZookeeperLockRegistry`, ensures only one instance of the aggregator can operate on a group concurrently.
See "`<<redis-lock-registry>>`", "`<<gemfire-lock-registry>>`", and "`<<zk-lock-registry>>`" for more information.
See <<redis-lock-registry>>, <<gemfire-lock-registry>>, and <<zk-lock-registry>> for more information.
<21> A timeout (in milliseconds) to force the `MessageGroup` complete when the `ReleaseStrategy` does not release the group when the current message arrives.
This attribute provides a built-in time-based release strategy for the aggregator when there is a need to emit a partial result (or discard the group) if a new message does not arrive for the `MessageGroup` within the timeout.
When a new message arrives at the aggregator, any existing `ScheduledFuture<?>` for its `MessageGroup` is canceled.
@@ -417,7 +417,7 @@ Doing so effectively disables the aggregator, because every message group is imm
You can, however, conditionally set it to zero (or a negative value) by using an expression.
See `group-timeout-expression` for information.
The action taken during the completion depends on the `ReleaseStrategy` and the `send-partial-group-on-expiry` attribute.
See "`<<agg-and-group-to>>`" for more information.
See <<agg-and-group-to>> for more information.
It is mutually exclusive with 'group-timeout-expression' attribute.
<22> The SpEL expression that evaluates to a `groupTimeout` with the `MessageGroup` as the `#root` evaluation context object.
Used for scheduling the `MessageGroup` to be forced complete.
@@ -610,7 +610,7 @@ In the preceding example, the root object of the SpEL evaluation context is the
====== Aggregator and Group Timeout
Starting with version 4.0, two new mutually exclusive attributes have been introduced: `group-timeout` and `group-timeout-expression` (see the earlier description).
See "`<<aggregator-xml>>`".
See <<aggregator-xml>>.
In some cases, you may need to emit the aggregator result (or discard the group) after a timeout if the `ReleaseStrategy` does not release when the current message arrives.
For this purpose, the `groupTimeout` option lets scheduling the `MessageGroup` be forced to complete, as the following example shows:
@@ -634,7 +634,7 @@ If the release strategy still does not release the group, it is expired.
If `send-partial-result-on-expiry` is `true`, existing messages in the (partial) `MessageGroup` are released as a normal aggregator reply message to the `output-channel`.
Otherwise, it is discarded.
There is a difference between `groupTimeout` behavior and `MessageGroupStoreReaper` (see "`<<aggregator-xml>>`").
There is a difference between `groupTimeout` behavior and `MessageGroupStoreReaper` (see <<aggregator-xml>>).
The reaper initiates forced completion for all `MessageGroup` s in the `MessageGroupStore` periodically.
The `groupTimeout` does it for each `MessageGroup` individually if a new message does not arrive during the `groupTimeout`.
Also, the reaper can be used to remove empty groups (empty groups are retained in order to discard late messages if `expire-groups-upon-completion` is false).
@@ -699,7 +699,7 @@ public MessageHandler aggregator(MessageGroupStore jdbcMessageGroupStore) {
----
====
See "`<<aggregator-api>>`" and "`<<annotations_on_beans>>`" for more information.
See <<aggregator-api>> and <<annotations_on_beans>> for more information.
NOTE: Starting with version 4.2, the `AggregatorFactoryBean` is available to simplify Java configuration for the `AggregatingMessageHandler`.
@@ -761,7 +761,7 @@ public interface MessageGroupCallback {
The callback has direct access to the store and the message group so that it can manage the persistent state (for example, by entirely removing the group from the store).
The `MessageGroupStore` maintains a list of these callbacks, which it applies, on demand, to all messages whose timestamps are earlier than a time supplied as a parameter (see the `registerMessageGroupExpiryCallback(..)` and `expireMessageGroups(..)` methods, described earlier).
For more detail, see "`<<reaper>>`".
For more detail, see <<reaper>>.
You can call the `expireMessageGroups` method with a timeout value.
Any message older than the current time minus this value is expired and has the callbacks applied.
@@ -805,5 +805,5 @@ Messages with the same correlation key are stored in the same message group.
Some `MessageStore` implementations allow using the same physical resources, by partitioning the data.
For example, the `JdbcMessageStore` has a `region` property, and the `MongoDbMessageStore` has a `collectionName` property.
For more information about the `MessageStore` interface and its implementations, see "`<<message-store>>`".
For more information about the `MessageStore` interface and its implementations, see <<message-store>>.
=====

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

@@ -71,7 +71,7 @@ The user application is responsible for acknowledgement.
`NONE` means no acknowledgements (`autoAck`).
`AUTO` means the adapter's container acknowledges when the downstream flow completes.
Optional (defaults to AUTO).
See "`<<amqp-inbound-ack>>`".
See <<amqp-inbound-ack>>.
<5> Extra AOP Advices to handle cross-cutting behavior associated with this inbound channel adapter.
Optional.
<6> Flag to indicate that channels created by this component are transactional.
@@ -260,7 +260,7 @@ public class AmqpJavaApplication {
=== Polled Inbound Channel Adapter
Version 5.0.1 introduced a polled channel adapter, letting you fetch individual messages on demand -- for example, with a `MessageSourcePollingTemplate` or a poller.
See "`<<deferred-acks-message-source>>`" for more information.
See <<deferred-acks-message-source>> for more information.
It does not currently support XML configuration.
@@ -347,7 +347,7 @@ If this option is not specified and an external `amqp-template` is provided, no
You must either specify this option or configure a default `exchange` and `routingKey` on that template,
if you anticipate cases when no `replyTo` property exists in the request message.
See the note in "`<<amqp-inbound-channel-adapter>>`" about configuring the `listener-container` attribute.
See the note in <<amqp-inbound-channel-adapter>> about configuring the `listener-container` attribute.
==== Configuring with Java Configuration
@@ -974,7 +974,7 @@ When `true` (the default), the connection is established (if it does not already
it) when the first message is sent.
====
See also "`<<async-service-activator>>`" for more information.
See also <<async-service-activator>> for more information.
[IMPORTANT]
.RabbitTemplate
@@ -1194,7 +1194,7 @@ The entire message was converted (serialized) and sent to RabbitMQ.
Now, you can set the `extract-payload` attribute (or `setExtractPayload()` when using Java configuration) to `true`.
When this flag is `true`, the message payload is converted and the headers are mapped, in a manner similar to when you use channel adapters.
This arrangement lets AMQP-backed channels be used with non-serializable payloads (perhaps with another message converter, such as the `Jackson2JsonMessageConverter`).
See "`<<amqp-message-headers>>`" for more about the default mapped headers.
See <<amqp-message-headers>> for more about the default mapped headers.
You can modify the mapping by providing custom mappers that use the `outbound-header-mapper` and `inbound-header-mapper` attributes.
You can now also specify a `default-delivery-mode`, which is used to set the delivery mode when there is no `amqp_deliveryMode` header.
By default, Spring AMQP `MessageProperties` uses `PERSISTENT` delivery mode.
@@ -1314,7 +1314,7 @@ The `org.springframework.amqp.support.AmqpHeaders` class identifies the default
* `amqp_clusterId`
* `amqp_contentEncoding`
* `amqp_contentLength`
* `content-type` (see "`<<amqp-content-type>>`")
* `content-type` (see <<amqp-content-type>>)
* `amqp_correlationId`
* `amqp_delay`
* `amqp_deliveryMode`
@@ -1418,7 +1418,7 @@ This is because the template "`borrows`" a channel from the cache for each send
One solution is to start a transaction before the splitter, but transactions are expensive in RabbitMQ and can reduce performance several hundred fold.
To solve this problem in a more efficient manner, starting with version 5.1, Spring Integration provides the `BoundRabbitChannelAdvice` which is a `HandleMessageAdvice`.
See "`<<handle-message-advice>>`".
See <<handle-message-advice>>.
When applied before the splitter, it ensures that all downstream operations are performed on the same channel and, optionally, can wait until publisher confirmations for all sent messages are received (if the connection factory is configured for confirmations).
The following example shows how to use `BoundRabbitChannelAdvice`:

38
src/reference/asciidoc/changes-1.0-2.0.adoc
View File

@@ -18,7 +18,7 @@ This guide includes many samples.
===== Conversion Service and Converter
You can now benefit from the conversion service support provided with Spring while configuring many Spring Integration components, such as a http://www.eaipatterns.com/DatatypeChannel.html[Datatype channel].
See "`<<channel-implementations>>`" and "`<<service-activator-introduction>>`".
See <<channel-implementations>> and <<service-activator-introduction>>.
Also, the SpEL support mentioned in the previous point also relies upon the conversion service.
Therefore, you can register converters once and take advantage of them anywhere you use SpEL expressions.
@@ -30,14 +30,14 @@ Spring Integration (which uses a lot of scheduling) now builds upon these.
In fact, Spring Integration 1.0 had originally defined some of the components (such as `CronTrigger`) that have now been migrated into Spring 3.0's core API.
Now you can benefit from reusing the same components within the entire application context (not just Spring Integration configuration).
We also greatly simplified configuration of Spring Integration pollers by providing attributes for directly configuring rates, delays, cron expressions, and trigger references.
See "`<<channel-adapter>>`" for sample configurations.
See <<channel-adapter>> for sample configurations.
[[rest-support]]
===== `RestTemplate` and `HttpMessageConverter`
Our outbound HTTP adapters now delegate to Spring's `RestTemplate` for executing the HTTP request and handling its response.
This also means that you can reuse any custom `HttpMessageConverter` implementations.
See "`<<http-outbound>>`" for more details.
See <<http-outbound>> for more details.
[[new-eip]]
==== Enterprise Integration Pattern Additions
@@ -48,7 +48,7 @@ Also in 2.0, we have added support for even more of the patterns described in Ho
===== Message History
We now provide support for the http://www.eaipatterns.com/MessageHistory.html[message history] pattern, letting you keep track of all traversed components, including the name of each channel and endpoint as well as the timestamp of that traversal.
See "`<<message-history>>`" for more details.
See <<message-history>> for more details.
[[new-message-store]]
===== Message Store
@@ -56,7 +56,7 @@ See "`<<message-history>>`" for more details.
We now provide support for the http://www.eaipatterns.com/MessageStore.html[message store] pattern.
The message store provides a strategy for persisting messages on behalf of any process whose scope extends beyond a single transaction, such as the aggregator and the resequencer.
Many sections of this guide include samples of how to use a message store, as it affects several areas of Spring Integration.
See "`<<message-store>>`", "`<<claim-check>>`", "`<<channel>>`", "`<<aggregator>>`", "`<<jdbc>>`", and "`<<resequencer>>`" for more details.
See <<message-store>>, <<claim-check>>, <<channel>>, <<aggregator>>, <<jdbc>>`", and <<resequencer>> for more details.
[[new-claim-check]]
===== Claim Check
@@ -64,14 +64,14 @@ See "`<<message-store>>`", "`<<claim-check>>`", "`<<channel>>`", "`<<aggregator>
We have added an implementation of the http://www.eaipatterns.com/StoreInLibrary.html[claim check] pattern.
The idea behind the claim check pattern is that you can exchange a message payload for a "`claim ticket`".
This lets you reduce bandwidth and avoid potential security issues when sending messages across channels.
See "`<<claim-check>>`" for more details.
See <<claim-check>> for more details.
[[new-control-bus]]
===== Control Bus
We have provided implementations of the http://www.eaipatterns.com/ControlBus.html[control bus] pattern, which lets you use messaging to manage and monitor endpoints and channels.
The implementations include both a SpEL-based approach and one that runs Groovy scripts.
See "`<<control-bus>>`" and "`<<groovy-control-bus>>`" for more details.
See <<control-bus>> and <<groovy-control-bus>> for more details.
[[new-adapters]]
==== New Channel Adapters and Gateways
@@ -82,39 +82,39 @@ We have added several new channel adapters and messaging gateways in Spring Inte
===== TCP and UDP Adapters
We have added channel adapters for receiving and sending messages over the TCP and UDP internet protocols.
See "`<<ip>>`" for more details.
See <<ip>> for more details.
See also the following blog: http://blog.springsource.com/2010/03/29/using-udp-and-tcp-adapters-in-spring-integration-2-0-m3/["`Using UDP and TCP Adapters in Spring Integration 2.0 M3`"].
[[new-twitter]]
===== Twitter Adapters
Twitter adapters provides support for sending and receiving Twitter Status updates as well as Direct Messages.
You can also perform Twitter Searches with an inbound Channel Adapter.
Twitter adapters provides support for sending and receiving Twitter status updates as well as direct messages.
You can also perform Twitter Searches with an inbound channel adapter.
See https://github.com/spring-projects/spring-integration-extensions/tree/master/spring-integration-social-twitter[Spring Integration Social Twitter] for more details.
[[new-xmpp]]
===== XMPP Adapters
The new XMPP adapters support both chat messages and presence events.
See "`<<xmpp>>`" for more details.
See <<xmpp>> for more details.
[[new-ftp]]
===== FTP and FTPS Adapters
Inbound and outbound file transfer support over FTP and FTPS is now available.
See "`<<ftp>>`" for more details.
See <<ftp>> for more details.
[[new-sftp]]
===== SFTP Adapters
Inbound and outbound file transfer support over SFTP is now available.
See "`<<sftp>>`" for more details.
See <<sftp>> for more details.
[[new-feed]]
===== Feed Adapters
We have also added channel adapters for receiving news feeds (ATOM and RSS).
See "`<<feed>>`" for more details.
See <<feed>> for more details.
[[new-other]]
==== Other Additions
@@ -124,33 +124,33 @@ Spring Integration adds a number of other features. This section describes them.
===== Groovy Support
Spring Integration 2.0 added Groovy support, letting you use the Groovy scripting language to provide integration and business logic.
See "`<<groovy>>`" for more details.
See <<groovy>> for more details.
[[new-map-transformer]]
===== Map Transformers
These symmetrical transformers convert payload objects to and from `Map` objects.
See "`<<transformer>>`" for more details.
See <<transformer>> for more details.
[[new-json-transformer]]
===== JSON Transformers
These symmetrical transformers convert payload objects to and from JSON.
See "`<<transformer>>`" for more details.
See <<transformer>> for more details.
[[new-serialize-transformer]]
===== Serialization Transformers
These symmetrical transformers convert payload objects to and from byte arrays.
They also support the serializer and deserializer strategy interfaces that Spring 3.0.5 added.
See "`<<transformer>>`" for more details.
See <<transformer>> for more details.
[[new-refactoring]]
==== Framework Refactoring
The core API went through some significant refactoring to make it simpler and more usable.
Although we anticipate that the impact to developers should be minimal, you should read through this document to find what was changed.
Specifically, you should read "`<<dynamic-routers>>`", "`<<gateway>>`", "`<<http-outbound>>`", "`<<message>>`", and "`<<aggregator>>`".
Specifically, you should read <<dynamic-routers>>, <<gateway>>, <<http-outbound>>, <<message>>, and <<aggregator>>.
If you directly depend on some of the core components (`Message`, `MessageHeaders`, `MessageChannel`, `MessageBuilder`, and others), you need to update any import statements.
We restructured some packaging to provide the flexibility we needed for extending the domain model while avoiding any cyclical dependencies (it is a policy of the framework to avoid such "`tangles`").

22
src/reference/asciidoc/changes-2.0-2.1.adoc
View File

@@ -20,7 +20,7 @@ Now you have the ability to use any scripting language that supports JSR-223 inc
* Python and Jython
* Groovy
For further details, see "`<<scripting>>`".
For further details, see <<scripting>>.
[[x2.1-new-gemfire-support]]
===== GemFire Support
@@ -28,7 +28,7 @@ For further details, see "`<<scripting>>`".
Spring Integration provides support for http://www.vmware.com/products/application-platform/vfabric-gemfire/overview.html[GemFire] by providing inbound adapters for entry and continuous query events, an outbound adapter to write entries to the cache, and http://static.springsource.org/spring-integration/api/org/springframework/integration/store/MessageStore.html[`MessageStore`] and http://static.springsource.org/spring-integration/api/org/springframework/integration/store/MessageGroupStore.html[`MessageGroupStore`] implementations.
Spring integration leverages the http://www.springsource.org/spring-gemfire[Spring Gemfire] project, providing a thin wrapper over its components.
For further details, see "`<<gemfire>>`".
For further details, see <<gemfire>>.
[[x2.1-new-amqp-support]]
===== AMQP Support
@@ -36,21 +36,21 @@ For further details, see "`<<gemfire>>`".
Spring Integration 2.1 added several channel adapters for receiving and sending messages by using the http://www.amqp.org/[Advanced Message Queuing Protocol] (AMQP).
Furthermore, Spring Integration also provides a point-to-point message channel and a publish-subscribe message channel, both of which are backed by AMQP Exchanges and Queues.
For further details, see "`<<amqp>>`".
For further details, see <<amqp>>.
[[x2.1-new-mongodb-support]]
===== MongoDB Support
As of version 2.1, Spring Integration provides support for http://www.mongodb.org/[MongoDB] by providing a MongoDB-based `MessageStore`.
For further details, see "`<<mongodb>>`".
For further details, see <<mongodb>>.
[[x2.1-new-redis-support]]
===== Redis Support
As of version 2.1, Spring Integration supports http://redis.io/[Redis], an advanced key-value store, by providing a Redis-based `MessageStore` as well as publish-subscribe messaging adapters.
For further details, see "`<<redis>>`".
For further details, see <<redis>>.
[[x2.1-new-resource-support]]
===== Support for Spring's Resource abstraction
@@ -58,7 +58,7 @@ For further details, see "`<<redis>>`".
In version 2.1, we introduced a new resource inbound channel adapter that builds upon Spring's resource abstraction to support greater flexibility across a variety of actual types of underlying resources, such as a file, a URL, or a classpath resource.
Therefore, it is similar to but more generic than the file inbound channel adapter.
For further details, see "`<<resource-inbound-channel-adapter>>`".
For further details, see <<resource-inbound-channel-adapter>>.
[[x2.1-new-stored-proc-support]]
===== Stored Procedure Components
@@ -81,7 +81,7 @@ The stored procedure components also support SQL functions for the following dat
* Oracle
* PostgreSQL
For further details, see "`<<stored-procedures>>`".
For further details, see <<stored-procedures>>.
[[x2.1-new-xpath-filter-support]]
===== XPath and XML Validating Filter
@@ -91,7 +91,7 @@ It is part of the `XML` module.
The XPath filter lets you filter messages by using XPath Expressions.
We also added documentation for the XML validating filter.
For more details, see "`<<xml-xpath-filter>>`" and "`<<xml-validating-filter>>`".
For more details, see <<xml-xpath-filter>> and <<xml-validating-filter>>.
[[x2.1-new-payload-enricher-support]]
===== Payload Enricher
@@ -100,7 +100,7 @@ Since Spring Integration 2.1, we added the payload enricher.
A payload enricher defines an endpoint that typically passes a http://static.springsource.org/spring-integration/api/org/springframework/integration/Message.html[`Message`] to the exposed request channel and then expects a reply message.
The reply message then becomes the root object for evaluation of expressions to enrich the target payload.
For further details, see "`<<payload-enricher>>`".
For further details, see <<payload-enricher>>.
[[x2.1-new-ftp-outbound-gateway]]
===== FTP and SFTP Outbound Gateways
@@ -110,7 +110,7 @@ These two gateways let you directly execute a limited set of remote commands.
For instance, you can use these outbound gateways to list, retrieve, and delete remote files and have the Spring Integration message flow continue with the remote server's response.
For further details, see "`<<ftp-outbound-gateway>>`" and "`<<sftp-outbound-gateway>>`".
For further details, see <<ftp-outbound-gateway>> and <<sftp-outbound-gateway>>.
[[x2.1-new-ftp-session-caching]]
===== FTP Session Caching
@@ -120,7 +120,7 @@ As of version 2.1, we have exposed more flexibility with regards to session mana
Specifically, we deprecated the `cache-sessions` attribute (which is available via the XML namespace support).
As an alternative, we added the `sessionCacheSize` and `sessionWaitTimeout` attributes on the `CachingSessionFactory`.
For further details, see "`<<ftp-session-caching>>`" and "`<<sftp-session-caching>>`".
For further details, see <<ftp-session-caching>> and <<sftp-session-caching>>.
[[x2.1-framework-refactorings]]
==== Framework Refactoring

18
src/reference/asciidoc/changes-2.1-2.2.adoc
View File

@@ -13,13 +13,13 @@ Version 2.2 added a number of new components.
===== `RedisStore` Inbound and Outbound Channel Adapters
Spring Integration now has `RedisStore` Inbound and Outbound Channel Adapters, letting you write and read `Message` payloads to and from Redis collections.
For more information, see "`<<redis-store-outbound-channel-adapter>>`" and "`<<redis-store-inbound-channel-adapter>>`".
For more information, see <<redis-store-outbound-channel-adapter>> and <<redis-store-inbound-channel-adapter>>.
[[x2.2-mongo-adapters]]
===== MongoDB Inbound and Outbound Channel Adapters
Spring Integration now has MongoDB inbound and outbound channel adapters, letting you write and read `Message` payloads to and from a MongoDB document store.
For more information, see "`<<mongodb-outbound-channel-adapter>>`" and "`<<mongodb-inbound-channel-adapter>>`".
For more information, see <<mongodb-outbound-channel-adapter>> and <<mongodb-inbound-channel-adapter>>.
[[x2.2-jpa]]
===== JPA Endpoints
@@ -32,7 +32,7 @@ The JPA Adapter includes the following components:
* <<jpa-updating-outbound-gateway,Updating outbound gateway>>
* <<jpa-retrieving-outbound-gateway,Retrieving outbound gateway>>
For more information, see "`<<jpa>>`".
For more information, see <<jpa>>.
[[x2.2-general]]
==== General Changes
@@ -58,7 +58,7 @@ In addition, we added three standard advice classes for this purpose:
* `MessageHandlerCircuitBreakerAdvice`
* `ExpressionEvaluatingMessageHandlerAdvice`
For more information, see "`<<message-handler-advice-chain>>`".
For more information, see <<message-handler-advice-chain>>.
[[x2.2-transaction-sync]]
===== Transaction Synchronization and Pseudo Transactions
@@ -68,7 +68,7 @@ This allows for synchronizing such operations as renaming files by an inbound ch
In addition, you can enable these features when no "`real`" transaction is present, by means of a `PseudoTransactionManager`.
For more information, see "`<<transaction-synchronization>>`".
For more information, see <<transaction-synchronization>>.
[[x2.2-file-adapter]]
===== File Adapter: Improved File Overwrite and Append Handling
@@ -82,7 +82,7 @@ Now you can specify the following options:
* `FAIL`
* `IGNORE`
For more information, see "`<<file-writing-destination-exists>>`".
For more information, see <<file-writing-destination-exists>>.
[[x2.2-outbound-gateways]]
===== Reply-Timeout Added to More Outbound Gateways
@@ -116,7 +116,7 @@ When using the stored procedure components of the Spring Integration JDBC Adapte
Doing so lets you specify the stored procedures to be invoked at runtime.
For example, you can provide stored procedure names that you would like to execute through message headers.
For more information, see "`<<stored-procedures>>`".
For more information, see <<stored-procedures>>.
====== JMX Support
@@ -136,7 +136,7 @@ You can now provide only a select query by using the request message as a source
===== JDBC Support: Channel-specific Message Store Implementation
We added a new message channel-specific message store implementation, providing a more scalable solution using database-specific SQL queries.
For more information, see "`<<jdbc-message-store-channels>>`".
For more information, see <<jdbc-message-store-channels>>.
[[x2.2-shutdown]]
===== Orderly Shutdown
@@ -154,7 +154,7 @@ Doing so can improve performance of the gateway.
===== `ObjectToJsonTransformer`
By default, the `ObjectToJsonTransformer` now sets the `content-type` header to `application/json`.
For more information, see "`<<transformer>>`".
For more information, see <<transformer>>.
[[httpChanges]]
===== HTTP Support

68
src/reference/asciidoc/changes-2.2-3.0.adoc
View File

@@ -18,26 +18,26 @@ Upon parsing of the HTTP inbound endpoint, either a new `IntegrationRequestMappi
To achieve flexible request mapping configuration, Spring Integration provides the `<request-mapping/>` child element for `<http:inbound-channel-adapter/>` and the `<http:inbound-gateway/>`.
Both HTTP inbound endpoints are now fully based on the request mapping infrastructure that was introduced with Spring MVC 3.1.
For example, multiple paths are supported on a single inbound endpoint.
For more information see "`<<http-namespace>>`".
For more information see <<http-namespace>>.
[[x3.0-spel-customization]]
===== Spring Expression Language (SpEL) Configuration
We added a new `IntegrationEvaluationContextFactoryBean` to allow configuration of custom `PropertyAccessor` implementations and functions for use in SpEL expressions throughout the framework.
For more information, see "`<<spel>>`".
For more information, see <<spel>>.
[[x3.0-spel-functions]]
===== SpEL Functions Support
To customize the SpEL `EvaluationContext` with static `Method` functions, we introduced the `<spel-function/>` component.
We also added two built-in functions: `#jsonPath` and `#xpath`.
For more information, see "`<<spel-functions>>`".
For more information, see <<spel-functions>>.
[[x3.0-spel-property-accessors]]
===== SpEL PropertyAccessors Support
To customize the SpEL `EvaluationContext` with `PropertyAccessor` implementations, we added the `<spel-property-accessors/>` component.
For more information, see "`<<spel-property-accessors>>`".
For more information, see <<spel-property-accessors>>.
[[x3.0-redis-new-components]]
===== Redis: New Components
@@ -59,7 +59,7 @@ For more information, "`see <<redis>>`".
You can now instruct the framework to store reply channels and error channels in a registry for later resolution.
This is useful for cases where the `replyChannel` or `errorChannel` might be lost (for example, when serializing a message).
See "`<<header-enricher>>`" for more information.
See <<header-enricher>> for more information.
[[x3.0-configurable-mongo-MS]]
===== MongoDB support: New `ConfigurableMongoDbMessageStore`
@@ -68,19 +68,19 @@ In addition to the existing `eMongoDbMessageStore`, we introduced a new `Configu
This provides a more robust and flexible implementation of `MessageStore` for MongoDB.
It does not have backward compatibility with the existing store, but we recommend using it for new applications.
Existing applications can use it, but messages in the old store are not available.
See "`<<mongodb>>`" for more information.
See <<mongodb>> for more information.
[[x3.0-syslog]]
===== Syslog Support
Building on the 2.2 `SyslogToMapTransformer`, Spring Integration 3.0 introduces `UDP` and `TCP` inbound channel adapters especially tailored for receiving SYSLOG messages.
For more information, see "`<<syslog>>`".
For more information, see <<syslog>>.
[[x3.0-tail]]
===== `tail` Support
We added file inbound channel adapters that use the `tail` command to generate messages when lines are added to the end of text files.
See "`<<file-tailing>>`".
See <<file-tailing>>.
[[x3.0-jmx]]
===== JMX Support
@@ -92,7 +92,7 @@ It permits simple transformation to, for example, JSON.
The `IntegrationMBeanExporter` now allows the configuration of a custom `ObjectNamingStrategy` by using the `naming-strategy` attribute.
For more information, see "`<<jmx>>`".
For more information, see <<jmx>>.
[[x3.0-tcp-events]]
===== TCP/IP Connection Events and Connection Management
@@ -112,19 +112,19 @@ It lets applications broadcast to all open connections, among other uses.
Finally, the connection factories also provide a new method called `closeConnection(String connectionId)`, which lets applications explicitly close a connection by using its ID.
For more information see "`<<tcp-events>>`".
For more information see <<tcp-events>>.
[[x3.0-inbound-script]]
===== Inbound Channel Adapter Script Support
The `<int:inbound-channel-adapter/>` now supports using `<expression/>` and `<script/>` child elements to create a `MessageSource`.
See "`<<channel-adapter-expressions-and-scripts>>`".
See <<channel-adapter-expressions-and-scripts>>.
[[x3.0-content-enricher-headers]]
===== Content Enricher: Headers Enrichment Support
The content enricher now provides configuration for `<header/>` child elements, to enrich the outbound message with headers based on the reply message from the underlying message flow.
For more information see "`<<payload-enricher>>`".
For more information see <<payload-enricher>>.
[[x3.0-general]]
==== General Changes
@@ -137,7 +137,7 @@ This section describes general changes from version 2.2 to version 3.0.
Previously, message IDs were generated by using the JDK `UUID.randomUUID()` method.
With this release, the default mechanism has been changed to use a more efficient and significantly faster algorithm.
In addition, we added the ability to change the strategy used to generate message IDs.
For more information see "`<<message-id-generation>>`".
For more information see <<message-id-generation>>.
[[x3.0-gateway]]
===== "`<gateway>`" Changes
@@ -149,7 +149,7 @@ You can now entirely customize the way that gateway method calls are mapped to m
The `GatewayMethodMetadata` is now a public class.
It lets you programmatically configure the `GatewayProxyFactoryBean` from Java.
For more information, see "`<<gateway>>`".
For more information, see <<gateway>>.
[[x3.0-http-endpointss]]
===== HTTP Endpoint Changes
@@ -167,7 +167,7 @@ These variables are available in both payload and header expressions.
* *Outbound Endpoint 'uri-variables-expression'*: HTTP outbound endpoints now support the `uri-variables-expression` attribute to specify an `Expression` to evaluate a `Map` for all URI variable placeholders within URL template.
This allows selection of a different map of expressions based on the outgoing message.
For more information, see "`<<http>>`".
For more information, see <<http>>.
[[x3.0-json-transformers]]
===== Jackson Support (JSON)
@@ -178,7 +178,7 @@ Previously, only Jackson 1.x was supported.
* The `ObjectToJsonTransformer` and `JsonToObjectTransformer` now emit/consume headers containing type information.
For more information, see "`JSON Transformers`" in "`<<transformer>>`".
For more information, see "`JSON Transformers`" in <<transformer>>.
[[x3.0-id-for-chain-sub-components]]
===== Chain Elements `id` Attribute
@@ -187,35 +187,35 @@ Previously, the `id` attribute for elements within a `<chain>` was ignored and,
Now, the `id` attribute is allowed for all elements within a `<chain>`.
The bean names of chain elements is a combination of the surrounding chain's `id` and the `id` of the element itself.
For example: 'myChain$child.myTransformer.handler'.
For more information see, "`<<chain>>`".
For more information see, <<chain>>.
[[x3.0-corr-endpoint-empty-groups]]
===== Aggregator 'empty-group-min-timeout' property
The `AbstractCorrelatingMessageHandler` provides a new property called `empty-group-min-timeout` to allow empty group expiry to run on a longer schedule than expiring partial groups.
Empty groups are not removed from the `MessageStore` until they have not been modified for at least this number of milliseconds.
For more information, see "`<<aggregator-config>>`".
For more information, see <<aggregator-config>>.
[[x3.0-filelistfilter]]
===== Persistent File List Filters (file, (S)FTP)
New `FileListFilter` implementations that use a persistent `MetadataStore` are now available.
You can use these to prevent duplicate files after a system restart.
See "`<<file-reading>>`", "`<<ftp-inbound>>`", and "`<<sftp-inbound>>`" for more information.
See <<file-reading>>, <<ftp-inbound>>, and <<sftp-inbound>> for more information.
[[x3.0-scripting-variables]]
===== Scripting Support: Variables Changes
We introduced a new `variables` attribute for scripting components.
In addition, variable bindings are now allowed for inline scripts.
See "`<<groovy>>`" and "`<<scripting>>`" for more information.
See <<groovy>> and <<scripting>> for more information.
[[x3.0-direct-channel-lb-ref]]
===== Direct Channel Load Balancing configuration
Previously, when configuring `LoadBalancingStrategy` on the channel's `dispatcher` child element, the only available option was to use a pre-defined enumeration of values which did not let developers set a custom implementation of the `LoadBalancingStrategy`.
You can now use `load-balancer-ref` to provide a reference to a custom implementation of the `LoadBalancingStrategy`.
For more information, see "`<<channel-implementations-directchannel>>`".
For more information, see <<channel-implementations-directchannel>>.
[[x3.0-pub-sub]]
===== PublishSubscribeChannel Behavior
@@ -271,7 +271,7 @@ A new higher-level abstraction (`RemoteFileTemplate`) is provided over the `Sess
While it is used internally by endpoints, you can also use this abstraction programmatically.
Like all Spring `*Template` implementations, it reliably closes the underlying session while allowing low level access to the session.
For more information, see "`<<ftp>>`" and "`<<sftp>>`".
For more information, see <<ftp>> and <<sftp>>.
[[x3.0-outbound-gateway-requires-reply]]
===== 'requires-reply' Attribute for Outbound Gateways
@@ -320,13 +320,13 @@ For more complex database-specific types not supported by the standard `Callable
The `row-mapper` attribute of the stored procedure inbound channel adapter `<returning-resultset/>` child element now supports a reference to a `RowMapper` bean definition.
Previously, it contained only a class name (which is still supported).
For more information, see "`<<stored-procedures>>`".
For more information, see <<stored-procedures>>.
[[x3.0-ws-outbound-uri-substitution]]
===== Web Service Outbound URI Configuration
The web service outbound gateway 'uri' attribute now supports `<uri-variable/>` substitution for all URI schemes supported by Spring Web Services.
For more information, see "`<<outbound-uri>>`".
For more information, see <<outbound-uri>>.
[[x3.0-redis]]
===== Redis Adapter Changes
@@ -337,26 +337,26 @@ The Redis outbound channel adapter now has the `topic-expression` property to de
The Redis inbound channel adapter, in addition to the existing `topics` attribute, now has the `topic-patterns` attribute.
For more information, see "`<<redis>>`".
For more information, see <<redis>>.
[[x3.0-advising-filters]]
===== Advising Filters
Previously, when a `<filter/>` had a `<request-handler-advice-chain/>`, the discard action was all performed within the scope of the advice chain (including any downstream flow on the `discard-channel`).
The filter element now has an attribute called `discard-within-advice` (default: `true`) to allow the discard action to be performed after the advice chain completes.
See "`<<advising-filters>>`".
See <<advising-filters>>.
[[x3.0-annotation-advice]]
===== Advising Endpoints using Annotations
Request handler advice chains can now be configured using annotations.
See "`<<advising-with-annotations>>`".
See <<advising-with-annotations>>.
[[x3.0-o-t-s-t]]
===== ObjectToStringTransformer Improvements
This transformer now correctly transforms `byte[]` and `char[]` payloads to `String`.
For more information, see "`<<transformer>>`".
For more information, see <<transformer>>.
[[x3.0-jpa-changes]]
===== JPA Support Changes
@@ -370,13 +370,13 @@ The JPA adapters now have additional attributes to optionally flush and clear en
Retrieving gateways had no mechanism to specify the first record to be retrieved, which is a common use case.
The retrieving gateways now support specifying this parameter by adding the `first-result` and `first-result-expression` attributes to the gateway definition.
For more information, see "`<<jpa-retrieving-outbound-gateway>>`".
For more information, see <<jpa-retrieving-outbound-gateway>>.
The JPA retrieving gateway and inbound adapter now have an attribute to specify the maximum number of results in a result set as an expression.
In addition, we introduced the `max-results` attribute to replace `max-number-of-results`, which has been deprecated.
`max-results` and `max-results-expression` are used to provide the maximum number of results or an expression to compute the maximum number of results, respectively, in the result set.
For more information, see "`<<jpa>>`".
For more information, see <<jpa>>.
[[x3.0-dalay-expression]]
===== Delayer: delay expression
@@ -386,14 +386,14 @@ In complex cases, the `<delayer>` had to be preceded with a `<header-enricher>`.
Spring Integration 3.0 introduced the `expression` attribute and `expression` child element for dynamic delay determination.
The `delay-header-name` attribute is now deprecated, because you can specify the header evaluation in the `expression`.
In addition, we introduced the `ignore-expression-failures` to control the behavior when an expression evaluation fails.
For more information, see "`<<delayer>>`".
For more information, see <<delayer>>.
[[x3.0-jdbc-mysql-v5_6_4]]
===== JDBC Message Store Improvements
Spring Integration 3.0 adds a new set of DDL scripts for MySQL version 5.6.4 and higher.
Now MySQL supports fractional seconds and is thus improving the FIFO ordering when polling from a MySQL-based message store.
For more information, see "`<<jdbc-message-store-generic>>`".
For more information, see <<jdbc-message-store-generic>>.
[[x3.0-event-for-imap-idle]]
===== IMAP Idle Connection Exceptions
@@ -408,7 +408,7 @@ Applications can obtain these events by using an `<int-event:inbound-channel-ada
The TCP connection factories now enable the configuration of a flexible mechanism to transfer selected headers (as well as the payload) over TCP.
A new `TcpMessageMapper` enables the selection of the headers, and you need to configure an appropriate serializer or deserializer to write the resulting `Map` to the TCP stream.
We added a `MapJsonSerializer` as a convenient mechanism to transfer headers and payload over TCP.
For more information, see "`<<ip-headers>>`".
For more information, see <<ip-headers>>.
[[x3.0-jms-mdca-te]]
===== JMS Message Driven Channel Adapter
@@ -421,7 +421,7 @@ This is in addition to several other container attributes that were already avai
===== RMI Inbound Gateway
The RMI Inbound Gateway now supports an `error-channel` attribute.
See "`<<rmi-inbound>>`".
See <<rmi-inbound>>.
[[x3.0-xslt-transformer]]
===== `XsltPayloadTransformer`

77
src/reference/asciidoc/changes-3.0-4.0.adoc
View File

@@ -13,19 +13,19 @@ Version 4.0 added a number of new components.
===== MQTT Channel Adapters
The MQTT channel adapters (previously available in the Spring Integration Extensions repository) are now available as part of the normal Spring Integration distribution.
See "`<<mqtt>>`".
See <<mqtt>>.
[[x4.0-enable-configuration]]
===== `@EnableIntegration`
We added the `@EnableIntegration` annotation to permit declaration of standard Spring Integration beans when using `@Configuration` classes.
See "`<<annotations>>`" for more information.
See <<annotations>> for more information.
[[x4.0-component-scan]]
===== `@IntegrationComponentScan`
We added the `@IntegrationComponentScan` annotation to permit classpath scanning for Spring Integration-specific components.
See "`<<annotations>>`" for more information.
See <<annotations>> for more information.
[[x4.0-message-history]]
===== "`@EnableMessageHistory`"
@@ -33,14 +33,14 @@ See "`<<annotations>>`" for more information.
You can now enable message history with the `@EnableMessageHistory` annotation in a `@Configuration` class.
In addition, a JMX MBean can modify the message history settings.
Also, `MessageHistory` can track auto-created `MessageHandler` instances for annotated endpoints (such as `@ServiceActivator`, `@Splitter`, and others).
For more information, see "`<<message-history>>`".
For more information, see <<message-history>>.
[[x4.0-messaging-gateway]]
===== `@MessagingGateway`
You can now configure messaging gateway interfaces with the `@MessagingGateway` annotation.
It is an analogue of the `<int:gateway/>` XML element.
For more information, see "`<<messaging-gateway-annotation>>`".
For more information, see <<messaging-gateway-annotation>>.
[[x4.0-boot]]
===== Spring Boot `@EnableAutoConfiguration`
@@ -52,68 +52,68 @@ For more information, see http://docs.spring.io/spring-boot/docs/current/referen
===== `@GlobalChannelInterceptor`
As well as the `@EnableIntegration` annotation mentioned above, we introduced the `@GlobalChannelInterceptor` annotation.
For more information, see "`<<annotations>>`".
For more information, see <<annotations>>.
[[x4.0-integration-converter]]
===== `@IntegrationConverter`
We introduced the `@IntegrationConverter` annotation as an analogue of the `<int:converter/>` component.
For more information, see "`<<annotations>>`".
For more information, see <<annotations>>.
[[x4.0-enable-publisher]]
===== `@EnablePublisher`
We added the `@EnablePublisher` annotation to allow the specification of a `default-publisher-channel` for `@Publisher` annotations.
See "`<<annotations>>`" for more information.
See <<annotations>> for more information.
[[x4.0-redis-cms]]
===== Redis Channel Message Stores
We added a Redis `MessageGroupStore` that is optimized for use when backing a `QueueChannel` for persistence.
For more information, see "`<<redis-cms>>`".
For more information, see <<redis-cms>>.
We added a Redis `ChannelPriorityMessageStore`.
You can use it to retrieve messages by priority.
For more information, see "`<<redis-cms>>`".
For more information, see <<redis-cms>>.
[[x4.0-priority-channel-mondodb]]
===== MongodDB Channel Message Store
The MongoDB support now provides the `MongoDbChannelMessageStore`, which is a channel-specific `MessageStore` implementation.
With `priorityEnabled = true`, you can use it in `<int:priority-queue>` elements to achieve priority order polling of persisted messages.
For more information see "`<<mongodb-priority-channel-message-store>>`".
For more information see <<mongodb-priority-channel-message-store>>.
[[x4.0-MBeanExport-annotation]]
===== `@EnableIntegrationMBeanExport`
You can now enable the `IntegrationMBeanExporter` with the `@EnableIntegrationMBeanExport` annotation in a `@Configuration` class.
For more information, see "`<<jmx-mbean-exporter>>`".
For more information, see <<jmx-mbean-exporter>>.
[[x4.0-channel-security-interceptor]]
===== `ChannelSecurityInterceptorFactoryBean`
`ChannelSecurityInterceptorFactoryBean` now supports configuration of Spring Security for message channels that use `@Configuration` classes.
For more information, see "`<<security>>`".
For more information, see <<security>>.
[[x4.0-redis-outbound-gateway]]
===== Redis Command Gateway
The Redis support now provides the `<outbound-gateway>` component to perform generic Redis commands by using the `RedisConnection#execute` method.
For more information, see "`<<redis-outbound-gateway>>`".
For more information, see <<redis-outbound-gateway>>.
[[x4.0-redis-gemfire-lock-registry]]
===== `RedisLockRegistry` and `GemfireLockRegistry`
The `RedisLockRegistry` and `GemfireLockRegistry` are now available to support global locks visible to multiple application instances and servers.
These can be used with aggregating message handlers across multiple application instances such that group release occurs on only one instance.
For more information, see "`<<redis-lock-registry>>`", "`<<gemfire-lock-registry>>`", and "`<<aggregator>>`".
For more information, see <<redis-lock-registry>>, <<gemfire-lock-registry>>, and <<aggregator>>.
[[x4.0-poller-annotation]]
===== `@Poller`
Annotation-based messaging configuration can now have a `poller` attribute.
This means that methods annotated with `@ServiceActivator`, `@Aggregator`, and similar annotations can now use an `inputChannel` that is a reference to a `PollableChannel`.
For more information, see "`<<annotations>>`".
For more information, see <<annotations>>.
[[x4.0-inbound-channel-adapter-annotation]]
===== `@InboundChannelAdapter` and `SmartLifecycle` for Annotated Endpoints
@@ -121,33 +121,33 @@ For more information, see "`<<annotations>>`".
We added the `@InboundChannelAdapter` method annotation.
It is an analogue of the `<int:inbound-channel-adapter>` XML component.
In addition, all messaging annotations now provide `SmartLifecycle` options.
For more information, see "`<<annotations>>`".
For more information, see <<annotations>>.
[[x4.0-twitter-sog]]
===== Twitter Search Outbound Gateway
A new twitter endpoint `<int-twitter-search-outbound-gateway/>` has been added.
Unlike the search inbound adapter which polls using the same search query each time, the outbound gateway allows on-demand customized queries.
We added a new twitter endpoint: `<int-twitter-search-outbound-gateway/>`.
Unlike the search inbound adapter, which polls by using the same search query each time, the outbound gateway allows on-demand customized queries.
For more information, see https://github.com/spring-projects/spring-integration-extensions/tree/master/spring-integration-social-twitter[Spring Integration Social Twitter].
[[x4.0-gemfire-metadata]]
===== Gemfire Metadata Store
We added the `GemfireMetadataStore`, letting it be used, for example, in an `AbstractPersistentAcceptOnceFileListFilter` implementation in a multiple application instance or server environment.
For more information, see "`<<metadata-store>>`", "`<<file-reading>>`", "`<<ftp-inbound>>`", and "`<<sftp-inbound>>`".
For more information, see <<metadata-store>>, <<file-reading>>, <<ftp-inbound>>, and <<sftp-inbound>>.
[[x4.0-bridge-annotations]]
===== `@BridgeFrom` and `@BridgeTo` Annotations
We introduced `@BridgeFrom` and `@BridgeTo` `@Bean` method annotations to mark `MessageChannel` beans in `@Configuration` classes.
For more information, see "`<<annotations>>`".
For more information, see <<annotations>>.
[[x4.0-meta-messaging-annotations]]
===== Meta-messaging Annotations
Messaging annotations (`@ServiceActivator`, `@Router`, `@MessagingGateway`, and others) can now be configured as meta-annotations for user-defined messaging annotations.
In addition, the user-defined annotations can have the same attributes (`inputChannel`, `@Poller`, `autoStartup`, and others).
For more information, see "`<<annotations>>`".
For more information, see <<annotations>>.
[[x4.0-general]]
==== General Changes
@@ -164,7 +164,7 @@ Developers who reference these classes directly in their code need to make chang
We introduced the `header-type` attribute for the `header` child element of the `<int-xml:xpath-header-enricher>`.
This attribute provides the target type for the header value (to which the result of the XPath expression evaluation is converted).
For more information see "`<<xml-xpath-header-enricher>>`".
For more information see <<xml-xpath-header-enricher>>.
[[x4.0-object-to-json-transformer-result-type]]
===== Object To JSON Transformer: Node Result
@@ -172,21 +172,21 @@ For more information see "`<<xml-xpath-header-enricher>>`".
We introduced the `result-type` attribute for the `<int:object-to-json-transformer>`.
This attribute provides the target type for the result of mapping an object to JSON.
It supports `STRING` (the default) and `NODE`.
For more information see "`<<transformer-xpath-spel-function>>`".
For more information see <<transformer-xpath-spel-function>>.
[[x4.0-jms-header-mapping]]
===== JMS Header Mapping
The `DefaultJmsHeaderMapper` now maps an incoming `JMSPriority` header to the Spring Integration `priority` header.
Previously, `priority` was only considered for outbound messages.
For more information, see "`<<jms-header-mapping>>`".
For more information, see <<jms-header-mapping>>.
[[x4.0-jms-ob]]
===== JMS Outbound Channel Adapter
The JMS outbound channel adapter now supports the `session-transacted` attribute (default: `false`).
Previously, you had to inject a customized `JmsTemplate` to use transactions.
See "`<<jms-outbound-channel-adapter>>`".
See <<jms-outbound-channel-adapter>>.
[[x4.0-jms-ib]]
===== JMS Inbound Channel Adapter
@@ -195,38 +195,38 @@ The JMS inbound channel adapter now supports the `session-transacted` attribute
Previously, you had to inject a customized `JmsTemplate` to use transactions.
The adapter allowed 'transacted' in the `acknowledgeMode`, which was incorrect and didn't work.
This value is no longer allowed.
See "`<<jms-inbound-channel-adapter>>`".
See <<jms-inbound-channel-adapter>>.
[[x4.0-datatype-channel]]
===== Datatype Channels
You can now specify a `MessageConverter` to be used when converting (if necessary) payloads to one of the accepted `datatype` instances in a Datatype channel.
For more information, see "`<<channel-datatype-channel>>`".
For more information, see <<channel-datatype-channel>>.
[[x4.0-retry-config]]
===== Simpler Retry Advice Configuration
We added simplified namespace support to configure a `RequestHandlerRetryAdvice`.
For more information, see "`<<retry-config>>`".
For more information, see <<retry-config>>.
[[x4.0-release-strategy-group-timeout]]
===== Correlation Endpoint: Time-based Release Strategy
We added the mutually exclusive `group-timeout` and `group-timeout-expression` attributes to `<int:aggregator>` and `<int:resequencer>`.
These attributes allow forced completion of a partial `MessageGroup`, provided the `ReleaseStrategy` does not release a group and no further messages arrive within the time specified.
For more information, see "`<<aggregator-config>>`".
For more information, see <<aggregator-config>>.
[[x4.0-redis-metadata]]
===== Redis Metadata Store
The `RedisMetadataStore` now implements `ConcurrentMetadataStore`, letting it be used, for example, in an `AbstractPersistentAcceptOnceFileListFilter` implementation in a multiple application instance or server environment.
For more information, see "`<<redis-metadata-store>>`", "`<<file-reading>>`", "`<<ftp-inbound>>`", and "`<<sftp-inbound>>`".
For more information, see <<redis-metadata-store>>, <<file-reading>>, <<ftp-inbound>>, and <<sftp-inbound>>.
[[x4.0-jdbc-cs]]
===== `JdbcChannelMessageStore` and `PriorityChannel`
T`JdbcChannelMessageStore` now implements `PriorityCapableChannelMessageStore`, letting it be used as a `message-store` reference for `priority-queue` instances.
For more information, see "`<<jdbc-message-store-channels>>`".
For more information, see <<jdbc-message-store-channels>>.
[[x4.0-amqp]]
===== AMQP Endpoints Delivery Mode
@@ -234,35 +234,36 @@ For more information, see "`<<jdbc-message-store-channels>>`".
Spring AMQP, by default, creates persistent messages on the broker.
You can override this behavior by setting the `amqp_deliveryMode` header or customizing the mappers.
We added a convenient `default-delivery-mode` attribute to the adapters to provide easier configuration of this important setting.
For more information, see "`<<amqp-outbound-channel-adapter>>`" and "`<<amqp-outbound-gateway>>`".
For more information, see <<amqp-outbound-channel-adapter>> and <<amqp-outbound-gateway>>.
[[x4.0-ftp]]
===== FTP Timeouts
The `DefaultFtpSessionFactory` now exposes the `connectTimeout`, `defaultTimeout`, and `dataTimeout` properties, avoiding the need to subclass the factory to set these common properties.
The `postProcess*` methods are still available for more advanced configuration.
See "`<<ftp-session-factory>>`" for more information.
See <<ftp-session-factory>> for more information.
[[x4.0-twitter-status-updating]]
===== Twitter: `StatusUpdatingMessageHandler`
The `StatusUpdatingMessageHandler` (`<int-twitter:outbound-channel-adapter>`) now supports the `tweet-data-expression` attribute to build a `org.springframework.social.twitter.api.TweetData` object for updating the timeline status allowing, for example, attaching an image.
The `StatusUpdatingMessageHandler` (`<int-twitter:outbound-channel-adapter>`) now supports the `tweet-data-expression` attribute to build a `org.springframework.social.twitter.api.TweetData` object for updating the timeline status.
This feature allows, for example, attaching an image.
See https://github.com/spring-projects/spring-integration-extensions/tree/master/spring-integration-social-twitter[Spring Integration Social Twitter] for more information.
[[x4.0-jpa-id-expression]]
===== JPA Retrieving Gateway: `id-expression`
We introduced the `id-expression` attribute for `<int-jpa:retrieving-outbound-gateway>` to perform `EntityManager.find(Class entityClass, Object primaryKey)`.
See "`<<jpa-retrieving-outbound-gateway>>`" for more information.
See <<jpa-retrieving-outbound-gateway>> for more information.
[[x4.0-tcp-deserializer-events]]
===== TCP Deserialization Events
When one of the standard deserializers encounters a problem decoding the input stream to a message, it now emits a `TcpDeserializationExceptionEvent`, letting applications examine the data at the point at which the exception occurred.
See "`<<tcp-events>>`" for more information.
See <<tcp-events>> for more information.
[[x4.0-bean-messaging-annotations]]
===== Messaging Annotations on `@Bean` Definitions
You can now configure messaging annotations (`@ServiceActivator`, `@Router`, `@InboundChannelAdapter`, and others) on `@Bean` definitions in `@Configuration` classes.
For more information, see "`<<annotations>>`".
For more information, see <<annotations>>.

72
src/reference/asciidoc/changes-4.0-4.1.adoc
View File

@@ -12,50 +12,50 @@ Version 4.1 added a number of new components.
===== Promise<?> Gateway
The messaging gateway methods now support a Reactor `Promise` return type.
See "`<<async-gateway>>`".
See <<async-gateway>>.
[[x4.1-web-socket-adapters]]
===== WebSocket support
The `WebSocket` module is now available.
It is fully based on the Spring WebSocket and Spring Messaging modules and provides an `<inbound-channel-adapter>` and an `<outbound-channel-adapter>`.
See "`<<web-sockets>>`" for more information.
See <<web-sockets>> for more information.
[[x4.1-scatter-gather]]
===== Scatter-Gather Enterprise Integration Pattern
We implemented the scatter-gather enterprise integration pattern.
See "`<<scatter-gather>>`" for more information.
See <<scatter-gather>> for more information.
[[x4.1-Routing-Slip]]
===== Routing Slip Pattern
We added the routing slip EIP pattern implementation.
See "`<<routing-slip>>`" for more information.
See <<routing-slip>> for more information.
[[x4.1-idempotent-receiver]]
===== Idempotent Receiver Pattern
We added the idempotent receiver enterprise integration pattern implementation by adding the `<idempotent-receiver>` component in XML or the `IdempotentReceiverInterceptor` and `IdempotentReceiver` annotations for Java configuration.
See "`<<idempotent-receiver>>`" and the https://docs.spring.io/spring-integration/api/index.html[Javadoc] for more information.
See <<idempotent-receiver>> and the https://docs.spring.io/spring-integration/api/index.html[Javadoc] for more information.
[[x4.1-BoonJsonObjectMapper]]
===== Boon `JsonObjectMapper`
We added T\the Boon `JsonObjectMapper` for the JSON transformers.
See "`<<transformer>>`" for more information.
We added the Boon `JsonObjectMapper` for the JSON transformers.
See <<transformer>> for more information.
[[x4.1-redis-queue-gateways]]
===== Redis Queue Gateways
We added the `<redis-queue-inbound-gateway>` and `<redis-queue-outbound-gateway>` components.
See "`<<redis-queue-inbound-gateway>>`" and "`<<redis-queue-outbound-gateway>>`".
See <<redis-queue-inbound-gateway>> and <<redis-queue-outbound-gateway>>.
[[x4.1-PollSkipAdvice]]
===== `PollSkipAdvice`
We added the `PollSkipAdvice`, which you can use within the `<advice-chain>` of the `<poller>` to determine if the current poll should be suppressed (skipped) by some condition that you implement with `PollSkipStrategy`.
See "`<<polling-consumer>>`" for more information.
See <<polling-consumer>> for more information.
[[x4.1-general]]
==== General Changes
@@ -66,7 +66,7 @@ This section describes general changes from version 4.0 to version 4.1.
===== AMQP Inbound Endpoints, Channel
Elements that use a message listener container (inbound endpoints and channel) now support the `missing-queues-fatal` attribute.
See "`<<amqp>>`" for more information.
See <<amqp>> for more information.
[[x4.1-amqp-outbound-lazy-connect]]
===== AMQP Outbound Endpoints
@@ -74,13 +74,13 @@ See "`<<amqp>>`" for more information.
The AMQP outbound endpoints support a new property called `lazy-connect` (default: `true`).
When `true`, the connection to the broker is not established until the first message arrives (assuming there are no inbound endpoints, which always try to establish the connection during startup).
When set to `false`, an attempt to establish the connection is made during application startup.
See "`<<amqp>>`" for more information.
See <<amqp>> for more information.
[[x4.1-sms-copy-on-get]]
===== SimpleMessageStore
The `SimpleMessageStore` no longer makes a copy of the group when calling `getMessageGroup()`.
See "`<<sms-caution>>`" for more information.
See <<sms-caution>> for more information.
[[x4.1-ws-encode-uri]]
===== Web Service Outbound Gateway: `encode-uri`
@@ -91,22 +91,22 @@ The `<ws:outbound-gateway/>` now provides an `encode-uri` attribute to allow dis
===== Http Inbound Channel Adapter and Status Code
The `<http:inbound-channel-adapter>` can now be configured with a `status-code-expression` to override the default `200 OK` status.
See "`<<http-namespace>>`" for more information.
See <<http-namespace>> for more information.
[[x4.1-mqtt]]
===== MQTT Adapter Changes
You can now configure the MQTT channel adapters to connect to multiple servers -- for example, to support High Availability (HA).
See "`<<mqtt>>`" for more information.
See <<mqtt>> for more information.
The MQTT message-driven channel adapter now supports specifying the QoS setting for each subscription.
See "`<<mqtt-inbound>>`" for more information.
See <<mqtt-inbound>> for more information.
The MQTT outbound channel adapter now supports asynchronous sends, avoiding blocking until delivery is confirmed.
See "`<<mqtt-outbound>>`" for more information.
See <<mqtt-outbound>> for more information.
It is now possible to programmatically subscribe to and unsubscribe from topics at runtime.
See "`<<mqtt-inbound>>`" for more information.
See <<mqtt-inbound>> for more information.
[[x4.1-sftp]]
===== FTP and SFTP Adapter Changes
@@ -115,115 +115,115 @@ The FTP and SFTP outbound channel adapters now support appending to remote files
The remote file templates now also supports this, as well as `rmdir()` and `exists()`.
In addition, the remote file templates provide access to the underlying client object, enabling access to low-level APIs.
See "`<<ftp>>`" and "`<<sftp>>`" for more information.
See <<ftp>> and <<sftp>> for more information.
[[x4.1-splitter-iterator]]
===== Splitter and Iterator
`Splitter` components now support an `Iterator` as the result object for producing output messages.
See "`<<splitter>>`" for more information.
See <<splitter>> for more information.
[[x4.1-aggregator]]
===== Aggregator
`Aggregator` instancess now support a new attribute `expire-groups-upon-timeout`.
See "`<<aggregator>>`" for more information.
See <<aggregator>> for more information.
[[x4.1-content-enricher-improvement]]
===== Content Enricher Improvements
We added a `null-result-expression` attribute, which is evaluated and returned if `<enricher>` returns `null`.
You can add it in `<header>` and `<property>`.
See "`<<content-enricher>>`" for more information.
See <<content-enricher>> for more information.
We added an `error-channel` attribute, which is used to handle an error flow if an `Exception` occurs downstream of the `request-channel`.
This lets you return an alternative object to use for enrichment.
See "`<<content-enricher>>`" for more information.
See <<content-enricher>> for more information.
[[x4.1-header-channel-registry]]
===== Header Channel Registry
The `<header-enricher/>` element's `<header-channels-to-string/>` child element can now override the header channel registry's default time for retaining channel mappings.
See "`<<header-channel-registry>>`" for more information.
See <<header-channel-registry>> for more information.
[[x4.1-orderly-shutdown]]
===== Orderly Shutdown
We made improvements to the orderly shutdown algorithm.
See "`<<jmx-shutdown>>`" for more information.
See <<jmx-shutdown>> for more information.
[[x4.1-recipientListRouter]]
===== Management for `RecipientListRouter`
The `RecipientListRouter` now provides several management operations to configure recipients at runtime.
With that, you can now configure the `<recipient-list-router>` without any `<recipient>` from the start.
See "`<<recipient-list-router-management>>`" for more information.
See <<recipient-list-router-management>> for more information.
[[x4.1-AbstractHeaderMapper-changes]]
===== AbstractHeaderMapper: NON_STANDARD_HEADERS token
The `AbstractHeaderMapper` implementation now provides the additional `NON_STANDARD_HEADERS` token to map any user-defined headers, which are not mapped by default.
See "`<<amqp-message-headers>>`" for more information.
See <<amqp-message-headers>> for more information.
[[x4.1-amqp-channels]]
===== AMQP Channels: `template-channel-transacted`
We introduced the `template-channel-transacted` attribute for AMQP `MessageChannel` instances.
See "`<<amqp-channels>>`" for more information.
See <<amqp-channels>> for more information.
[[x4.1-syslog]]
===== Syslog Adapter
The default syslog message converter now has an option to retain the original message in the payload while still setting the headers.
See "`<<syslog-inbound-adapter>>`" for more information.
See <<syslog-inbound-adapter>> for more information.
[[x4.1-async-gateway]]
===== Asynchronous Gateway
In addition to the `Promise` return type <<x4.1-promise-gateway,mentioned earlier>>, gateway methods may now return a `ListenableFuture`, introduced in Spring Framework 4.0.
You can also disable asynchronous processing in the gateway, letting a downstream flow directly return a `Future`.
See "`<<async-gateway>>`".
See <<async-gateway>>.
[[x4.1-aggregator-advice-chain]]
===== Aggregator Advice Chain
`Aggregator` and `Resequencer` now support `<expire-advice-chain/>` and `<expire-transactional/>` child elements to advise the `forceComplete` operation.
See "`<<aggregator-config>>`" for more information.
See <<aggregator-config>> for more information.
[[x4.1-script-outbound-channel-adapter]]
===== Outbound Channel Adapter and Scripts
The `<int:outbound-channel-adapter/>` now supports the `<script/>` child element.
The underlying script must have a `void` return type or return `null`.
See "`<<groovy>>`" and "`<<scripting>>`".
See <<groovy>> and <<scripting>>.
[[x4.1-reseq]]
===== Resequencer Changes
When a message group in a resequencer times out (using `group-timeout` or a `MessageGroupStoreReaper`), late arriving messages are now, by default, discarded immediately.
See "`<<resequencer>>`".
See <<resequencer>>.
[[x4.1-Optional-Parameter]]
===== Optional POJO method parameter
Spring Integration now consistently handles the Java 8's `Optional` type.
See "`<<service-activator-namespace>>`".
See <<service-activator-namespace>>.
[[x4.1-queue-channel-queue.typ]]
===== `QueueChannel` backed Queue type
The `QueueChannel` backed `Queue type` has been changed from `BlockingQueue` to the more generic `Queue`.
This change allows the use of any external `Queue` implementation (for example, Reactor's `PersistentQueue`).
See "`<<channel-configuration-queuechannel>>`".
See <<channel-configuration-queuechannel>>.
[[x4.1-channel-interceptor]]
===== `ChannelInterceptor` Changes
The `ChannelInterceptor` now supports additional `afterSendCompletion()` and `afterReceiveCompletion()` methods.
See "`<<channel-interceptors>>`".
See <<channel-interceptors>>.
[[x4.1-mail-peek]]
===== IMAP PEEK
Since version 4.1.1 there is a change of behavior if you explicitly set the `mail.[protocol].peek` JavaMail property to `false` (where `[protocol]` is `imap` or `imaps`).
See "`<<imap-peek>>`".
See <<imap-peek>>.

68
src/reference/asciidoc/changes-4.1-4.2.adoc
View File

@@ -17,25 +17,25 @@ This change, together with other changes in the JMX and management infrastructur
However, this has some important implications for (some) user environments.
For complete details, see "`<<metrics-management>>`" and "`<<jmx-42-improvements>>`".
For complete details, see <<metrics-management>> and <<jmx-42-improvements>>.
[[x4.2-mongodb-metadata-store]]
==== MongoDB Metadata Store
The `MongoDbMetadataStore` is now available.
For more information, see "`<<mongodb-metadata-store>>`".
For more information, see <<mongodb-metadata-store>>.
[[x4.2-secured-channel-annotation]]
==== SecuredChannel Annotation
We introduced the `@SecuredChannel` annotation, replacing the deprecated `ChannelSecurityInterceptorFactoryBean`.
For more information, see "`<<security>>`".
For more information, see <<security>>.
[[x4.2-security-context-propagation]]
==== `SecurityContext` Propagation
We introduced the `SecurityContextPropagationChannelInterceptor` for the `SecurityContext` propagation from one message flow's thread to another.
For more information, see "`<<security>>`".
For more information, see <<security>>.
[[x4.2-file-splitter]]
@@ -43,7 +43,7 @@ For more information, see "`<<security>>`".
In 4.1.2, we added `FileSplitter`, which splits text files into lines.
It now has full support in the `int-file:` namespace.
See "`<<file-splitter>>`" for more information.
See <<file-splitter>> for more information.
[[x4.2-zk]]
==== Zookeeper Support
@@ -55,32 +55,32 @@ The change impacts the following features:
* `ZookeeperLockRegistry`
* Zookeeper Leadership
See "`<<zookeeper>>`" for more information.
See <<zookeeper>> for more information.
[[x4.2-barrier]]
==== Thread Barrier
A new thread `<int:barrier/>` component is available, letting a thread be suspended until some asynchronous event occurs.
See "`<<barrier>>`" for more information.
See <<barrier>> for more information.
[[x4.2-stomp]]
==== STOMP Support
We added STOMP support to the framework as an inbound and outbound channel adapters pair.
See "`<<stomp>>`" for more information.
See <<stomp>> for more information.
[[x4.2-codec]]
==== Codec
A new `Codec` abstraction has been introduced, to encode and decode objects to and from `byte[]`.
We added an implementation that uses Kryo.
We also added codec-based transformers and message converters.
See "`<<codec>>`" for more information.
See <<codec>> for more information.
[[x4.2-prepared-statement-setter]]
==== Message PreparedStatement Setter
A new `MessagePreparedStatementSetter` functional interface callback is available for the `JdbcMessageHandler` (`<int-jdbc:outbound-gateway>` and `<int-jdbc:outbound-channel-adapter>`) as an alternative to using `SqlParameterSourceFactory` to populate parameters on the `PreparedStatement` with the `requestMessage` context.
See "`<<jdbc-outbound-channel-adapter>>`" for more information.
See <<jdbc-outbound-channel-adapter>> for more information.
[[x4.2-general]]
=== General Changes
@@ -95,7 +95,7 @@ As an alternative to the existing `selector` attribute, the `<wire-tap/>` elemen
[[x4.2-file-changes]]
==== File Changes
See "`<<files>>`" for more information about these changes.
See <<files>> for more information about these changes.
===== Appending New Lines
@@ -148,7 +148,7 @@ If you use the serializers directly within your code, you may have to `flush()`
===== Server Socket Exceptions
`TcpConnectionServerExceptionEvent` instances are now published whenever an unexpected exception occurs on a TCP server socket (also added to 4.1.3 and 4.0.7).
See "`<<tcp-events>>`" for more information.
See <<tcp-events>> for more information.
[[x4.2-tcp-server-port]]
===== TCP Server Port
@@ -166,13 +166,13 @@ This allows setting the timeout based on each message.
Also, the `remote-timeout` no longer defaults to the same value as `reply-timeout`, which has a completely different meaning.
See "`<<tcp-ob-gateway-attributes>>`" for more information.
See <<tcp-ob-gateway-attributes>> for more information.
[[x4.2-tcp-ssl]]
===== TCP SSLSession Available for Header Mapping
`TcpConnection` implementations now support `getSslSession()` to let you extract information from the session to add to message headers.
See "`<<ip-msg-headers>>`" for more information.
See <<ip-msg-headers>> for more information.
[[x4.2-tcp-events]]
===== TCP Events
@@ -182,7 +182,7 @@ New events are now published whenever a correlation exception occurs -- such as
The `TcpConnectionEventListeningMessageProducer` is deprecated.
Use the generic event adapter instead.
See "`<<tcp-events>>`" for more information.
See <<tcp-events>> for more information.
[[x4.2-inbound-channel-adapter-annotation]]
==== `@InboundChannelAdapter` Changes
@@ -209,13 +209,13 @@ This section describes general changes to the Spring Integration TCP functionali
===== Reply Listener Lazy Initialization
You can now configure the reply listener in JMS outbound gateways to be initialized on-demand and stopped after an idle period, instead of being controlled by the gateway's lifecycle.
See "`<<jms-outbound-gateway>>`" for more information.
See <<jms-outbound-gateway>> for more information.
===== Conversion Errors in Message-Driven Endpoints
The `error-channel` is now used for the conversion errors. In previous versions, they caused transaction rollback and message redelivery.
See "`<<jms-message-driven-channel-adapter>>`" and "`<<jms-inbound-gateway>>`" for more information.
See <<jms-message-driven-channel-adapter>> and <<jms-inbound-gateway>> for more information.
===== Default Acknowledge Mode
@@ -224,21 +224,21 @@ We recommend using `transacted` when using this container, to avoid message loss
This default now applies to the message-driven inbound adapter and the inbound gateway.
It was already the default for JMS-backed channels.
See "`<<jms-message-driven-channel-adapter>>`" and "`<<jms-inbound-gateway>>`" for more information.
See <<jms-message-driven-channel-adapter>> and <<jms-inbound-gateway>> for more information.
===== Shared Subscriptions
We added Namespace support for shared subscriptions (JMS 2.0) to message-driven endpoints and the `<int-jms:publish-subscribe-channel>`.
Previously, you had to wire up listener containers as `<bean/>` declarations to use shared connections.
See "`<<jms>>`" for more information.
See <<jms>> for more information.
[[x4.2-conditional-pollers]]
==== Conditional Pollers
We now provide much more flexibility for dynamic polling.
See "`<<conditional-pollers>>`" for more information.
See <<conditional-pollers>> for more information.
[[x4.2-amqp-changes]]
==== AMQP Changes
@@ -260,14 +260,14 @@ The `<int-amqp:inbound-gateway>` now exposes the `amqp-template` attribute to al
You can also provide your own `AmqpTemplate` implementation.
In addition, you can use `default-reply-to` if the request message does not have a `replyTo` property.
See "`<<amqp>>`" for more information.
See <<amqp>> for more information.
[[x4.2-xpath-splitter]]
==== XPath Splitter Improvements
The `XPathMessageSplitter` (`<int-xml:xpath-splitter>`) now allows the configuration of `output-properties` for the internal `javax.xml.transform.Transformer` and supports an `Iterator` mode (defaults to `true`) for the XPath evaluation `org.w3c.dom.NodeList` result.
See "`<<xml-xpath-splitting>>`" for more information.
See <<xml-xpath-splitting>> for more information.
[[x4.2-http-changes]]
==== HTTP Changes
@@ -279,19 +279,19 @@ This section describes general changes to the Spring Integration HTTP functional
The HTTP inbound endpoints (`<int-http:inbound-channel-adapter>` and `<int-http:inbound-gateway>`) now allow the
configuration of Cross-origin Resource Sharing (CORS).
See "`<<http-cors>>`" for more information.
See <<http-cors>> for more information.
===== Inbound Gateway Timeout
You can configure the HTTP inbound gate way to return a status code that you specify when a request times out.
The default is now `500 Internal Server Error` instead of `200 OK`.
See "`<<http-response-statuscode>>`" for more information.
See <<http-response-statuscode>> for more information.
===== Form Data
We added documentation for proxying `multipart/form-data` requests.
See "`<<http>>`" for more information.
See <<http>> for more information.
[[x4.2-gw]]
==== Gateway Changes
@@ -301,12 +301,12 @@ This section describes general changes to the Spring Integration Gateway functio
===== Gateway Methods can Return `CompletableFuture<?>`
When using Java 8, gateway methods can now return `CompletableFuture<?>`.
See "`<<gw-completable-future>>`" for more information.
See <<gw-completable-future>> for more information.
===== MessagingGateway Annotation
The request and reply timeout properties are now `String` instead of `Long` to allow configuration with property placeholders or SpEL.
See "`<<messaging-gateway-annotation>>`".
See <<messaging-gateway-annotation>>.
[[x4.2-aggregator-changes]]
==== Aggregator Changes
@@ -326,7 +326,7 @@ When using a `ref` or inner bean for the aggregator, you can now directly bind a
In addition, we added a `SimpleMessageGroupProcessor` that returns the collection of messages in the group.
When an output processor produces a collection of `Message<?>`, the aggregator releases those messages individually.
Configuring the `SimpleMessageGroupProcessor` makes the aggregator a message barrier, where messages are held up until they all arrive and are then released individually.
See "`<<aggregator>>`" for more information.
See <<aggregator>> for more information.
==== FTP and SFTP Changes
@@ -335,20 +335,20 @@ This section describes general changes to the Spring Integration FTP and SFTP fu
===== Inbound Channel Adapters
You can now specify a `remote-directory-expression` on the inbound channel adapters, to determine the directory at runtime.
See "`<<ftp>>`" and "`<<sftp>>`" for more information.
See <<ftp>> and <<sftp>> for more information.
===== Gateway Partial Results
When you use FTP or SFTP outbound gateways to operate on multiple files (with `mget` and `mput`), an exception can
occur after part of the request is completed.
If such a condition occurs, a `PartialSuccessException` that contains the partial results is thrown.
See "`<<ftp-outbound-gateway>>`" and "`<<sftp-outbound-gateway>>`" for more information.
See <<ftp-outbound-gateway>> and <<sftp-outbound-gateway>> for more information.
===== Delegating Session Factory
We added a delegating session factory, enabling the selection of a particular session factory based on some thread context value.
See "`<<ftp-dsf>>`" and "`<<sftp-dsf>>`" for more information.
See <<ftp-dsf>> and <<sftp-dsf>> for more information.
===== Default Sftp Session Factory
@@ -357,18 +357,18 @@ This is now configurable (default: `false`).
The factory now requires a configured `knownHosts`, file unless the `allowUnknownKeys` property is `true` (default: `false`).
See "`<<sftp-unk-keys>>`" for more information.
See <<sftp-unk-keys>> for more information.
===== Message Session Callback
We introduced the `MessageSessionCallback<F, T>` to perform any custom `Session` operations with the `requestMessage` context in the `<int-(s)ftp:outbound-gateway/>`.
See "`<<ftp-session-callback>>`" and "`<<sftp-session-callback>>`" for more information.
See <<ftp-session-callback>> and <<sftp-session-callback>> for more information.
==== Websocket Changes
We added `WebSocketHandlerDecoratorFactory` support to the `ServerWebSocketContainer` to allow chained customization for the internal `WebSocketHandler`.
See "`<<web-sockets-namespace>>`" for more information.
See <<web-sockets-namespace>> for more information.
==== Application Event Adapters changes

84
src/reference/asciidoc/changes-4.2-4.3.adoc
View File

@@ -12,45 +12,45 @@ Version 4.3 added a number of new components.
==== AMQP Async Outbound Gateway
See "`<<amqp-async-outbound-gateway>>`".
See <<amqp-async-outbound-gateway>>.
==== `MessageGroupFactory`
We introduced the `MessageGroupFactory` strategy to allow control over `MessageGroup` instances in `MessageGroupStore` logic.
We added `SimpleMessageGroupFactory` implementation for the `SimpleMessageGroup`, with the `GroupType.HASH_SET` as the default
factory for the standard `MessageGroupStore` implementations.
See "`<<message-store>>`" for more information.
See <<message-store>> for more information.
==== `PersistentMessageGroup`
We added the `PersistentMessageGroup` (lazy-load proxy) implementation for persistent `MessageGroupStore` instances,
which return this instance for the `getMessageGroup()` when their `lazyLoadMessageGroups` is `true` (the default).
See "`<<message-store>>`" for more information.
See <<message-store>> for more information.
==== FTP and SFTP Streaming Inbound Channel Adapters
We added inbound channel adapters that return an `InputStream` for each file, letting you retrieve remote files without writing them to the local file system.
See "`<<ftp-streaming>>`" and "`<<sftp-streaming>>`" for more information.
See <<ftp-streaming>> and <<sftp-streaming>> for more information.
==== `StreamTransformer`
We added `StreamTransformer` to transform an `InputStream` payload to either a `byte[]` or a `String`.
See "`<<stream-transformer>>`" for more information.
See <<stream-transformer>> for more information.
==== Integration Graph
We added `IntegrationGraphServer`, together with the `IntegrationGraphController` REST service, to expose the runtime model of a Spring Integration application as a graph.
See "`<<integration-graph>>`" for more information.
See <<integration-graph>> for more information.
==== JDBC Lock Registry
We added `JdbcLockRegistry` for distributed locks shared through a database table.
See "`<<jdbc-lock-registry>>`" for more information.
See <<jdbc-lock-registry>> for more information.
==== `LeaderInitiator` for `LockRegistry`
We added `LeaderInitiator` implementation based on the `LockRegistry` strategy.
See "`<<leadership-event-handling>>`" for more information.
See <<leadership-event-handling>> for more information.
[[x4.3-general]]
=== General Changes
@@ -72,14 +72,14 @@ If you have such a configuration, remove the `reply-channel`.
===== Asynchronous Service Activator
We added an option to make the service activator be synchronous.
See "`<<async-service-activator>>`" for more information.
See <<async-service-activator>> for more information.
===== Messaging Annotation Support changes
The messaging annotation support does not require a `@MessageEndpoint` (or any other `@Component`) annotation declaration on the class level.
To restore the previous behavior, set the `spring.integration.messagingAnnotations.require.componentAnnotation` of
`spring.integration.properties` to `true`.
See "`<<global-properties>>`" and "`<<annotations>>`" for more information.
See <<global-properties>> and <<annotations>> for more information.
==== Mail Changes
@@ -89,13 +89,13 @@ This section describes general changes to the Spring Integration Mail functional
The customizable `userFlag` (added in 4.2.2 to provide customization of the flag used to denote that the mail has been
seen) is now available in the XML namespace.
See "`<<imap-seen>>`" for more information.
See <<imap-seen>> for more information.
===== Mail Message Mapping
You can now map inbound mail messages with the `MessageHeaders` containing the mail headers and the payload containing the email content.
Previously, the payload was always the raw `MimeMessage`.
See "`<<mail-mapping>>`" for more information.
See <<mail-mapping>> for more information.
==== JMS Changes
@@ -104,18 +104,18 @@ This section describes general changes to the Spring Integration JMS functionali
===== Header Mapper
The `DefaultJmsHeaderMapper` now maps the standard `correlationId` header as a message property by invoking its `toString()` method.
See "`<<jms-header-mapping>>`" for more information.
See <<jms-header-mapping>> for more information.
===== Asynchronous Gateway
The JMS outbound gateway now has an `async` property.
See "`<<jms-async-gateway>>`" for more information.
See <<jms-async-gateway>> for more information.
==== Aggregator Changes
There is a change in behavior when a POJO aggregator releases a collection of `Message<?>` objects.
This is rare, but, if your application does that, you need to make a small change to your POJO.
See this "`<<agg-message-collection>>`" note for more information.
See this <<agg-message-collection>> note for more information.
==== TCP/UDP Changes
@@ -124,20 +124,20 @@ This section describes general changes to the Spring Integration TCP/UDP functio
===== Events
A new `TcpConnectionServerListeningEvent` is emitted when a server connection factory is started.
See "`<<tcp-events>>`" for more information.
See <<tcp-events>> for more information.
You can now use the `destination-expression` and `socket-expression` attributes on `<int-ip:udp-outbound-channel-adapter>`.
See "`<<udp-adapters>>`" for more information.
See <<udp-adapters>> for more information.
===== Stream Deserializers
The various deserializers that cannot allocate the final buffer until the whole message has been assembled now support pooling the raw buffer into which the data is received rather than creating and discarding a buffer for each message.
See "`<<tcp-connection-factories>>`" for more information.
See <<tcp-connection-factories>> for more information.
===== TCP Message Mapper
The message mapper now, optionally, sets a configured content type header.
See "`<<ip-msg-headers>>`" for more information.
See <<ip-msg-headers>> for more information.
==== File Changes
@@ -146,12 +146,12 @@ This section describes general changes to the Spring Integration File functional
===== Destination Directory Creation
The generated file name for the `FileWritingMessageHandler` can represent a sub-path to save the desired directory structure for a file in the target directory.
See "`<<file-writing-file-names>>`" for more information.
See <<file-writing-file-names>> for more information.
The `FileReadingMessageSource` now hides the `WatchService` directory scanning logic in the inner class.
We added the `use-watch-service` and `watch-events` options to enable this behavior.
We deprecated the top-level `WatchServiceDirectoryScanner` because of inconsistency around the API.
See "`<<watch-service-directory-scanner>>`" for more information.
See <<watch-service-directory-scanner>> for more information.
===== Buffer Size
@@ -160,24 +160,24 @@ When writing files, you can now specify the buffer size.
===== Appending and Flushing
You can now avoid flushing files when appending and use a number of strategies to flush the data during idle periods.
See "`<<file-flushing>>`" for more information.
See <<file-flushing>> for more information.
===== Preserving Timestamps
You can now configure the outbound channel adapter to set the destination file's `lastmodified` timestamp.
See "`<<file-timestamps>>`" for more information.
See <<file-timestamps>> for more information.
===== Splitter Changes
The `FileSplitter` now automatically closes an FTP or SFTP session when the file is completely read.
This applies when the outbound gateway returns an `InputStream` or when you use the new FTP or SFTP streaming channel adapters.
We also introduced a new `markers-json` option to convert `FileSplitter.FileMarker` to JSON `String` for relaxed downstream network interaction.
See "`<<file-splitter>>`" for more information.
See <<file-splitter>> for more information.
===== File Filters
We added `ChainFileListFilter` as an alternative to `CompositeFileListFilter`.
See "`<<file-reading>>`" for more information.
See <<file-reading>> for more information.
==== AMQP Changes
@@ -187,7 +187,7 @@ This section describes general changes to the Spring Integration AMQP functional
The outbound endpoints now support a `RabbitTemplate` configured with a `ContentTypeDelegatingMessageConverter` such
that you can choose the converter based on the message content type.
See "`<<content-type-conversion-outbound>>`" for more information.
See <<content-type-conversion-outbound>> for more information.
===== Headers for Delayed Message Handling
@@ -197,7 +197,7 @@ Header mapping now supports the headers (`amqp_delay` and `amqp_receivedDelay`)
===== AMQP-Backed Channels
AMQP-backed channels now support message mapping.
See "`<<amqp-channels>>`" for more information.
See <<amqp-channels>> for more information.
==== Redis Changes
@@ -208,22 +208,22 @@ This section describes general changes to the Spring Integration Redis functiona
Previously, the queue channel adapters always used the Redis list in a fixed direction, pushing to the left end and reading from the right end.
You can now configure the reading and writing direction with the `rightPop` and `leftPush` options for the
`RedisQueueMessageDrivenEndpoint` and `RedisQueueOutboundChannelAdapter`, respectively.
See "`<<redis-queue-inbound-channel-adapter>>`" and "`<<redis-queue-outbound-channel-adapter>>`" for more information.
See <<redis-queue-inbound-channel-adapter>> and <<redis-queue-outbound-channel-adapter>> for more information.
===== Queue Inbound Gateway Default Serializer
The default serializer in the inbound gateway has been changed to a `JdkSerializationRedisSerializer` for compatibility with the outbound gateway.
See "`<<redis-queue-inbound-gateway>>`" for more information.
See <<redis-queue-inbound-gateway>> for more information.
==== HTTP Changes
Previously, with requests that had a body (such as `POST`) that had no `content-type` header, the body was ignored.
With this release, the content type of such requests is considered to be `application/octet-stream` as recommended
by RFC 2616.
See "`<<http-inbound>>`" for more information.
See <<http-inbound>> for more information.
`uriVariablesExpression` now uses a `SimpleEvaluationContext` by default (since 4.3.15).
See "`<<mapping-uri-variables>>`" for more information.
See <<mapping-uri-variables>> for more information.
==== SFTP Changes
@@ -232,7 +232,7 @@ This section describes general changes to the Spring Integration SFTP functional
===== Factory Bean
We added a new factory bean to simplify the configuration of Jsch proxies for SFTP.
See "`<<sftp-proxy-factory-bean>>`" for more information.
See <<sftp-proxy-factory-bean>> for more information.
===== `chmod` Changes
@@ -248,14 +248,14 @@ This section describes general changes to the Spring Integration FTP functionali
The `FtpSession` now supports `null` for the `list()` and `listNames()` methods, since underlying FTP Client can use it.
With that, you can now configure the `FtpOutboundGateway` without the `remoteDirectory` expression.
You can also configure the `<int-ftp:inbound-channel-adapter>` without `remote-directory` or `remote-directory-expression`.
See "`<<ftp>>`" for more information.
See <<ftp>> for more information.
==== Router Changes
The `ErrorMessageExceptionTypeRouter` now supports the `Exception` superclass mappings to avoid duplication for the same channel in case of multiple inheritors.
For this purpose, the `ErrorMessageExceptionTypeRouter` loads mapping classes during initialization to fail-fast for a `ClassNotFoundException`.
See "`<<router>>`" for more information.
See <<router>> for more information.
==== Header Mapping
@@ -264,7 +264,7 @@ This section describes the changes to header mapping between version 4.2 and 4.3
===== General
AMQP, WS, and XMPP header mappings (such as `request-header-mapping` and `reply-header-mapping`) now support negated patterns.
See "`<<amqp-message-headers>>`", "`<<ws-message-headers>>`", and "`<<xmpp-message-headers>>`" for more information.
See <<amqp-message-headers>>, <<ws-message-headers>>, and <<xmpp-message-headers>> for more information.
===== AMQP Header Mapping
@@ -272,36 +272,36 @@ Previously, only standard AMQP headers were mapped by default.
You had to explicitly enable mapping of user-defined headers.
With this release, all headers are mapped by default.
In addition, the inbound `amqp_deliveryMode` header is no longer mapped by default.
See "`<<amqp-message-headers>>`" for more information.
See <<amqp-message-headers>> for more information.
==== Groovy Scripts
You can now configure groovy scripts with the `compile-static` hint or any other `CompilerConfiguration` options.
See "`<<groovy-config>>`" for more information.
See <<groovy-config>> for more information.
==== `@InboundChannelAdapter` Changes
The `@InboundChannelAdapter` now has an alias `channel` attribute for the regular `value`.
In addition, the target `SourcePollingChannelAdapter` components can now resolve the target `outputChannel` bean from its provided name (`outputChannelName` options) in a late-binding manner.
See "`<<annotations>>`" for more information.
See <<annotations>> for more information.
==== XMPP Changes
The XMPP channel adapters now support the XMPP Extensions (XEP).
See "`<<xmpp-extensions>>`" for more information.
See <<xmpp-extensions>> for more information.
==== WireTap Late Binding
The `WireTap` `ChannelInterceptor` now can accept a `channelName` that is resolved to the target `MessageChannel`
later, during the first active interceptor operation.
See "`<<channel-wiretap>>`" for more information.
See <<channel-wiretap>> for more information.
==== `ChannelMessageStoreQueryProvider` Changes
The `ChannelMessageStoreQueryProvider` now supports H2 databases.
See "`<<jdbc-message-store-channels>>`" for more information.
See <<jdbc-message-store-channels>> for more information.
==== WebSocket Changes
The `ServerWebSocketContainer` now exposes an `allowedOrigins` option, and `SockJsServiceOptions` exposes a `suppressCors` option.
See "`<<web-sockets>>`" for more information.
See <<web-sockets>> for more information.

80
src/reference/asciidoc/changes-4.3-5.0.adoc
View File

@@ -13,7 +13,7 @@ Version 5.0 added a number of new components.
The separate https://github.com/spring-projects/spring-integration-java-dsl[Spring Integration Java DSL] project has now been merged into the core Spring Integration project.
The `IntegrationComponentSpec` implementations for channel adapters and gateways are distributed to their specific modules.
See "`<<java-dsl>>`" for more information about Java DSL support.
See <<java-dsl>> for more information about Java DSL support.
See also the https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-4.3-to-5.0-Migration-Guide#java-dsl[4.3 to 5.0 Migration Guide] for the required steps to move to Spring Integration 5.0.
==== Testing Support
@@ -21,38 +21,38 @@ See also the https://github.com/spring-projects/spring-integration/wiki/Spring-I
We created a new Spring Integration Test Framework to help with testing Spring Integration applications.
Now, with the `@SpringIntegrationTest` annotation on test classes and the `MockIntegration` factory, you can make your JUnit tests for integration flows somewhat easier.
See "`<<testing>>`" for more information.
See <<testing>> for more information.
==== MongoDB Outbound Gateway
The new `MongoDbOutboundGateway` lets you make queries to the database on demand by sending a message to its request channel.
See "`<<mongodb-outbound-gateway>>`" for more information.
See <<mongodb-outbound-gateway>> for more information.
==== WebFlux Gateways and Channel Adapters
We introduced the new WebFlux support module for Spring WebFlux Framework gateways and channel adapters.
See "`<<webflux>>`" for more information.
See <<webflux>> for more information.
==== Content Type Conversion
Now that we use the new `InvocableHandlerMethod`-based infrastructure for service method invocations, we can perform `contentType` conversion from the payload to a target method argument.
See "`<<content-type-conversion>>`" for more information.
See <<content-type-conversion>> for more information.
==== `ErrorMessagePublisher` and `ErrorMessageStrategy`
We added `ErrorMessagePublisher` and the `ErrorMessageStrategy` for creating `ErrorMessage` instances.
See "`<<namespace-errorhandler>>`" for more information.
See <<namespace-errorhandler>> for more information.
==== JDBC Metadata Store
We added a JDBC implementation of the `MetadataStore` implementation.
This is useful when you need to ensure transactional boundaries for metadata.
See "`<<jdbc-metadata-store>>`" for more information.
See <<jdbc-metadata-store>> for more information.
[[x5.0-general]]
=== General Changes
@@ -63,33 +63,33 @@ Previous Project Reactor versions are no longer supported.
==== Core Changes
The `@Poller` annotation now has the `errorChannel` attribute for easier configuration of the underlying `MessagePublishingErrorHandler`.
See "`<<annotations>>`" for more information.
See <<annotations>> for more information.
All the request-reply endpoints (based on `AbstractReplyProducingMessageHandler`) can now start transactions and, therefore, make the whole downstream flow transactional.
See "`<<tx-handle-message-advice>>`" for more information.
See <<tx-handle-message-advice>> for more information.
The `SmartLifecycleRoleController` now provides methods to obtain status of endpoints in roles.
See "`<<endpoint-roles>>`" for more information.
See <<endpoint-roles>> for more information.
By default, POJO methods are now invoked by using an `InvocableHandlerMethod`, but you can configure them to use SpEL, as before.
See "`<<pojo-invocation>>`" for more information.
See <<pojo-invocation>> for more information.
When targeting POJO methods as message handlers, you can now mark one of the service methods with the `@Default` annotation to provide a fallback mechanism for non-matched conditions.
See "`<<service-activator-namespace>>`" for more information.
See <<service-activator-namespace>> for more information.
We added a simple `PassThroughTransactionSynchronizationFactory` to always store a polled message in the current transaction context.
That message is used as a `failedMessage` property of the `MessagingException`, which wraps any raw exception thrown during transaction completion.
See "`<<transaction-synchronization>>`" for more information.
See <<transaction-synchronization>> for more information.
The aggregator expression-based `ReleaseStrategy` now evaluates the expression against the `MessageGroup` instead of just the collection of `Message<?>`.
See "`<<aggregator-spel>>`" for more information.
See <<aggregator-spel>> for more information.
You can now supply the `ObjectToMapTransformer` with a customized `JsonObjectMapper`.
See "`<<aggregator-spel>>`" for more information.
See <<aggregator-spel>> for more information.
The `@GlobalChannelInterceptor` annotation and `<int:channel-interceptor>` now support negative patterns (via `!` prepending) for component names matching.
See "`<<global-channel-configuration-interceptors>>`" for more information.
See <<global-channel-configuration-interceptors>> for more information.
When a candidate failed to acquire the lock, the `LockRegistryLeaderInitiator` now emits a new `OnFailedToAcquireMutexEvent` through `DefaultLeaderEventPublisher`.
See `<<leadership-event-handling>>` for more information.
@@ -103,20 +103,20 @@ This caused synchronous downstream flows (running on the calling thread) to send
The `RequestReplyExchanger` interface now has a `throws MessagingException` clause to meet the proposed messages exchange contract.
You can now specify the request and reply timeouts with SpEL expressions.
See "`<<gateway>>`" for more information.
See <<gateway>> for more information.
==== Aggregator Performance Changes
By default, aggregators now use a `SimpleSequenceSizeReleaseStrategy`, which is more efficient, especially with large groups.
Empty groups are now scheduled for removal after `empty-group-min-timeout`.
See "`<<aggregator>>`" for more information.
See <<aggregator>> for more information.
==== Splitter Changes
The splitter component can now handle and split Java `Stream` and Reactive Streams `Publisher` objects.
If the output channel is a `ReactiveStreamsSubscribableChannel`, the `AbstractMessageSplitter` builds a `Flux` for subsequent iteration instead of a regular `Iterator`, independent of the object being split.
In addition, `AbstractMessageSplitter` provides `protected obtainSizeIfPossible()` methods to allow determination of the size of the `Iterable` and `Iterator` objects, if that is possible.
See "`<<splitter>>`" for more information.
See <<splitter>> for more information.
==== JMS Changes
@@ -124,7 +124,7 @@ Previously, Spring Integration JMS XML configuration used a default bean name of
We renamed it to `jmsConnectionFactory`, which is the bean name used by Spring Boot to auto-configure the JMS connection factory bean.
If your application relies on the previous behavior, you can rename your `connectionFactory` bean to `jmsConnectionFactory` or specifically configure your components to use your bean by using its current name.
See "`<<jms>>`" for more information.
See <<jms>> for more information.
==== Mail Changes
@@ -134,7 +134,7 @@ See <<imap-format-important,the note in the "`Mail-receiving Channel Adapter`" s
==== Feed Changes
Instead of the `com.rometools.fetcher.FeedFetcher`, which is deprecated in ROME, we introduced a new `Resource` property for the `FeedEntryMessageSource`.
See "`<<feed>>`" for more information.
See <<feed>> for more information.
==== File Changes
@@ -149,11 +149,11 @@ The file outbound channel adapter and gateway (`FileWritingMessageHandler`) now
They also now support setting file permissions on the newly written file.
A new `FileSystemMarkerFilePresentFileListFilter` is now available.
See "`<<file-incomplete>>`" for more information.
See <<file-incomplete>> for more information.
The `FileSplitter` now provides a `firstLineAsHeader` option to carry the first line of content as a header in the messages emitted for the remaining lines.
See "`<<files>>`" for more information.
See <<files>> for more information.
==== FTP and SFTP Changes
@@ -174,7 +174,7 @@ The FTP and SFTP streaming inbound channel adapters now add remote file informat
The FTP and SFTP outbound channel adapters (as well as the `PUT` command for outbound gateways) now support `InputStream` as `payload`, too.
The inbound channel adapters can now build file trees locally by using a newly introduced `RecursiveDirectoryScanner`.
See the `scanner` option in the "`<<ftp-inbound>>`" section for injection.
See the `scanner` option in the <<ftp-inbound>> section for injection.
Also, you can now switch these adapters to the `WatchService` instead.
We added The `NLST` command to the `AbstractRemoteFileOutboundGateway` to perform the list files names remote command.
@@ -187,22 +187,22 @@ We added new filters for detecting incomplete remote files.
The `FtpOutboundGateway` and `SftpOutboundGateway` now support an option to remove the remote file after a successful transfer by using the `GET` or `MGET` commands.
See "`<<ftp>>`" and "`<<sftp>>`" for more information.
See <<ftp>> and <<sftp>> for more information.
==== Integration Properties
Version 4.3.2 added a new `spring.integration.readOnly.headers` global property to let you customize the list of headers that should not be copied to a newly created `Message` by the `MessageBuilder`.
See "`<<global-properties>>`" for more information.
See <<global-properties>> for more information.
==== Stream Changes
We added a new option on the `CharacterStreamReadingMessageSource` to let it be used to "`pipe`" stdin and publish an application event when the pipe is closed.
See "`<<stream-reading>>`" for more information.
See <<stream-reading>> for more information.
==== Barrier Changes
The `BarrierMessageHandler` now supports a discard channel to which late-arriving trigger messages are sent.
See "`<<barrier>>`" for more information.
See <<barrier>> for more information.
==== AMQP Changes
@@ -215,16 +215,16 @@ Pollable AMQP-backed channels now block the poller thread for the poller's confi
Headers, such as `contentType`, that are added to message properties by the message converter are now used in the final message.
Previously, it depended on the converter type as to which headers and message properties appeared in the final message.
To override the headers set by the converter, set the `headersMappedLast` property to `true`.
See "`<<amqp>>`" for more information.
See <<amqp>> for more information.
==== HTTP Changes
By default, the `DefaultHttpHeaderMapper.userDefinedHeaderPrefix` property is now an empty string instead of `X-`.
See "`<<http-header-mapping>>`" for more information.
See <<http-header-mapping>> for more information.
By default, `uriVariablesExpression` now uses a `SimpleEvaluationContext` (since 5.0.4).
See "`<<mapping-uri-variables>>`" for more information.
See <<mapping-uri-variables>> for more information.
==== MQTT Changes
@@ -232,13 +232,13 @@ Inbound messages are now mapped with the `RECEIVED_TOPIC`, `RECEIVED_QOS`, and `
The outbound channel adapter now supports expressions for the topic, qos, and retained properties.
The defaults remain the same.
See "`<<mqtt>>`" for more information.
See <<mqtt>> for more information.
==== STOMP Changes
We changed the STOMP module to use `ReactorNettyTcpStompClient`, based on the Project Reactor `3.1` and `reactor-netty` extension.
We renamed `Reactor2TcpStompSessionManager` to `ReactorNettyTcpStompSessionManager`, according to the `ReactorNettyTcpStompClient` foundation.
See "`<<stomp>>`" for more information.
See <<stomp>> for more information.
==== Web Services Changes
@@ -248,7 +248,7 @@ You can now supply `WebServiceOutboundGateway` instances with an externally conf
Simple WebService inbound and outbound gateways can now deal with the complete `WebServiceMessage` as a `payload`, allowing the manipulation of MTOM attachments.
See "`<<ws>>`" for more information.
See <<ws>> for more information.
==== Redis Changes
@@ -259,7 +259,7 @@ In addition, this property has been changed from `true` to `false` since the `IN
You can now supply the `RedisInboundChannelAdapter` with an `Executor` for executing Redis listener invokers.
In addition, the received messages now contain a `RedisHeaders.MESSAGE_SOURCE` header to indicate the source of the message (topic or pattern).
See "`<<redis>>`" for more information.
See <<redis>> for more information.
==== TCP Changes
@@ -269,12 +269,12 @@ You can now configure the TCP connection factories to support `PushbackInputStre
We added a `ByteArrayElasticRawDeserializer` without `maxMessageSize` to control and buffer incoming data as needed.
See "`<<ip>>`" for more information.
See <<ip>> for more information.
==== Gemfire Changes
The `GemfireMetadataStore` now implements `ListenableMetadataStore`, letting you listen to cache events by providing `MetadataStoreListener` instances to the store.
See "`<<gemfire>>`" for more information.
See <<gemfire>> for more information.
==== JDBC Changes
@@ -282,13 +282,13 @@ The `JdbcMessageChannelStore` now provides a setter for `ChannelMessageStorePrep
The `ExpressionEvaluatingSqlParameterSourceFactory` now provides a setter for `sqlParameterTypes`, letting you customize the SQL types of the parameters.
See "`<<jdbc>>`" for more information.
See <<jdbc>> for more information.
==== Metrics Changes
http://micrometer.io/[Micrometer] application monitoring is now supported (since version 5.0.2).
See "`<<micrometer-integration>>`" for more information.
See <<micrometer-integration>> for more information.
IMPORTANT: Changes were made to the Micrometer `Meters` in version 5.0.3 to make them more suitable for use in dimensional systems.
Further changes were made in 5.0.4.
@@ -298,4 +298,4 @@ If you usie Micrometer, we recommend a minimum of version 5.0.4.
==== `@EndpointId` Annotations
Introduced in version 5.0.4, this annotation provides control over bean naming when you use Java configuration.
See "`<<endpoint-bean-names>>`" for more information.
See <<endpoint-bean-names>> for more information.

6
src/reference/asciidoc/channel-adapter.adoc
View File

@@ -30,10 +30,10 @@ The following example defines two `inbound-channel-adapter` instances:
----
====
See also "`<<channel-adapter-expressions-and-scripts>>`".
See also <<channel-adapter-expressions-and-scripts>>.
NOTE: If no poller is provided, then a single default poller must be registered within the context.
See "`<<endpoint-namespace>>`" for more detail.
See <<endpoint-namespace>> for more detail.
[IMPORTANT]
.Important: Poller Configuration
@@ -147,7 +147,7 @@ If you want the script to be checked on each poll, you would need to coordinate
====
See also the `cacheSeconds` property on the `ReloadableResourceBundleExpressionSource` when using the `<expression/>` sub-element.
For more information regarding expressions, see "`<<spel>>`". For scripts, see "`<<groovy>>`" and "`<<scripting>>`".
For more information regarding expressions, see <<spel>>. For scripts, see <<groovy>> and <<scripting>>.
IMPORTANT: The `<int:inbound-channel-adapter/>` is endpoint starts a message flow by periodically triggering to poll some underlying `MessageSource`.
Since, at the time of polling, there is no message object, expressions and scripts do not have access to a root `Message`, so there are no payload or headers properties that are available in most other messaging SpEL expressions.

40
src/reference/asciidoc/channel.adoc
View File

@@ -127,7 +127,7 @@ In other words, with a `RendezvousChannel`, the sender knows that some receiver
TIP: Keep in mind that all of these queue-based channels are storing messages in-memory only by default.
When persistence is required, you can either provide a 'message-store' attribute within the 'queue' element to reference a persistent `MessageStore` implementation or you can replace the local channel with one that is backed by a persistent broker, such as a JMS-backed channel or channel adapter.
The latter option lets you take advantage of any JMS provider's implementation for message persistence, as discussed in "`<<jms>>`".
The latter option lets you take advantage of any JMS provider's implementation for message persistence, as discussed in <<jms>>.
However, when buffering in a queue is not necessary, the simplest approach is to rely upon the `DirectChannel`, discussed in the next section.
The `RendezvousChannel` is also useful for implementing request-reply operations.
@@ -280,7 +280,7 @@ Therefore, the `preReceive(...)`, `postReceive(...)`, and `afterReceiveCompletio
Spring Integration also provides an implementation of the http://eaipatterns.com/WireTap.html[Wire Tap] pattern.
It is a simple interceptor that sends the `Message` to another channel without otherwise altering the existing flow.
It can be very useful for debugging and monitoring.
An example is shown in "`<<channel-wiretap>>`".
An example is shown in <<channel-wiretap>>.
Because it is rarely necessary to implement all of the interceptor methods, a `ChannelInterceptorAdapter` class is also available for sub-classing.
It provides no-op methods (the `void` method is empty, the `Message`-returning methods return the `Message` as-is, and the `boolean` method returns `true`).
@@ -353,7 +353,7 @@ public Message<?> receive(final PollableChannel<?> channel) { ...
----
====
NOTE: A less invasive approach that lets you invoke simple interfaces with payload or header values instead of `Message` instances is described in "`<<gateway-proxy>>`".
NOTE: A less invasive approach that lets you invoke simple interfaces with payload or header values instead of `Message` instances is described in <<gateway-proxy>>.
[[channel-configuration]]
==== Configuring Message Channels
@@ -379,7 +379,7 @@ To create a publish-subscribe channel, use the `<publish-subscribe-channel/>` el
When you use the `<channel/>` element without any sub-elements, it creates a `DirectChannel` instance (a `SubscribableChannel`).
However, you can alternatively provide a variety of `<queue/>` sub-elements to create any of the pollable channel types (as described in "`<<channel-implementations>>`").
However, you can alternatively provide a variety of `<queue/>` sub-elements to create any of the pollable channel types (as described in <<channel-implementations>>).
The following sections shows examples of each channel type.
[[channel-configuration-directchannel]]
@@ -395,7 +395,7 @@ The following listing shows who to define one in XML:
----
====
A default channel has a round-robin load-balancer and also has failover enabled (see "`<<channel-implementations-directchannel>>`" for more detail).
A default channel has a round-robin load-balancer and also has failover enabled (see <<channel-implementations-directchannel>> for more detail).
To disable one or both of these, add a `<dispatcher/>` sub-element and configure the attributes as follows:
====
@@ -493,7 +493,7 @@ Then we can register it as a converter with the Integration Conversion Service,
When the 'converter' element is parsed, it creates the `integrationConversionService` bean if one is not already defined.
With that converter in place, the `send` operation would now be successful, because the datatype channel uses that converter to convert the `String` payload to an `Integer`.
For more information regarding payload type conversion, see "`<<payload-type-conversion>>`".
For more information regarding payload type conversion, see <<payload-type-conversion>>.
Beginning with version 4.0, the `integrationConversionService` is invoked by the `DefaultDatatypeChannelMessageConverter`, which looks up the conversion service in the application context.
To use a different conversion technique, you can specify the `message-converter` attribute on the channel.
@@ -527,7 +527,7 @@ To avoid issues such as running out of memory, we highly recommend that you set
Since a `QueueChannel` provides the capability to buffer messages but does so in-memory only by default, it also introduces a possibility that messages could be lost in the event of a system failure.
To mitigate this risk, a `QueueChannel` may be backed by a persistent implementation of the `MessageGroupStore` strategy interface.
For more details on `MessageGroupStore` and `MessageStore`, see "`<<message-store>>`".
For more details on `MessageGroupStore` and `MessageStore`, see <<message-store>>.
IMPORTANT: The `capacity` attribute is not allowed when the `message-store` attribute is used.
@@ -639,13 +639,13 @@ If you provide a resequencer or aggregator downstream from a `PublishSubscribeCh
Doing so indicates that the channel should set the `sequence-size` and `sequence-number` message headers as well as the correlation ID prior to passing along the messages.
For example, if there are five subscribers, the `sequence-size` would be set to `5`, and the messages would have `sequence-number` header values ranging from `1` to `5`.
Alongside with the `Executor`, an `ErrorHandler` can be configured as well.
By default the `PublishSubscribeChannel` uses a `MessagePublishingErrorHandler` implementation to send error to the `MessageChannel` from the `errorChannel` header or a global `errorChannel` instance.
If an `Executor` is not configured, the `ErrorHandler` is ignored and exceptions are thrown directly to the caller's Thread.
Along with the `Executor`, you can also configure an `ErrorHandler`.
By default, the `PublishSubscribeChannel` uses a `MessagePublishingErrorHandler` implementation to send an error to the `MessageChannel` from the `errorChannel` header or into the global `errorChannel` instance.
If an `Executor` is not configured, the `ErrorHandler` is ignored and exceptions are thrown directly to the caller's thread.
If you are providing a _Resequencer_ or _Aggregator_ downstream from a `PublishSubscribeChannel`, then you can set the 'apply-sequence' property on the channel to `true`.
That will indicate that the channel should set the sequence-size and sequence-number Message headers as well as the correlation id prior to passing the Messages along.
For example, if there are 5 subscribers, the sequence-size would be set to 5, and the Messages would have sequence-number header values ranging from 1 to 5.
If you provide a `Resequencer` or `Aggregator` downstream from a `PublishSubscribeChannel`, you can set the 'apply-sequence' property on the channel to `true`.
Doing so indicates that the channel should set the sequence-size and sequence-number message headers as well as the correlation ID prior to passing along the messages.
For example, if there are five subscribers, the sequence-size would be set to `5`, and the messages would have sequence-number header values ranging from `1` to `5`.
The following example shows how to set the `apply-sequence` header to `true`:
@@ -679,7 +679,7 @@ The following example shows how to use the `dispatcher` element and specify an e
[NOTE]
=====
The `load-balancer` and `failover` options are also both available on the <dispatcher/> sub-element, as described earlier in "`<<channel-configuration-directchannel>>`".
The `load-balancer` and `failover` options are also both available on the <dispatcher/> sub-element, as described earlier in <<channel-configuration-directchannel>>.
The same defaults apply.
Consequently, the channel has a round-robin load-balancing strategy with failover enabled unless explicit configuration is provided for one or both of those attributes, as the following example shows:
@@ -726,8 +726,8 @@ The following example demonstrates all of these:
Since version 4.0, the `priority-channel` child element supports the `message-store` option (`comparator` and `capacity` are not allowed in that case).
The message store must be a `PriorityCapableChannelMessageStore`.
Implementations of the `PriorityCapableChannelMessageStore` are currently provided for `Redis`, `JDBC`, and `MongoDB`.
See "`<<channel-configuration-queuechannel>>`" and "`<<message-store>>`" for more information.
You can find sample configuration in "`<<jdbc-message-store-channels>>`".
See <<channel-configuration-queuechannel>> and <<message-store>> for more information.
You can find sample configuration in <<jdbc-message-store-channels>>.
[[channel-configuration-rendezvouschannel]]
===== `RendezvousChannel` Configuration
@@ -761,7 +761,7 @@ Any channel can be configured with a `scope` attribute, as the following example
[[channel-configuration-interceptors]]
===== Channel Interceptor Configuration
Message channels may also have interceptors, as described in "`<<channel-interceptors>>`".
Message channels may also have interceptors, as described in <<channel-interceptors>>.
The `<interceptors/>` sub-element can be added to a `<channel/>` (or the more specific element types).
You can provide the `ref` attribute to reference any Spring-managed object that implements the `ChannelInterceptor` interface, as the following example shows:
@@ -836,7 +836,7 @@ NOTE: Note that both the `order` and `pattern` attributes are optional.
The default value for `order` will be 0 and for `pattern`, the default is '*' (to match all channels).
Starting with version 4.3.15, you can configure the `spring.integration.postProcessDynamicBeans = true` property to apply any global interceptors to dynamically created `MessageChannel` beans.
See "`<<global-properties>>`" for more information.
See <<global-properties>> for more information.
[[channel-wiretap]]
===== Wire Tap
@@ -960,7 +960,7 @@ If namespace support is enabled, two special channels are defined within the app
The 'nullChannel' acts like `/dev/null`, logging any message sent to it at the `DEBUG` level and returning immediately.
Any time you face channel resolution errors for a reply that you do not care about, you can set the affected component's `output-channel` attribute to 'nullChannel' (the name, 'nullChannel', is reserved within the application context).
The 'errorChannel' is used internally for sending error messages and may be overridden with a custom configuration.
This is discussed in greater detail in "`<<namespace-errorhandler>>`".
This is discussed in greater detail in <<namespace-errorhandler>>.
See also "`<<java-dsl-channels>>`" in the Java DSL chapter for more information about message channel and interceptors.
See also <<java-dsl-channels>> in the Java DSL chapter for more information about message channel and interceptors.

4
src/reference/asciidoc/claim-check.adoc
View File

@@ -172,6 +172,7 @@ This feature has an impact in terms of storage space, especially in the case of
Therefore, if you do not expect multiple claims to be made, we recommend that you set the `remove-message` attribute's value to `true`.
The following example show how to use the `remove-message` attribute:
====
[source,xml]
----
<int:claim-check-out id="checkout"
@@ -180,8 +181,9 @@ The following example show how to use the `remove-message` attribute:
output-channel="output"
remove-message="true"/>
----
====
==== A word on Message Store
==== A Word on Message Store
Although we rarely care about the details of the claim checks (as long as they work), you should know that the current implementation of the actual claim check (the pointer) in Spring Integration uses a UUID to ensure uniqueness.

2
src/reference/asciidoc/codec.adoc
View File

@@ -129,6 +129,7 @@ You can also use this technique to wrap a serialization library other than Kryo.
Kryo also provides a `@DefaultSerializer` annotation, as described https://github.com/EsotericSoftware/kryo#default-serializers[here].
====
[source,java]
----
@DefaultSerializer(SomeClassSerializer.class)
@@ -136,6 +137,7 @@ public class SomeClass {
// ...
}
----
====
If you have write access to the domain object, this may be a simpler way to specify a custom serializer.
Note that this does not register the class with an ID, which may make the technique unhelpful for certain situations.

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

@@ -114,7 +114,7 @@ IntegrationContextUtils.TASK_SCHEDULER_BEAN_NAME
====
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` starts up automatically with a pool of ten threads, but see "`<<global-properties>>`".
That default `TaskScheduler` starts up automatically with a pool of ten threads, but see <<global-properties>>.
If you provide your own `TaskScheduler` instance instead, you can set the 'autoStartup' property to `false` or provide your own pool size value.
When polling consumers provide an explicit task executor reference in their configuration, the invocation of the handler methods happens within that executor's thread pool and not the main scheduler pool.
@@ -167,9 +167,9 @@ In that case, if an `Exception` is thrown, it can be caught by the sender (or it
So far, everything is fine.
This is the same behavior as an exception-throwing operation in a normal call stack.
A message flow that runs on a caller thread might be invoked through a messaging gateway (see "`<<gateway>>`") or a `MessagingTemplate` (see "`<<channel-template>>`").
A message flow that runs on a caller thread might be invoked through a messaging gateway (see <<gateway>>) or a `MessagingTemplate` (see <<channel-template>>).
In either case, the default behavior is to throw any exceptions to the caller.
For the messaging gateway, see "`<<gateway-error-handling>>`" for details about how the exception is thrown and how to configure the gateway to route the errors to an error channel instead.
For the messaging gateway, see <<gateway-error-handling>> for details about how the exception is thrown and how to configure the gateway to route the errors to an error channel instead.
When using a `MessagingTemplate` or sending to a `MessageChannel` directly, exceptions are always thrown to the caller.
When adding asynchronous processing, things become rather more complicated.
@@ -257,18 +257,18 @@ It can be used to avoid inadvertently subscribing more than the expected number
You can override it on individual channels by setting the `max-subscribers` attribute.
<4> The number of threads available in the default `taskScheduler` bean.
See "`<<namespace-taskscheduler>>`".
See <<namespace-taskscheduler>>.
<5> When `true`, messages that arrive at a gateway reply channel throw an exception when the gateway is not
expecting a reply (because the sending thread has timed out or already received a reply).
<6> A comma-separated list of message header names that should not be populated into `Message` instances during a header copying operation.
The list is used by the `DefaultMessageBuilderFactory` bean and propagated to the `IntegrationMessageHeaderAccessor` instances (see "`<<message-header-accessor>>`") used to build messages via `MessageBuilder` (see "`<<message-builder>>`").
The list is used by the `DefaultMessageBuilderFactory` bean and propagated to the `IntegrationMessageHeaderAccessor` instances (see <<message-header-accessor>>) used to build messages via `MessageBuilder` (see <<message-builder>>).
By default, only `MessageHeaders.ID` and `MessageHeaders.TIMESTAMP` are not copied during message building.
Since version 4.3.2.
<7> A comma-separated list of `AbstractEndpoint` bean names patterns (`xxx*`, `*xxx`, `*xxx*` or `xxx*yyy`) that should not be started automatically during application startup.
You can manually start these endpoints later by their bean name through a `Control Bus` (see "`<<control-bus>>`"), by their role with the `SmartLifecycleRoleController` (see <<endpoint-roles>>), or by `Lifecycle` bean injection.
You can manually start these endpoints later by their bean name through a `Control Bus` (see <<control-bus>>), by their role with the `SmartLifecycleRoleController` (see <<endpoint-roles>>), or by `Lifecycle` bean injection.
You can explicitly override the effect of this global property by specifying `auto-startup` XML annotation or the `autoStartup` annotation attribute or by calling `AbstractEndpoint.setAutoStartup()` in the bean definition.
Since version 4.3.12.
@@ -306,17 +306,17 @@ public class FooService {
Exactly what it means for the method to "`handle`" the Message depends on the particular annotation.
Annotations available in Spring Integration include:
* `@Aggregator` (see "`<<aggregator>>`")
* `@Filter` (see "`<<filter>>`")
* `@Router` (see "`<<router>>`")
* `@ServiceActivator` (see "`<<service-activator>>`")
* `@Splitter` (see "`<<splitter>>`")
* `@Transformer` (see "`<<transformer>>`")
* `@InboundChannelAdapter` (see "`<<channel-adapter>>`")
* `@BridgeFrom` (see "`<<bridge-annot>>`")
* `@BridgeTo` (see "`<<bridge-annot>>`")
* `@MessagingGateway` (see "`<<gateway>>`")
* `@IntegrationComponentScan` (see "`<<configuration-enable-integration>>`")
* `@Aggregator` (see <<aggregator>>)
* `@Filter` (see <<filter>>)
* `@Router` (see <<router>>)
* `@ServiceActivator` (see <<service-activator>>)
* `@Splitter` (see <<splitter>>)
* `@Transformer` (see <<transformer>>)
* `@InboundChannelAdapter` (see <<channel-adapter>>)
* `@BridgeFrom` (see <<bridge-annot>>)
* `@BridgeTo` (see <<bridge-annot>>)
* `@MessagingGateway` (see <<gateway>>)
* `@IntegrationComponentScan` (see <<configuration-enable-integration>>)
NOTE: If you use 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, you can provide only the method-level annotations.
@@ -403,7 +403,7 @@ public class ThingService {
====
The processing of these annotations creates the same beans as the corresponding XML components -- `AbstractEndpoint` instances and `MessageHandler` instances (or `MessageSource` instances for the inbound channel adapter).
See "`<<annotations_on_beans>>`".
See <<annotations_on_beans>>.
The bean names are generated from the following pattern: `[componentName].[methodName].[decapitalizedAnnotationClassShortName]`
(for example, for the preceding example the bean name is `thingService.otherThing.serviceActivator`) for the `AbstractEndpoint` and the same name with an additional `.handler` (`.source`) suffix for the `MessageHandler` (`MessageSource`) bean.
The `MessageHandler` instances (`MessageSource` instances) are also eligible to be tracked by <<message-history, the message history>>.
@@ -411,7 +411,7 @@ The `MessageHandler` instances (`MessageSource` instances) are also eligible to
Starting with version 4.0, all messaging annotations provide `SmartLifecycle` options (`autoStartup` and `phase`) to allow endpoint lifecycle control on application context initialization.
They default to `true` and `0`, respectively.
To change the state of an endpoint (such as ` start()` or `stop()`), you can obtain a reference to the endpoint bean by using the `BeanFactory` (or autowiring) and invoke the methods.
Alternatively, you can send a command message to the `Control Bus` (see "`<<control-bus>>`").
Alternatively, you can send a command message to the `Control Bus` (see <<control-bus>>).
For these purposes, you should use the `beanName` mentioned earlier in the preceding paragraph.
[[configuration-using-poller-annotation]]
@@ -501,7 +501,7 @@ public class AnnotationService {
Starting with version 4.3.3, the `@Poller` annotation has the `errorChannel` attribute for easier configuration of the underlying `MessagePublishingErrorHandler`.
This attribute plays the same role as `error-channel` in the `<poller>` XML component.
See "`<<endpoint-namespace>>`" for more information.
See <<endpoint-namespace>> for more information.
==== Using the `@InboundChannelAdapter` Annotation
@@ -536,12 +536,12 @@ The first example requires that the default poller has been declared elsewhere i
Using the `@MessagingGateway` Annotation
See "`<<messaging-gateway-annotation>>`".
See <<messaging-gateway-annotation>>.
==== Using the `@IntegrationComponentScan` Annotation
The standard Spring Framework `@ComponentScan` annotation does not scan interfaces for stereotype `@Component` annotations.
To overcome this limitation and allow the configuration of `@MessagingGateway` (see "`<<messaging-gateway-annotation>>`"), we introduced the `@IntegrationComponentScan` mechanism.
To overcome this limitation and allow the configuration of `@MessagingGateway` (see <<messaging-gateway-annotation>>), we introduced the `@IntegrationComponentScan` mechanism.
This annotation must be placed with a `@Configuration` annotation and be customized to define its scanning options,
such as `basePackages` and `basePackageClasses`.
In this case, all discovered interfaces annotated with `@MessagingGateway` are parsed and registered as `GatewayProxyFactoryBean` instances.
@@ -667,7 +667,7 @@ NOTE: The bean names are generated with the following algorithm:
This works as though there were no messaging annotation on the `@Bean` method.
* The `AbstractEndpoint` bean name is generated with the following pattern: `[configurationComponentName].[methodName].[decapitalizedAnnotationClassShortName]`.
For example, the `SourcePollingChannelAdapter` endpoint for the `consoleSource()` definition <<annotations_on_beans,shown earlier>> gets a bean name of `myFlowConfiguration.consoleSource.inboundChannelAdapter`.
See also "`<<endpoint-bean-names>>`".
See also <<endpoint-bean-names>>.
IMPORTANT: When using these annotations on `@Bean` definitions, the `inputChannel` must reference a declared bean.
Channels are not automatically declared in this case.
@@ -726,7 +726,7 @@ You can use these annotations as meta-annotations as well.
==== Advising Annotated Endpoints
See "`<<advising-with-annotations>>`".
See <<advising-with-annotations>>.
[[message-mapping-rules]]
=== Message Mapping Rules and Conventions

6
src/reference/asciidoc/content-enrichment.adoc
View File

@@ -17,7 +17,7 @@ It also includes three adapter-specific header enrichers:
See the adapter-specific sections of this reference manual to learn more about those adapters.
For more information regarding expressions support, see "`<<spel>>`".
For more information regarding expressions support, see <<spel>>.
[[header-enricher]]
==== Header Enricher
@@ -54,7 +54,7 @@ The header enricher also provides helpful sub-elements to set well known header
The preceding configuration shows that, for well known headers (such as `errorChannel`, `correlationId`, `priority`, `replyChannel`, `routing-slip`, and others), instead of using generic `<header>` sub-elements where you would have to provide both header 'name' and 'value', you can use convenient sub-elements to set those values directly.
Starting with version 4.1, the header enricher provides a `routing-slip` sub-element.
See "`<<routing-slip>>`" for more information.
See <<routing-slip>> for more information.
===== POJO Support
@@ -364,7 +364,7 @@ When the `enricher` returns null, it is evaluated, and the output of the evaluat
This section contains several examples of using a payload enricher in various situations.
TIP: The code samples shown here are part of the Spring Integration Samples project.
See "`<<samples>>`".
See <<samples>>.
In the following example, a `User` object is passed as the payload of the `Message`:

4
src/reference/asciidoc/delayer.adoc
View File

@@ -110,7 +110,7 @@ Consequently, if there is a possibility of the header being omitted and you want
The delayer delegates to an instance of Spring's `TaskScheduler` abstraction.
The default scheduler used by the delayer is the `ThreadPoolTaskScheduler` instance provided by Spring Integration on startup.
See "`<<namespace-taskscheduler>>`".
See <<namespace-taskscheduler>>.
If you want to delegate to a different scheduler, you can provide a reference through the delayer element's 'scheduler' attribute, as the following example shows:
====
@@ -186,4 +186,4 @@ Message<String> delayerReschedulingMessage =
----
====
NOTE: For more information regarding the message store, JMX, and the control bus, see "`<<system-management-chapter>>`".
NOTE: For more information regarding the message store, JMX, and the control bus, see <<system-management-chapter>>.

2
src/reference/asciidoc/dsl.adoc
View File

@@ -652,7 +652,7 @@ For example, the `ConsumerEndpointFactoryBean` for the `.transform("Hello "::con
The `Transformer` implementation bean for that endpoint has a bean name of `lambdaFlow.o.s.i.transformer.MethodInvokingTransformer#0`.
(In both cases, `o.s.i` is `org.springframework.integration`, shortened here to fit on the page.)
These generated bean names are prepended with the flow ID for purposes such as parsing logs or grouping components together in some analysis tool, as well as to avoid a race condition when we concurrently register integration flows at runtime.
See "`<<java-dsl-runtime-flows>>`" for more information.
See <<java-dsl-runtime-flows>> for more information.
[[java-dsl-function-expression]]
=== `FunctionExpression`

6
src/reference/asciidoc/endpoint-summary.adoc
View File

@@ -179,9 +179,9 @@ The following table summarizes the various endpoints with quick links to the app
| N
|===
In addition, as discussed in "`<<spring-integration-core-messaging>>`", Spring Integration provides endpoints for interfacing with Plain Old Java Objects (POJOs).
As discussed in "`<<channel-adapter>>`", the `<int:inbound-channel-adapter>` element lets you poll a Java method for data.
In addition, as discussed in <<spring-integration-core-messaging>>, Spring Integration provides endpoints for interfacing with Plain Old Java Objects (POJOs).
As discussed in <<channel-adapter>>, the `<int:inbound-channel-adapter>` element lets you poll a Java method for data.
The `<int:outbound-channel-adapter>` element lets you send data to a `void` method.
As discussed in "`<<gateway>>`", the `<int:gateway>` element lets any Java program invoke a messaging flow.
As discussed in <<gateway>>, the `<int:gateway>` element lets any Java program invoke a messaging flow.
Each of these works without requiring any source-level dependencies on Spring Integration.
The equivalent of an outbound gateway in this context is using a service activator (see <<service-activator>>) to invoke a method that returns an `Object` of some kind.

30
src/reference/asciidoc/endpoint.adoc
View File

@@ -3,13 +3,13 @@
The first part of this chapter covers some background theory and reveals quite a bit about the underlying API that drives Spring Integration's various messaging components.
This information can be helpful if you want to really understand what goes on behind the scenes.
However, if you want to get up and running with the simplified namespace-based configuration of the various elements, feel free to skip ahead to "`<<endpoint-namespace>>`" for now.
However, if you want to get up and running with the simplified namespace-based configuration of the various elements, feel free to skip ahead to <<endpoint-namespace>> for now.
As mentioned in the overview, message endpoints are responsible for connecting the various messaging components to channels.
Over the next several chapters, we cover a number of different components that consume messages.
Some of these are also capable of sending reply messages.
Sending messages is quite straightforward.
As shown earlier in "`<<channel>>`", you can send a message to a message channel.
As shown earlier in <<channel>>, you can send a message to a message channel.
However, receiving is a bit more complicated.
The main reason is that there are two types of consumers: http://www.eaipatterns.com/PollingConsumer.html[polling consumers] and http://www.eaipatterns.com/EventDrivenConsumer.html[event-driven consumers].
@@ -49,7 +49,7 @@ Spring Integration provides two endpoint implementations that host these callbac
==== Event-driven Consumer
Because it is the simpler of the two, we cover the event-driven consumer endpoint first.
You may recall that the `SubscribableChannel` interface provides a `subscribe()` method and that the method accepts a `MessageHandler` parameter (as shown in "`<<channel-interfaces-subscribablechannel>>`").
You may recall that the `SubscribableChannel` interface provides a `subscribe()` method and that the method accepts a `MessageHandler` parameter (as shown in <<channel-interfaces-subscribablechannel>>).
The following listing shows the definition of the `subscribe` method:
====
@@ -84,7 +84,7 @@ PollingConsumer consumer = new PollingConsumer(channel, exampleHandler);
----
====
NOTE: For more information regarding polling consumers, see "`<<polling-consumer>>`" and "`<<channel-adapter>>`".
NOTE: For more information regarding polling consumers, see <<polling-consumer>> and <<channel-adapter>>.
There are many other configuration options for the polling consumer.
For example, the trigger is a required property.
@@ -167,7 +167,7 @@ consumer.setTaskExecutor(taskExecutor);
Furthermore, a `PollingConsumer` has a property called `adviceChain`.
This property lets you to specify a `List` of AOP advices for handling additional cross cutting concerns including transactions.
These advices are applied around the `doPoll()` method.
For more in-depth information, see the sections on AOP advice chains and transaction support under "`<<endpoint-namespace>>`".
For more in-depth information, see the sections on AOP advice chains and transaction support under <<endpoint-namespace>>.
The earlier examples show dependency lookups.
However, keep in mind that these consumers are most often configured as Spring bean definitions.
@@ -230,7 +230,7 @@ If you do not use the `time-unit` attribute, the specified value is represented
If this attribute is set, none of the following attributes must be specified: `fixed-delay`, `trigger`, `cron`, and `ref`.
<6> The ID referring to the poller's underlying bean-definition, which is of type `org.springframework.integration.scheduling.PollerMetadata`.
The `id` attribute is required for a top-level poller element, unless it is the default poller (`default="true"`).
<7> See "`<<channel-adapter-namespace-inbound>>`" for more information.
<7> See <<channel-adapter-namespace-inbound>> for more information.
If not specified, the default value depends on the context.
If you use a `PollingConsumer`, this attribute defaults to `-1`.
However, if you use a `SourcePollingChannelAdapter`, the `max-messages-per-poll` attribute defaults to `1`.
@@ -242,7 +242,7 @@ Optional.
The `ref` attribute must not be present on the top-level `poller` element.
However, if this attribute is set, none of the following attributes must be specified: `fixed-rate`, `trigger`, `cron`, and `fixed-delay`.
<10> Provides the ability to reference a custom task executor.
See "`<<taskexecutor-support>>`" for further information.
See <<taskexecutor-support>> for further information.
Optional.
<11> This attribute specifies the `java.util.concurrent.TimeUnit` enum value on the underlying `org.springframework.scheduling.support.PeriodicTrigger`.
Therefore, this attribute can be used only in combination with the `fixed-delay` or `fixed-rate` attributes.
@@ -256,10 +256,10 @@ For hourly, daily, and monthly settings, we recommend using a `cron` trigger ins
However, if this attribute is set, none of the following attributes must be specified: `fixed-delay`, `fixed-rate`, `cron`, and `ref`.
Optional.
<13> Allows specifying extra AOP advices to handle additional cross-cutting concerns.
See "`<<transaction-support>>`" for further information.
See <<transaction-support>> for further information.
Optional.
<14> Pollers can be made transactional.
See "`<<aop-advice-chains>>`" for further information.
See <<aop-advice-chains>> for further information.
Optional.
===== Examples
@@ -348,7 +348,7 @@ The following example shows the available attributes:
</int:poller>
----
For more information, see "`<<transaction-poller>>`".
For more information, see <<transaction-poller>>.
[[aop-advice-chains]]
===== AOP Advice chains
@@ -378,7 +378,7 @@ An advice chain can also be applied on a poller that does not have any transacti
IMPORTANT: When using an advice chain, the `<transactional/>` child element cannot be specified.
Instead, declare a `<tx:advice/>` bean and add it to the `<advice-chain/>`.
See "`<<transaction-poller>>`" for complete configuration details.
See <<transaction-poller>> for complete configuration details.
[[taskexecutor-support]]
====== TaskExecutor Support
@@ -404,7 +404,7 @@ To enable concurrency for a polling endpoint that is configured with the XML nam
====
If you do not provide a task-executor, the consumer's handler is invoked in the caller's thread.
Note that the caller is usually the default `TaskScheduler` (see "`<<namespace-taskscheduler>>`").
Note that the caller is usually the default `TaskScheduler` (see <<namespace-taskscheduler>>).
You should also keep in mind that the `task-executor` attribute can provide a reference to any implementation of Spring's `TaskExecutor` interface by specifying the bean name.
The `executor` element shown earlier is provided for convenience.
@@ -587,7 +587,7 @@ Those two new converters are registered in the composite before the defaults.
You can also not use a `ConfigurableCompositeMessageConverter` but provide your own `MessageConverter` by registering a bean with the name, `integrationArgumentResolverMessageConverter` (by setting the `IntegrationContextUtils.ARGUMENT_RESOLVER_MESSAGE_CONVERTER_BEAN_NAME` property).
NOTE: The `MessageConverter`-based (including `contentType` header) conversion is not available when using SpEL method invocation.
In this case, only the regular class-to-class conversion mentioned above in the "`<<payload-type-conversion>>`" is available.
In this case, only the regular class-to-class conversion mentioned above in the <<payload-type-conversion>> is available.
[[async-polling]]
==== Asynchronous Polling
@@ -769,7 +769,7 @@ public Map<String, Boolean> getEndpointsRunningStatus(String role) <4>
Groups of endpoints can be started and stopped based on leadership being granted or revoked, respectively.
This is useful in clustered scenarios where shared resources must be consumed by only a single instance.
An example of this is a file inbound channel adapter that is polling a shared directory.
(See "`<<file-reading>>`").
(See <<file-reading>>).
To participate in a leader election and be notified when elected leader, when leadership is revoked, or on failure to acquire the resources to become leader, an application creates a component in the application context called a "`leader initiator`".
Normally, a leader initiator is a `SmartLifecycle`, so it starts (optionally) when the context starts and then publishes notifications when leadership changes.
@@ -814,4 +814,4 @@ If the lock registry is implemented correctly, there is only ever at most one le
If the lock registry also provides locks that throw exceptions (ideally, `InterruptedException`) when they expire or are broken, the duration of the leaderless periods can be as short as is allowed by the inherent latency in the lock implementation.
By default, the `busyWaitMillis` property adds some additional latency to prevent CPU starvation in the (more usual) case that the locks are imperfect and you only know they expired when you try to obtain one again.
See "`<<zk-leadership>>`" for more information about leadership election and events that use Zookeeper.
See <<zk-leadership>> for more information about leadership election and events that use Zookeeper.

2
src/reference/asciidoc/feed.adoc
View File

@@ -56,7 +56,7 @@ Otherwise the next attempt to poll for a feed is determined by the trigger of th
Polling for a feed can result in entries that have already been processed ("`I already read that news item, why are you showing it to me again?`").
Spring Integration provides a convenient mechanism to eliminate the need to worry about duplicate entries.
Each feed entry has a "`published date`" field.
Every time a new `Message` is generated and sent, Spring Integration stores the value of the latest published date in an instance of the `MetadataStore` strategy (see "`<<metadata-store>>`").
Every time a new `Message` is generated and sent, Spring Integration stores the value of the latest published date in an instance of the `MetadataStore` strategy (see <<metadata-store>>).
NOTE: The key used to persist the latest published date is the value of the (required) `id` attribute of the feed inbound channel adapter component plus the `feedUrl` (if any) from the adapter's configuration.

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

@@ -47,7 +47,7 @@ The `AcceptOnceFileListFilter` ensures files are picked up only once from the di
====
The `AcceptOnceFileListFilter` stores its state in memory.
If you wish the state to survive a system restart, you can use the `FileSystemPersistentAcceptOnceFileListFilter`.
This filter stores the accepted file names in a `MetadataStore` implementation (see "`<<metadata-store>>`").
This filter stores the accepted file names in a `MetadataStore` implementation (see <<metadata-store>>).
This filter matches on the filename and modified time.
Since version 4.0, this filter requires a `ConcurrentMetadataStore`.
@@ -157,13 +157,13 @@ Starting with version 5.0, the `FileReadingMessageSource` (in addition to the `p
* `FileHeaders.FILENAME`: The `File.getName()` of the file to send.
Can be used for subsequent rename or copy logic.
* `FileHeaders.ORIGINAL_FILE`: The `File` object itself.
Typically, this header is populated automatically by framework components (such as "`<<file-splitter,splitters>>`" or "`<<file-transforming,transformers>>`") when we lose the original `File` object.
Typically, this header is populated automatically by framework components (such as <<file-splitter,splitters>> or`<<file-transforming,transformers>>) when we lose the original `File` object.
However, for consistency and convenience with any other custom use cases, this header can be useful to get access to the original file.
* `FileHeaders.RELATIVE_PATH`: A new header introduced to represent the part of file path relative to the root directory for the scan.
This header can be useful when the requirement is to restore a source directory hierarchy in the other places.
For this purpose, the `DefaultFileNameGenerator` (see "`<<file-writing-file-names>>`") can be configured to use this header.
For this purpose, the `DefaultFileNameGenerator` (see "`<<file-writing-file-names>>) can be configured to use this header.
==== Directory scanning and polling
==== Directory Scanning and Polling
The `FileReadingMessageSource` does not produce messages for files from the directory immediately.
It uses an internal queue for 'eligible files' returned by the `scanner`.
@@ -722,7 +722,7 @@ The file is closed after each message.
`APPEND_NO_FLUSH`::
This option has the same semantics as `APPEND`, but the data is not flushed and the file is not closed after each message.
This can provide a significant performance at the risk of data loss in the event of a failure.
See "`<<file-flushing>>`" for more information.
See <<file-flushing>> for more information.
`FAIL`::
If the target file exists, a http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/messaging/MessageHandlingException.html[`MessageHandlingException`] is thrown.
`IGNORE`::
@@ -832,7 +832,7 @@ The following example configures an outbound gateway:
====
As mentioned earlier, you can also specify the `mode` attribute, which defines the behavior of how to deal with situations where the destination file already exists.
See "`<<file-writing-destination-exists>>`" for further details.
See <<file-writing-destination-exists>> for further details.
Generally, when using the file outbound gateway, the result file is returned as the message payload on the reply channel.
This also applies when specifying the `IGNORE` mode.
@@ -1023,7 +1023,7 @@ The default is `true`.
The `FileSplitter` also splits any text-based `InputStream` into lines.
Starting with version 4.3, when used in conjunction with an FTP or SFTP streaming inbound channel adapter or an FTP or SFTP outbound gateway that uses the `stream` option to retrieve a file, the splitter automatically closes the session that supports the stream when the file is completely consumed
See "`<<ftp-streaming>>`" and "`<<sftp-streaming>>`" as well as "`<<ftp-outbound-gateway>>`" and "`<<sftp-outbound-gateway>>`" for more
See <<ftp-streaming>> and <<sftp-streaming>> as well as <<ftp-outbound-gateway>> and <<sftp-outbound-gateway>> for more
information about these facilities.
When using Java configuration, an additional constructor is available, as the following example shows:

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

@@ -88,7 +88,7 @@ If you want rejected messages to be routed to a specific channel, provide that r
----
====
See also "`<<advising-filters>>`".
See also <<advising-filters>>.
NOTE: Message filters are commonly used in conjunction with a publish-subscribe channel.
Many filter endpoints may be subscribed to the same channel, and they decide whether or not to pass the message to the next endpoint, which could be any of the supported types (such as a service activator).
@@ -194,4 +194,4 @@ All of the configuration options provided by the XML element are also available
The filter can be either referenced explicitly from XML or, if the `@MessageEndpoint` annotation is defined on the class, detected automatically through classpath scanning.
See also "`<<advising-with-annotations>>`".
See also <<advising-with-annotations>>.

29
src/reference/asciidoc/ftp.adoc
View File

@@ -33,7 +33,7 @@ Spring Integration provides factories you can use to create FTP (or FTPS) sessio
==== Default Factories
IMPORTANT: Starting with version 3.0, sessions are no longer cached by default.
See "`<<ftp-session-caching>>`".
See <<ftp-session-caching>>.
Before configuring FTP adapters, you must configure an FTP session factory.
You can configure the FTP Session Factory with a regular bean definition where the implementation class is `o.s.i.ftp.session.DefaultFtpSessionFactory`.
@@ -244,7 +244,7 @@ The following example shows how to declare a delegating session factory:
----
====
IMPORTANT: When you use session caching (see "`<<ftp-session-caching>>`"), each of the delegates should be cached.
IMPORTANT: When you use session caching (see <<ftp-session-caching>>), each of the delegates should be cached.
You cannot cache the `DelegatingSessionFactory` itself.
Starting with _version 5.0.7_, the `DelegatingSessionFactory` can be used in conjuction with a `RotatingServerAdvice` to poll multiple servers; see <<ftp-rotating-server-advice>>.
@@ -290,7 +290,7 @@ Starting with version 5.0, you can now limit the number of files fetched from th
This can be beneficial when the target files are very large or when you run in a clustered system with a persistent file list filter, discussed later.
Use `max-fetch-size` for this purpose.
A negative value (the default) means no limit and all matching files are retrieved.
See "`<<ftp-max-fetch>>`" for more information.
See <<ftp-max-fetch>> for more information.
Since version 5.0, you can also provide a custom `DirectoryScanner` implementation to the `inbound-channel-adapter` by setting the `scanner` attribute.
Starting with Spring Integration 3.0, you can specify the `preserve-timestamp` attribute (its default is `false`).
@@ -311,7 +311,7 @@ You can also combine a pattern-based filter with other filters (such as an `Acce
The `AcceptOnceFileListFilter` stores its state in memory.
If you wish the state to survive a system restart, consider using the `FtpPersistentAcceptOnceFileListFilter` instead.
This filter stores the accepted file names in an instance of the `MetadataStore` strategy (see "`<<metadata-store>>`").
This filter stores the accepted file names in an instance of the `MetadataStore` strategy (see <<metadata-store>>).
This filter matches on the filename and the remote modified time.
Since version 4.0, this filter requires a `ConcurrentMetadataStore`.
@@ -330,7 +330,7 @@ Also, if you configure the `filter` to use a `FtpPersistentAcceptOnceFileListFil
You can use the `local-filter` attribute to configure the behavior of the local file system filter.
Starting with version 4.3.8, a `FileSystemPersistentAcceptOnceFileListFilter` is configured by default.
This filter stores the accepted file names and modified timestamp in an instance of the `MetadataStore` strategy (see "`<<metadata-store>>`") and detects changes to the local file modified time.
This filter stores the accepted file names and modified timestamp in an instance of the `MetadataStore` strategy (see <<metadata-store>>) and detects changes to the local file modified time.
The default `MetadataStore` is a `SimpleMetadataStore`, which stores state in memory.
Since version 4.1.5, these filters have a new property (`flushOnUpdate`) that causes them to flush the
@@ -456,7 +456,7 @@ See https://docs.spring.io/spring-integration/api/org/springframework/integratio
Also, you can now switch the `AbstractInboundFileSynchronizingMessageSource` to the `WatchService`-based `DirectoryScanner` by using `setUseWatchService()` option.
It is also configured for all the `WatchEventType` instances to react to any modifications in local directory.
The reprocessing sample shown earlier is based on the built-in functionality of the `FileReadingMessageSource.WatchServiceDirectoryScanner` to perform `ResettableFileListFilter.remove()` when the file is deleted (`StandardWatchEventKinds.ENTRY_DELETE`) from the local directory.
See "`<<watch-service-directory-scanner>>`" for more information.
See <<watch-service-directory-scanner>> for more information.
==== Configuring with Java Configuration
@@ -561,7 +561,7 @@ public class FtpJavaApplication {
[[ftp-incomplete]]
==== Dealing With Incomplete Data
See "`<<file-incomplete>>`".
See <<file-incomplete>>.
The `FtpSystemMarkerFilePresentFileListFilter` is provided to filter remote files that do not have a corresponding marker file on the remote system.
See the https://docs.spring.io/spring-integration/api/org/springframework/integration/ftp/filters/FtpSystemMarkerFilePresentFileListFilter.html[Javadoc] (and browse to the parent classes) for configuration information.
@@ -576,7 +576,7 @@ Since the session remains open, the consuming application is responsible for clo
consumed.
The session is provided in the `closeableResource` header (`IntegrationMessageHeaderAccessor.CLOSEABLE_RESOURCE`).
Standard framework components, such as the `FileSplitter` and `StreamTransformer`, automatically close the session.
See "`<<file-splitter>>`" and "`<<stream-transformer>>`" for more information about these components.
See <<file-splitter>> and <<stream-transformer>> for more information about these components.
The follwoing example shows how to configure an `inbound-streaming-channel-adapter`:
====
@@ -608,7 +608,7 @@ The Java configuration (<<ftp-streaming-java,later in the document>>) shows one
Use the `max-fetch-size` attribute to limit the number of files fetched on each poll when a fetch is necessary.
Set it to `1` and use a persistent filter when running in a clustered environment.
See "`<<ftp-max-fetch>>`" for more information.
See <<ftp-max-fetch>> for more information.
The adapter puts the remote directory and file name in the `FileHeaders.REMOTE_DIRECTORY` and `FileHeaders.REMOTE_FILE` headers, respectively.
Starting with version 5.0, the `FileHeaders.REMOTE_FILE_INFO` header provides additional remote file information (represented in JSON by default).
@@ -616,7 +616,10 @@ If you set the `fileInfoJson` property on the `FtpStreamingMessageSource` to `fa
The `FTPFile` object provided by the underlying Apache Net library can be accessed by using the `FtpFileInfo.getFileInfo()` method.
The `fileInfoJson` property is not available when you use XML configuration, but you can set it by injecting the `FtpStreamingMessageSource` into one of your configuration classes.
Starting with version 5.1, the `comparator` 's generic type is now `FTPFile`; previously it was `AbstractFileInfo<FTPFile>`; this is because the sort is now performed earlier in the processing, before filtering and applying `maxFetch`.
Starting with version 5.1, the generic type of the `comparator` is `FTPFile`.
Previously, it was `AbstractFileInfo<FTPFile>`.
This is because the sort is now performed earlier in the processing, before filtering and applying `maxFetch`.
[[ftp-streaming-java]]
==== Configuring with Java Configuration
@@ -992,7 +995,7 @@ The default is to retrieve a list of `FileInfo` objects.
* `-R`: List the remote directory recursively
In addition, filename filtering is provided, in the same manner as the `inbound-channel-adapter`.
See "`<<ftp-inbound>>`".
See <<ftp-inbound>>.
The message payload resulting from an `ls` operation is a list of file names or a list of `FileInfo` objects.
These objects provide information such as modified time, permissions, and other details.
@@ -1150,7 +1153,7 @@ Doing so allows recursion for a simple pattern, as the following examples show:
Once you have defined filters such as those in the preceding example, you can use one by setting the `filter` property on the gateway.
See also "`<<ftp-partial>>`".
See also <<ftp-partial>>.
[[ftp-put-command]]
==== Using the `put` Command
@@ -1179,7 +1182,7 @@ Subdirectories that do not pass the filter are not recursed.
The message payload resulting from an `mget` operation is a `List<String>` object (that is, a `List` of remote file paths that result from the transfer).
See also "`<<ftp-partial>>`".
See also <<ftp-partial>>.
==== Using the `rm` Command

26
src/reference/asciidoc/gateway.adoc
View File

@@ -50,10 +50,10 @@ See the <<samples,"`Samples`">> Appendix for an example that uses the `gateway`
The defaults in the preceding configuration are applied to all methods on the gateway interface.
If a reply timeout is not specified, the calling thread waits indefinitely for a reply.
See "`<<gateway-no-response>>`".
See <<gateway-no-response>>.
The defaults can be overridden for individual methods.
See "`<<gateway-configuration-annotations>>`".
See <<gateway-configuration-annotations>>.
[[gateway-default-reply-channel]]
==== Setting the Default Reply Channel
@@ -311,11 +311,11 @@ IMPORTANT: Similarly to the XML version, when Spring Integration discovers these
To perform this scan and register the `BeanDefinition` in the application context, add the `@IntegrationComponentScan` annotation to a `@Configuration` class.
The standard `@ComponentScan` infrastructure does not deal with interfaces.
Consequently, we introduced the custom `@IntegrationComponentScan` logic to fine the `@MessagingGateway` annotation on the interfaces and register `GatewayProxyFactoryBean` instances for them.
See also "`<<annotations>>`".
See also <<annotations>>.
NOTE: If you have no XML configuration, the `@EnableIntegration` annotation is required on at least one `@Configuration`
class.
See "`<<configuration-enable-integration>>`" for more information.
See <<configuration-enable-integration>> for more information.
[[gateway-calling-no-argument-methods]]
==== Invoking No-Argument Methods
@@ -463,7 +463,7 @@ To do so, you can either return an `Exception` (as the `reply` from some service
Generally, even with an asynchronous flow, the framework takes care of propagating an exception thrown by the
downstream flow back to the gateway.
The https://github.com/spring-projects/spring-integration-samples/tree/master/intermediate/tcp-client-server-multiplex[TCP Client-Server Multiplex] sample demonstrates both techniques to return the exception to the caller.
It emulates a socket IO error to the waiting thread by using an `aggregator` with `group-timeout` (see "`<<agg-and-group-to>>`")
It emulates a socket IO error to the waiting thread by using an `aggregator` with `group-timeout` (see <<agg-and-group-to>>)
and a `MessagingTimeoutException` reply on the discard flow.
[[gateway-timeouts]]
@@ -585,7 +585,7 @@ result.addCallback(new ListenableFutureCallback<String>() {
By default, the `GatewayProxyFactoryBean` uses `org.springframework.core.task.SimpleAsyncTaskExecutor` when submitting internal `AsyncInvocationTask` instances for any gateway method whose return type is a `Future`.
However, the `async-executor` attribute in the `<gateway/>` element's configuration lets you provide a reference to any implementation of `java.util.concurrent.Executor` available within the Spring application context.
The (default) `SimpleAsyncTaskExecutor` supports both `Future` and `ListenableFuture` return types, returning `FutureTask` or `ListenableFutureTask` respectively. See "`<<gw-completable-future>>`".
The (default) `SimpleAsyncTaskExecutor` supports both `Future` and `ListenableFuture` return types, returning `FutureTask` or `ListenableFutureTask` respectively. See <<gw-completable-future>>.
Even though there is a default executor, it is often useful to provide an external one so that you can identify its threads in logs (when using XML, the thread name is based on the executor's bean name), as the following example shows:
====
@@ -764,16 +764,17 @@ mono.subscribe(invoice -> handleInvoice(invoice));
The calling thread continues, with `handleInvoice()` being called when the flow completes.
===== Downstream Flows Returning an Async Type
===== Downstream Flows Returning an Asynchronous Type
As mentioned in the `ListenableFuture` section above; if you wish some downstream component to return a message with an async payload (`Future`, `Mono`, etc), you must explicitly set the async executor to `null` (or `""` when using XML configuration).
As mentioned in the `ListenableFuture` section above, if you wish some downstream component to return a message with an async payload (`Future`, `Mono`, and others), you must explicitly set the async executor to `null` (or `""` when using XML configuration).
The flow is then invoked on the caller thread and the result can be retrieved later.
===== `void` Return Type
Unlike the return types above, when the method return type is `void`, the framework cannot implicitly determine that you wish the downstream flow to run asynchronously, with the caller thread returning immediately.
In this case, it is necessary to annotate the interface method with `@Async`.
Unlike the return types mentioned earlier, when the method return type is `void`, the framework cannot implicitly determine that you wish the downstream flow to run asynchronously, with the caller thread returning immediately.
In this case, you must annotate the interface method with `@Async`, as the following example shows:
====
[source, java]
----
@MessagingGateway
@@ -785,8 +786,9 @@ public interface MyGateway {
}
----
====
Of course, unlike the `Future<?>` return types, there is no way to inform the caller if some exception is thrown by the flow, unless some custom `TaskExecutor` (e.g. an `ErrorHandlingTaskExecutor`) is associated with the `@Async` annotation.
Unlike the `Future<?>` return types, there is no way to inform the caller if some exception is thrown by the flow, unless some custom `TaskExecutor` (such as an `ErrorHandlingTaskExecutor`) is associated with the `@Async` annotation.
[[gateway-no-response]]
==== Gateway Behavior When No response Arrives
@@ -855,4 +857,4 @@ At that time, the calling thread starts waiting for the reply.
If the flow was completely synchronous, the reply is immediately available.
For asynchronous flows, the thread waits for up to this time.
See "`<<java-dsl-gateway>>`" in the Java DSL chapter for options to define gateways through `IntegrationFlows`.
See <<java-dsl-gateway>> in the Java DSL chapter for options to define gateways through `IntegrationFlows`.

8
src/reference/asciidoc/graph.adoc
View File

@@ -119,7 +119,7 @@ Node elements contain various properties that are generally self-explanatory.
For example, expression-based components include the `expression` property that contains the primary expression string for the component.
To enable the metrics, add an `@EnableIntegrationManagement` to a `@Configuration` class or add an `<int:management/>` element to your XML configuration.
You can control exactly which components in the framework collect statistics.
See "`<<metrics-management>>`" for complete information.
See <<metrics-management>> for complete information.
See the `stats` attribute from the `o.s.i.errorLogger` component in the JSON example shown earlier.
In this case, The `nullChannel` and `errorChannel` do not provide statistics information, because the configuration for this example was as follows:
@@ -158,7 +158,7 @@ Within the graph, Spring Integration components are represented by using the `In
For example, you can use the `ErrorCapableDiscardingMessageHandlerNode` for the `AggregatingMessageHandler` (because it has a `discardChannel` option) and can produce errors when consuming from a `PollableChannel` by using a `PollingConsumer`.
Another example is `CompositeMessageHandlerNode` -- for a `MessageHandlerChain` when subscribed to a `SubscribableChannel` by using an `EventDrivenConsumer`.
NOTE: The `@MessagingGateway` (see "`<<gateway>>`") provides nodes for each of its method, where the `name` attribute is based on the gateway's bean name and the short method signature.
NOTE: The `@MessagingGateway` (see <<gateway>>) provides nodes for each of its method, where the `name` attribute is based on the gateway's bean name and the short method signature.
Consider the following example of a gateway:
====
@@ -211,11 +211,11 @@ The preceding gateway produces nodes similar to the following:
====
You can use this `IntegrationNode` hierarchy for parsing the graph model on the client side as well as to understand the general Spring Integration runtime behavior.
See also "`<<programming-tips>>`" for more information.
See also <<programming-tips>> for more information.
=== Integration Graph Controller
If your application is web-based (or built on top of Spring Boot with an embedded web container) and the Spring Integration HTTP or WebFlux module (see "`<<http>>`" and "`<<webflux>>`", respectively) is present on the classpath, you can use a `IntegrationGraphController` to expose the `IntegrationGraphServer` functionality as a REST service.
If your application is web-based (or built on top of Spring Boot with an embedded web container) and the Spring Integration HTTP or WebFlux module (see <<http>> and <<webflux>>, respectively) is present on the classpath, you can use a `IntegrationGraphController` to expose the `IntegrationGraphServer` functionality as a REST service.
For this purpose, the `@EnableIntegrationGraphController` and `@Configuration` class annotations and the `<int-http:graph-controller/>` XML element are available in the HTTP module.
Together with the `@EnableWebMvc` annotation (or `<mvc:annotation-driven/>` for XML definitions), this configuration registers an `IntegrationGraphController` `@RestController` where its `@RequestMapping.path` can be configured on the `@EnableIntegrationGraphController` annotation or `<int-http:graph-controller/>` element.
The default path is `/integration`.

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

@@ -7,7 +7,7 @@ For more information about Groovy, see the Groovy documentation, which you can f
[[groovy-config]]
==== Groovy Configuration
With Spring Integration 2.1, the configuration namespace for the Groovy support is an extension of Spring Integration's scripting support and shares the core configuration and behavior described in detail in the "`<<scripting>>`" section.
With Spring Integration 2.1, the configuration namespace for the Groovy support is an extension of Spring Integration's scripting support and shares the core configuration and behavior described in detail in the <<scripting>> section.
Even though Groovy scripts are well supported by generic scripting support, the Groovy support provides the `Groovy` configuration namespace, which is backed by the Spring Framework's `org.springframework.scripting.groovy.GroovyScriptFactory` and related components, offering extended capabilities for using Groovy.
The following listing shows two sample configurations:
@@ -69,7 +69,7 @@ The following example shows how to use a variable (`entityManager`):
`entityManager` must be an appropriate bean in the application context.
For more information regarding the `<variable>` element, the `variables` attribute, and the `script-variable-generator` attribute, see "`<<scripting-script-variable-bindings>>`".
For more information regarding the `<variable>` element, the `variables` attribute, and the `script-variable-generator` attribute, see <<scripting-script-variable-bindings>>.
==== Groovy Script Compiler Customization

8
src/reference/asciidoc/handler-advice.adoc
View File

@@ -540,7 +540,7 @@ For other message handlers, the advice is applied to `MessageHandler.handleMessa
There are some circumstances where, even if a message handler is an `AbstractReplyProducingMessageHandler`, the advice must be applied to the `handleMessage` method.
For example, the <<idempotent-receiver, idempotent receiver>> might return `null`, which would cause an exception if the handler's `replyRequired` property is set to `true`.
Another example is the `BoundRabbitChannelAdvice` -- see "`<<amqp-strict-ordering>>`".
Another example is the `BoundRabbitChannelAdvice` -- see <<amqp-strict-ordering>>.
Starting with version 4.3.1, a new `HandleMessageAdvice` interface and its base implementation (`AbstractHandleMessageAdvice`) have been introduced.
`Advice` objects that implement `HandleMessageAdvice` are always applied to the `handleMessage()` method, regardless of the handler type.
@@ -664,7 +664,7 @@ Setting `discard-within-advice` to `false` modifies this behavior and the discar
==== Advising Endpoints Using Annotations
When configuring certain endpoints by using annotations (`@Filter`, `@ServiceActivator`, `@Splitter`, and `@Transformer`), you can supply a bean name for the advice chain in the `adviceChain` attribute.
In addition, the `@Filter` annotation also has the `discardWithinAdvice` attribute, which can be used to configure the discard behavior, as discussed in "`<<advising-filters>>`".
In addition, the `@Filter` annotation also has the `discardWithinAdvice` attribute, which can be used to configure the discard behavior, as discussed in <<advising-filters>>.
The following example causes the discard to be performed after the advice:
[source,java]
@@ -741,7 +741,7 @@ It is a functional pattern and the whole idempotency logic should be implemented
However, to simplify the decision-making, the `IdempotentReceiverInterceptor` component is provided.
This is an AOP `Advice` that is applied to the `MessageHandler.handleMessage()` method and that can `filter` a request message or mark it as a `duplicate`, according to its configuration.
Previously, you could have implemented this pattern by using a custom `MessageSelector` in a `<filter/>` (see "`<<filter>>`"), for example.
Previously, you could have implemented this pattern by using a custom `MessageSelector` in a `<filter/>` (see <<filter>>), for example.
However, since this pattern really defines the behavior of an endpoint rather than being an endpoint itself, the idempotent receiver implementation does not provide an endpoint component.
Rather, it is applied to endpoints declared in the application.
@@ -856,6 +856,6 @@ public IntegrationFlow flow() {
NOTE: The `IdempotentReceiverInterceptor` is designed only for the `MessageHandler.handleMessage(Message<?>)` method.
Starting with version 4.3.1, it implements `HandleMessageAdvice`, with the `AbstractHandleMessageAdvice` as a base class, for better dissociation.
See "<<handle-message-advice>>" for more information.
See <<handle-message-advice>> for more information.
====

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

@@ -3,7 +3,7 @@
Spring Integration's HTTP support allows for the running of HTTP requests and the processing of inbound HTTP requests.
The HTTP support consists of the following gateway implementations: `HttpInboundEndpoint` and `HttpRequestExecutingMessageHandler`.
See also "`<<webflux>>`".
See also <<webflux>>.
[[http-inbound]]
=== Http Inbound Components
@@ -485,7 +485,7 @@ Those are two of the most commonly configured values.
The default `http-method` is `POST`, and the default response type is null.
With a null response type, the payload of the reply `Message` contains the `ResponseEntity`, as long as its HTTP status is a success (non-successful status codes throw exceptions).
If you expect a different type, such as a `String`, provide that as a fully-qualified class name (`java.lang.String` in the preceding example).
See also the note about empty response bodies in "`<<http-outbound>>`".
See also the note about empty response bodies in <<http-outbound>>.
IMPORTANT: Beginning with Spring Integration 2.1, the `request-timeout` attribute of the HTTP outbound gateway was renamed to `reply-timeout` to better reflect its intent.
@@ -986,12 +986,12 @@ If you need to do something other than what the `DefaultHttpHeaderMapper` suppor
=== Integration Graph Controller
Starting with version 4.3, the HTTP module provides an `@EnableIntegrationGraphController` configuration class annotation and an `<int-http:graph-controller/>` XML element to expose the `IntegrationGraphServer` as a REST service.
See "`<<integration-graph>>`" for more information.
See <<integration-graph>> for more information.
[[http-samples]]
=== HTTP Samples
This section wraps up our coverage of Spring Integration's HTTP support with a few examples
This section wraps up our coverage of Spring Integration's HTTP support with a few examples.
[[multipart-rest-inbound]]
==== Multipart HTTP Request -- RestTemplate (Client) and Http Inbound Gateway (Server)

4
src/reference/asciidoc/index-docinfo.xml
View File

@@ -38,6 +38,10 @@
<firstname>Amol</firstname>
<surname>Nayak</surname>
</author>
</author><author>
<firstname>Jay</firstname>
<surname>Bryant</surname>
</author>
</authorgroup>
<copyright>

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

@@ -34,7 +34,7 @@ If the associated connection factory is configured for single-use connections, a
Otherwise, if the connection is in use, the calling thread blocks on the connection until either a response is received or a timeout or I/O error occurs.
The TCP and UDP inbound channel adapters and the TCP inbound gateway support the `error-channel` attribute.
This provides the same basic functionality as described in "`<<gateway-proxy>>`".
This provides the same basic functionality as described in <<gateway-proxy>>.
[[udp-adapters]]
=== UDP Adapters
@@ -291,7 +291,7 @@ Such sharing allows for asynchronous two-way communication over TCP.
By default, only payload information is transferred using TCP.
Therefore, any message correlation must be performed by downstream components such as aggregators or other endpoints.
Support for transferring selected headers was introduced in version 3.0.
For more information, see "`<<ip-correlation>>`".
For more information, see <<ip-correlation>>.
You may give a reference to a connection factory to a maximum of one adapter of each type.
@@ -457,7 +457,7 @@ In environments where DNS is not configured, this can cause connection delays.
You can override this default behavior by setting the `lookup-host` attribute to `false`.
NOTE: You can also modify the attributes of sockets and socket factories.
See "`<<ssl-tls>>`".
See <<ssl-tls>>.
As noted there, such modifications are possible whether or not SSL is being used.
[[caching-cf]]
@@ -467,7 +467,7 @@ As <<ip-intro,noted earlier>>, TCP sockets can be 'single-use' (one request or r
Shared sockets do not perform well with outbound gateways in high-volume environments, because the socket can only process one request or response at a time.
To improve performance, you can use collaborating channel adapters instead of gateways, but that requires application-level message correlation.
See "`<<ip-correlation>>`" for more information.
See <<ip-correlation>> for more information.
Spring Integration 2.2 introduced a caching client connection factory, which uses a pool of shared sockets, letting a gateway process multiple concurrent requests with a pool of shared connections.
@@ -605,9 +605,9 @@ Beginning with version 3.0, changes to `TcpConnection` instances are reported by
* `throwable`: The `Throwable` (for `TcpConnectionExceptionEvent` events only).
* `source`: The `TcpConnection`. You can use this, for example, to determine the remote IP Address with `getHostAddress()` (cast required).
In addition, since version 4.0, the standard deserializers discussed in "`<<tcp-connection-factories>>`" now emit `TcpDeserializationExceptionEvent` instances when they encounter problems while decoding the data stream.
In addition, since version 4.0, the standard deserializers discussed in <<tcp-connection-factories>> now emit `TcpDeserializationExceptionEvent` instances when they encounter problems while decoding the data stream.
These events contain the exception, the buffer that was in the process of being built, and an offset into the buffer (if available) at the point where the exception occurred.
Applications can use a normal `ApplicationListener` or an `ApplicationEventListeningMessageProducer` (see "`<<appevent-inbound>>`") to capture these events, allowing analysis of the problem.
Applications can use a normal `ApplicationListener` or an `ApplicationEventListeningMessageProducer` (see <<appevent-inbound>>) to capture these events, allowing analysis of the problem.
Starting with versions 4.0.7 and 4.1.3, `TcpConnectionServerExceptionEvent` instances are published whenever an unexpected exception occurs on a server socket (such as a `BindException` when the server socket is in use).
These events have a reference to the connection factory and the cause.
@@ -783,7 +783,7 @@ remote-timeout-expression="headers['timeout']" -->
One goal of the IP endpoints is to provide communication with systems other than Spring Integration applications.
For this reason, only message payloads are sent and received by default.
Since 3.0, you can transfer headers by using JSON, Java serialization, or custom serializers and deserializers.
See "`<<ip-headers>>`" for more information.
See <<ip-headers>> for more information.
No message correlation is provided by the framework (except when using the gateways) or collaborating channel adapters on the server side.
<<ip-collaborating-adapters,Later in this document>>, we discuss the various correlation techniques available to applications.
In most cases, this requires specific application-level correlation of messages, even when message payloads contain some natural correlation data (such as an order number).
@@ -827,7 +827,7 @@ Such a transformer may transform the original payload to a new object that conta
Of course, live objects (such as reply channels) from the headers cannot be included in the transformed payload.
If you choose such a strategy, you need to ensure the connection factory has an appropriate serializer-deserializer pair to handle such a payload (such as `DefaultSerializer` and `DefaultDeserializer`, which use java serialization, or a custom serializer and deserializer).
The `ByteArray*Serializer` options mentioned in "`<<tcp-connection-factories>>`", including the default `ByteArrayCrLfSerializer`, do not support such payloads unless the transformed payload is a `String` or `byte[]`.
The `ByteArray*Serializer` options mentioned in <<tcp-connection-factories>>, including the default `ByteArrayCrLfSerializer`, do not support such payloads unless the transformed payload is a `String` or `byte[]`.
[NOTE]
=====
@@ -914,7 +914,7 @@ A message sent with the preceding configuration, with a payload of 'something' w
[[note_nio]]
=== About Non-blocking I/O (NIO)
Using NIO (see `using-nio` in "`<<ip-endpoint-reference>>`") avoids dedicating a thread to read from each socket.
Using NIO (see `using-nio` in <<ip-endpoint-reference>>) avoids dedicating a thread to read from each socket.
For a small number of sockets, you are likely to find that not using NIO, together with an asynchronous handoff (such as to a `QueueChannel`), performs as well as or better than using NIO.
You should consider using NIO when handling a large number of connections.
@@ -1386,7 +1386,7 @@ Defaults to `ByteArrayCrLfSerializer`
| `true`, `false`
| Whether or not connection uses NIO.
Refer to the `java.nio` package for more information.
See "`<<note_nio>>`".
See <<note_nio>>.
Default: `false`.
| `using-direct-buffers`
@@ -1403,7 +1403,7 @@ Must be `false` if `using-nio` is `false`.
| `true`, `false`
| When you use NIO, it may be necessary to resequence messages.
When this attribute is set to `true`, `correlationId` and `sequenceNumber` headers are added to received messages.
See "`<<note_nio>>`".
See <<note_nio>>.
Default: `false`.
| `so-timeout`
@@ -1499,7 +1499,7 @@ Default: `true`.
| Y
| Y
|
| See "`<<ip-interceptors>>`".
| See <<ip-interceptors>>.
| `ssl-context-support`
| Y
@@ -1517,13 +1517,13 @@ Default: `true`.
| Y
| Y
|
| See "`<<ssl-tls>>`".
| See <<ssl-tls>>.
| `nio-connection-support`
| Y
| Y
|
| See "`<<tcp-advanced-techniques>>`".
| See <<tcp-advanced-techniques>>.
| `read-delay`
| Y
@@ -1739,7 +1739,7 @@ Default: 60000 (60 seconds).
| `true`, `false`
| Specifies a `TaskScheduler` to use for managing the `client-mode` connection.
If not specified, it defaults to the global Spring Integration `taskScheduler` bean, which has a default pool size of 10.
See "`<<namespace-taskscheduler>>`".
See <<namespace-taskscheduler>>.
|===
The following table describes attributes that you can set to configure TCP outbound channel adapters:
@@ -1777,7 +1777,7 @@ Default: 60000 (60 seconds).
| `true`, `false`
| Specifies a `TaskScheduler` to use for managing the `client-mode` connection.
If not specified, it defaults to the global Spring Integration `taskScheduler` bean, which has a default pool size of 10.
See "`<<namespace-taskscheduler>>`".
See <<namespace-taskscheduler>>.
|===
The following table describes attributes that you can set to configure TCP inbound gateways:
@@ -1828,7 +1828,7 @@ Default: 60000 (60 seconds).
| `true`, `false`
| Specifies a `TaskScheduler` to use for managing the `client-mode` connection.
If not specified, it defaults to the global Spring Integration `taskScheduler` bean, which has a default pool size of 10.
See "`<<namespace-taskscheduler>>`".
See <<namespace-taskscheduler>>.
|===
The following table describes attributes that you can set to configure TCP outbound gateways:

22
src/reference/asciidoc/jdbc.adoc
View File

@@ -155,7 +155,7 @@ Under normal circumstances, you would likely not want to set the poller's `max-m
Its default value is `1`, which means that the JDBC inbound channel adapter's https://docs.spring.io/spring-integration/api/org/springframework/integration/jdbc/JdbcPollingChannelAdapter.html#receive()[`receive()`] method is executed exactly once for each poll interval.
Setting the `max-messages-per-poll` attribute to a larger value means that the query is executed that many times back to back.
For more information regarding the `max-messages-per-poll` attribute, see "`<<channel-adapter-namespace-inbound>>`".
For more information regarding the `max-messages-per-poll` attribute, see <<channel-adapter-namespace-inbound>>.
In contrast, the `max-rows` attribute, if greater than `0`, specifies the maximum number of rows to be used from the query result set created by the `receive()` method.
If the attribute is set to `0`, all rows are included in the resulting message.
@@ -221,7 +221,7 @@ The following example uses a `ExpressionEvaluatingSqlParameterSourceFactory` to
----
====
For further information, see "`<<sp-defining-parameter-sources>>`".
For further information, see <<sp-defining-parameter-sources>>.
==== Using the `PreparedStatement` Callback
@@ -339,7 +339,7 @@ It can also have a `SqlParameterSourceFactory` injected to control the binding o
Starting with the version 4.2, the `request-prepared-statement-setter` attribute is available on the `<int-jdbc:outbound-gateway>` as an alternative to `request-sql-parameter-source-factory`.
It lets you specify a `MessagePreparedStatementSetter` bean reference, which implements more sophisticated `PreparedStatement` preparation before its execution.
See "`<<jdbc-outbound-channel-adapter>>`" for more information about `MessagePreparedStatementSetter`.
See <<jdbc-outbound-channel-adapter>> for more information about `MessagePreparedStatementSetter`.
[[jdbc-message-store]]
=== JDBC Message Store
@@ -636,14 +636,14 @@ A value of `0` disables caching.
Negative values are not permitted.
+
If you enable JMX, statistical information about the `jdbc-call-operations-cache` is exposed as an MBean.
See "`<<jmx-mbean-exporter>>`" for more information.
See <<jmx-mbean-exporter>> for more information.
* `sql-parameter-source-factory`: (Not available for the stored procedure inbound channel adapter.)
Reference to a `SqlParameterSourceFactory`.
By default, bean properties of the passed in `Message` payload are used as a source for the stored procedure's input parameters by using a `BeanPropertySqlParameterSourceFactory`.
+
This may suffice for basic use cases.
For more sophisticated options, consider passing in one or more `ProcedureParameter` values.
See "`<<sp-defining-parameter-sources>>`".
See <<sp-defining-parameter-sources>>.
Optional.
* `use-payload-as-parameter-source`: (Not available for the stored procedure inbound channel adapter.)
If set to `true`, the payload of the `Message` is used as a source for providing parameters.
@@ -987,7 +987,7 @@ public static void findCoffee(int coffeeId, String[] coffeeDescription)
----
====
The following listing shows the corresponding SQL
The following listing shows the corresponding SQL:
====
[source,sql]
@@ -1030,6 +1030,7 @@ The `JdbcLockRegistry` is based on the `LockRepository` abstraction, which has a
The database schema scripts are located in the `org.springframework.integration.jdbc` package, which is divided for the particular RDBMS vendors.
For example, the following listing shows the H2 DDL for the lock table:
====
[source,sql]
----
CREATE TABLE INT_LOCK (
@@ -1040,6 +1041,7 @@ CREATE TABLE INT_LOCK (
constraint LOCK_PK primary key (LOCK_KEY, REGION)
);
----
====
The `INT_` can be changed according to the target database design requirements.
Therefore, you must use `prefix` property on the `DefaultLockRepository` bean definition.
@@ -1053,7 +1055,7 @@ If so, you can specify the `id` to be associated with the `DefaultLockRepository
[[jdbc-metadata-store]]
=== JDBC Metadata Store
Version 5.0 introduced the JDBC `MetadataStore` (see "`<<metadata-store>>`") implementation.
Version 5.0 introduced the JDBC `MetadataStore` (see <<metadata-store>>) implementation.
You can use the `JdbcMetadataStore` to maintain the metadata state across application restarts.
This `MetadataStore` implementation can be used with adapters such as the following:
@@ -1102,6 +1104,6 @@ Inbound channel adapters can be supplied with a reference to the `TransactionMan
Unlike non-transactional `MetadataStore` implementations, with `JdbcMetadataStore`, the entry appears in the target table only after the transaction commits.
When a rollback occurs, no entries are added to the `INT_METADATA_STORE` table.
Since version 5.0.7, the `JdbcMetadataStore` can be configured with the RDBMS vendor-specific `lockHint` option for lock-based queries on metadata store entries.
It is `FOR UPDATE` by default and can be configured with an empty string, if the target data base doesn't support row locking functionality.
Please, consult with your vendor for particular possible hint in the `SELECT` expression for locking rows before updates.
Since version 5.0.7, you can configure the `JdbcMetadataStore` with the RDBMS vendor-specific `lockHint` option for lock-based queries on metadata store entries.
By default, it is `FOR UPDATE` and can be configured with an empty string if the target database does not support row locking functionality.
Consult with your vendor for particular and possible hints in the `SELECT` expression for locking rows before updates.

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

@@ -111,7 +111,7 @@ The `poller` element is not applicable for a message-driven channel adapter, as
For most scenarios, the message-driven approach is better, since the messages are passed along to the `MessageChannel` as soon as they are received from the underlying JMS consumer.
Finally, the `<message-driven-channel-adapter>` element also accepts the 'error-channel' attribute.
This provides the same basic functionality, as described in "`<<gateway-proxy>>`".
This provides the same basic functionality, as described in <<gateway-proxy>>.
The following example shows how to set an error channel on a message-driven channel adapter:
====
@@ -223,10 +223,10 @@ You can use the error-channel attribute to configure such a channel, as the foll
----
====
You might notice that this example looks very similar to that included within "`<<gateway-proxy>>`".
You might notice that this example looks very similar to that included within <<gateway-proxy>>.
The same idea applies here: The `exceptionTransformer` could be a POJO that creates error-response objects, you could reference the `nullChannel` to suppress the errors, or you could leave 'error-channel' out to let the exception propagate.
See "`<<jms-md-conversion-errors>>`".
See <<jms-md-conversion-errors>>.
When consuming from topics, set the `pub-sub-domain` attribute to true.
Set `subscription-durable` to `true` for a durable subscription or `subscription-shared` for a shared subscription (requires a JMS 2.0 broker and has been available since version 4.2).
@@ -319,13 +319,13 @@ If all the reply listeners are active, the JMS broker has an active consumer for
By enabling the idle timeout, each consumer exists only while the corresponding batch job is running (and
for a short time after it finishes).
See `idle-reply-listener-timeout` in "`<<jms-og-attributes>>`".
See `idle-reply-listener-timeout` in <<jms-og-attributes>>.
==== Gateway Reply Correlation
This section describes the mechanisms used for reply correlation (ensuring the originating gateway receives replies
to only its requests), depending on how the gateway is configured.
See "`<<jms-og-attributes>>`" for complete description of the attributes discussed here.
See <<jms-og-attributes>> for complete description of the attributes discussed here.
The following list describes the various scenarios (the numbers are for identification -- order does not matter):
@@ -558,7 +558,7 @@ The container continues to run until at least this time elapses with no requests
are outstanding).
The container is started again on the next request.
The stop time is a minimum and may actually be up to 1.5x this value.
<26> See "`<<jms-async-gateway>>`".
<26> See <<jms-async-gateway>>.
<27> When this element is included, replies are received by an asynchronous `MessageListenerContainer` rather than
creating a consumer for each reply.
This can be more efficient in many cases.

8
src/reference/asciidoc/jmx.adoc
View File

@@ -231,7 +231,7 @@ It registers message channels and message handlers but does not register itself.
You can expose the exporter itself (and certain other components in Spring Integration) by using the standard `<context:mbean-export/>` tag.
The exporter has some metrics attached to it -- for instance, a count of the number of active handlers and the number of queued messages.
It also has a useful operation, as discussed in "`<<jmx-mbean-shutdown>>`".
It also has a useful operation, as discussed in <<jmx-mbean-shutdown>>.
=====
Spring Integration 4.0 introduced the `@EnableIntegrationMBeanExport` annotation to allow for convenient configuration of a default `integrationMbeanExporter` bean of type `IntegrationMBeanExporter` with several useful options at the `@Configuration` class level.
@@ -345,7 +345,7 @@ Previously, `MessageSource`, `MessageChannel`, and `MessageHandler` metrics were
The proxy was added when an integration MBean exporter was declared in the context.
+
Now, the statistics are captured by the beans themselves.
See "`<<metrics-management>>`" for more information.
See <<metrics-management>> for more information.
+
WARNING: This change means that you no longer automatically get an MBean or statistics for custom `MessageHandler` implementations, unless those custom handlers extend `AbstractMessageHandler`.
The simplest way to resolve this is to extend `AbstractMessageHandler`.
@@ -372,7 +372,7 @@ You can now control whether the statistics are enabled on an individual componen
Further, you can capture simple counts on `MessageChannel` instances and `MessageHandler` instances instead of capturing the complete time-based statistics.
This can have significant performance implications, because you can selectively configure where you need detailed statistics and enable and disable collection at runtime.
+
See "`<<metrics-management>>`".
See <<metrics-management>>.
@IntegrationManagedResource::
Similar to the `@ManagedResource` annotation, the `@IntegrationManagedResource` marks a class as being eligible to be exported as an MBean.
@@ -434,4 +434,4 @@ public void stopActiveComponents(long howLong)
----
====
Its use and operation are described in "`<<jmx-shutdown>>`".
Its use and operation are described in <<jmx-shutdown>>.

8
src/reference/asciidoc/jpa.adoc
View File

@@ -827,7 +827,7 @@ An updating outbound gateway is functionally similar to an outbound channel adap
A retrieving outbound gateway is similar to an inbound channel adapter.
NOTE: We recommend you first read the "`<<jpa-outbound-channel-adapter>>`" section and the "`<<jpa-inbound-channel-adapter>>`" sections earlier in this chapter, as most of the common concepts are explained there.
NOTE: We recommend you first read the <<jpa-outbound-channel-adapter>> section and the <<jpa-inbound-channel-adapter>> sections earlier in this chapter, as most of the common concepts are explained there.
This similarity was the main factor to use the central `JpaExecutor` class to unify common functionality as much as possible.
@@ -838,7 +838,7 @@ Common for all JPA outbound gateways and similar to the `outbound-channel-adapte
* Native query
* Named query
For configuration examples see "`<<outboundGatewaySamples>>`".
For configuration examples see <<outboundGatewaySamples>>.
[[jpa-outbound-gateway-common-parameters]]
==== Common Configuration Parameters
@@ -909,7 +909,7 @@ The value is specified in milliseconds.
Optional.
====
The remaining attributes are described earlier in this chapter. See "`<<jpaInboundChannelAdapterParameters>>`" and "`<<jpaOutboundChannelAdapterParameters>>`".
The remaining attributes are described earlier in this chapter. See <<jpaInboundChannelAdapterParameters>> and <<jpaOutboundChannelAdapterParameters>>.
==== Configuring with Java Configuration
@@ -1052,7 +1052,7 @@ Version 3.0 introduced this attribute.
Optional.
====
The remaining attributes are described earlier in this chapter. See "`<<jpaInboundChannelAdapterParameters>>`" and "`<<jpaOutboundChannelAdapterParameters>>`".
The remaining attributes are described earlier in this chapter. See <<jpaInboundChannelAdapterParameters>> and <<jpaOutboundChannelAdapterParameters>>.
==== Configuring with Java Configuration

2
src/reference/asciidoc/logging-adapter.adoc
View File

@@ -1,7 +1,7 @@
[[logging-channel-adapter]]
=== Logging Channel Adapter
The `<logging-channel-adapter>` is often used in conjunction with a wire tap, as discussed in "`<<channel-wiretap>>`".
The `<logging-channel-adapter>` is often used in conjunction with a wire tap, as discussed in <<channel-wiretap>>.
However, it can also be used as the ultimate consumer of any flow.
For example, consider a flow that ends with a `<service-activator>` that returns a result, but you wish to discard that result.
To do that, you could send the result to `NullChannel`.

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

@@ -25,7 +25,7 @@ However, Spring Integration supports a few simple message mapping strategies.
For example, if the message payload is a byte array, that is mapped to an attachment.
For simple text-based emails, you can provide a string-based message payload.
In that case, a `MailMessage` is created with that `String` as the text content.
If you work with a message payload type whose `toString()` method returns appropriate mail text content, consider adding Spring Integration's `ObjectToStringTransformer` prior to the outbound mail adapter (see the example in "`<<transformer-namespace>>`" for more detail).
If you work with a message payload type whose `toString()` method returns appropriate mail text content, consider adding Spring Integration's `ObjectToStringTransformer` prior to the outbound mail adapter (see the example in <<transformer-namespace>> for more detail).
You can also configure the outbound `MailMessage` with certain values from `MessageHeaders`.
If available, values are mapped to the outbound mail's properties, such as the recipients (To, Cc, and BCc), the from, the reply-to, and the subject.
@@ -210,7 +210,7 @@ Alternatively, you can provide the host, username, and password, as the followin
----
====
NOTE: As with any outbound Channel Adapter, if the referenced channel is a `PollableChannel`, you should provide a `<poller>` element (see "`<<endpoint-namespace>>`").
NOTE: As with any outbound Channel Adapter, if the referenced channel is a `PollableChannel`, you should provide a `<poller>` element (see <<endpoint-namespace>>).
When you use the namespace support, you can also use a `header-enricher` message transformer.
Doing so simplifies the application of the headers mentioned earlier to any message prior to sending to the mail outbound channel adapter.
@@ -331,7 +331,7 @@ The following example relies `TestSearchTermStrategy` rather than the default `S
----
====
See "`<<imap-seen>>`" for information about message flagging.
See <<imap-seen>> for information about message flagging.
[[imap-peek]]
[IMPORTANT]
@@ -389,7 +389,7 @@ You should understand that that these actions (marking messages read and deletin
This can cause messages to be lost.
You may wish to consider using transaction synchronization instead.
See "`<<mail-tx-sync>>`".
See <<mail-tx-sync>>.
=====
The `<imap-idle-channel-adapter/>` also accepts the 'error-channel' attribute.
@@ -410,7 +410,7 @@ flag (by default, `spring-integration-mail-adapter`), as long as the server supp
If not, `Flag.FLAGGED` is set to `true`.
These flags are applied regardless of the `shouldMarkMessagesRead` setting.
As discussed in "`<<search-term>>`", the default `SearchTermStrategy` ignore messages that are so flagged.
As discussed in <<search-term>>, the default `SearchTermStrategy` ignore messages that are so flagged.
Starting with version 4.2.2, you can set the name of the user flag by using `setUserFlag` on the `MailReceiver`.
Doing so lets multiple receivers use a different flag (as long as the mail server supports user flags).
@@ -465,7 +465,7 @@ In other words, while our adapter may peek at the email, it also lets the email
Transaction synchronization for inbound adapters lets you take different actions after a transaction commits or rolls back.
You can enable transaction synchronization by adding a `<transactional/>` element to the poller for the polled `<inbound-adapter/>` or to the `<imap-idle-inbound-adapter/>`.
Even if there is no 'real' transaction involved, you can still enable this feature by using a `PseudoTransactionManager` with the `<transactional/>` element.
For more information, see "`<<transaction-synchronization>>`".
For more information, see <<transaction-synchronization>>.
Because of the many different mail servers and specifically the limitations that some have, at this time we provide only a strategy for these transaction synchronizations.
You can send the messages to some other Spring Integration components or invoke a custom bean to perform some action.

2
src/reference/asciidoc/message-history.adoc
View File

@@ -80,7 +80,7 @@ The following example shows how to do so:
In the preceding example, message history is maintained only for the components that end with 'Gateway', start with 'sample', or match the name, 'aName', exactly.
Starting with version 4.0, you can also use the `@EnableMessageHistory` annotation in a `@Configuration` class.
In addition, the `MessageHistoryConfigurer` bean is now exposed as a JMX MBean by the `IntegrationMBeanExporter` (see "`<<jmx-mbean-exporter>>`"), letting you change the patterns at runtime.
In addition, the `MessageHistoryConfigurer` bean is now exposed as a JMX MBean by the `IntegrationMBeanExporter` (see <<jmx-mbean-exporter>>), letting you change the patterns at runtime.
Note, however, that the bean must be stopped (turning off message history) in order to change the patterns.
This feature might be useful to temporarily turn on history to analyze a system.
The MBean's object name is `<domain>:name=messageHistoryConfigurer,type=MessageHistoryConfigurer`.

6
src/reference/asciidoc/message-publishing.adoc
View File

@@ -16,7 +16,7 @@ Spring Integration provides two approaches: XML configuration and annotation-dri
The annotation-driven approach lets you annotate any method with the `@Publisher` annotation to specify a 'channel' attribute.
Starting with version 5.1, to switch this functionality on, you must use the `@EnablePublisher` annotation on some `@Configuration` class.
See "`<<configuration-enable-integration>>`" for more information.
See <<configuration-enable-integration>> for more information.
The message is constructed from the return value of the method invocation and sent to the channel specified by the 'channel' attribute.
To further manage message structure, you can also use a combination of both `@Payload` and `@Header` annotations.
@@ -158,7 +158,7 @@ public @interface Audit {
----
====
In the preceding example, we define the `@Audit` annotation, which itself is annotated with `@Publisher`.
In the preceding example, we define the `@Audit` annotation, which is itself annotated with `@Publisher`.
Also note that you can define a `channel` attribute on the meta-annotation to encapsulate where messages are sent inside of this annotation.
Now you can annotate any method with the `@Audit` annotation, as the following example shows:
@@ -313,7 +313,7 @@ The following example shows how to an asynchronous `publishing-interceptor`:
----
====
Another way of handling this type of scenario is with a wire-tap. See "`<<channel-wiretap>>`".
Another way of handling this type of scenario is with a wire-tap. See <<channel-wiretap>>.
[[scheduled-producer]]
==== Producing and Publishing Messages Based on a Scheduled Trigger

6
src/reference/asciidoc/message-store.adoc
View File

@@ -13,7 +13,7 @@ Spring Integration provides support for the message store pattern by:
* Providing several implementations of this interface
* Exposing a `message-store` attribute on all components that have the capability to buffer messages so that you can inject any instance that implements the `MessageStore` interface.
Details on how to configure a specific message store implementation and how to inject a `MessageStore` implementation into a specific buffering component are described throughout the manual (see the specific component, such as "`<<channel-configuration-queuechannel,QueueChannel>>`", "`<<aggregator,Aggregator>>`", "`<<delayer,Delayer>>`", and others).
Details on how to configure a specific message store implementation and how to inject a `MessageStore` implementation into a specific buffering component are described throughout the manual (see the specific component, such as <<channel-configuration-queuechannel,QueueChannel>>, <<aggregator,Aggregator>>, <<delayer,Delayer>>, and others).
The following pair of examples show how to add a reference to a message store for a `QueueChannel` and for an aggregator:
.QueueChannel
@@ -65,7 +65,7 @@ Beginning with Spring Integration version 3.0, you can resolve this issue with a
Also, consider what happens when you configure a message-flow as follows: gateway -> queue-channel (backed by a persistent Message Store) -> service-activator. That gateway creates a temporary reply channel, which is lost by the time the service-activator's poller reads from the queue.
Again, you can use the header enricher to replace the headers with a `String` representation.
For more information, see "`<<header-enricher>>`".
For more information, see <<header-enricher>>.
=====
Spring Integration 4.0 introduced two new interfaces:
@@ -113,7 +113,7 @@ Starting with version 5.0.1, the `LIST` option is also available for when the or
Starting with version 4.3, all persistent `MessageGroupStore` instances retrieve `MessageGroup` instances and their `messages`
from the store in the lazy-load manner.
In most cases, it is useful for the correlation `MessageHandler` instances (see "`<<aggregator>>`" and "`<<resequencer>>`"),
In most cases, it is useful for the correlation `MessageHandler` instances (see <<aggregator>> and <<resequencer>>),
when it would add overhead to load entire the `MessageGroup` from the store on each correlation operation.
You can use the `AbstractMessageGroupStore.setLazyLoadMessageGroups(false)` option to switch off the lazy-load behavior from the configuration.

6
src/reference/asciidoc/message.adoc
View File

@@ -151,7 +151,7 @@ PRIORITY`
DUPLICATE_MESSAGE`
| `java.lang.Boolean`
| True if a message was detected as a duplicate by an idempotent receiver interceptor.
See "`<<idempotent-receiver>>`".
See <<idempotent-receiver>>.
| `IntegrationMessageHeaderAccessor.
CLOSEABLE_RESOURCE`
@@ -171,7 +171,7 @@ ACKNOWLEDGMENT_CALLBACK`
`Acknowledgment`
`Callback`
| If a message source supports it, a call back to accept, reject, or requeue a message.
See "`<<deferred-acks-message-source>>`".
See <<deferred-acks-message-source>>.
|===
Convenient typed getters for some of these headers are provided on the `IntegrationMessageHeaderAccessor` class, as the following example shows:
@@ -205,7 +205,7 @@ SEQUENCE_DETAILS`
ROUTING_SLIP`
| `java.util.`
`Map<List<Object>, Integer>`
| See "`<<routing-slip>>`".
| See <<routing-slip>>.
|===
[[message-id-generation]]

2
src/reference/asciidoc/meta-data-store.adoc
View File

@@ -63,7 +63,7 @@ The following configuration shows an example of how to do so:
The `value` of the idempotent entry may be an expiration date, after which that entry should be removed from metadata store by some scheduled reaper.
See also "`<<idempotent-receiver>>`".
See also <<idempotent-receiver>>.
[[metadatastore-listener]]
==== `MetadataStoreListener`

16
src/reference/asciidoc/metrics.adoc
View File

@@ -7,11 +7,11 @@ This section describes how to capture metrics for Spring Integration. In recent
==== Configuring Metrics Capture
NOTE: Prior to version 4.2, metrics were only available when JMX was enabled.
See "`<<jmx>>`".
See <<jmx>>.
To enable `MessageSource`, `MessageChannel`, and `MessageHandler` metrics, add an `<int:management/>` bean to the application context (in XML) or annotate one of your `@Configuration` classes with `@EnableIntegrationManagement` (in Java).
`MessageSource` instances maintain only counts, `MessageChannel` instances and `MessageHandler` instances maintain duration statistics in addition to counts.
See "`<<mgmt-channel-features>>`" and "`<<mgmt-handler-features>>`", later in this chapter.
See <<mgmt-channel-features>> and <<mgmt-handler-features>>, later in this chapter.
Doing so causes the automatic registration of the `IntegrationManagementConfigurer` bean in the application context.
Only one such bean can exist in the context, and, if registered manually via a `<bean/>` definition, it must have the bean name set to `integrationManagementConfigurer`.
@@ -80,13 +80,13 @@ In the unlikely event that you have a bean name starting with `!`, escape the `!
The collection of statistics implies the collection of counts.
<6> A reference to a `MetricsFactory`.
See "`<<mgmt-metrics-factory>>`".
See <<mgmt-metrics-factory>>.
At runtime, counts and statistics can be obtained by calling `getChannelMetrics`, `getHandlerMetrics` and `getSourceMetrics` (all from the `IntegrationManagementConfigurer` class), which return `MessageChannelMetrics`, `MessageHandlerMetrics`, and `MessageSourceMetrics`, respectively.
See the https://docs.spring.io/spring-integration/api/index.html[Javadoc] for complete information about these classes.
When JMX is enabled (see "`<<jmx>>`"), `IntegrationMBeanExporter` also exposes these metrics.
When JMX is enabled (see <<jmx>>), `IntegrationMBeanExporter` also exposes these metrics.
IMPORTANT:
`defaultLoggingEnabled`, `defaultCountsEnabled`, and `defaultStatsEnabled` are applied only if you have not explicitly configured the corresponding setting in a bean definition.
@@ -162,7 +162,7 @@ In addition, there are three `Gauge` Meters:
==== `MessageChannel` Metric Features
These legacy metrics will be removed in a future release.
See "`<<micrometer-integration>>`".
See <<micrometer-integration>>.
Message channels report metrics according to their concrete type.
If you are looking at a `DirectChannel`, you see statistics for the send operation.
@@ -267,7 +267,7 @@ To override the default `MetricsFactory`, configure it as <<configuring-metrics-
You can either customize the default implementations, as described in the next section, or provide completely different
implementations by extending `AbstractMessageChannelMetrics` or `AbstractMessageHandlerMetrics`.
See also "`<<micrometer-integration>>`".
See also <<micrometer-integration>>.
In addition to the default metrics factory <<configuring-metrics-capture,described earlier>>, the framework provides the `AggregatingMetricsFactory`.
This factory creates `AggregatingMessageChannelMetrics` and `AggregatingMessageHandlerMetrics` instances.
@@ -296,7 +296,7 @@ Counts (send and error) are maintained per-message, but the statistics are per 1
===== Customizing the Default Channel and Handler Statistics
See "`<<mgmt-statistics>>`" and the https://docs.spring.io/spring-integration/api/index.html[Javadoc] for the `ExponentialMovingAverage*` classes for more information about these values.
See <<mgmt-statistics>> and the https://docs.spring.io/spring-integration/api/index.html[Javadoc] for the `ExponentialMovingAverage*` classes for more information about these values.
By default, the `DefaultMessageChannelMetrics` and `DefaultMessageHandlerMetrics` use a "`window`" of ten measurements,
a rate period of one second (meaning rate per second) and a decay lapse period of one minute.
@@ -340,7 +340,7 @@ runtime (after the application context has been refreshed) by invoking the `conf
===== Performance Improvement
Previously, the time-based metrics (see "`<<mgmt-statistics>>`") were calculated in real time.
Previously, the time-based metrics (see <<mgmt-statistics>>) were calculated in real time.
The statistics are now calculated when retrieved instead.
This resulted in a significant performance improvement, at the expense of a small amount of additional memory for each statistic.
As <<configuring-metrics-capture,discussed earlier>>, you can disable the statistics altogether while retaining the MBean that allows the invocation of `Lifecycle` methods.

4
src/reference/asciidoc/mongodb.adoc
View File

@@ -156,7 +156,7 @@ To configure that scenario, you can extend one message store bean from the other
[[mongodb-metadata-store]]
==== MongoDB Metadata Store
Spring Integration 4.2 introduced a new MongoDB-based `MetadataStore` (see "`<<metadata-store>>`") implementation.
Spring Integration 4.2 introduced a new MongoDB-based `MetadataStore` (see <<metadata-store>>) implementation.
You can use the `MongoDbMetadataStore` to maintain metadata state across application restarts.
You can use this new `MetadataStore` implementation with adapters such as:
@@ -281,7 +281,7 @@ If only the `expression` attribute is present and the result of an expression is
If you want the evaluation result to go to a specific channel, add a `channel` attribute.
If the result of an expression is null or void, no message is generated.
For more information about transaction synchronization, see "`<<transaction-synchronization>>`".
For more information about transaction synchronization, see <<transaction-synchronization>>.
[[mongodb-outbound-channel-adapter]]
=== MongoDB Outbound Channel Adapter

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

@@ -92,7 +92,7 @@ In Spring Integration, pollable channels are capable of buffering Messages withi
The advantage of buffering is that it allows for throttling the inbound messages and thereby prevents overloading a consumer.
However, as the name suggests, this also adds some complexity, since a consumer can only receive the messages from such a channel if a poller is configured.
On the other hand, a consumer connected to a subscribable channel is simply message-driven.
"`<<channel-implementations>>`" has a detailed discussion of the variety of channel implementations available in Spring Integration.
<<channel-implementations>> has a detailed discussion of the variety of channel implementations available in Spring Integration.
[[overview-components-endpoint]]
==== Message Endpoint
@@ -414,14 +414,14 @@ In particular, it:
The `@IntegrationComponentScan` annotation also permits classpath scanning.
This annotation plays a similar role as the standard Spring Framework `@ComponentScan` annotation, but it is restricted to components and annotations that are specific to Spring Integration, which the standard Spring Framework component scan mechanism cannot reach.
For an example, see "`<<messaging-gateway-annotation>>`".
For an example, see <<messaging-gateway-annotation>>.
The `@EnablePublisher` annotation registers a `PublisherAnnotationBeanPostProcessor` bean and configures the `default-publisher-channel` for those `@Publisher` annotations that are provided without a `channel` attribute.
If more than one `@EnablePublisher` annotation is found, they must all have the same value for the default channel.
See "`<<publisher-annotation>>`" for more information.
See <<publisher-annotation>> for more information.
The `@GlobalChannelInterceptor` annotation has been introduced to mark `ChannelInterceptor` beans for global channel interception.
This annotation is an analogue of the `<int:channel-interceptor>` XML element (see "`<<global-channel-configuration-interceptors>>`").
This annotation is an analogue of the `<int:channel-interceptor>` XML element (see <<global-channel-configuration-interceptors>>).
`@GlobalChannelInterceptor` annotations can be placed at the class level (with a `@Component` stereotype annotation) or on `@Bean` methods within `@Configuration` classes.
In either case, the bean must implement `ChannelInterceptor`.
@@ -429,16 +429,16 @@ Starting with version 5.1, global channel interceptors apply to dynamically regi
Previously, interceptors were not applied when beans were created after the application context was refreshed.
The `@IntegrationConverter` annotation marks `Converter`, `GenericConverter`, or `ConverterFactory` beans as candidate converters for `integrationConversionService`.
This annotation is an analogue of the `<int:converter>` XML element (see "`<<payload-type-conversion>>`").
This annotation is an analogue of the `<int:converter>` XML element (see <<payload-type-conversion>>).
You can place `@IntegrationConverter` annotations at the class level (with a `@Component` stereotype annotation) or on `@Bean` methods within `@Configuration` classes.
See "`<<annotations>>`" for more information about messaging mnnotations.
See <<annotations>> for more information about messaging mnnotations.
[[programming-considerations]]
=== Programming Considerations
You should use plain old java objects (POJOs) whenever possible and only expose the framework in your code when absolutely necessary.
See "`<<pojo-invocation>>`" for more information.
See <<pojo-invocation>> for more information.
If you do expose the framework to your classes, there are some considerations that need to be taken into account, especially during application startup:
@@ -579,9 +579,9 @@ For Java configuration, it is important to understand the Framework API for targ
The first-class citizens for EIP implementation are `Message`, `Channel`, and `Endpoint` (see <<overview-components>>, earlier in this chapter).
Their implementations (contracts) are:
* `org.springframework.messaging.Message`: See "`<<message>>`";
* `org.springframework.messaging.MessageChannel`: See "`<<channel>>`";
* `org.springframework.integration.endpoint.AbstractEndpoint`: See "`<<polling-consumer>>`".
* `org.springframework.messaging.Message`: See <<message>>;
* `org.springframework.messaging.MessageChannel`: See <<channel>>;
* `org.springframework.integration.endpoint.AbstractEndpoint`: See <<polling-consumer>>.
The first two are simple enough to understand how to implement, configure, and use.
The last one deserves more attention
@@ -601,7 +601,7 @@ The goal of the implementation of this interface is to handle the message consum
All EIP components in Spring Integration are `MessageHandler` implementations (for example, `AggregatingMessageHandler`, `MessageTransformingHandler`, `AbstractMessageSplitter`, and others).
The target protocol outbound adapters (`FileWritingMessageHandler`, `HttpRequestExecutingMessageHandler`, `AbstractMqttMessageHandler`, and others) are also `MessageHandler` implementations.
When you develop Spring Integration applications with Java configuration, you should look into the Spring Integration module to find an appropriate `MessageHandler` implementation to use for the `@ServiceActivator`\ configuration.
For example, to send an XMPP message (see "`<<xmpp>>`") you should configure something like the following:
For example, to send an XMPP message (see <<xmpp>>) you should configure something like the following:
====
[source,java]
@@ -677,7 +677,7 @@ The sending thread returns immediately; the reply is sent asynchronously; uses '
[[pojo-invocation]]
=== POJO Method invocation
As discussed in "`<<programming-considerations>>`", we recommend using a POJO programming style, as the following example shows:
As discussed in <<programming-considerations>>, we recommend using a POJO programming style, as the following example shows:
====
[source, java]

10
src/reference/asciidoc/polling-consumer.adoc
View File

@@ -25,7 +25,7 @@ You can find a description of the pattern on the http://www.enterpriseintegratio
Spring Integration offers a second variation of the polling consumer pattern.
When inbound channel adapters are used, these adapters are often wrapped by a `SourcePollingChannelAdapter`.
For example, when retrieving messages from a remote FTP Server location, the adapter described in "`<<ftp-inbound>>`" is configured with a poller to periodically retrieve messages.
For example, when retrieving messages from a remote FTP Server location, the adapter described in <<ftp-inbound>> is configured with a poller to periodically retrieve messages.
So, when components are configured with pollers, the resulting instances are of one of the following types:
* http://static.springsource.org/spring-integration/api/org/springframework/integration/endpoint/PollingConsumer.html[`PollingConsumer`]
@@ -49,10 +49,10 @@ advice chain.
To skip polling, call `skipPolls()`.
To resume polling, call `reset()`.
Version 4.2 added more flexibility in this area.
See "`<<conditional-pollers>>`".
See <<conditional-pollers>>.
This chapter is meant to only give a high-level overview of polling consumers and how they fit into the concept of message channels (see "`<<channel>>`") and channel adapters (see "`<<channel-adapter>>`").
For more information regarding messaging endpoints in general and polling consumers in particular, see "`<<endpoint>>`".
This chapter is meant to only give a high-level overview of polling consumers and how they fit into the concept of message channels (see <<channel>>) and channel adapters (see <<channel-adapter>>).
For more information regarding messaging endpoints in general and polling consumers in particular, see <<endpoint>>.
[[deferred-acks-message-source]]
==== Deferred Acknowledgment Pollable Message Source
@@ -60,7 +60,7 @@ For more information regarding messaging endpoints in general and polling consum
Starting with version 5.0.1, certain modules provide `MessageSource` implementations that support deferring acknowledgment until the downstream flow completes (or hands off the message to another thread).
This is currently limited to the `AmqpMessageSource` and the `KafkaMessageSource` provided by the https://github.com/spring-projects/spring-integration-kafka[`spring-kafka-integration` extension project, version 3.0.1 or higher].
With these message sources, the `IntegrationMessageHeaderAccessor.ACKNOWLEDGMENT_CALLBACK` header (see "`<<message-header-accessor>>`") is added to the message.
With these message sources, the `IntegrationMessageHeaderAccessor.ACKNOWLEDGMENT_CALLBACK` header (see <<message-header-accessor>>) is added to the message.
The value of the header is an instance of `AcknowledgmentCallback`, as the following example shows:
[source, java]

2
src/reference/asciidoc/preface.adoc
View File

@@ -57,7 +57,7 @@ The following example shows the `int`, `int-event`, and `int-stream` namespaces
----
====
For a detailed explanation regarding Spring Integration's namespace support, see "`<<configuration-namespace>>`".
For a detailed explanation regarding Spring Integration's namespace support, see <<configuration-namespace>>.
NOTE: The namespace prefix can be freely chosen.
You may even choose not to use any namespace prefixes at all.

6
src/reference/asciidoc/redis.adoc
View File

@@ -12,7 +12,7 @@ To download, install, and run Redis, see the http://redis.io/download[Redis docu
To begin interacting with Redis, you first need to connect to it.
Spring Integration uses support provided by another Spring project, https://github.com/SpringSource/spring-data-redis[Spring Data Redis], which provides typical Spring constructs: `ConnectionFactory` and `Template`.
Those abstractions simplify integration with several Redis client Java APIs.
\Currently Spring Data Redis supports https://github.com/xetorthio/jedis[jedis], http://code.google.com/p/jredis/[jredis] and https://github.com/e-mzungu/rjc[Redis Java Client (RJC)].
Currently Spring Data Redis supports https://github.com/xetorthio/jedis[jedis], http://code.google.com/p/jredis/[jredis] and https://github.com/e-mzungu/rjc[Redis Java Client (RJC)].
==== Using `RedisConnectionFactory`
@@ -393,7 +393,7 @@ They can be used only for situations such as backing a `QueueChannel`.
[[redis-metadata-store]]
=== Redis Metadata Store
Spring Integration 3.0 introduced a new Redis-based http://docs.spring.io/spring-integration/docs/latest-ga/api/org/springframework/integration/metadata/MetadataStore.html[`MetadataStore`] (see "`<<metadata-store>>`") implementation.
Spring Integration 3.0 introduced a new Redis-based http://docs.spring.io/spring-integration/docs/latest-ga/api/org/springframework/integration/metadata/MetadataStore.html[`MetadataStore`] (see <<metadata-store>>) implementation.
You can use the `RedisMetadataStore` to maintain the state of a `MetadataStore` across application restarts.
You can use this new `MetadataStore` implementation with adapters such as:
@@ -527,7 +527,7 @@ If only the `expression` attribute is present and the result of an expression is
If you want the evaluation result to go to a specific channel, add a `channel` attribute.
If the result of an expression is null or void, no message is generated.
For more information about transaction synchronization, see "`<<transaction-synchronization>>`".
For more information about transaction synchronization, see <<transaction-synchronization>>.
[[redis-store-outbound-channel-adapter]]
=== RedisStore Outbound Channel Adapter

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

@@ -16,7 +16,7 @@ If you have a large number of disjoint sequences with many gaps, you may experie
==== Configuring a Resequencer
See "`<<java-dsl-aggregators>>`" for configuring a resequencer in Java DSL.
See <<java-dsl-aggregators>> for configuring a resequencer in Java DSL.
Configuring a resequencer requires only including the appropriate element in XML.
@@ -66,7 +66,7 @@ Optional. (The default is `false`.)
Optional. (The default is 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. (The default is false.)
See "`<<reaper>>`".
See <<reaper>>.
<8> The timeout interval to wait when sending a reply `Message` to the `output-channel` or `discard-channel`.
Defaults to `-1`, which blocks indefinitely.
It is applied only if the output channel has some 'sending' limitations, such as a `QueueChannel` with a fixed 'capacity'.
@@ -100,10 +100,10 @@ This is to enable the detection and discarding of late-arriving messages.
If you wish to expire empty groups on a longer schedule than expiring partial groups, set this property.
Empty groups are then not removed from the `MessageStore` until they have not been modified for at least this number of milliseconds.
Note that the actual time to expire an empty group is also affected by the reaper's timeout property, and it could be as much as this value plus the timeout.
<16> See "`<<aggregator-xml>>`".
<17> See "`<<aggregator-xml>>`".
<18> See "`<<aggregator-xml>>`".
<19> See "`<<aggregator-xml>>`".
<16> See <<aggregator-xml>>.
<17> See <<aggregator-xml>>.
<18> See <<aggregator-xml>>.
<19> See <<aggregator-xml>>.
<20> By default, when a group is completed due to a timeout (or by a `MessageGroupStoreReaper`), the empty group's metadata is retained.
Late arriving messages are immediately discarded.
Set this to `true` to remove the group completely.

52
src/reference/asciidoc/resource.adoc
View File

@@ -1,51 +1,56 @@
[[resource]]
== Resource Support
[[resource-intro]]
=== Introduction
The _Resource Inbound Channel Adapter_ builds upon Spring's `Resource` abstraction to support greater flexibility across a variety of actual types of underlying resources, such as a file, a URL, or a class path resource.
Therefore, it's similar to but more generic than the _File Inbound Channel Adapter_.
The resource inbound channel adapter builds upon Spring's `Resource` abstraction to support greater flexibility across a variety of actual types of underlying resources, such as a file, a URL, or a class path resource.
Therefore, it is similar to but more generic than the file inbound channel adapter.
[[resource-inbound-channel-adapter]]
=== Resource Inbound Channel Adapter
The _Resource Inbound Channel Adapter_ is a polling adapter that creates a `Message` whose payload is a collection of `Resource` objects.
The resource inbound channel adapter is a polling adapter that creates a `Message` whose payload is a collection of `Resource` objects.
`Resource` objects are resolved based on the pattern specified using the `pattern` attribute.
`Resource` objects are resolved based on the pattern specified by the `pattern` attribute.
The collection of resolved `Resource` objects is then sent as a payload within a `Message` to the adapter's channel.
That is one major difference between _Resource Inbound Channel Adapter_ and _File Inbound Channel Adapter_; the latter buffers File objects and sends a single `File` object per `Message`.
That is one major difference between resource inbound channel adapter and file inbound channel adapter: The latter buffers `File` objects and sends a single `File` object per `Message`.
Below is an example of a very simple configuration which will find all files ending with the 'properties' extension in the `foo.bar` package available on the classpath and will send them as the payload of a Message to the channel named '`resultChannel`':
The following example shows a simple configuration that finds all files that end with the 'properties' extension in the `things.thing1` package available on the classpath and sends them as the payload of a `Message` to the channel named '`resultChannel`':
====
[source,xml]
----
<int:resource-inbound-channel-adapter id="resourceAdapter"
channel="resultChannel"
pattern="classpath:foo/bar/*.properties">
pattern="classpath:things/thing1/*.properties">
<int:poller fixed-rate="1000"/>
</int:resource-inbound-channel-adapter>
----
====
The _Resource Inbound Channel Adapter_ relies on the `org.springframework.core.io.support.ResourcePatternResolver` strategy interface to resolve the provided pattern.
The resource inbound channel adapter relies on the `org.springframework.core.io.support.ResourcePatternResolver` strategy interface to resolve the provided pattern.
It defaults to an instance of the current `ApplicationContext`.
However you may provide a reference to an instance of your own implementation of `ResourcePatternResolver` using the `pattern-resolver` attribute:
However, you can provide a reference to an instance of your own implementation of `ResourcePatternResolver` by setting the `pattern-resolver` attribute, as the following example shows:
====
[source,xml]
----
<int:resource-inbound-channel-adapter id="resourceAdapter"
channel="resultChannel"
pattern="classpath:foo/bar/*.properties"
pattern="classpath:things/thing1/*.properties"
pattern-resolver="myPatternResolver">
<int:poller fixed-rate="1000"/>
</int:resource-inbound-channel-adapter>
<bean id="myPatternResolver" class="org.example.MyPatternResolver"/>
----
====
You may have a use case where you need to further filter the collection of resources resolved by the `ResourcePatternResolver`.
For example, you may want to prevent resources that were resolved already from appearing in a collection of resolved resources ever again.
On the other hand your resources might be updated rather often and you _do_ want them to be picked up again.
In other words there is a valid use case for defining an additional filter as well as disabling filtering altogether.
You can provide your own implementation of the `org.springframework.integration.util.CollectionFilter` strategy interface:
For example, you may want to prevent resources that were already resolved from appearing in a collection of resolved resources ever again.
On the other hand, your resources might be updated rather often and you _do_ want them to be picked up again.
In other words, both defining an additional filter and disabling filtering altogether are valid use cases.
You can provide your own implementation of the `org.springframework.integration.util.CollectionFilter` strategy interface, as the following example shows:
====
[source,java]
----
public interface CollectionFilter<T> {
@@ -54,25 +59,28 @@ public interface CollectionFilter<T> {
}
----
====
As you can see the `CollectionFilter` receives a collection of un-filtered elements (which would be `Resource` objects in this case), and it returns a collection of filtered elements of that same type.
The `CollectionFilter` receives a collection of un-filtered elements (which are `Resource` objects in the preceding example), and it returns a collection of filtered elements of that same type.
If you are defining the adapter via XML but you do not specify a filter reference, a default implementation of `CollectionFilter` will be used by the _Resource Inbound Channel Adapter_.
If you define the adapter with XML but you do not specify a filter reference, the resource inbound channel adapter uses a default implementation of `CollectionFilter`.
The implementation class of that default filter is `org.springframework.integration.util.AcceptOnceCollectionFilter`.
It remembers the elements passed in the previous invocation in order to avoid returning those elements more than once.
To inject your own implementation of `CollectionFilter` instead, use the `filter` attribute.
To inject your own implementation of `CollectionFilter` instead, use the `filter` attribute, as the following example shows:
====
[source,xml]
----
<int:resource-inbound-channel-adapter id="resourceAdapter"
channel="resultChannel"
pattern="classpath:foo/bar/*.properties"
pattern="classpath:things/thing1/*.properties"
filter="myFilter">
<int:poller fixed-rate="1000"/>
</int:resource-inbound-channel-adapter>
<bean id="myFilter" class="org.example.MyFilter"/>
----
====
If you don't need any filtering and want to disable even the default `CollectionFilter` strategy, simply provide an empty value for the filter attribute (e.g., `filter=""`)
If you do not need any filtering and want to disable even the default `CollectionFilter` strategy, provide an empty value for the filter attribute (for example, `filter=""`)

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

@@ -630,7 +630,7 @@ The following example creates a `RecipientListRouter`:
----
====
Spring Integration also provides namespace support for the `RecipientListRouter` configuration (see "`<<configuration-namespace>>`") as the following example shows:
Spring Integration also provides namespace support for the `RecipientListRouter` configuration (see <<configuration-namespace>>) as the following example shows:
====
[source,xml]
@@ -686,7 +686,7 @@ public IntegrationFlow routerFlow() {
====
NOTE: The 'apply-sequence' flag here has the same effect as it does for a publish-subscribe-channel, and, as with a publish-subscribe-channel, it is disabled by default on the `recipient-list-router`.
See "`<<channel-configuration-pubsubchannel>>`" for more information.
See <<channel-configuration-pubsubchannel>> for more information.
Another convenient option when configuring a `RecipientListRouter` is to use Spring Expression Language (SpEL) support as selectors for individual recipient channels.
Doing so is similar to using a filter at the beginning of a 'chain' to act as a "`selective consumer`".
@@ -709,7 +709,7 @@ If this attribute is not defined, the channel is always among the list of recipi
Starting with version 4.1, the `RecipientListRouter` provides several operations to manipulate recipients dynamically at runtime.
These management operations are presented by `RecipientListRouterManagement` through the `@ManagedResource` annotation.
They are available by using "`<<control-bus>>`" as well as by using JMX, as the following example shows:
They are available by using <<control-bus>> as well as by using JMX, as the following example shows:
====
[source,xml]
@@ -742,7 +742,7 @@ Otherwise the `MessageDeliveryException` is thrown.
===== XPath Router
The XPath Router is part of the XML Module.
See "`<<xml-xpath-routing>>`".
See <<xml-xpath-routing>>.
[[router-implementations-exception-router]]
===== Routing and Error Handling
@@ -1001,7 +1001,7 @@ public List<String> route(Foo payload) {...}
====
In addition to payload-based routing, a message may be routed based on metadata available within the message header as either a property or an attribute.
In this case, a method annotated with `@Router` may include a parameter annotated with `@Header`, which is mapped to a header value as the following example shows and documented in "`<<annotations>>`":
In this case, a method annotated with `@Router` may include a parameter annotated with `@Header`, which is mapped to a header value as the following example shows and documented in <<annotations>>:
====
[source,java]
@@ -1011,9 +1011,9 @@ public List<String> route(@Header("orderStatus") OrderStatus status)
----
====
NOTE: For routing of XML-based Messages, including XPath support, see "`<<xml>>`".
NOTE: For routing of XML-based Messages, including XPath support, see <<xml>>.
See also "`<<java-dsl-routers>>`" in the Java DSL chapter for more information about router configuration.
See also <<java-dsl-routers>> in the Java DSL chapter for more information about router configuration.
[[dynamic-routers]]
==== Dynamic Routers
@@ -1120,14 +1120,14 @@ In fact, it applies to every other router, including expression-based routers, s
Any router that is a subclass of the `AbstractMappingMessageRouter` (which includes most framework-defined routers) is a dynamic router, because the `channelMapping` is defined at the `AbstractMappingMessageRouter` level.
That map's setter method is exposed as a public method along with the 'setChannelMapping' and 'removeChannelMapping' methods.
These let you change, add, and remove router mappings at runtime, as long as you have a reference to the router itself.
It also means that you could expose these same configuration options through JMX (see "`<<jmx>>`") or the Spring Integration control bus (see "`<<control-bus>>`") functionality. 
It also means that you could expose these same configuration options through JMX (see <<jmx>>) or the Spring Integration control bus (see <<control-bus>>) functionality. 
[[dynamic-routers-control-bus]]
===== Manage Router Mappings using the Control Bus
One way to manage the router mappings is through the http://www.eaipatterns.com/ControlBus.html[control bus] pattern, which exposes a control channel to which you can send control messages to manage and monitor Spring Integration components, including routers.
NOTE: For more information about the control bus, see "`<<control-bus>>`".
NOTE: For more information about the control bus, see <<control-bus>>.
Typically, you would send a control message asking to invoke a particular operation on a particular managed component (such as a
router).
@@ -1163,7 +1163,7 @@ For programmatic changes to the map, we recommend that you use the `setChannelMa
You can also use Spring's JMX support to expose a router instance and then use your favorite JMX client (for example, JConsole) to manage those operations (methods) for changing the router's configuration.
NOTE: For more information about Spring Integration's JMX support, see "`<<jmx>>`".
NOTE: For more information about Spring Integration's JMX support, see <<jmx>>.
[[routing-slip]]
===== Routing Slip

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

@@ -1,9 +1,6 @@
[[scatter-gather]]
=== Scatter-Gather
[[scatter-gather-introduction]]
==== Introduction
Starting with version 4.1, Spring Integration provides an implementation of the http://www.eaipatterns.com/BroadcastAggregate.html[scatter-gather] enterprise integration pattern.
It is a compound endpoint for which the goal is to send a message to the recipients and aggregate the results.
As noted in http://www.eaipatterns.com[_Enterprise Integration Patterns_], it is a component for scenarios such as "`best quote`", where we need to request information from several suppliers and decide which one provides us with the best term for the requested item.
@@ -20,17 +17,17 @@ The request message is sent to the `scatter` channel, and the `ScatterGatherHand
The `Scatter-Gather` pattern suggests two scenarios: "`auction`" and "`distribution`".
In both cases, the `aggregation` function is the same and provides all the options available for the `AggregatingMessageHandler`.
(Actually, the `ScatterGatherHandler` requires only an `AggregatingMessageHandler` as a constructor argument.)
See "`<<aggregator>>`" for more information.
See <<aggregator>> for more information.
===== Auction
The auction `Scatter-Gather` variant uses "`publish-subscribe`" logic for the request message, where the "`scatter`" channel is a `PublishSubscribeChannel` with `apply-sequence="true"`.
However, this channel can be any `MessageChannel` implementation (as is the case with the `request-channel` in the `ContentEnricher` -- see "`<<content-enricher>>`").
However, this channel can be any `MessageChannel` implementation (as is the case with the `request-channel` in the `ContentEnricher` -- see <<content-enricher>>).
However, in this case, you should create your own custom `correlationStrategy` for the `aggregation` function.
===== 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 on only the default `correlationStrategy` for the `recipient-list-router` and the `aggregator`, you should specify `apply-sequence="true"`.
Otherwise, you should supply a custom `correlationStrategy` for the `aggregator`.

2
src/reference/asciidoc/security.adoc
View File

@@ -114,7 +114,7 @@ Often, though, processing logic can be performed on another thread, on several t
Standard thread-bound behavior is easy to configure if our application is built on the Spring Integration components
and its message channels.
In this case, the secured objects can be any service activator or transformer, secured with a
`MethodSecurityInterceptor` in their `<request-handler-advice-chain>` (see "`<<message-handler-advice-chain>>`") or even `MessageChannel` (see "`<<securing-channels>>`", earlier).
`MethodSecurityInterceptor` in their `<request-handler-advice-chain>` (see <<message-handler-advice-chain>>) or even `MessageChannel` (see <<securing-channels>>, earlier).
When using `DirectChannel` communication, the `SecurityContext` is automatically available, because the downstream flow runs on the current thread.
However, in the cases of the `QueueChannel`, `ExecutorChannel`, and `PublishSubscribeChannel` with an `Executor`, messages are transferred from one thread to another (or several) by the nature of those channels.
In order to support such scenarios, we have two choices:

6
src/reference/asciidoc/service-activator.adoc
View File

@@ -59,7 +59,7 @@ This is the technique used for request-reply messaging in Spring Integration, an
If your method returns a result and you want to discard it and end the flow, you should configure the `output-channel` to send to a `NullChannel`.
For convenience, the framework registers one with the name, `nullChannel`.
See "`<<channel-special-channels>>`" for more information.
See <<channel-special-channels>> for more information.
The service activator is one of those components that is not required to produce a reply message.
If your method returns `null` or has a `void` return type, the service activator exits after the method invocation, without any signals.
@@ -69,7 +69,7 @@ If the flag is set to `true` and the method returns null, a `ReplyRequiredExcept
The argument in the service method could be either a message or an arbitrary type.
If the latter, then it is assumed to be a message payload, which is extracted from the message and injected into the service method.
We generally recommend this approach, as it follows and promotes a POJO model when working with Spring Integration.
Arguments may also have `@Header` or `@Headers` annotations, as described in "`<<annotations>>`".
Arguments may also have `@Header` or `@Headers` annotations, as described in <<annotations>>.
NOTE: The service method is not required to have any arguments, which means you can implement event-style service activators (where all you care about is an invocation of the service method) and not worry about the contents of the message.
Think of it as a null JMS message.
@@ -147,7 +147,7 @@ For simple scenarios, your service activators need not reference a bean if all l
In the preceding configuration, our service logic is to multiply the payload value by two.
SpEL lets us handle it relatively easily.
See "`<<java-dsl-handle>>`" in the Java DSL chapter for more information about configuring service activator.
See <<java-dsl-handle>> in the Java DSL chapter for more information about configuring service activator.
[[async-service-activator]]
==== Asynchronous Service Activator

33
src/reference/asciidoc/sftp.adoc
View File

@@ -25,7 +25,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/sftp
=== SFTP Session Factory
IMPORTANT: As of version 3.0, sessions are no longer cached by default.
See "`<<sftp-session-caching>>`".
See <<sftp-session-caching>>.
Before configuring SFTP adapters, you must configure an SFTP session factory.
You can configure the SFTP session factory with a regular bean definition, as the following example shows:
@@ -48,7 +48,7 @@ Every time an adapter requests a session object from its `SessionFactory`, a new
Under the covers, the SFTP Session Factory relies on the http://www.jcraft.com/jsch/[JSch] library to provide the SFTP capabilities.
However, Spring Integration also supports the caching of SFTP sessions.
See "`<<sftp-session-caching>>`" for more information.
See <<sftp-session-caching>> for more information.
[IMPORTANT]
=====
@@ -64,7 +64,7 @@ The connection is refreshed if it is found to be disconnected when a new operati
=====
NOTE: If you experience connectivity problems and would like to trace session creation and see which sessions are polled, you may enable tracing by setting the logger to `TRACE` level (for example, `log4j.category.org.springframework.integration.sftp=TRACE`).
See "`<<sftp-jsch-logging>>`".
See <<sftp-jsch-logging>>.
Now all you need to do is inject this SFTP session factory into your adapters.
@@ -113,7 +113,7 @@ Optional.
`proxy`::Allows for specifying a JSch-based http://epaul.github.com/jsch-documentation/javadoc/com/jcraft/jsch/Proxy.html[proxy].
If set, the proxy object is used to create the connection to the remote host through the proxy.
See "`<<sftp-proxy-factory-bean>>`" for a convenient way to configure the proxy.
See <<sftp-proxy-factory-bean>> for a convenient way to configure the proxy.
`serverAliveCountMax`::Specifies the number of server-alive messages, which are sent without any reply from the server before disconnecting.
If not set, this property defaults to `1`.
@@ -207,7 +207,7 @@ We added convenience methods so that you can more easily do so from a message fl
----
====
IMPORTANT: When using session caching (see "`<<sftp-session-caching>>`"), each of the delegates should be cached.
IMPORTANT: When using session caching (see <<sftp-session-caching>>), each of the delegates should be cached.
You cannot cache the `DelegatingSessionFactory` itself.
Starting with _version 5.0.7_, the `DelegatingSessionFactory` can be used in conjuction with a `RotatingServerAdvice` to poll multiple servers; see <<sftp-rotating-server-advice>>.
@@ -315,7 +315,7 @@ Starting with version 5.0, you can limit the number of files fetched from the FT
This can be beneficial when the target files are large or when running in a clustered system with a persistent file list filter, discussed later in this section.
Use `max-fetch-size` for this purpose.
A negative value (the default) means no limit and all matching files are retrieved.
See "`<<sftp-max-fetch>>`" for more information.
See <<sftp-max-fetch>> for more information.
Since version 5.0, you can also provide a custom `DirectoryScanner` implementation to the `inbound-channel-adapter` by setting the `scanner` attribute.
Starting with Spring Integration 3.0, you can specify the `preserve-timestamp` attribute (the default is `false`).
@@ -333,7 +333,7 @@ You can also combine a pattern-based filter with other filters (such as an `Acce
The `AcceptOnceFileListFilter` stores its state in memory.
If you wish the state to survive a system restart, consider using the `SftpPersistentAcceptOnceFileListFilter` instead.
This filter stores the accepted file names in an instance of the `MetadataStore` strategy (see "`<<metadata-store>>`").
This filter stores the accepted file names in an instance of the `MetadataStore` strategy (see <<metadata-store>>).
This filter matches on the filename and the remote modified time.
Since version 4.0, this filter requires a `ConcurrentMetadataStore`.
@@ -352,7 +352,7 @@ Also, if you configure the `filter` to use a `FtpPersistentAcceptOnceFileListFil
You can use the `local-filter` attribute to configure the behavior of the local file system filter.
Starting with version 4.3.8, a `FileSystemPersistentAcceptOnceFileListFilter` is configured by default.
This filter stores the accepted file names and modified timestamp in an instance of the `MetadataStore` strategy (see "`<<metadata-store>>`") and detects changes to the local file modified time.
This filter stores the accepted file names and modified timestamp in an instance of the `MetadataStore` strategy (see <<metadata-store>>) and detects changes to the local file modified time.
The default `MetadataStore` is a `SimpleMetadataStore` that stores state in memory.
Since version 4.1.5, these filters have a new property called `flushOnUpdate`, which causes them to flush the
@@ -450,7 +450,7 @@ See https://docs.spring.io/spring-integration/api/org/springframework/integratio
Also, you can now switch the `AbstractInboundFileSynchronizingMessageSource` to the `WatchService`-based `DirectoryScanner` by using `setUseWatchService()` option.
It is also configured for all the `WatchEventType` instances to react for any modifications in local directory.
The reprocessing sample shown earlier is based on the built-in functionality of the `FileReadingMessageSource.WatchServiceDirectoryScanner`, which uses `ResettableFileListFilter.remove()` when the file is deleted (`StandardWatchEventKinds.ENTRY_DELETE`) from the local directory.
See "`<<watch-service-directory-scanner>>`" for more information.
See <<watch-service-directory-scanner>> for more information.
==== Configuring with Java Configuration
@@ -555,7 +555,7 @@ public class SftpJavaApplication {
[[sftp-incomplete]]
==== Dealing With Incomplete Data
See "`<<file-incomplete>>`".
See <<file-incomplete>>.
The `SftpSystemMarkerFilePresentFileListFilter` is provided to filter remote files that don't have the corresponding marker file on the remote system.
See the https://docs.spring.io/spring-integration/api/org/springframework/integration/sftp/filters/SftpSystemMarkerFilePresentFileListFilter.html[Javadoc] for configuration information.
@@ -568,7 +568,7 @@ This adapter produces message with payloads of type `InputStream`, letting you f
Since the session remains open, the consuming application is responsible for closing the session when the file has been consumed.
The session is provided in the `closeableResource` header (`IntegrationMessageHeaderAccessor.CLOSEABLE_RESOURCE`).
Standard framework components, such as the `FileSplitter` and `StreamTransformer`, automatically close the session.
See "`<<file-splitter>>`" and "`<<stream-transformer>>`" for more information about these components.
See <<file-splitter>> and <<stream-transformer>> for more information about these components.
The following example shows how to configure an SFTP streaming inbound channel adapter:
====
@@ -600,7 +600,7 @@ The Java configuration <<sftp-streaming-java-config,shown later>> shows one tech
You can use the `max-fetch-size` attribute to limit the number of files fetched on each poll when a fetch is necessary.
Set it to `1` and use a persistent filter when running in a clustered environment.
See "`<<sftp-max-fetch>>`" for more information.
See <<sftp-max-fetch>> for more information.
The adapter puts the remote directory and the file name in headers (`FileHeaders.REMOTE_DIRECTORY` and `FileHeaders.REMOTE_FILE`, respectively).
Starting with version 5.0, the `FileHeaders.REMOTE_FILE_INFO` header provides additional remote file information (in JSON).
@@ -608,7 +608,10 @@ If you set the `fileInfoJson` property on the `SftpStreamingMessageSource` to `f
You can access the `LsEntry` object provided by the underlying Jsch library by using the `SftpFileInfo.getFileInfo()` method.
The `fileInfoJson` property is not available when you use XML configuration, but you can set it by injecting the `SftpStreamingMessageSource` into one of your configuration classes.
Starting with version 5.1, the `comparator` 's generic type is now `LsEntry`; previously it was `AbstractFileInfo<LsEntry>`; this is because the sort is now performed earlier in the processing, before filtering and applying `maxFetch`.
Starting with version 5.1, the generic type of the `comparator` is `LsEntry`.
Previously, it was `AbstractFileInfo<LsEntry>`.
This is because the sort is now performed earlier in the processing, before filtering and applying `maxFetch`.
[[sftp-streaming-java-config]]
==== Configuring with Java Configuration
@@ -1105,7 +1108,7 @@ Doing so allows recursion for a simple pattern, as the following examples show:
You can provide one of these filters by using the `filter` property on the gateway.
See also "`<<sftp-partial>>`".
See also <<sftp-partial>>.
[[sftp-put-command]]
==== Using the `put` Command
@@ -1137,7 +1140,7 @@ Subdirectories that do not pass the filter are not recursed.
The message payload resulting from an `mget` operation is a `List<String>` object (that is, a `List` of remote file paths resulting from the transfer).
See also "`<<sftp-partial>>`".
See also <<sftp-partial>>.
Version 4.3 introduced the `chmod` attribute, which lets you change the remote file permissions after upload.
You can use the conventional Unix octal format (for example, `600` allows read-write for the file owner only).

2
src/reference/asciidoc/shutdown.adoc
View File

@@ -21,7 +21,7 @@ It is therefore important to select an appropriate timeout when invoking this op
+
Doing so lets such components perform final shutdown tasks (closing all open sockets, for example).
As discussed in "`<<jmx-mbean-shutdown>>`", this operation can be invoked by using JMX.
As discussed in <<jmx-mbean-shutdown>>, this operation can be invoked by using JMX.
If you wish to programmatically invoke the method, you need to inject or otherwise get a reference to the `IntegrationMBeanExporter`.
If no `id` attribute is provided on the `<int-jmx:mbean-export/>` definition, the bean has a generated name.
This name contains a random component to avoid `ObjectName` collisions if multiple Spring Integration contexts exist in the same JVM (`MBeanServer`).

2
src/reference/asciidoc/spel.adoc
View File

@@ -159,7 +159,7 @@ Otherwise the `#jsonPath` SpEL function is not registered.
For more information regarding JSON see 'JSON Transformers' in <<transformer>>.
* `#xpath`: To evaluate an 'xpath' on some provided object.
For more information regarding XML and XPath, see "`<<xml>>`".
For more information regarding XML and XPath, see <<xml>>.
[[spel-property-accessors]]
=== Property Accessors

4
src/reference/asciidoc/splitter.adoc
View File

@@ -134,6 +134,6 @@ List<LineItem> extractItems(Order order) {
----
====
See also "`<<advising-with-annotations>>`".
See also <<advising-with-annotations>>.
See also "`<<java-dsl-splitters>>`" in the Java DSL chapter.
See also <<java-dsl-splitters>> in the Java DSL chapter.

10
src/reference/asciidoc/stomp.adoc
View File

@@ -35,7 +35,7 @@ See `StompSessionManager` (and its implementations) JavaDocs for more informatio
The `StompInboundChannelAdapter` is a one-stop `MessageProducer` component that subscribes your Spring Integration application to the provided STOMP destinations and receives messages from them (converted from the STOMP frames by using the provided `MessageConverter` on the connected `StompSession`).
You can change the destinations (and therefore STOMP subscriptions) at runtime by using appropriate `@ManagedOperation` annotations on the `StompInboundChannelAdapter`.
For more configuration options, see "`<<stomp-namespace>>`" and the `StompInboundChannelAdapter` https://docs.spring.io/spring-integration/api/org/springframework/integration/stomp/inbound/StompInboundChannelAdapter.html[Javadoc].
For more configuration options, see <<stomp-namespace>> and the `StompInboundChannelAdapter` https://docs.spring.io/spring-integration/api/org/springframework/integration/stomp/inbound/StompInboundChannelAdapter.html[Javadoc].
[[stomp-outbound-adapter]]
=== STOMP Outbound Channel Adapter
@@ -43,7 +43,7 @@ For more configuration options, see "`<<stomp-namespace>>`" and the `StompInboun
The `StompMessageHandler` is the `MessageHandler` for the `<int-stomp:outbound-channel-adapter>` and is used
to send the outgoing `Message<?>` instances to the STOMP `destination` (pre-configured or determined at runtime with a SpEL expression) through the `StompSession` (which is provided by the shared `StompSessionManager`).
For more configuration options see "`<<stomp-namespace>>`" and the `StompMessageHandler` https://docs.spring.io/spring-integration/api/org/springframework/integration/stomp/outbound/StompMessageHandler.html[Javadoc].
For more configuration options see <<stomp-namespace>> and the `StompMessageHandler` https://docs.spring.io/spring-integration/api/org/springframework/integration/stomp/outbound/StompMessageHandler.html[Javadoc].
[[stomp-headers]]
=== STOMP Headers Mapping
@@ -74,7 +74,7 @@ As with many other Spring Integration modules, the `IntegrationStompHeaders` cla
In addition, all `MessageHeaders` instances with that prefix are mapped to the `StompHeaders` when sending to a destination.
For more information, see the https://docs.spring.io/spring-integration/api/[Javadoc] for those classes and the `mapped-headers` attribute description in the
"`<<stomp-namespace>>`".
<<stomp-namespace>>.
[[stomp-events]]
=== STOMP Integration Events
@@ -82,7 +82,7 @@ For more information, see the https://docs.spring.io/spring-integration/api/[Jav
Many STOMP operations are asynchronous, including error handling.
For example, STOMP has a `RECEIPT` server frame that it returns when a client frame has requested one by adding
the `RECEIPT` header.
To provide access to these asynchronous events, Spring Integration emits `StompIntegrationEvent` instances, which you can obtain by implementing an `ApplicationListener` or by using an `<int-event:inbound-channel-adapter>` (see "`<<appevent-inbound>>`").
To provide access to these asynchronous events, Spring Integration emits `StompIntegrationEvent` instances, which you can obtain by implementing an `ApplicationListener` or by using an `<int-event:inbound-channel-adapter>` (see <<appevent-inbound>>).
Specifically, a `StompExceptionEvent` is emitted from the `AbstractStompSessionManager` when a
`stompSessionListenableFuture` receives `onFailure()` due to failure to connect to STOMP broker.
@@ -96,7 +96,7 @@ It defaults to `15 * 1000` (in milliseconds, so 15 seconds).
NOTE: The `StompSession.Receiptable` callbacks are added only if the `RECEIPT` STOMP header of the message to send is not `null`.
You can enable automatic `RECEIPT` header generation on the `StompSession` through its `autoReceipt` option and on the `StompSessionManager` respectively.
See "`<<stomp-java-config>>`" for more information how to configure Spring Integration to accept those `ApplicationEvent` instances.
See <<stomp-java-config>> for more information how to configure Spring Integration to accept those `ApplicationEvent` instances.
[[stomp-java-config]]
=== STOMP Adapters Java Configuration

4
src/reference/asciidoc/stream.adoc
View File

@@ -84,7 +84,7 @@ public static final CharacterStreamReadingMessageSource stdinPipe(String charset
For target streams, you can use either of two implementations: `ByteStreamWritingMessageHandler` or `CharacterStreamWritingMessageHandler`.
Each requires a single constructor argument (`OutputStream` for byte streams or `Writer` for character streams), and each provides a second constructor that adds the optional 'bufferSize'.
Since both of these ultimately implement the `MessageHandler` interface, you can reference them from a `channel-adapter` configuration, as described in "`<<channel-adapter>>`".
Since both of these ultimately implement the `MessageHandler` interface, you can reference them from a `channel-adapter` configuration, as described in <<channel-adapter>>.
====
[source,xml]
@@ -132,7 +132,7 @@ The following code snippet shows the different configuration options that are su
====
Starting with version 5.0, you can set the `detect-eof` attribute, which sets the `blockToDetectEOF` property.
See "`<<stream-reading>>`" for more information.
See <<stream-reading>> for more information.
To configure the outbound channel adapter, you can use the namespace support as well.
The following example shows the different configuration for an outbound channel adapters:

4
src/reference/asciidoc/syslog.adoc
View File

@@ -93,7 +93,7 @@ The following example shows a `UDP` adapter that sends messages to channel `from
The preceding example also shows two `SmartLifecycle` attributes: `auto-startup` and `phase`.
It has a reference to a custom `org.springframework.integration.syslog.MessageConverter` with an ID of `converter` and an `error-channel`.
Also notice the `udp-attributes` child element.
You can set various UDP attributes here, as defined in "`<<ip-udp-ib-atts>>`".
You can set various UDP attributes here, as defined in <<ip-udp-ib-atts>>.
NOTE: When you use the `udp-attributes` element, you must provide the `port` attribute there rather than on the `inbound-channel-adapter` element itself.
@@ -112,7 +112,7 @@ The following example shows a `TCP` adapter that sends messages to channel `from
====
It also shows how to reference an externally defined connection factory, which can be used for advanced configuration (socket keep-alive and other uses).
For more information, see "`<<tcp-connection-factories>>`".
For more information, see <<tcp-connection-factories>>.
NOTE: The externally configured `connection-factory` must be of type `server`, and the port is defined there rather than on the `inbound-channel-adapter` element itself.

8
src/reference/asciidoc/transactions.adoc
View File

@@ -93,11 +93,11 @@ Internally, the process is wrapped in Spring's native transaction, where `Transa
For more information on how to configure a transaction manager, the types of transaction managers (such as JTA, Datasource, and others), and other details related to transaction configuration, see the https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction[Spring Framework Reference Guide].
With the preceding configuration, all message flows initiated by this poller are transactional.
For more information and details on a poller's transactional configuration, see "`<<jdbc-polling-transactions>>`".
For more information and details on a poller's transactional configuration, see <<jdbc-polling-transactions>>.
Along with transactions, you might need to address several more cross-cutting concerns when you run a poller.
To help with that, the poller element accepts an `<advice-chain>` child element, which lets you define a custom chain of advice instances to be applied on the Poller.
(See "`<<pollable-message-source>>`" for more details.)
(See <<pollable-message-source>> for more details.)
In Spring Integration 2.0, the Poller went through a refactoring effort and now uses a proxy mechanism to address transactional concerns as well as other cross-cutting concerns.
One of the significant changes evolving from this effort is that we made the `<transactional>` and `<advice-chain>` elements be mutually exclusive.
The rationale behind this is that, if you need more than one advice and one of them is Transaction advice, you can include it in the `<advice-chain>` with the same convenience as before but with much more control, since you now have an option to position the advice in the desired order.
@@ -147,7 +147,7 @@ If the transaction commits, we might want to move the file to a `success` direct
Spring Integration 2.2 introduced the capability of synchronizing these operations with a transaction.
In addition, you can configure a `PseudoTransactionManager` if you do not have a 'real' transaction but still want to perform different actions on success or failure.
For more information, see "`<<pseudo-transactions>>`".
For more information, see <<pseudo-transactions>>.
The following listing shows the key strategy interfaces for this feature:
@@ -233,7 +233,7 @@ In that case, if the evaluation (or downstream processing) throws an exception,
[[pseudo-transactions]]
=== Pseudo Transactions
After reading the "`<<transaction-synchronization>>`" section, you might think it would be useful to take these 'success' or 'failure' actions when a flow completes, even if there is no "`real`" transactional resources (such as JDBC) downstream of the poller.
After reading the <<transaction-synchronization>> section, you might think it would be useful to take these 'success' or 'failure' actions when a flow completes, even if there is no "`real`" transactional resources (such as JDBC) downstream of the poller.
For example, consider a "`<file:inbound-channel-adapter/>`" followed by an "`<ftp:outbout-channel-adapter/>`".
Neither of these components is transactional, but we might want to move the input file to different directories, based on the success or failure of the FTP transfer.

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

@@ -12,14 +12,14 @@ The rest of this chapter describes these configuration options.
NOTE: For the sake of maximizing flexibility, Spring does not require XML-based message payloads.
Nevertheless, the framework does provide some convenient transformers for dealing with XML-based payloads if that is indeed the right choice for your application.
For more information on those transformers, see "`<<xml>>`".
For more information on those transformers, see <<xml>>.
[[transformer-namespace]]
==== Configuring a Transformer with XML
The `<transformer>` element is used to create a message-transforming endpoint.
In addition to `input-channel` and `output-channel` attributes, it requires a ` attribute`.
The `ref` may either point to an object that contains the `@Transformer` annotation on a single method (see "`<<transformer-annotation>>`"), or it may be combined with an explicit method name value provided in the `method` attribute.
The `ref` may either point to an object that contains the `@Transformer` annotation on a single method (see <<transformer-annotation>>), or it may be combined with an explicit method name value provided in the `method` attribute.
====
[source,xml]
@@ -99,7 +99,7 @@ That works fine as long as the result of the `toString()` call is what you want
Otherwise, you can provide a custom POJO-based transformer by using the generic 'transformer' element shown previously.
TIP: When debugging, this transformer is not typically necessary, since the 'logging-channel-adapter' is capable of logging the message payload.
See "`<<channel-wiretap>>`" for more detail.
See <<channel-wiretap>> for more detail.
[NOTE]
====
@@ -269,7 +269,7 @@ Also, if you use the 'ref' attribute, you must point to a 'prototype' scoped bea
Otherwise, a `BeanCreationException` is thrown. 
Starting with version 5.0, you can supply the `ObjectToMapTransformer` with a customized `JsonObjectMapper` -- for when you need special formats for dates or nulls for empty collections (and other uses).
See "`<<json-transformers>>`" for more information about `JsonObjectMapper` implementations.
See <<json-transformers>> for more information about `JsonObjectMapper` implementations.
[[stream-transformer]]
===== Stream Transformer
@@ -430,17 +430,17 @@ Where both adapters are configured with a `SimpleMessageConverter`.
NOTE: When using the headers to determine the type, you should not provide a `class` attribute, because it takes precedence over the headers.
In addition to JSON Transformers, Spring Integration provides a built-in `#jsonPath` SpEL function for use in expressions.
For more information see "`<<spel>>`".
For more information see <<spel>>.
[[transformer-xpath-spel-function]]
Since version 3.0, Spring Integration also provides a built-in `#xpath` SpEL function for use in expressions.
For more information see "`<<xpath-spel-function>>`".
For more information see <<xpath-spel-function>>.
Beginning with version 4.0, the `ObjectToJsonTransformer` supports the `resultType` property, to specify the node JSON representation.
The result node tree representation depends on the implementation of the provided `JsonObjectMapper`.
By default, the `ObjectToJsonTransformer` uses a `Jackson2JsonObjectMapper` and delegates the conversion of the object to the node tree to the `ObjectMapper#valueToTree` method.
The node JSON representation provides efficiency for using the `JsonPropertyAccessor` when the downstream message flow uses SpEL expressions with access to the properties of the JSON data.
See "`<<spel-property-accessors>>`" for more information.
See <<spel-property-accessors>> for more information.
When using Boon, the `NODE` representation is a `Map<String, Object>`
Beginning with version 5.1, the `resultType` can be configured as `BYTES` to produce a message with the `byte[]` payload for convenience when working with downstream handlers which operate with this data type.
@@ -475,7 +475,7 @@ Order generateOrder(String productId, @Header("customerName") String customer) {
----
====
See also "`<<advising-with-annotations>>`".
See also <<advising-with-annotations>>.
[[header-filter]]
==== Header Filter
@@ -483,7 +483,7 @@ See also "`<<advising-with-annotations>>`".
Sometimes, your transformation use case might be as simple as removing a few headers.
For such a use case, Spring Integration provides a header filter that lets you specify certain header names that should be removed from the output message (for example, removing headers for security reasons or a value that was needed only temporarily).
Basically, the header filter is the opposite of the header enricher.
The latter is discussed in "`<<header-enricher>>`".
The latter is discussed in <<header-enricher>>.
The following example defines a header filter:
====
@@ -502,4 +502,4 @@ So, in the preceding example, the headers named 'lastName' and 'state' are not p
==== Codec-Based Transformers
See "`<<codec>>`".
See <<codec>>.

2
src/reference/asciidoc/web-sockets.adoc
View File

@@ -93,7 +93,7 @@ NOTE: Spring's WebSocket Support allows the configuration of only one broker rel
Consequently, we do not require an `AbstractBrokerMessageHandler` reference.
It is detected in the Application Context.
For more configuration options, see "`<<web-sockets-namespace>>`".
For more configuration options, see <<web-sockets-namespace>>.
[[web-socket-outbound-adapter]]
=== WebSocket Outbound Channel Adapter

8
src/reference/asciidoc/webflux.adoc
View File

@@ -4,7 +4,7 @@
The WebFlux Spring Integration module (`spring-integration-webflux`) allows for the execution of HTTP requests and the processing of inbound HTTP requests in a reactive manner.
The WebFlux support consists of the following gateway implementations: `WebFluxInboundEndpoint` and `WebFluxRequestExecutingMessageHandler`.
The support is fully based on the Spring https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#spring-webflux[WebFlux] and https://projectreactor.io/[Project Reactor] foundations.
See "`<<http>>`" for more information, since many options are shared between reactive and regular HTTP components.
See <<http>> for more information, since many options are shared between reactive and regular HTTP components.
[[webflux-inbound]]
=== WebFlux Inbound Components
@@ -64,7 +64,7 @@ public IntegrationFlow sseFlow() {
----
====
See "`<<http-request-mapping>>`" and "`<<http-cors>>`" for more possible configuration options.
See <<http-request-mapping>> and <<http-cors>> for more possible configuration options.
When the request body is empty or `payloadExpression` returns `null`, the request params (`MultiValueMap<String, String>`) is used for a `payload` of the target message to process.
@@ -115,7 +115,7 @@ In addition a `BodyExtractor<?, ClientHttpResponse>` can be injected into the `W
It can be used for low-level access to the `ClientHttpResponse` and more control over body and HTTP headers conversion.
Spring Integration provides `ClientHttpResponseBodyExtractor` as a identity function to produce (downstream) the whole `ClientHttpResponse` and any other possible custom logic.
See "`<<http-outbound>>`" for more possible configuration options.
See <<http-outbound>> for more possible configuration options.
[[webflux-namespace]]
=== WebFlux Namespace Support
@@ -310,4 +310,4 @@ public IntegrationFlow outboundReactive() {
=== WebFlux Header Mappings
Since WebFlux components are fully based on the HTTP protocol, there is no difference in the HTTP headers mapping.
See "`<<http-header-mapping>>`" for more possible options and components to use for mapping headers.
See <<http-header-mapping>> for more possible options and components to use for mapping headers.

15
src/reference/asciidoc/whats-new.adoc
View File

@@ -21,7 +21,7 @@ See <<amqp-strict-ordering>>.
[[x5.1-general]]
=== General Changes
The following general changes have been made in version 5.1:
The following changes have been made in version 5.1:
* <<x5.1-java-dsl>>
* <<x5.1-dispatcher-exceptions>>
@@ -62,7 +62,7 @@ Previously, when beans were created after the application context was refreshed,
A new `ResultType.BYTES` mode is introduced for the `ObjectToJsonTransformer`.
See "`<<json-transformers>>`" for more information.
See <<json-transformers>> for more information.
[[x5.1-integration-flows-generated-bean-names]]
==== Integration Flows: Generated Bean Names
@@ -90,10 +90,10 @@ See "`<<publisher-annotation>>`" for more information.
=== AMQP Changes
We have made `ID` and `Timestamp` header mapping changes in the `DefaultAmqpHeaderMapper`.
See the note near the bottom of "`<<amqp-message-headers>>`" for more information.
See the note near the bottom of <<amqp-message-headers>> for more information.
The `contentType` header is now correctly mapped as an entry in the general headers map.
See "`<<amqp-content-type>>`" for more information.
See <<amqp-content-type>> for more information.
[[x5.1-jdbc]]
=== JDBC Changes
@@ -109,12 +109,13 @@ A `RotatingServerAdvice` is now available to poll multiple servers and directori
See <<ftp-rotating-server-advice>> and <<sftp-rotating-server-advice>> for more information.
Also, inbound adapter `localFilenameExpression` instances can contain the `#remoteDirectory` variable, which contains the remote directory being polled.
The generic type of the comparators, used to sort the fetched file list for the streaming adapters, has changed from `Comparator<AbstractFileInfo<F>>` to simply `Comparator<F>`.
The generic type of the comparators (used to sort the fetched file list for the streaming adapters) has changed from `Comparator<AbstractFileInfo<F>>` to `Comparator<F>`.
See <<ftp-streaming>> and <<sftp-streaming>> for more information.
In addition, the synchronizers for inbound channel adapters can now be provided with a `Comparator`; this is useful when using `maxFetchSize` to limit the files retrieved.
In addition, the synchronizers for inbound channel adapters can now be provided with a `Comparator`.
This is useful when using `maxFetchSize` to limit the files retrieved.
==== Twitter Support
Since the Spring Social project has moved to https://spring.io/blog/2018/07/03/spring-social-end-of-life-announcement[End of Life Status], Twitter support in Spring Integration has been moved to the Extensions project.
Since the Spring Social project has moved to https://spring.io/blog/2018/07/03/spring-social-end-of-life-announcement[end of life status], Twitter support in Spring Integration has been moved to the Extensions project.
See https://github.com/spring-projects/spring-integration-extensions/tree/master/spring-integration-social-twitter[Spring Integration Social Twitter] for more information.

16
src/reference/asciidoc/xml.adoc
View File

@@ -273,7 +273,7 @@ NOTE: If you do not explicitly set a `SourceFactory`, the property on the `Unmar
Starting with version 5.0, the `UnmarshallingTransformer` also supports an `org.springframework.ws.mime.MimeMessage` as the incoming payload.
This can be useful when we receive a raw `WebServiceMessage` with MTOM attachments over SOAP .
See "`<<mtom-support>>`" for more information.
See <<mtom-support>> for more information.
The following example shows how to define an unmarshalling transformer:
@@ -371,7 +371,7 @@ By default, if the input payload is an instance of `String` or http://docs.oracl
However, if the input payload is a http://docs.oracle.com/javase/6/docs/api/javax/xml/transform/Source.html[`Source`] or any other type, the `resultTransformer` property is applied.
Additionally, you can set the `alwaysUseResultFactory` property to `true`, which also causes the specified `resultTransformer` to be used.
For more information and examples, see "`<<xml-using-result-transformers-namespace>>`".
For more information and examples, see <<xml-using-result-transformers-namespace>>.
[[xml-transformer-namespace]]
==== Namespace Support for XML Transformers
@@ -490,7 +490,7 @@ Starting with Spring Integration 3.0, you can now specify the transformer factor
[[xml-using-result-transformers-namespace]]
==== Namespace Configuration and Result Transformers
We cover using result transformers in "`<<xml-using-result-transformers>>`".
We cover using result transformers in <<xml-using-result-transformers>>.
The examples in this section use XML namespace configuration to illustrates several special use cases.
First, we define the `ResultTransformer`, as the following example shows:
@@ -745,7 +745,7 @@ Starting with `version 4.2`, the `XPathMessageSplitter` exposes an `iterator` op
This allows the "`streaming`" of split nodes in the downstream flow.
With the `iterator` mode set to `true`, each node is transformed while iterating.
When `false`, all entries are first transformed, before the split nodes start being sent to the output channel. (You can think of the difference as "`transform, send, transform, send`" versus "`transform, transform, send, send`".)
See "`<<splitter>>`" for more information.
See <<splitter>> for more information.
[[xml-xpath-routing]]
=== Routing XML Messages with XPath
@@ -763,7 +763,7 @@ The following example shows how to create such a router:
----
====
NOTE: For an overview of attributes that are common among Routers, see "`<<router-common-parameters>>`".
NOTE: For an overview of attributes that are common among Routers, see <<router-common-parameters>>.
Internally, XPath expressions are evaluated as type `NODESET` and converted to a `List<String>` that represents channel names.
Typically, such a list contains a single channel name.
@@ -914,7 +914,7 @@ Optional.
The result of the XPath evaluation is converted to this type by `ConversionService`.
This allows, for example, a `NUMBER_RESULT` (a double) to be converted to an `Integer`.
The type can be declared as a primitive (such as `int`), but the result is always the equivalent wrapper class (such as `Integer`).
The same integration `ConversionService` discussed in "`<<payload-type-conversion>>`" is used for the conversion, so conversion to custom types is supported by adding a custom converter to the service.
The same integration `ConversionService` discussed in <<payload-type-conversion>> is used for the conversion, so conversion to custom types is supported by adding a custom converter to the service.
Optional.
<10> Boolean value to indicate whether this header value should overwrite an existing header value for the same name if already present on the input `Message`.
<11> The XPath expression as a `String`.
@@ -929,7 +929,7 @@ You must set either this attribute or `xpath-expression`, but not both.
This component defines an XPath-based message filter.
Internally, this components uses a `MessageFilter` that wraps an instance of `AbstractXPathMessageSelector`.
NOTE: See "`<<filter>>`" for further details.
NOTE: See <<filter>> for further details.
to use the XPath filter you must, at a minimum, provide an XPath expression either by declaring the `xpath-expression` element or by referencing an XPath Expression in the `xpath-expression-ref` attribute.
@@ -1022,7 +1022,7 @@ By default, the `#xpath` SpEL function returns a `String` representation of the
NOTE: To enable the `#xpath` SpEL function, you can add the `spring-integration-xml.jar` to the classpath.
You need no declare any components from the Spring Integration XML Namespace.
For more information, see "`<<spel>>`".
For more information, see "`<<spel>>.
[[xml-validating-filter]]
=== XML Validating Filter

4
src/reference/asciidoc/xmpp.adoc
View File

@@ -444,6 +444,4 @@ smackMessage.addExtension(packetExtension);
----
====
See "<<xmpp-message-inbound-channel-adapter>>" and "<<xmpp-message-outbound-channel-adapter>>" earlier in this chapter for more information.
====
See <<xmpp-message-inbound-channel-adapter>> and <<xmpp-message-outbound-channel-adapter>> earlier in this chapter for more information.

4
src/reference/asciidoc/zookeeper.adoc
View File

@@ -11,7 +11,7 @@ Version 4.2 added https://zookeeper.apache.org/[Zookeeper] support to the framew
=== Zookeeper Metadata Store
You ca use the `ZookeeperMetadataStore` where any `MetadataStore` is needed, such as for persistent file list filters.
See "`<<metadata-store>>`" for more information.
See <<metadata-store>> for more information.
The following example configures a Zookeeper metadata store with XML:
====
@@ -82,7 +82,7 @@ When a leader is elected, an `OnGrantedEvent` is published for the role `cluster
Any endpoints in that role are started.
When leadership is revoked, an `OnRevokedEvent` is published for the role `cluster`.
Any endpoints in that role are stopped.
See "`<<endpoint-roles>>`" for more information.
See <<endpoint-roles>> for more information.
You can use Java configuration to create an instance of the leader initiator, as the following example shows: