Add Multi-Page HTML Reference
- to avoid having to load the whole document - provide a link to the single page version for browser search * Fix cross-document links. Links need to be qualified with the containing file name for the multi-page html doc.
This commit is contained in:
committed by
Artem Bilan
parent
d7fa60922b
commit
9fa9d1b3d0
69
build.gradle
69
build.gradle
@@ -6,6 +6,7 @@ buildscript {
|
||||
dependencies {
|
||||
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlinVersion"
|
||||
classpath "org.jetbrains.kotlin:kotlin-allopen:$kotlinVersion"
|
||||
classpath "org.asciidoctor:asciidoctor-gradle-plugin:1.5.6"
|
||||
classpath 'org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.16'
|
||||
}
|
||||
}
|
||||
@@ -819,6 +820,12 @@ project("spring-integration-bom") {
|
||||
}
|
||||
}
|
||||
|
||||
apply plugin: "org.asciidoctor.convert"
|
||||
|
||||
asciidoctorj {
|
||||
version = '1.5.5'
|
||||
}
|
||||
|
||||
configurations {
|
||||
docs
|
||||
}
|
||||
@@ -836,33 +843,52 @@ task prepareAsciidocBuild(type: Sync) {
|
||||
into "$buildDir/asciidoc"
|
||||
}
|
||||
|
||||
asciidoctor {
|
||||
dependsOn 'prepareAsciidocBuild'
|
||||
task('makePDF', type: org.asciidoctor.gradle.AsciidoctorTask) {
|
||||
dependsOn prepareAsciidocBuild
|
||||
backends 'pdf'
|
||||
sourceDir "$buildDir/asciidoc"
|
||||
sources {
|
||||
include 'index.adoc'
|
||||
include 'index-single.adoc'
|
||||
}
|
||||
options doctype: 'book', eruby: 'erubis'
|
||||
logDocuments = true
|
||||
attributes 'icons': 'font',
|
||||
'sectanchors': '',
|
||||
'sectnums': '',
|
||||
'toc': '',
|
||||
'source-highlighter' : 'coderay',
|
||||
revnumber: project.version
|
||||
}
|
||||
|
||||
asciidoctor {
|
||||
dependsOn makePDF
|
||||
backends 'html5'
|
||||
sourceDir "$buildDir/asciidoc"
|
||||
resources {
|
||||
from(sourceDir) {
|
||||
include 'images/*', 'css/*', 'js/**'
|
||||
include 'images/*', 'css/**', 'js/**'
|
||||
}
|
||||
}
|
||||
backends = ['html5', 'pdf']
|
||||
options doctype: 'book', eruby: 'erubis'
|
||||
attributes 'icons': 'font',
|
||||
'idprefix': '',
|
||||
'idseparator': '-',
|
||||
docinfo: 'shared',
|
||||
sectanchors: '',
|
||||
sectnums: '',
|
||||
stylesdir: 'css/',
|
||||
stylesheet: 'spring.css',
|
||||
'linkcss': true,
|
||||
'source-highlighter=highlight.js',
|
||||
'highlightjsdir=js/highlight',
|
||||
'highlightjs-theme=atom-one-dark-reasonable',
|
||||
'project-version': project.version,
|
||||
'allow-uri-read': ''
|
||||
logDocuments = true
|
||||
attributes 'docinfo': 'shared',
|
||||
// use provided stylesheet
|
||||
stylesdir: "css/",
|
||||
stylesheet: 'spring.css',
|
||||
'linkcss': true,
|
||||
'icons': 'font',
|
||||
'sectanchors': '',
|
||||
// use provided highlighter
|
||||
'source-highlighter=highlight.js',
|
||||
'highlightjsdir=js/highlight',
|
||||
'highlightjs-theme=atom-one-dark-reasonable',
|
||||
'idprefix': '',
|
||||
'idseparator': '-',
|
||||
'spring-version': project.version,
|
||||
'allow-uri-read': '',
|
||||
'toc': 'left',
|
||||
'toclevbels': '4',
|
||||
revnumber: project.version
|
||||
}
|
||||
|
||||
task reference(dependsOn: asciidoctor) {
|
||||
@@ -953,8 +979,9 @@ task docsZip(type: Zip, dependsOn: reference) {
|
||||
}
|
||||
|
||||
from ('build/asciidoc/pdf') {
|
||||
include 'index.pdf'
|
||||
into 'reference/pdf'
|
||||
include "index-single.pdf"
|
||||
rename 'index-single.pdf', 'spring-integration-reference.pdf'
|
||||
into 'reference/pdf'
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -108,7 +108,7 @@ It is done only if the message group release result is not a message or collecti
|
||||
In that case a target `MessageGroupProcessor` is responsible for the `MessageBuilder.popSequenceDetails()` call while building those messages.
|
||||
This functionality can be controlled by a new `popSequence` `boolean` property, so the `MessageBuilder.popSequenceDetails()` can be disabled in some scenarios when correlation details have not been populated by the standard splitter.
|
||||
This property, essentially, undoes what has been done by the nearest upstream `applySequence = true` in the `AbstractMessageSplitter`.
|
||||
See <<splitter>> for more information.
|
||||
See <<./splitter.adoc#splitter,Splitter>> for more information.
|
||||
|
||||
[[agg-message-collection]]
|
||||
IMPORTANT: The `SimpleMessageGroup.getMessages()` method returns an `unmodifiableCollection`.
|
||||
@@ -223,7 +223,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-store.adoc#message-group-factory,Using `MessageGroupFactory`>>, 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`:
|
||||
@@ -324,7 +324,7 @@ Of course, the first solution above does not apply in this case.
|
||||
[[aggregator-java-dsl]]
|
||||
==== Configuring an Aggregator in Java DSL
|
||||
|
||||
See <<java-dsl-aggregators>> for how to configure an aggregator in Java DSL.
|
||||
See <<./dsl.adoc#java-dsl-aggregators,Aggregators and Resequencers>> for how to configure an aggregator in Java DSL.
|
||||
|
||||
[[aggregator-xml]]
|
||||
===== Configuring an Aggregator with XML
|
||||
@@ -399,7 +399,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.adoc#message-store,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)`]).
|
||||
@@ -457,7 +457,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.adoc#redis-lock-registry,Redis Lock Registry>>, <<./gemfire.adoc#gemfire-lock-registry,Gemfire Lock Registry>>, and <<./zookeeper.adoc#zk-lock-registry,Zookeeper 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.
|
||||
@@ -750,7 +750,7 @@ public MessageHandler aggregator(MessageGroupStore jdbcMessageGroupStore) {
|
||||
----
|
||||
====
|
||||
|
||||
See <<aggregator-api>> and <<annotations_on_beans>> for more information.
|
||||
See <<aggregator-api>> and <<./configuration.adoc#annotations_on_beans,Annotations on `@Bean` Methods>> for more information.
|
||||
|
||||
NOTE: Starting with version 4.2, the `AggregatorFactoryBean` is available to simplify Java configuration for the `AggregatingMessageHandler`.
|
||||
|
||||
@@ -863,5 +863,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.adoc#message-store,Message Store>>.
|
||||
=====
|
||||
|
||||
@@ -294,7 +294,7 @@ The default `BatchingStrategy` is the `SimpleBatchingStrategy`, but this can be
|
||||
==== Overview
|
||||
|
||||
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 <<./polling-consumer.adoc#deferred-acks-message-source,Deferred Acknowledgment Pollable Message Source>> for more information.
|
||||
|
||||
It does not currently support XML configuration.
|
||||
|
||||
@@ -1036,7 +1036,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 <<./service-activator.adoc#async-service-activator,Asynchronous Service Activator>> for more information.
|
||||
|
||||
[IMPORTANT]
|
||||
.RabbitTemplate
|
||||
@@ -1492,7 +1492,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 <<./handler-advice.adoc#handle-message-advice,Handling 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`:
|
||||
|
||||
|
||||
@@ -121,7 +121,7 @@ In this case, it is 'somethingChain$child#1'.
|
||||
Note, this transformer is not registered as a bean within the application context, so it does not get a `beanName`.
|
||||
However its `componentName` has a value that is useful for logging and other purposes.
|
||||
|
||||
The `id` attribute for `<chain>` elements lets them be eligible for <<jmx-mbean-exporter,JMX export>>, and they are trackable in the <<message-history,message history>>.
|
||||
The `id` attribute for `<chain>` elements lets them be eligible for <<./jmx.adoc#jmx-mbean-exporter,,JMX export>>, and they are trackable in the <<./message-history.adoc#message-history,,message history>>.
|
||||
You can access them from the `BeanFactory` by using the appropriate bean name, as discussed earlier.
|
||||
|
||||
TIP: It is useful to provide an explicit `id` attribute on `<chain>` elements to simplify the identification of sub-components in logs and to provide access to them from the `BeanFactory` etc.
|
||||
|
||||
@@ -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 https://www.enterpriseintegrationpatterns.com/DatatypeChannel.html[Datatype channel].
|
||||
See <<channel-implementations>> and <<service-activator>>.
|
||||
See <<./channel.adoc#channel-implementations,Message Channel Implementations>> and <<./service-activator.adoc#service-activator,Service Activator>>.
|
||||
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.adoc#channel-adapter,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.adoc#http-outbound,HTTP Outbound Components>> 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 https://www.enterpriseintegrationpatterns.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.adoc#message-history,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 https://www.enterpriseintegrationpatterns.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.adoc#message-store,Message Store>>, <<./claim-check.adoc#claim-check,Claim Check>>, <<./channel.adoc#channel,Message Channels>>, <<./aggregator.adoc#aggregator,Aggregator>>, <<./jdbc.adoc#jdbc,JDBC Support>>`", and <<./resequencer.adoc#resequencer,Resequencer>> for more details.
|
||||
|
||||
[[new-claim-check]]
|
||||
===== Claim Check
|
||||
@@ -64,14 +64,14 @@ See <<message-store>>, <<claim-check>>, <<channel>>, <<aggregator>>, <<jdbc>>`",
|
||||
We have added an implementation of the https://www.enterpriseintegrationpatterns.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.adoc#claim-check,Claim Check>> for more details.
|
||||
|
||||
[[new-control-bus]]
|
||||
===== Control Bus
|
||||
|
||||
We have provided implementations of the https://www.enterpriseintegrationpatterns.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.adoc#control-bus,Control Bus>> and <<./groovy.adoc#groovy-control-bus,Control Bus>> for more details.
|
||||
|
||||
[[new-adapters]]
|
||||
==== New Channel Adapters and Gateways
|
||||
@@ -82,7 +82,7 @@ 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.adoc#ip,TCP and UDP Support>> for more details.
|
||||
See also the following blog: https://spring.io/blog/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]]
|
||||
@@ -96,25 +96,25 @@ See https://github.com/spring-projects/spring-integration-extensions/tree/master
|
||||
===== XMPP Adapters
|
||||
|
||||
The new XMPP adapters support both chat messages and presence events.
|
||||
See <<xmpp>> for more details.
|
||||
See <<./xmpp.adoc#xmpp,XMPP Support>> 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.adoc#ftp,FTP/FTPS Adapters>> 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.adoc#sftp,SFTP Adapters>> 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.adoc#feed,Feed Adapter>> for more details.
|
||||
|
||||
[[new-other]]
|
||||
==== Other Additions
|
||||
@@ -125,33 +125,33 @@ 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.adoc#groovy,Groovy support>> 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.adoc#transformer,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.adoc#transformer,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.adoc#transformer,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 <<./router.adoc#dynamic-routers,Dynamic Routers>>, <<./gateway.adoc#gateway,Messaging Gateways>>, <<./http.adoc#http-outbound,HTTP Outbound Components>>, <<./message.adoc#message,Message>>, and <<./aggregator.adoc#aggregator,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`").
|
||||
|
||||
|
||||
@@ -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.adoc#scripting,Scripting Support>>.
|
||||
|
||||
[[x2.1-new-gemfire-support]]
|
||||
===== GemFire Support
|
||||
@@ -28,7 +28,7 @@ For further details, see <<scripting>>.
|
||||
Spring Integration provides support for https://www.vmware.com/products/pivotal-gemfire.html[GemFire] by providing inbound adapters for entry and continuous query events, an outbound adapter to write entries to the cache, and https://docs.spring.io/spring-integration/api/org/springframework/integration/store/MessageStore.html[`MessageStore`] and https://docs.spring.io/spring-integration/api/org/springframework/integration/store/MessageGroupStore.html[`MessageGroupStore`] implementations.
|
||||
Spring integration leverages the https://spring.io/projects/spring-data-gemfire[Spring Gemfire] project, providing a thin wrapper over its components.
|
||||
|
||||
For further details, see <<gemfire>>.
|
||||
For further details, see <<./gemfire.adoc#gemfire,Pivotal GemFire and Apache Geode Support>>.
|
||||
|
||||
[[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 https://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.adoc#amqp,AMQP Support>>.
|
||||
|
||||
[[x2.1-new-mongodb-support]]
|
||||
===== MongoDB Support
|
||||
|
||||
As of version 2.1, Spring Integration provides support for https://www.mongodb.org/[MongoDB] by providing a MongoDB-based `MessageStore`.
|
||||
|
||||
For further details, see <<mongodb>>.
|
||||
For further details, see <<./mongodb.adoc#mongodb,MongoDb Support>>.
|
||||
|
||||
[[x2.1-new-redis-support]]
|
||||
===== Redis Support
|
||||
|
||||
As of version 2.1, Spring Integration supports https://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.adoc#redis,Redis Support>>.
|
||||
|
||||
[[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.adoc#resource-inbound-channel-adapter,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 <<./jdbc.adoc#stored-procedures,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.adoc#xml-xpath-filter,Using the XPath Filter>> and <<./xml.adoc#xml-validating-filter,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 https://docs.spring.io/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 <<./content-enrichment.adoc#payload-enricher,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.adoc#ftp-outbound-gateway,FTP Outbound Gateway>> and <<./sftp.adoc#sftp-outbound-gateway,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.adoc#ftp-session-caching,FTP Session Caching>> and <<./sftp.adoc#sftp-session-caching,SFTP Session Caching>>.
|
||||
|
||||
[[x2.1-framework-refactorings]]
|
||||
==== Framework Refactoring
|
||||
@@ -142,7 +142,7 @@ If, however, you do want to drop messages silently, you can set `default-output-
|
||||
|
||||
IMPORTANT: With the standardization of router parameters and the consolidation of the parameters described earlier, older Spring Integration based applications may break.
|
||||
|
||||
For further details, see `<<router>>`.
|
||||
For further details, see `<<./router.adoc#router,Routers>>`.
|
||||
|
||||
[[x2.1-schema-updated]]
|
||||
===== XML Schemas updated to 2.1
|
||||
|
||||
@@ -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.adoc#redis-store-outbound-channel-adapter,RedisStore Outbound Channel Adapter>> and <<./redis.adoc#redis-store-inbound-channel-adapter,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.adoc#mongodb-outbound-channel-adapter,MongoDB Outbound Channel Adapter>> and <<./mongodb.adoc#mongodb-inbound-channel-adapter,MongoDB Inbound Channel Adapter>>.
|
||||
|
||||
[[x2.2-jpa]]
|
||||
===== JPA Endpoints
|
||||
@@ -27,12 +27,12 @@ For more information, see <<mongodb-outbound-channel-adapter>> and <<mongodb-inb
|
||||
Spring Integration now includes components for the Java Persistence API (JPA) for retrieving and persisting JPA entity objects.
|
||||
The JPA Adapter includes the following components:
|
||||
|
||||
* <<jpa-inbound-channel-adapter,Inbound channel adapter>>
|
||||
* <<jpa-outbound-channel-adapter,Outbound channel adapter>>
|
||||
* <<jpa-updating-outbound-gateway,Updating outbound gateway>>
|
||||
* <<jpa-retrieving-outbound-gateway,Retrieving outbound gateway>>
|
||||
* <<./jpa.adoc#jpa-inbound-channel-adapter,,Inbound channel adapter>>
|
||||
* <<./jpa.adoc#jpa-outbound-channel-adapter,,Outbound channel adapter>>
|
||||
* <<./jpa.adoc#jpa-updating-outbound-gateway,,Updating outbound gateway>>
|
||||
* <<./jpa.adoc#jpa-retrieving-outbound-gateway,,Retrieving outbound gateway>>
|
||||
|
||||
For more information, see <<jpa>>.
|
||||
For more information, see <<./jpa.adoc#jpa,JPA Support>>.
|
||||
|
||||
[[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 <<./handler-advice.adoc#message-handler-advice-chain,Adding Behavior to Endpoints>>.
|
||||
|
||||
[[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 <<./transactions.adoc#transaction-synchronization,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.adoc#file-writing-destination-exists,Dealing with Existing Destination Files>>.
|
||||
|
||||
[[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 <<./jdbc.adoc#stored-procedures,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.adoc#jdbc-message-store-channels,Backing Message 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.adoc#transformer,Transformer>>.
|
||||
|
||||
[[httpChanges]]
|
||||
===== HTTP Support
|
||||
|
||||
@@ -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.adoc#http-namespace,HTTP Namespace Support>>.
|
||||
|
||||
[[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.adoc#spel,Spring Expression Language (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.adoc#spel-functions,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.adoc#spel-property-accessors,Property Accessors>>.
|
||||
|
||||
[[x3.0-redis-new-components]]
|
||||
===== Redis: New Components
|
||||
@@ -52,14 +52,14 @@ This new `MetadataStore` implementation can be used with adapters, such as:
|
||||
We added new queue-based components.
|
||||
We added the `<int-redis:queue-inbound-channel-adapter/>` and `<int-redis:queue-outbound-channel-adapter/>` components to perform 'right pop' and 'left push' operations, respectively, on a Redis List.
|
||||
|
||||
For more information, "`see <<redis>>`".
|
||||
For more information, "`see <<./redis.adoc#redis,Redis Support>>`".
|
||||
|
||||
[[x3.0-hcr]]
|
||||
===== Header Channel Registry
|
||||
|
||||
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 <<./content-enrichment.adoc#header-enricher,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.adoc#mongodb,MongoDb Support>> 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.adoc#syslog,Syslog Support>>.
|
||||
|
||||
[[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.adoc#file-tailing,'tail'ing Files>>.
|
||||
|
||||
[[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.adoc#jmx,JMX Support>>.
|
||||
|
||||
[[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 <<./ip.adoc#tcp-events,TCP Connection 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.adoc#channel-adapter-expressions-and-scripts,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 <<./content-enrichment.adoc#payload-enricher,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.adoc#message-id-generation,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.adoc#gateway,Messaging Gateways>>.
|
||||
|
||||
[[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.adoc#http,HTTP Support>>.
|
||||
|
||||
[[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.adoc#transformer,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.adoc#chain,Message Handler 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-xml>>.
|
||||
For more information, see <<./aggregator.adoc#aggregator-xml,Configuring an Aggregator with XML>>.
|
||||
|
||||
[[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.adoc#file-reading,Reading Files>>, <<./ftp.adoc#ftp-inbound,FTP Inbound Channel Adapter>>, and <<./sftp.adoc#sftp-inbound,SFTP Inbound Channel Adapter>> 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.adoc#groovy,Groovy support>> and <<./scripting.adoc#scripting,Scripting Support>> 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.adoc#channel-implementations-directchannel,`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.adoc#ftp,FTP/FTPS Adapters>> and <<./sftp.adoc#sftp,SFTP Adapters>>.
|
||||
|
||||
[[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 <<./jdbc.adoc#stored-procedures,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 <<./ws.adoc#outbound-uri,Outbound URI Configuration>>.
|
||||
|
||||
[[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.adoc#redis,Redis Support>>.
|
||||
|
||||
[[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 <<./handler-advice.adoc#advising-filters,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 <<./handler-advice.adoc#advising-with-annotations,Advising Endpoints Using 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.adoc#transformer,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.adoc#jpa-retrieving-outbound-gateway,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.adoc#jpa,JPA Support>>.
|
||||
|
||||
[[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.adoc#delayer,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.adoc#jdbc-message-store-generic,The Generic JDBC Message Store>>.
|
||||
|
||||
[[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.adoc#ip-headers,Transferring Headers>>.
|
||||
|
||||
[[x3.0-jms-mdca-te]]
|
||||
===== JMS Message Driven Channel Adapter
|
||||
@@ -421,10 +421,10 @@ 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.adoc#rmi-inbound,Inbound RMI>>.
|
||||
|
||||
[[x3.0-xslt-transformer]]
|
||||
===== `XsltPayloadTransformer`
|
||||
|
||||
You can now specify the transformer factory class name by setting the `transformer-factory-class` attribute.
|
||||
See `<<xml-xslt-payload-transformers>>`.
|
||||
See `<<./xml.adoc#xml-xslt-payload-transformers,XsltPayloadTransformer>>`.
|
||||
|
||||
@@ -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.adoc#mqtt,MQTT Support>>.
|
||||
|
||||
[[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 <<./configuration.adoc#annotations,Annotation Support>> 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 <<./configuration.adoc#annotations,Annotation Support>> 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.adoc#message-history,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 <<./gateway.adoc#messaging-gateway-annotation,`@MessagingGateway` Annotation>>.
|
||||
|
||||
[[x4.0-boot]]
|
||||
===== Spring Boot `@EnableAutoConfiguration`
|
||||
@@ -52,68 +52,68 @@ For more information, see https://docs.spring.io/spring-boot/docs/current/refere
|
||||
===== `@GlobalChannelInterceptor`
|
||||
|
||||
As well as the `@EnableIntegration` annotation mentioned above, we introduced the `@GlobalChannelInterceptor` annotation.
|
||||
For more information, see <<annotations>>.
|
||||
For more information, see <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
[[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 <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
[[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 <<./configuration.adoc#annotations,Annotation Support>> 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.adoc#redis-cms,Redis Channel Message Stores>>.
|
||||
|
||||
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.adoc#redis-cms,Redis Channel Message Stores>>.
|
||||
|
||||
[[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.adoc#mongodb-priority-channel-message-store,MongoDB 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.adoc#jmx-mbean-exporter,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.adoc#security,Security in Spring Integration>>.
|
||||
|
||||
[[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.adoc#redis-outbound-gateway,Redis Outbound Command 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.adoc#redis-lock-registry,Redis Lock Registry>>, <<./gemfire.adoc#gemfire-lock-registry,Gemfire Lock Registry>>, and <<./aggregator.adoc#aggregator,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 <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
[[x4.0-inbound-channel-adapter-annotation]]
|
||||
===== `@InboundChannelAdapter` and `SmartLifecycle` for Annotated Endpoints
|
||||
@@ -121,7 +121,7 @@ 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 <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
[[x4.0-twitter-sog]]
|
||||
===== Twitter Search Outbound Gateway
|
||||
@@ -134,20 +134,20 @@ For more information, see https://github.com/spring-projects/spring-integration-
|
||||
===== 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 <<./meta-data-store.adoc#metadata-store,Metadata Store>>, <<./file.adoc#file-reading,Reading Files>>, <<./ftp.adoc#ftp-inbound,FTP Inbound Channel Adapter>>, and <<./sftp.adoc#sftp-inbound,SFTP Inbound Channel Adapter>>.
|
||||
|
||||
[[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 <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
[[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 <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
[[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.adoc#xml-xpath-header-enricher,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.adoc#transformer-xpath-spel-function,Since version 3.0, Spring Integration also provides a built-in `#xpath` SpEL function for use in expressions.>>.
|
||||
|
||||
[[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.adoc#jms-header-mapping,Mapping Message Headers to and from JMS Message>>.
|
||||
|
||||
[[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.adoc#jms-outbound-channel-adapter,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.adoc#jms-inbound-channel-adapter,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.adoc#channel-datatype-channel,Datatype Channel Configuration>>.
|
||||
|
||||
[[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 <<./handler-advice.adoc#retry-config,Configuring the Retry Advice>>.
|
||||
|
||||
[[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-xml>>.
|
||||
For more information, see <<./aggregator.adoc#aggregator-xml,Configuring an Aggregator with XML>>.
|
||||
|
||||
[[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.adoc#redis-metadata-store,Redis Metadata Store>>, <<./file.adoc#file-reading,Reading Files>>, <<./ftp.adoc#ftp-inbound,FTP Inbound Channel Adapter>>, and <<./sftp.adoc#sftp-inbound,SFTP Inbound Channel Adapter>>.
|
||||
|
||||
[[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.adoc#jdbc-message-store-channels,Backing Message Channels>>.
|
||||
|
||||
[[x4.0-amqp]]
|
||||
===== AMQP Endpoints Delivery Mode
|
||||
@@ -234,14 +234,14 @@ 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.adoc#amqp-outbound-channel-adapter,Outbound Channel Adapter>> and <<./amqp.adoc#amqp-outbound-gateway,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.adoc#ftp-session-factory,FTP Session Factory>> for more information.
|
||||
|
||||
[[x4.0-twitter-status-updating]]
|
||||
===== Twitter: `StatusUpdatingMessageHandler`
|
||||
@@ -254,16 +254,16 @@ See https://github.com/spring-projects/spring-integration-extensions/tree/master
|
||||
===== 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.adoc#jpa-retrieving-outbound-gateway,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 <<./ip.adoc#tcp-events,TCP Connection 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 <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
@@ -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 <<./gateway.adoc#async-gateway,Asynchronous 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.adoc#web-sockets,WebSockets Support>> 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.adoc#scatter-gather,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 <<./router.adoc#routing-slip,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 <<./handler-advice.adoc#idempotent-receiver,Idempotent Receiver Enterprise Integration Pattern>> and the https://docs.spring.io/spring-integration/api/index.html[Javadoc] for more information.
|
||||
|
||||
[[x4.1-BoonJsonObjectMapper]]
|
||||
===== Boon `JsonObjectMapper`
|
||||
|
||||
We added the Boon `JsonObjectMapper` for the JSON transformers.
|
||||
See <<transformer>> for more information.
|
||||
See <<./transformer.adoc#transformer,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.adoc#redis-queue-inbound-gateway,Redis Queue Inbound Gateway>> and <<./redis.adoc#redis-queue-outbound-gateway,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.adoc#polling-consumer,Poller>> 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.adoc#amqp,AMQP Support>> 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.adoc#amqp,AMQP Support>> 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 <<./message-store.adoc#sms-caution,[WARNING]>> 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.adoc#http-namespace,HTTP Namespace Support>> 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.adoc#mqtt,MQTT Support>> 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.adoc#mqtt-inbound,Inbound (Message-driven) Channel Adapter>> 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.adoc#mqtt-outbound,Outbound Channel Adapter>> 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.adoc#mqtt-inbound,Inbound (Message-driven) Channel Adapter>> 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.adoc#ftp,FTP/FTPS Adapters>> and <<./sftp.adoc#sftp,SFTP Adapters>> 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.adoc#splitter,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.adoc#aggregator,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-enrichment.adoc#content-enricher,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-enrichment.adoc#content-enricher,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 <<./content-enrichment.adoc#header-channel-registry,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 <<./shutdown.adoc#jmx-shutdown,Orderly 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 <<./router.adoc#recipient-list-router-management,`RecipientListRouterManagement`>> 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.adoc#amqp-message-headers,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.adoc#amqp-channels,AMQP-backed Message 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.adoc#syslog-inbound-adapter,Syslog Inbound Channel 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 <<./gateway.adoc#async-gateway,Asynchronous 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-xml>> for more information.
|
||||
See <<./aggregator.adoc#aggregator-xml,Configuring an Aggregator with XML>> 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.adoc#groovy,Groovy support>> and <<./scripting.adoc#scripting,Scripting Support>>.
|
||||
|
||||
[[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.adoc#resequencer,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.adoc#service-activator-namespace,Configuring Service Activator>>.
|
||||
|
||||
[[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.adoc#channel-configuration-queuechannel,`QueueChannel` Configuration>>.
|
||||
|
||||
[[x4.1-channel-interceptor]]
|
||||
===== `ChannelInterceptor` Changes
|
||||
|
||||
The `ChannelInterceptor` now supports additional `afterSendCompletion()` and `afterReceiveCompletion()` methods.
|
||||
See <<channel-interceptors>>.
|
||||
See <<./channel.adoc#channel-interceptors,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 <<./mail.adoc#imap-peek,[IMPORTANT]>>.
|
||||
|
||||
@@ -5,48 +5,48 @@ See the https://github.com/spring-projects/spring-integration/wiki/Spring-Integr
|
||||
You can find migration guides for all versions back to 2.1 on the https://github.com/spring-projects/spring-integration/wiki[wiki].
|
||||
|
||||
[[x4.2-new-components]]
|
||||
=== New Components
|
||||
==== New Components
|
||||
|
||||
Version 4.2 added a number of new components.
|
||||
|
||||
[[x4.2-JMX]]
|
||||
==== Major Management/JMX Rework
|
||||
===== Major Management/JMX Rework
|
||||
|
||||
We added a new `MetricsFactory` strategy interface.
|
||||
This change, together with other changes in the JMX and management infrastructure, provides much more control over management configuration and runtime performance.
|
||||
|
||||
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.adoc#metrics-management,Metrics and Management>> and <<./jmx.adoc#jmx-42-improvements,JMX Improvements>>.
|
||||
|
||||
[[x4.2-mongodb-metadata-store]]
|
||||
==== MongoDB Metadata Store
|
||||
===== MongoDB Metadata Store
|
||||
|
||||
The `MongoDbMetadataStore` is now available.
|
||||
For more information, see <<mongodb-metadata-store>>.
|
||||
For more information, see <<./mongodb.adoc#mongodb-metadata-store,MongoDB Metadata Store>>.
|
||||
|
||||
[[x4.2-secured-channel-annotation]]
|
||||
==== SecuredChannel Annotation
|
||||
===== SecuredChannel Annotation
|
||||
|
||||
We introduced the `@SecuredChannel` annotation, replacing the deprecated `ChannelSecurityInterceptorFactoryBean`.
|
||||
For more information, see <<security>>.
|
||||
For more information, see <<./security.adoc#security,Security in Spring Integration>>.
|
||||
|
||||
[[x4.2-security-context-propagation]]
|
||||
==== `SecurityContext` 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.adoc#security,Security in Spring Integration>>.
|
||||
|
||||
|
||||
[[x4.2-file-splitter]]
|
||||
==== FileSplitter
|
||||
===== FileSplitter
|
||||
|
||||
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.adoc#file-splitter,File Splitter>> for more information.
|
||||
|
||||
[[x4.2-zk]]
|
||||
==== Zookeeper Support
|
||||
===== Zookeeper Support
|
||||
|
||||
We added Zookeeper support to the framework to assist when running on a clustered or multi-host environment.
|
||||
The change impacts the following features:
|
||||
@@ -55,144 +55,144 @@ The change impacts the following features:
|
||||
* `ZookeeperLockRegistry`
|
||||
* Zookeeper Leadership
|
||||
|
||||
See <<zookeeper>> for more information.
|
||||
See <<./zookeeper.adoc#zookeeper,Zookeeper Support>> for more information.
|
||||
|
||||
[[x4.2-barrier]]
|
||||
==== Thread 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.adoc#barrier,Thread Barrier>> for more information.
|
||||
|
||||
[[x4.2-stomp]]
|
||||
==== STOMP Support
|
||||
===== STOMP Support
|
||||
|
||||
We added STOMP support to the framework as an inbound and outbound channel adapters pair.
|
||||
See <<stomp>> for more information.
|
||||
See <<./stomp.adoc#stomp,STOMP Support>> for more information.
|
||||
|
||||
[[x4.2-codec]]
|
||||
==== 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.adoc#codec,Codec>> for more information.
|
||||
|
||||
[[x4.2-prepared-statement-setter]]
|
||||
==== Message PreparedStatement 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.adoc#jdbc-outbound-channel-adapter,Outbound Channel Adapter>> for more information.
|
||||
|
||||
[[x4.2-general]]
|
||||
=== General Changes
|
||||
==== General Changes
|
||||
|
||||
This section describes general changes from version 4.1 to version 4.2.
|
||||
|
||||
[[x4.2-wire-tap]]
|
||||
==== WireTap
|
||||
===== WireTap
|
||||
|
||||
As an alternative to the existing `selector` attribute, the `<wire-tap/>` element now supports the `selector-expression` attribute.
|
||||
|
||||
[[x4.2-file-changes]]
|
||||
==== File Changes
|
||||
===== File Changes
|
||||
|
||||
See <<files>> for more information about these changes.
|
||||
See <<./file.adoc#files,File Support>> for more information about these changes.
|
||||
|
||||
===== Appending New Lines
|
||||
====== Appending New Lines
|
||||
|
||||
The `<int-file:outbound-channel-adapter>` and `<int-file:outbound-gateway>` now support an `append-new-line` attribute.
|
||||
If set to `true`, a new line is appended to the file after a message is written.
|
||||
The default attribute value is `false`.
|
||||
|
||||
===== Ignoring Hidden Files
|
||||
====== Ignoring Hidden Files
|
||||
|
||||
We added the `ignore-hidden` attribute for the `<int-file:inbound-channel-adapter>` to let you set whether to pick up hidden files from the source directory.
|
||||
It defaults to `true`.
|
||||
|
||||
===== Writing `InputStream` Payloads
|
||||
====== Writing `InputStream` Payloads
|
||||
|
||||
The `FileWritingMessageHandler` now also accepts `InputStream` as a valid message payload type.
|
||||
|
||||
===== `HeadDirectoryScanner`
|
||||
====== `HeadDirectoryScanner`
|
||||
|
||||
You can now use the `HeadDirectoryScanner` with other `FileListFilter` implementations.
|
||||
|
||||
===== Last Modified Filter
|
||||
====== Last Modified Filter
|
||||
|
||||
We added the `LastModifiedFileListFilter`.
|
||||
|
||||
===== Watch Service Directory Scanner
|
||||
====== Watch Service Directory Scanner
|
||||
|
||||
We added the `WatchServiceDirectoryScanner`.
|
||||
|
||||
===== Persistent File List Filter Changes
|
||||
====== Persistent File List Filter Changes
|
||||
|
||||
The `AbstractPersistentFileListFilter` has a new property (`flushOnUpdate`) which, when set to `true`, calls `flush()` on the metadata store if it implements `Flushable` (for example, `PropertiesPersistingMetadataStore`).
|
||||
|
||||
[[x4.2-class-package-change]]
|
||||
==== Class Package Change
|
||||
===== Class Package Change
|
||||
|
||||
We moved the `ScatterGatherHandler` class from the `org.springframework.integration.handler` to the `org.springframework.integration.scattergather`.
|
||||
|
||||
==== TCP Changes
|
||||
===== TCP Changes
|
||||
|
||||
This section describes general changes to the Spring Integration TCP functionality.
|
||||
|
||||
[[x4.2-tcp-serializers]]
|
||||
===== TCP Serializers
|
||||
====== TCP Serializers
|
||||
|
||||
The TCP `Serializers` no longer `flush()` the `OutputStream`.
|
||||
This is now done by the `TcpNxxConnection` classes.
|
||||
If you use the serializers directly within your code, you may have to `flush()` the `OutputStream`.
|
||||
|
||||
[[x4.2-tcp-server-exceptions]]
|
||||
===== Server Socket Exceptions
|
||||
====== 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 <<./ip.adoc#tcp-events,TCP Connection Events>> for more information.
|
||||
|
||||
[[x4.2-tcp-server-port]]
|
||||
===== TCP Server Port
|
||||
====== TCP Server Port
|
||||
|
||||
If you configure a TCP server socket factory to listen on a random port, you can now obtain the actual port chosen by the OS by using `getPort()`.
|
||||
`getServerSocketAddress()` is also available.
|
||||
|
||||
See "<<tcp-connection-factories>>" for more information.
|
||||
See "<<./ip.adoc#tcp-connection-factories,TCP Connection Factories>>" for more information.
|
||||
|
||||
[[x4.2-tcp-gw-rto]]
|
||||
===== TCP Gateway Remote Timeout
|
||||
====== TCP Gateway Remote Timeout
|
||||
|
||||
The `TcpOutboundGateway` now supports `remote-timeout-expression` as an alternative to the existing `remote-timeout` attribute.
|
||||
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 <<./ip.adoc#tcp-ob-gateway-attributes,.TCP Outbound Gateway Attributes>> for more information.
|
||||
|
||||
[[x4.2-tcp-ssl]]
|
||||
===== TCP SSLSession Available for Header Mapping
|
||||
====== 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.adoc#ip-msg-headers,IP Message Headers>> for more information.
|
||||
|
||||
[[x4.2-tcp-events]]
|
||||
===== TCP Events
|
||||
====== TCP Events
|
||||
|
||||
New events are now published whenever a correlation exception occurs -- such as sending a message to a non-existent socket.
|
||||
|
||||
The `TcpConnectionEventListeningMessageProducer` is deprecated.
|
||||
Use the generic event adapter instead.
|
||||
|
||||
See <<tcp-events>> for more information.
|
||||
See <<./ip.adoc#tcp-events,TCP Connection Events>> for more information.
|
||||
|
||||
[[x4.2-inbound-channel-adapter-annotation]]
|
||||
==== `@InboundChannelAdapter` Changes
|
||||
===== `@InboundChannelAdapter` Changes
|
||||
|
||||
Previously, the `@Poller` on an inbound channel adapter defaulted the `maxMessagesPerPoll` attribute to `-1` (infinity).
|
||||
This was inconsistent with the XML configuration of `<inbound-channel-adapter/>`, which defaults to `1`.
|
||||
The annotation now defaults this attribute to `1`.
|
||||
|
||||
[[x4.2-api-changes]]
|
||||
==== API Changes
|
||||
===== API Changes
|
||||
|
||||
`o.s.integration.util.FunctionIterator` now requires a `o.s.integration.util.Function` instead of a `reactor.function.Function`.
|
||||
This was done to remove an unnecessary hard dependency on Reactor.
|
||||
@@ -202,177 +202,177 @@ Reactor is still supported for functionality such as the `Promise` gateway.
|
||||
The dependency was removed for those users who do not need it.
|
||||
|
||||
[[x4.2-jms-changes]]
|
||||
==== JMS Changes
|
||||
===== JMS Changes
|
||||
|
||||
This section describes general changes to the Spring Integration TCP functionality.
|
||||
|
||||
===== Reply Listener Lazy Initialization
|
||||
====== 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.adoc#jms-outbound-gateway,Outbound Gateway>> for more information.
|
||||
|
||||
===== Conversion Errors in Message-Driven Endpoints
|
||||
====== 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.adoc#jms-message-driven-channel-adapter,Message-driven Channel Adapter>> and <<./jms.adoc#jms-inbound-gateway,Inbound Gateway>> for more information.
|
||||
|
||||
===== Default Acknowledge Mode
|
||||
====== Default Acknowledge Mode
|
||||
|
||||
When using an implicitly defined `DefaultMessageListenerContainer`, the default `acknowledge` is now `transacted`.
|
||||
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.adoc#jms-message-driven-channel-adapter,Message-driven Channel Adapter>> and <<./jms.adoc#jms-inbound-gateway,Inbound Gateway>> for more information.
|
||||
|
||||
===== Shared Subscriptions
|
||||
====== 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.adoc#jms,JMS Support>> for more information.
|
||||
|
||||
[[x4.2-conditional-pollers]]
|
||||
==== Conditional Pollers
|
||||
===== Conditional Pollers
|
||||
|
||||
We now provide much more flexibility for dynamic polling.
|
||||
|
||||
See <<conditional-pollers>> for more information.
|
||||
See <<./polling-consumer.adoc#conditional-pollers,Conditional Pollers for Message Sources>> for more information.
|
||||
|
||||
[[x4.2-amqp-changes]]
|
||||
==== AMQP Changes
|
||||
===== AMQP Changes
|
||||
|
||||
This section describes general changes to the Spring Integration AMQP functionality.
|
||||
|
||||
===== Publisher Confirmations
|
||||
====== Publisher Confirmations
|
||||
|
||||
The `<int-amqp:outbound-gateway>` now supports `confirm-correlation-expression`, `confirm-ack-channel`, and `confirm-nack-channel` attributes (which have a purpose similar to that of `<int-amqp:outbound-channel-adapter>`).
|
||||
|
||||
===== Correlation Data
|
||||
====== Correlation Data
|
||||
|
||||
For both the outbound channel adapter and the inbound gateway, if the correlation data is a `Message<?>`, it becomes the basis of the message on the ack or nack channel, with the additional header(s) added.
|
||||
Previously, any correlation data (including `Message<?>`) was returned as the payload of the ack or nack message.
|
||||
|
||||
===== Inbound Gateway Properties
|
||||
====== Inbound Gateway Properties
|
||||
|
||||
The `<int-amqp:inbound-gateway>` now exposes the `amqp-template` attribute to allow more control over an external bean for the reply `RabbitTemplate`.
|
||||
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.adoc#amqp,AMQP Support>> for more information.
|
||||
|
||||
[[x4.2-xpath-splitter]]
|
||||
==== XPath Splitter Improvements
|
||||
===== 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.adoc#xml-xpath-splitting,Splitting XML Messages>> for more information.
|
||||
|
||||
[[x4.2-http-changes]]
|
||||
==== HTTP Changes
|
||||
===== HTTP Changes
|
||||
|
||||
This section describes general changes to the Spring Integration HTTP functionality.
|
||||
|
||||
===== CORS
|
||||
====== CORS
|
||||
|
||||
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.adoc#http-cors,Cross-origin Resource Sharing (CORS) Support>> for more information.
|
||||
|
||||
===== Inbound Gateway Timeout
|
||||
====== 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.adoc#http-response-statuscode,Response Status Code>> for more information.
|
||||
|
||||
===== Form Data
|
||||
====== Form Data
|
||||
|
||||
We added documentation for proxying `multipart/form-data` requests.
|
||||
See <<http>> for more information.
|
||||
See <<./http.adoc#http,HTTP Support>> for more information.
|
||||
|
||||
[[x4.2-gw]]
|
||||
==== Gateway Changes
|
||||
===== Gateway Changes
|
||||
|
||||
This section describes general changes to the Spring Integration Gateway functionality.
|
||||
|
||||
===== Gateway Methods can Return `CompletableFuture<?>`
|
||||
====== Gateway Methods can Return `CompletableFuture<?>`
|
||||
|
||||
When using Java 8, gateway methods can now return `CompletableFuture<?>`.
|
||||
See <<gw-completable-future>> for more information.
|
||||
See <<./gateway.adoc#gw-completable-future,`CompletableFuture`>> for more information.
|
||||
|
||||
===== MessagingGateway Annotation
|
||||
====== 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 <<./gateway.adoc#messaging-gateway-annotation,`@MessagingGateway` Annotation>>.
|
||||
|
||||
[[x4.2-aggregator-changes]]
|
||||
==== Aggregator Changes
|
||||
===== Aggregator Changes
|
||||
|
||||
This section describes general changes to the Spring Integration aggregator functionality.
|
||||
|
||||
===== Aggregator Performance
|
||||
====== Aggregator Performance
|
||||
|
||||
This release includes some performance improvements for aggregating components (aggregator, resequencer, and others), by more efficiently removing messages from groups when they are released.
|
||||
New methods (`removeMessagesFromGroup`) have been added to the message store.
|
||||
Set the `removeBatchSize` property (default: `100`) to adjust the number of messages deleted in each operation.
|
||||
Currently, the JDBC, Redis, and MongoDB message stores support this property.
|
||||
|
||||
===== Output Message Group Processor
|
||||
====== Output Message Group Processor
|
||||
|
||||
When using a `ref` or inner bean for the aggregator, you can now directly bind a `MessageGroupProcessor`.
|
||||
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.adoc#aggregator,Aggregator>> for more information.
|
||||
|
||||
==== FTP and SFTP Changes
|
||||
===== FTP and SFTP Changes
|
||||
|
||||
This section describes general changes to the Spring Integration FTP and SFTP functionality.
|
||||
|
||||
===== Inbound Channel Adapters
|
||||
====== 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.adoc#ftp,FTP/FTPS Adapters>> and <<./sftp.adoc#sftp,SFTP Adapters>> for more information.
|
||||
|
||||
===== Gateway Partial Results
|
||||
====== 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.adoc#ftp-outbound-gateway,FTP Outbound Gateway>> and <<./sftp.adoc#sftp-outbound-gateway,SFTP Outbound Gateway>> for more information.
|
||||
|
||||
===== Delegating Session Factory
|
||||
====== 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.adoc#ftp-dsf,Delegating Session Factory>> and <<./sftp.adoc#sftp-dsf,Delegating Session Factory>> for more information.
|
||||
|
||||
===== Default Sftp Session Factory
|
||||
====== Default Sftp Session Factory
|
||||
|
||||
Previously, the `DefaultSftpSessionFactory` unconditionally allowed connections to unknown hosts.
|
||||
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.adoc#sftp-unk-keys,`allowUnknownKeys`::Set to `true` to allow connections to hosts with unknown (or changed) keys.>> for more information.
|
||||
|
||||
===== Message Session Callback
|
||||
====== 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.adoc#ftp-session-callback,Using `MessageSessionCallback`>> and <<./sftp.adoc#sftp-session-callback,MessageSessionCallback>> for more information.
|
||||
|
||||
==== Websocket Changes
|
||||
===== 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.adoc#web-sockets-namespace,WebSockets Namespace Support>> for more information.
|
||||
|
||||
==== Application Event Adapters changes
|
||||
===== Application Event Adapters changes
|
||||
|
||||
The `ApplicationEvent` adapters can now operate with `payload` as an `event` to directly allow omitting custom `ApplicationEvent` extensions.
|
||||
For this purpose, we introduced the `publish-payload` boolean attribute has been introduced on the `<int-event:outbound-channel-adapter>`.
|
||||
See <<applicationevent>> for more information.
|
||||
See <<./event.adoc#applicationevent,Spring `ApplicationEvent` Support>> for more information.
|
||||
|
||||
@@ -6,62 +6,62 @@ for important changes that might affect your applications.
|
||||
You can find migration guides for all versions back to 2.1 on the https://github.com/spring-projects/spring-integration/wiki[Wiki].
|
||||
|
||||
[[x4.3-new-components]]
|
||||
=== New Components
|
||||
==== New Components
|
||||
|
||||
Version 4.3 added a number of new components.
|
||||
|
||||
==== AMQP Async Outbound Gateway
|
||||
===== AMQP Async Outbound Gateway
|
||||
|
||||
See <<amqp-async-outbound-gateway>>.
|
||||
See <<./amqp.adoc#amqp-async-outbound-gateway,Asynchronous Outbound Gateway>>.
|
||||
|
||||
==== `MessageGroupFactory`
|
||||
===== `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.adoc#message-store,Message Store>> for more information.
|
||||
|
||||
==== `PersistentMessageGroup`
|
||||
===== `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.adoc#message-store,Message Store>> for more information.
|
||||
|
||||
==== FTP and SFTP Streaming Inbound Channel Adapters
|
||||
===== 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.adoc#ftp-streaming,FTP Streaming Inbound Channel Adapter>> and <<./sftp.adoc#sftp-streaming,SFTP Streaming Inbound Channel Adapter>> for more information.
|
||||
|
||||
==== `StreamTransformer`
|
||||
===== `StreamTransformer`
|
||||
|
||||
We added `StreamTransformer` to transform an `InputStream` payload to either a `byte[]` or a `String`.
|
||||
See <<stream-transformer>> for more information.
|
||||
See <<./transformer.adoc#stream-transformer,Stream Transformer>> for more information.
|
||||
|
||||
==== Integration Graph
|
||||
===== 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 <<./graph.adoc#integration-graph,Integration Graph>> for more information.
|
||||
|
||||
==== JDBC Lock Registry
|
||||
===== JDBC Lock Registry
|
||||
|
||||
We added `JdbcLockRegistry` for distributed locks shared through a database table.
|
||||
See <<jdbc-lock-registry>> for more information.
|
||||
See <<./jdbc.adoc#jdbc-lock-registry,JDBC Lock Registry>> for more information.
|
||||
|
||||
==== `LeaderInitiator` for `LockRegistry`
|
||||
===== `LeaderInitiator` for `LockRegistry`
|
||||
|
||||
We added `LeaderInitiator` implementation based on the `LockRegistry` strategy.
|
||||
See <<leadership-event-handling>> for more information.
|
||||
See <<./endpoint.adoc#leadership-event-handling,Leadership Event Handling>> for more information.
|
||||
|
||||
[[x4.3-general]]
|
||||
=== General Changes
|
||||
==== General Changes
|
||||
|
||||
This section describes general changes that version 4.3 brought to Spring Integration.
|
||||
|
||||
==== Core Changes
|
||||
===== Core Changes
|
||||
|
||||
This section describes general changes to the core of Spring Integration.
|
||||
|
||||
===== Outbound Gateway within a Chain
|
||||
====== Outbound Gateway within a Chain
|
||||
|
||||
Previously, you could specify a `reply-channel` on an outbound gateway within a chain.
|
||||
It was completely ignored.
|
||||
@@ -69,239 +69,239 @@ The gateway's reply goes to the next chain element or, if the gateway is the las
|
||||
This condition is now detected and disallowed.
|
||||
If you have such a configuration, remove the `reply-channel`.
|
||||
|
||||
===== Asynchronous Service Activator
|
||||
====== Asynchronous Service Activator
|
||||
|
||||
We added an option to make the service activator be synchronous.
|
||||
See <<async-service-activator>> for more information.
|
||||
See <<./service-activator.adoc#async-service-activator,Asynchronous Service Activator>> for more information.
|
||||
|
||||
===== Messaging Annotation Support changes
|
||||
====== 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 <<./configuration.adoc#global-properties,Global Properties>> and <<./configuration.adoc#annotations,Annotation Support>> for more information.
|
||||
|
||||
==== Mail Changes
|
||||
===== Mail Changes
|
||||
|
||||
This section describes general changes to the Spring Integration Mail functionality.
|
||||
|
||||
===== Customizable User Flag
|
||||
====== Customizable User Flag
|
||||
|
||||
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 <<./mail.adoc#imap-seen,Marking IMAP Messages When `\Recent` Is Not Supported>> for more information.
|
||||
|
||||
===== Mail Message Mapping
|
||||
====== 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.adoc#mail-mapping,Inbound Mail Message Mapping>> for more information.
|
||||
|
||||
==== JMS Changes
|
||||
===== JMS Changes
|
||||
|
||||
This section describes general changes to the Spring Integration JMS functionality.
|
||||
|
||||
===== Header Mapper
|
||||
====== 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.adoc#jms-header-mapping,Mapping Message Headers to and from JMS Message>> for more information.
|
||||
|
||||
===== Asynchronous Gateway
|
||||
====== Asynchronous Gateway
|
||||
|
||||
The JMS outbound gateway now has an `async` property.
|
||||
See <<jms-async-gateway>> for more information.
|
||||
See <<./jms.adoc#jms-async-gateway,Async Gateway>> for more information.
|
||||
|
||||
==== Aggregator Changes
|
||||
===== 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 <<./aggregator.adoc#agg-message-collection,IMPORTANT: The `SimpleMessageGroup.getMessages()` method returns an `unmodifiableCollection`.>> note for more information.
|
||||
|
||||
==== TCP/UDP Changes
|
||||
===== TCP/UDP Changes
|
||||
|
||||
This section describes general changes to the Spring Integration TCP/UDP functionality.
|
||||
|
||||
===== Events
|
||||
====== Events
|
||||
|
||||
A new `TcpConnectionServerListeningEvent` is emitted when a server connection factory is started.
|
||||
See <<tcp-events>> for more information.
|
||||
See <<./ip.adoc#tcp-events,TCP Connection 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 <<./ip.adoc#udp-adapters,UDP Adapters>> for more information.
|
||||
|
||||
===== Stream Deserializers
|
||||
====== 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 <<./ip.adoc#tcp-connection-factories,TCP Connection Factories>> for more information.
|
||||
|
||||
===== TCP Message Mapper
|
||||
====== TCP Message Mapper
|
||||
|
||||
The message mapper now, optionally, sets a configured content type header.
|
||||
See <<ip-msg-headers>> for more information.
|
||||
See <<./ip.adoc#ip-msg-headers,IP Message Headers>> for more information.
|
||||
|
||||
==== File Changes
|
||||
===== File Changes
|
||||
|
||||
This section describes general changes to the Spring Integration File functionality.
|
||||
|
||||
===== Destination Directory Creation
|
||||
====== 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.adoc#file-writing-file-names,Generating 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 <<./file.adoc#watch-service-directory-scanner,`WatchServiceDirectoryScanner`>> for more information.
|
||||
|
||||
===== Buffer Size
|
||||
====== Buffer Size
|
||||
|
||||
When writing files, you can now specify the buffer size.
|
||||
|
||||
===== Appending and Flushing
|
||||
====== 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.adoc#file-flushing,Flushing Files When Using `APPEND_NO_FLUSH`>> for more information.
|
||||
|
||||
===== Preserving Timestamps
|
||||
====== 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.adoc#file-timestamps,File Timestamps>> for more information.
|
||||
|
||||
===== Splitter Changes
|
||||
====== 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.adoc#file-splitter,File Splitter>> for more information.
|
||||
|
||||
===== File Filters
|
||||
====== File Filters
|
||||
|
||||
We added `ChainFileListFilter` as an alternative to `CompositeFileListFilter`.
|
||||
See <<file-reading>> for more information.
|
||||
See <<./file.adoc#file-reading,Reading Files>> for more information.
|
||||
|
||||
==== AMQP Changes
|
||||
===== AMQP Changes
|
||||
|
||||
This section describes general changes to the Spring Integration AMQP functionality.
|
||||
|
||||
===== Content Type Message Converter
|
||||
====== Content Type Message Converter
|
||||
|
||||
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 <<./amqp.adoc#content-type-conversion-outbound,Outbound Message Conversion>> for more information.
|
||||
|
||||
===== Headers for Delayed Message Handling
|
||||
====== Headers for Delayed Message Handling
|
||||
|
||||
Spring AMQP 1.6 adds support for https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq/[delayed message exchanges].
|
||||
Header mapping now supports the headers (`amqp_delay` and `amqp_receivedDelay`) used by this feature.
|
||||
|
||||
===== AMQP-Backed Channels
|
||||
====== AMQP-Backed Channels
|
||||
|
||||
AMQP-backed channels now support message mapping.
|
||||
See <<amqp-channels>> for more information.
|
||||
See <<./amqp.adoc#amqp-channels,AMQP-backed Message Channels>> for more information.
|
||||
|
||||
==== Redis Changes
|
||||
===== Redis Changes
|
||||
|
||||
This section describes general changes to the Spring Integration Redis functionality.
|
||||
|
||||
===== List Push/Pop Direction
|
||||
====== List Push/Pop Direction
|
||||
|
||||
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.adoc#redis-queue-inbound-channel-adapter,Redis Queue Inbound Channel Adapter>> and <<./redis.adoc#redis-queue-outbound-channel-adapter,Redis Queue Outbound Channel Adapter>> for more information.
|
||||
|
||||
===== Queue Inbound Gateway Default Serializer
|
||||
====== 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.adoc#redis-queue-inbound-gateway,Redis Queue Inbound Gateway>> for more information.
|
||||
|
||||
==== HTTP Changes
|
||||
===== 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.adoc#http-inbound,Http Inbound Components>> for more information.
|
||||
|
||||
`uriVariablesExpression` now uses a `SimpleEvaluationContext` by default (since 4.3.15).
|
||||
See <<mapping-uri-variables>> for more information.
|
||||
See <<./http.adoc#mapping-uri-variables,Mapping URI Variables>> for more information.
|
||||
|
||||
==== SFTP Changes
|
||||
===== SFTP Changes
|
||||
|
||||
This section describes general changes to the Spring Integration SFTP functionality.
|
||||
|
||||
===== Factory Bean
|
||||
====== 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.adoc#sftp-proxy-factory-bean,Proxy Factory Bean>> for more information.
|
||||
|
||||
===== `chmod` Changes
|
||||
====== `chmod` Changes
|
||||
|
||||
The SFTP outbound gateway (for `put` and `mput` commands) and the SFTP outbound channel adapter now support the `chmod` attribute to change the remote file permissions after uploading.
|
||||
See `<<sftp-outbound>>` and `<<sftp-outbound-gateway>>` for more information.
|
||||
See `<<./sftp.adoc#sftp-outbound,SFTP Outbound Channel Adapter>>` and `<<./sftp.adoc#sftp-outbound-gateway,SFTP Outbound Gateway>>` for more information.
|
||||
|
||||
==== FTP Changes
|
||||
===== FTP Changes
|
||||
|
||||
This section describes general changes to the Spring Integration FTP functionality.
|
||||
|
||||
===== Session Changes
|
||||
====== Session Changes
|
||||
|
||||
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.adoc#ftp,FTP/FTPS Adapters>> for more information.
|
||||
|
||||
==== Router Changes
|
||||
===== 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.adoc#router,Routers>> for more information.
|
||||
|
||||
==== Header Mapping
|
||||
===== Header Mapping
|
||||
|
||||
This section describes the changes to header mapping between version 4.2 and 4.3.
|
||||
|
||||
===== General
|
||||
====== 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.adoc#amqp-message-headers,AMQP Message Headers>>, <<./ws.adoc#ws-message-headers,WS Message Headers>>, and <<./xmpp.adoc#xmpp-message-headers,XMPP Message Headers>> for more information.
|
||||
|
||||
===== AMQP Header Mapping
|
||||
====== AMQP Header Mapping
|
||||
|
||||
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.adoc#amqp-message-headers,AMQP Message Headers>> for more information.
|
||||
|
||||
==== Groovy Scripts
|
||||
===== 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.adoc#groovy-config,Groovy Configuration>> for more information.
|
||||
|
||||
==== `@InboundChannelAdapter` Changes
|
||||
===== `@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 <<./configuration.adoc#annotations,Annotation Support>> for more information.
|
||||
|
||||
==== XMPP Changes
|
||||
===== XMPP Changes
|
||||
|
||||
The XMPP channel adapters now support the XMPP Extensions (XEP).
|
||||
See <<xmpp-extensions>> for more information.
|
||||
See <<./xmpp.adoc#xmpp-extensions,XMPP Extensions>> for more information.
|
||||
|
||||
==== WireTap Late Binding
|
||||
===== 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.adoc#channel-wiretap,Wire Tap>> for more information.
|
||||
|
||||
==== `ChannelMessageStoreQueryProvider` Changes
|
||||
===== `ChannelMessageStoreQueryProvider` Changes
|
||||
|
||||
The `ChannelMessageStoreQueryProvider` now supports H2 databases.
|
||||
See <<jdbc-message-store-channels>> for more information.
|
||||
See <<./jdbc.adoc#jdbc-message-store-channels,Backing Message Channels>> for more information.
|
||||
|
||||
==== WebSocket Changes
|
||||
===== WebSocket Changes
|
||||
|
||||
The `ServerWebSocketContainer` now exposes an `allowedOrigins` option, and `SockJsServiceOptions` exposes a `suppressCors` option.
|
||||
See <<web-sockets>> for more information.
|
||||
See <<./web-sockets.adoc#web-sockets,WebSockets Support>> for more information.
|
||||
|
||||
@@ -5,96 +5,96 @@ See the https://github.com/spring-projects/spring-integration/wiki/Spring-Integr
|
||||
You can find migration guides for all versions back to 2.1 on the https://github.com/spring-projects/spring-integration/wiki[wiki].
|
||||
|
||||
[[x5.0-new-components]]
|
||||
=== New Components
|
||||
==== New Components
|
||||
|
||||
Version 5.0 added a number of new components.
|
||||
|
||||
==== Java DSL
|
||||
===== Java DSL
|
||||
|
||||
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 <<./dsl.adoc#java-dsl,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
|
||||
===== Testing Support
|
||||
|
||||
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.adoc#testing,Testing support>> for more information.
|
||||
|
||||
==== MongoDB Outbound Gateway
|
||||
===== 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.adoc#mongodb-outbound-gateway,MongoDB Outbound Gateway>> for more information.
|
||||
|
||||
==== WebFlux Gateways and Channel Adapters
|
||||
===== 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.adoc#webflux,WebFlux Support>> for more information.
|
||||
|
||||
==== Content Type Conversion
|
||||
===== 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 <<./endpoint.adoc#content-type-conversion,Content Type Conversion>> for more information.
|
||||
|
||||
==== `ErrorMessagePublisher` and `ErrorMessageStrategy`
|
||||
===== `ErrorMessagePublisher` and `ErrorMessageStrategy`
|
||||
|
||||
We added `ErrorMessagePublisher` and the `ErrorMessageStrategy` for creating `ErrorMessage` instances.
|
||||
|
||||
See <<namespace-errorhandler>> for more information.
|
||||
See <<./configuration.adoc#namespace-errorhandler,Error Handling>> for more information.
|
||||
|
||||
==== JDBC Metadata Store
|
||||
===== 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.adoc#jdbc-metadata-store,JDBC Metadata Store>> for more information.
|
||||
|
||||
[[x5.0-general]]
|
||||
=== General Changes
|
||||
==== General Changes
|
||||
|
||||
Spring Integration is now fully based on Spring Framework `5.0` and Project Reactor `3.1`.
|
||||
Previous Project Reactor versions are no longer supported.
|
||||
|
||||
==== Core Changes
|
||||
===== Core Changes
|
||||
|
||||
The `@Poller` annotation now has the `errorChannel` attribute for easier configuration of the underlying `MessagePublishingErrorHandler`.
|
||||
See <<annotations>> for more information.
|
||||
See <<./configuration.adoc#annotations,Annotation Support>> 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 <<./handler-advice.adoc#tx-handle-message-advice,Transaction Support>> for more information.
|
||||
|
||||
The `SmartLifecycleRoleController` now provides methods to obtain status of endpoints in roles.
|
||||
See <<endpoint-roles>> for more information.
|
||||
See <<./endpoint.adoc#endpoint-roles,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 <<./overview.adoc#pojo-invocation,POJO Method 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.adoc#service-activator-namespace,Configuring Service Activator>> 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 <<./transactions.adoc#transaction-synchronization,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.adoc#aggregator-spel,Aggregators and Spring Expression Language (SpEL)>> for more information.
|
||||
|
||||
You can now supply the `ObjectToMapTransformer` with a customized `JsonObjectMapper`.
|
||||
|
||||
See <<aggregator-spel>> for more information.
|
||||
See <<./aggregator.adoc#aggregator-spel,Aggregators and Spring Expression Language (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 <<./channel.adoc#global-channel-configuration-interceptors,Global Channel Interceptor Configuration>> 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.
|
||||
See `<<./endpoint.adoc#leadership-event-handling,Leadership Event Handling>>` for more information.
|
||||
|
||||
==== Gateway Changes
|
||||
===== Gateway Changes
|
||||
|
||||
When the gateway method has a `void` return type and an error channel is provided, the gateway now correctly sets the `errorChannel` header.
|
||||
Previously, the header was not populated.
|
||||
@@ -103,40 +103,40 @@ 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.adoc#gateway,Messaging Gateways>> for more information.
|
||||
|
||||
==== Aggregator Performance Changes
|
||||
===== 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.adoc#aggregator,Aggregator>> for more information.
|
||||
|
||||
==== Splitter Changes
|
||||
===== 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.adoc#splitter,Splitter>> for more information.
|
||||
|
||||
==== JMS Changes
|
||||
===== JMS Changes
|
||||
|
||||
Previously, Spring Integration JMS XML configuration used a default bean name of `connectionFactory` for the JMS connection factory, letting the property be omitted from component definitions.
|
||||
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.adoc#jms,JMS Support>> for more information.
|
||||
|
||||
==== Mail Changes
|
||||
===== Mail Changes
|
||||
|
||||
Some inconsistencies with rendering IMAP mail content have been resolved.
|
||||
See <<imap-format-important,the note in the "`Mail-receiving Channel Adapter`" section>> for more information.
|
||||
See <<./mail.adoc#imap-format-important,,the note in the "`Mail-receiving Channel Adapter`" section>> for more information.
|
||||
|
||||
==== Feed Changes
|
||||
===== 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.adoc#feed,Feed Adapter>> for more information.
|
||||
|
||||
==== File Changes
|
||||
===== File Changes
|
||||
|
||||
We introduced the new `FileHeaders.RELATIVE_PATH` message header to represent relative path in `FileReadingMessageSource`.
|
||||
|
||||
@@ -149,13 +149,13 @@ 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.adoc#file-incomplete,Dealing With Incomplete Data>> 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 <<./file.adoc#files,File Support>> for more information.
|
||||
|
||||
==== FTP and SFTP Changes
|
||||
===== FTP and SFTP Changes
|
||||
|
||||
The inbound channel adapters now have a property called `max-fetch-size`, which is used to limit the number of files fetched during a poll when no files are currently in the local directory.
|
||||
By default, they also are configured with a `FileSystemPersistentAcceptOnceFileListFilter` in the `local-filter`.
|
||||
@@ -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.adoc#ftp-inbound,FTP Inbound Channel Adapter>> 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,24 +187,24 @@ 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.adoc#ftp,FTP/FTPS Adapters>> and <<./sftp.adoc#sftp,SFTP Adapters>> for more information.
|
||||
|
||||
==== Integration Properties
|
||||
===== 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 <<./configuration.adoc#global-properties,Global Properties>> for more information.
|
||||
|
||||
==== Stream Changes
|
||||
===== 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.adoc#stream-reading,Reading from Streams>> for more information.
|
||||
|
||||
==== Barrier Changes
|
||||
===== Barrier Changes
|
||||
|
||||
The `BarrierMessageHandler` now supports a discard channel to which late-arriving trigger messages are sent.
|
||||
See <<barrier>> for more information.
|
||||
See <<./barrier.adoc#barrier,Thread Barrier>> for more information.
|
||||
|
||||
==== AMQP Changes
|
||||
===== AMQP Changes
|
||||
|
||||
The AMQP outbound endpoints now support setting a delay expression when you use the RabbitMQ Delayed Message Exchange plugin.
|
||||
|
||||
@@ -215,32 +215,32 @@ 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.adoc#amqp,AMQP Support>> for more information.
|
||||
|
||||
==== HTTP Changes
|
||||
===== 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.adoc#http-header-mapping,HTTP Header Mappings>> for more information.
|
||||
|
||||
By default, `uriVariablesExpression` now uses a `SimpleEvaluationContext` (since 5.0.4).
|
||||
|
||||
See <<mapping-uri-variables>> for more information.
|
||||
See <<./http.adoc#mapping-uri-variables,Mapping URI Variables>> for more information.
|
||||
|
||||
==== MQTT Changes
|
||||
===== MQTT Changes
|
||||
|
||||
Inbound messages are now mapped with the `RECEIVED_TOPIC`, `RECEIVED_QOS`, and `RECEIVED_RETAINED` headers to avoid inadvertent propagation to outbound messages when an application relays messages.
|
||||
|
||||
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.adoc#mqtt,MQTT Support>> for more information.
|
||||
|
||||
==== STOMP Changes
|
||||
===== 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.adoc#stomp,STOMP Support>> for more information.
|
||||
|
||||
==== Web Services Changes
|
||||
===== Web Services Changes
|
||||
|
||||
You can now supply `WebServiceOutboundGateway` instances with an externally configured `WebServiceTemplate` instances.
|
||||
|
||||
@@ -248,9 +248,9 @@ 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.adoc#ws,Web Services Support>> for more information.
|
||||
|
||||
==== Redis Changes
|
||||
===== Redis Changes
|
||||
|
||||
The `RedisStoreWritingMessageHandler` is supplied now with additional `String`-based setters for SpEL expressions (for convenience with Java configuration).
|
||||
You can now configure the `zsetIncrementExpression` on the `RedisStoreWritingMessageHandler` as well.
|
||||
@@ -259,9 +259,9 @@ 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.adoc#redis,Redis Support>> for more information.
|
||||
|
||||
==== TCP Changes
|
||||
===== TCP Changes
|
||||
|
||||
We added a new `ThreadAffinityClientConnectionFactory` to bind TCP connections to threads.
|
||||
|
||||
@@ -269,33 +269,33 @@ 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.adoc#ip,TCP and UDP Support>> for more information.
|
||||
|
||||
==== Gemfire Changes
|
||||
===== 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.adoc#gemfire,Pivotal GemFire and Apache Geode Support>> for more information.
|
||||
|
||||
==== JDBC Changes
|
||||
===== JDBC Changes
|
||||
|
||||
The `JdbcMessageChannelStore` now provides a setter for `ChannelMessageStorePreparedStatementSetter`, letting you customize message insertion in the store.
|
||||
|
||||
The `ExpressionEvaluatingSqlParameterSourceFactory` now provides a setter for `sqlParameterTypes`, letting you customize the SQL types of the parameters.
|
||||
|
||||
See <<jdbc>> for more information.
|
||||
See <<./jdbc.adoc#jdbc,JDBC Support>> for more information.
|
||||
|
||||
|
||||
==== Metrics Changes
|
||||
===== Metrics Changes
|
||||
|
||||
https://micrometer.io/[Micrometer] application monitoring is now supported (since version 5.0.2).
|
||||
See <<micrometer-integration>> for more information.
|
||||
See <<./metrics.adoc#micrometer-integration,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.
|
||||
If you use Micrometer, we recommend a minimum of version 5.0.4.
|
||||
|
||||
|
||||
==== `@EndpointId` Annotations
|
||||
===== `@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 <<./overview.adoc#endpoint-bean-names,Endpoint Bean Names>> for more information.
|
||||
|
||||
@@ -2,34 +2,34 @@
|
||||
=== Changes between 5.1 and 5.1
|
||||
|
||||
[[x5.1-new-components]]
|
||||
=== New Components
|
||||
==== New Components
|
||||
|
||||
The following components are new in 5.1:
|
||||
|
||||
* <<x5.1-AmqpDedicatedChannelAdvice>>
|
||||
|
||||
[[x5.1-AmqpDedicatedChannelAdvice]]
|
||||
==== `AmqpDedicatedChannelAdvice`
|
||||
===== `AmqpDedicatedChannelAdvice`
|
||||
|
||||
See <<amqp-strict-ordering>>.
|
||||
See <<./amqp.adoc#amqp-strict-ordering,Strict Message Ordering>>.
|
||||
|
||||
[[x5.1-Functions]]
|
||||
==== Improved Function Support
|
||||
===== Improved Function Support
|
||||
|
||||
The `java.util.function` interfaces now have improved integration support in the Framework components.
|
||||
Also Kotlin lambdas now can be used for handler and source methods.
|
||||
|
||||
See <<functions-support>>.
|
||||
See <<./functions-support.adoc#functions-support,`java.util.function` Interfaces Support>>.
|
||||
|
||||
[[x5.1-LongRunningTest]]
|
||||
==== `@LongRunningTest`
|
||||
===== `@LongRunningTest`
|
||||
|
||||
A JUnit 5 `@LongRunningTest` conditional annotation is provided to check the environment or system properties for the `RUN_LONG_INTEGRATION_TESTS` entry with the value of `true` to determine if test should be run or skipped.
|
||||
|
||||
See <<test-junit-rules>>.
|
||||
See <<./testing.adoc#test-junit-rules,JUnit Rules and Conditions>>.
|
||||
|
||||
[[x5.1-general]]
|
||||
=== General Changes
|
||||
==== General Changes
|
||||
|
||||
The following changes have been made in version 5.1:
|
||||
|
||||
@@ -45,7 +45,7 @@ The following changes have been made in version 5.1:
|
||||
* <<x51.-poller-annotation>>
|
||||
|
||||
[[x5.1-java-dsl]]
|
||||
==== Java DSL
|
||||
===== Java DSL
|
||||
|
||||
The `IntegrationFlowContext` is now an interface and `IntegrationFlowRegistration` is an inner interface of `IntegrationFlowContext`.
|
||||
|
||||
@@ -57,7 +57,7 @@ A generated bean name for any `NamedComponent` within an integration flow is now
|
||||
The `GenericHandler.handle()` now excepts a `MessageHeaders` type for the second argument.
|
||||
|
||||
[[x5.1-dispatcher-exceptions]]
|
||||
==== Dispatcher Exceptions
|
||||
===== Dispatcher Exceptions
|
||||
|
||||
Exceptions caught and re-thrown by `AbstractDispatcher` are now more consistent:
|
||||
|
||||
@@ -72,13 +72,13 @@ Previously:
|
||||
* Checked exceptions were wrapped in a `MessageDeliveryException` with the `failedMessage` property set.
|
||||
|
||||
[[x5.1-global-channel-interceptors]]
|
||||
==== Global Channel Interceptors
|
||||
===== Global Channel Interceptors
|
||||
|
||||
Global channel interceptors now apply to dynamically registered channels, such as through the `IntegrationFlowContext` when using the Java DSL or beans that are initialized using `beanFactory.initializeBean()`.
|
||||
Previously, when beans were created after the application context was refreshed, interceptors were not applied.
|
||||
|
||||
[[x5.1-channel-interceptors]]
|
||||
==== Channel Interceptors
|
||||
===== Channel Interceptors
|
||||
|
||||
`ChannelInterceptor.postReceive()` is no longer called when no message is received; it is no longer necessary to check for a `null` `Message<?>`.
|
||||
Previously, the method was called.
|
||||
@@ -86,22 +86,22 @@ If you have an interceptor that relies on the previous behavior, implement `afte
|
||||
Furthermore, the `PolledAmqpChannel` and `PolledJmsChannel` previously did not invoke `afterReceiveCompleted()` with `null`; they now do.
|
||||
|
||||
[[x5.1-object-to-json-transformer]]
|
||||
==== `ObjectToJsonTransformer`
|
||||
===== `ObjectToJsonTransformer`
|
||||
|
||||
A new `ResultType.BYTES` mode is introduced for the `ObjectToJsonTransformer`.
|
||||
|
||||
See <<json-transformers>> for more information.
|
||||
See <<./transformer.adoc#json-transformers,JSON Transformers>> for more information.
|
||||
|
||||
[[x5.1-integration-flows-generated-bean-names]]
|
||||
==== Integration Flows: Generated Bean Names
|
||||
===== Integration Flows: Generated Bean Names
|
||||
|
||||
Starting with version 5.0.5, generated bean names for the components in an `IntegrationFlow` include the flow bean name, followed by a dot, as a prefix.
|
||||
For example, if a flow bean were named `flowBean`, a generated bean might be named `flowBean.generatedBean`.
|
||||
|
||||
See <<java-dsl-flows>> for more information.
|
||||
See <<./dsl.adoc#java-dsl-flows,Working With Message Flows>> for more information.
|
||||
|
||||
[[x5.1-aggregator]]
|
||||
==== Aggregator Changes
|
||||
===== Aggregator Changes
|
||||
|
||||
If the `groupTimeout` is evaluated to a negative value, an aggregator now expires the group immediately.
|
||||
Only `null` is considered as a signal to do nothing for the current message.
|
||||
@@ -109,18 +109,18 @@ Only `null` is considered as a signal to do nothing for the current message.
|
||||
A new `popSequence` property has been introduced to allow (by default) to call a `MessageBuilder.popSequenceDetails()` for the output message.
|
||||
Also an `AbstractAggregatingMessageGroupProcessor` returns now an `AbstractIntegrationMessageBuilder` instead of the whole `Message` for optimization.
|
||||
|
||||
See <<aggregator>> for more information.
|
||||
See <<./aggregator.adoc#aggregator,Aggregator>> for more information.
|
||||
|
||||
[[x5.1-publisher]]
|
||||
==== @Publisher annotation changes
|
||||
===== @Publisher annotation changes
|
||||
|
||||
Starting with version 5.1, you must explicitly turn on the `@Publisher` AOP functionality by using `@EnablePublisher` or by using the `<int:enable-publisher>` child element on `<int:annotation-config>`.
|
||||
Also the `proxy-target-class` and `order` attributes have been added for tuning the `ProxyFactory` configuration.
|
||||
|
||||
See <<publisher-annotation>> for more information.
|
||||
See <<./message-publishing.adoc#publisher-annotation,Annotation-driven Configuration with the `@Publisher` Annotation>> for more information.
|
||||
|
||||
[[x5.1-files]]
|
||||
=== Files Changes
|
||||
==== Files Changes
|
||||
|
||||
If you are using `FileExistsMode.APPEND` or `FileExistsMode.APPEND_NO_FLUSH` you can provide a `newFileCallback` that will be called when creating a new file.
|
||||
This callback receives the newly created file and the message that triggered the callback.
|
||||
@@ -129,23 +129,23 @@ This could be used to write a CSV header, for an example.
|
||||
The `FileReadingMessageSource` now doesn't check and create a directory until its `start()` is called.
|
||||
So, if an Inbound Channel Adapter for the `FileReadingMessageSource` has `autoStartup = false`, there are no failures against the file system during application start up.
|
||||
|
||||
See <<files>> for more information.
|
||||
See <<./file.adoc#files,File Support>> for more information.
|
||||
|
||||
[[x5.1-amqp]]
|
||||
=== AMQP Changes
|
||||
==== 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.adoc#amqp-message-headers,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.adoc#amqp-content-type,contentType Header>> for more information.
|
||||
|
||||
Starting with version 5.1.3, if a message conversion exception occurs when using manual acknowledgments, and an error channel is defined, the payload is a `ManualAckListenerExecutionFailedException` with additional `channel` and `deliveryTag` properties.
|
||||
This enables the error flow to ack/nack the original message.
|
||||
See <<amqp-conversion-inbound>> for more information.
|
||||
See <<./amqp.adoc#amqp-conversion-inbound,Inbound Message Conversion>> for more information.
|
||||
|
||||
[[x5.1-jdbc]]
|
||||
=== JDBC Changes
|
||||
==== JDBC Changes
|
||||
|
||||
A confusing `max-rows-per-poll` property on the JDBC Inbound Channel Adapter and JDBC Outbound Gateway has been deprecated in favor of the newly introduced `max-rows` property.
|
||||
|
||||
@@ -154,61 +154,61 @@ The `JdbcMessageHandler` supports now a `batchUpdate` functionality when the pay
|
||||
The indexes for the `INT_CHANNEL_MESSAGE` table (for the `JdbcChannelMessageStore`) have been optimized.
|
||||
If you have large message groups in such a store, you may wish to alter the indexes.
|
||||
|
||||
See <<jdbc>> for more information.
|
||||
See <<./jdbc.adoc#jdbc,JDBC Support>> for more information.
|
||||
|
||||
[[x5.1-ftp-sftp]]
|
||||
=== FTP and SFTP Changes
|
||||
==== FTP and SFTP Changes
|
||||
|
||||
A `RotatingServerAdvice` is now available to poll multiple servers and directories with the inbound channel adapters.
|
||||
See <<ftp-rotating-server-advice>> and <<sftp-rotating-server-advice>> for more information.
|
||||
See <<./ftp.adoc#ftp-rotating-server-advice,Inbound Channel Adapters: Polling Multiple Servers and Directories>> and <<./sftp.adoc#sftp-rotating-server-advice,Inbound Channel Adapters: Polling Multiple Servers and Directories>> 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 `Comparator<F>`.
|
||||
See <<ftp-streaming>> and <<sftp-streaming>> for more information.
|
||||
See <<./ftp.adoc#ftp-streaming,FTP Streaming Inbound Channel Adapter>> and <<./sftp.adoc#sftp-streaming,SFTP Streaming Inbound Channel Adapter>> 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.
|
||||
|
||||
The `CachingSessionFactory` has a new property `testSession` which, when true, causes the factory to perform a `test()` operation on the `Session` when checking out an existing session from the cache.
|
||||
|
||||
See <<sftp-session-caching>> and <<ftp-session-caching>> for more information.
|
||||
See <<./sftp.adoc#sftp-session-caching,SFTP Session Caching>> and <<./ftp.adoc#ftp-session-caching,FTP Session Caching>> for more information.
|
||||
|
||||
The outbound gateway MPUT command now supports a message payload with a collection of files or strings.
|
||||
See <<sftp-outbound-gateway>> and <<ftp-outbound-gateway>> for more information.
|
||||
See <<./sftp.adoc#sftp-outbound-gateway,SFTP Outbound Gateway>> and <<./ftp.adoc#ftp-outbound-gateway,FTP Outbound Gateway>> for more information.
|
||||
|
||||
[[x51.-tcp]]
|
||||
=== TCP Support
|
||||
==== TCP Support
|
||||
|
||||
When using SSL, host verification is now enabled, by default, to prevent man-in-the-middle attacks with a trusted certificate.
|
||||
See <<tcp-ssl-host-verification>> for more information.
|
||||
See <<./ip.adoc#tcp-ssl-host-verification,Host Verification>> for more information.
|
||||
|
||||
In addition the key and trust store types can now be configured on the `DefaultTcpSSLContextSupport`.
|
||||
|
||||
[[x5.1-twitter]]
|
||||
=== Twitter Support
|
||||
==== 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.
|
||||
See https://github.com/spring-projects/spring-integration-extensions/tree/master/spring-integration-social-twitter[Spring Integration Social Twitter] for more information.
|
||||
|
||||
[[x51.-jms]]
|
||||
=== JMS Support
|
||||
==== JMS Support
|
||||
|
||||
The `JmsSendingMessageHandler` now provides `deliveryModeExpression` and `timeToLiveExpression` options to determine respective QoS options for JMS message to send at runtime.
|
||||
The `DefaultJmsHeaderMapper` now allows to map inbound `JMSDeliveryMode` and `JMSExpiration` properties via setting to `true` respective `setMapInboundDeliveryMode()` and `setMapInboundExpiration()` options.
|
||||
When a `JmsMessageDrivenEndpoint` or `JmsInboundGateway` is stopped, the associated listener container is now shut down; this closes its shared connection and any consumers.
|
||||
You can configure the endpoints to revert to the previous behavior.
|
||||
|
||||
See <<jms>> for more information.
|
||||
See <<./jms.adoc#jms,JMS Support>> for more information.
|
||||
|
||||
[[x51.-http]]
|
||||
=== HTTP/WebFlux Support
|
||||
==== HTTP/WebFlux Support
|
||||
|
||||
The `statusCodeExpression` (and `Function`) is now supplied with the `RequestEntity<?>` as a root object for evaluation context, so request headers, method, URI and body are available for target status code calculation.
|
||||
|
||||
See <<http>> and <<webflux>> for more information.
|
||||
See <<./http.adoc#http,HTTP Support>> and <<./webflux.adoc#webflux,WebFlux Support>> for more information.
|
||||
|
||||
[[x51.-jmx]]
|
||||
=== JMX Changes
|
||||
==== JMX Changes
|
||||
|
||||
Object name key values are now quoted if they contain any characters other than those allowed in a Java identifier (or period `.`).
|
||||
For example `org.springframework.integration:type=MessageChannel,` `name="input:foo.myGroup.errors"`.
|
||||
@@ -216,25 +216,25 @@ This has the side effect that previously "allowed" names, with such characters,
|
||||
For example `org.springframework.integration:type=MessageChannel,` `name="input#foo.myGroup.errors"`.
|
||||
|
||||
[[x51.-micrometer]]
|
||||
=== Micrometer Support Changes
|
||||
==== Micrometer Support Changes
|
||||
|
||||
It is now simpler to customize the standard Micrometer meters created by the framework.
|
||||
See <<micrometer-integration>> for more information.
|
||||
See <<./metrics.adoc#micrometer-integration,Micrometer Integration>> for more information.
|
||||
|
||||
[[x51.-integration-graph]]
|
||||
=== Integration Graph Customization
|
||||
==== Integration Graph Customization
|
||||
|
||||
It is now possible to add additional properties to the `IntegrationNode` s via `Function<NamedComponent, Map<String, Object>> additionalPropertiesCallback` on the `IntegrationGraphServer`.
|
||||
See <<integration-graph>> for more information.
|
||||
See <<./graph.adoc#integration-graph,Integration Graph>> for more information.
|
||||
|
||||
[[x51.-global-properties]]
|
||||
=== Integration Global Properties
|
||||
==== Integration Global Properties
|
||||
|
||||
The Integration global properties (including defaults) can now be printed in the logs, when a `DEBUG` logic level is turned on for the `org.springframework.integration` category.
|
||||
See <<global-properties>> for more information.
|
||||
See <<./configuration.adoc#global-properties,Global Properties>> for more information.
|
||||
|
||||
[[x51.-poller-annotation]]
|
||||
=== The `receiveTimeout` for `@Poller`
|
||||
==== The `receiveTimeout` for `@Poller`
|
||||
|
||||
The `@Poller` annotation now provides a `receiveTimeout` option for convenience.
|
||||
See <<configuration-using-poller-annotation>> for more information.
|
||||
See <<./configuration.adoc#configuration-using-poller-annotation,Using the `@Poller` Annotation>> for more information.
|
||||
|
||||
@@ -33,7 +33,7 @@ The following example defines two `inbound-channel-adapter` instances:
|
||||
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.adoc#endpoint-namespace,Endpoint Namespace Support>> for more detail.
|
||||
|
||||
[IMPORTANT]
|
||||
.Important: Poller Configuration
|
||||
@@ -147,8 +147,8 @@ 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.adoc#spel,Spring Expression Language (SpEL)>>.
|
||||
For scripts, see <<./groovy.adoc#groovy,Groovy support>> and <<./scripting.adoc#scripting,Scripting Support>>.
|
||||
|
||||
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.
|
||||
|
||||
@@ -26,7 +26,7 @@ If the send call times out or is interrupted, it returns `false`.
|
||||
[[channel-interfaces-pollablechannel]]
|
||||
===== `PollableChannel`
|
||||
|
||||
Since message channels may or may not buffer messages (as discussed in the <<overview>>), two sub-interfaces define the buffering (pollable) and non-buffering (subscribable) channel behavior.
|
||||
Since message channels may or may not buffer messages (as discussed in the <<./overview.adoc#overview,Spring Integration Overview>>), two sub-interfaces define the buffering (pollable) and non-buffering (subscribable) channel behavior.
|
||||
The following listing shows the definition of the `PollableChannel` interface:
|
||||
|
||||
====
|
||||
@@ -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.adoc#jms,JMS Support>>.
|
||||
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.
|
||||
@@ -343,7 +343,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.adoc#gateway-proxy,Enter the `GatewayProxyFactoryBean`>>.
|
||||
|
||||
[[channel-configuration]]
|
||||
==== Configuring Message Channels
|
||||
@@ -483,7 +483,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 <<./endpoint.adoc#payload-type-conversion,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.
|
||||
@@ -517,7 +517,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.adoc#message-store,Message Store>>.
|
||||
|
||||
IMPORTANT: The `capacity` attribute is not allowed when the `message-store` attribute is used.
|
||||
|
||||
@@ -556,7 +556,7 @@ Since version 4.0, we recommend that `QueueChannel` instances be configured to u
|
||||
These are generally optimized for this use, as compared to a general message store.
|
||||
If the `ChannelMessageStore` is a `ChannelPriorityMessageStore`, the messages are received in FIFO within priority order.
|
||||
The notion of priority is determined by the message store implementation.
|
||||
For example, the following example shows the Java configuration for the <<mongodb-priority-channel-message-store>>:
|
||||
For example, the following example shows the Java configuration for the <<./mongodb.adoc#mongodb-priority-channel-message-store,MongoDB Channel Message Store>>:
|
||||
|
||||
====
|
||||
[source,java]
|
||||
@@ -716,8 +716,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.adoc#message-store,Message Store>> for more information.
|
||||
You can find sample configuration in <<./jdbc.adoc#jdbc-message-store-channels,Backing Message Channels>>.
|
||||
|
||||
[[channel-configuration-rendezvouschannel]]
|
||||
===== `RendezvousChannel` Configuration
|
||||
@@ -826,7 +826,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 <<./configuration.adoc#global-properties,Global Properties>> for more information.
|
||||
|
||||
[[channel-wiretap]]
|
||||
===== Wire Tap
|
||||
@@ -854,7 +854,7 @@ By default, it is `false` so that only the payload is logged.
|
||||
Setting it to `true` enables logging of all headers in addition to the payload.
|
||||
The 'expression' option provides the most flexibility (for example, `expression="payload.user.name"`).
|
||||
|
||||
One of the common misconceptions about the wire tap and other similar components (<<message-publishing-config>>) is that they are automatically asynchronous in nature.
|
||||
One of the common misconceptions about the wire tap and other similar components (<<./message-publishing.adoc#message-publishing-config,Message Publishing Configuration>>) is that they are automatically asynchronous in nature.
|
||||
By default, wire tap as a component is not invoked asynchronously.
|
||||
Instead, Spring Integration focuses on a single unified approach to configuring asynchronous behavior: the message channel.
|
||||
What makes certain parts of the message flow synchronous or asynchronous is the type of Message Channel that has been configured within that flow.
|
||||
@@ -951,7 +951,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 <<./configuration.adoc#namespace-errorhandler,Error Handling>>.
|
||||
|
||||
|
||||
See also <<java-dsl-channels>> in the Java DSL chapter for more information about message channel and interceptors.
|
||||
See also <<./dsl.adoc#java-dsl-channels,Message Channels>> in the Java DSL chapter for more information about message channel and interceptors.
|
||||
|
||||
@@ -152,7 +152,7 @@ The next section describes what happens if exceptions occur within the asynchron
|
||||
[[namespace-errorhandler]]
|
||||
=== Error Handling
|
||||
|
||||
As described in the <<overview,overview>> at the very beginning of this manual, one of the main motivations behind a message-oriented framework such as Spring Integration is to promote loose coupling between components.
|
||||
As described in the <<./overview.adoc#overview,,overview>> at the very beginning of this manual, one of the main motivations behind a message-oriented framework such as Spring Integration is to promote loose coupling between components.
|
||||
The message channel plays an important role, in that producers and consumers do not have to know about each other.
|
||||
However, the advantages also have some drawbacks.
|
||||
Some things become more complicated in a loosely coupled environment, and one example is error handling.
|
||||
@@ -164,9 +164,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.adoc#gateway,Messaging Gateways>>) or a `MessagingTemplate` (see <<./channel.adoc#channel-template,`MessagingTemplate`>>).
|
||||
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.adoc#gateway-error-handling,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.
|
||||
@@ -210,7 +210,7 @@ Starting with version 4.3.10, Spring Integration provides the `ErrorMessagePubli
|
||||
You can use them as a general mechanism for publishing `ErrorMessage` instances.
|
||||
You can call or extend them in any error handling scenarios.
|
||||
The `ErrorMessageSendingRecoverer` extends this class as a `RecoveryCallback` implementation that can be used with retry, such as the
|
||||
<<retry-advice, `RequestHandlerRetryAdvice`>>.
|
||||
<<./handler-advice.adoc#retry-advice,, `RequestHandlerRetryAdvice`>>.
|
||||
The `ErrorMessageStrategy` is used to build an `ErrorMessage` based on the provided exception and an `AttributeAccessor` context.
|
||||
It can be injected into any `MessageProducerSupport` or `MessagingGatewaySupport`.
|
||||
The `requestMessage` is stored under `ErrorMessageUtils.INPUT_MESSAGE_CONTEXT_KEY` in the `AttributeAccessor` context.
|
||||
@@ -255,12 +255,12 @@ 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.adoc#message-header-accessor,`MessageHeaderAccessor` API>>) used to build messages via `MessageBuilder` (see <<./message.adoc#message-builder,The `MessageBuilder` Helper Class>>).
|
||||
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.adoc#control-bus,Control Bus>>), by their role with the `SmartLifecycleRoleController` (see <<./endpoint.adoc#endpoint-roles,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.
|
||||
|
||||
@@ -315,17 +315,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.adoc#aggregator,Aggregator>>)
|
||||
* `@Filter` (see <<./filter.adoc#filter,Filter>>)
|
||||
* `@Router` (see <<./router.adoc#router,Routers>>)
|
||||
* `@ServiceActivator` (see <<./service-activator.adoc#service-activator,Service Activator>>)
|
||||
* `@Splitter` (see <<./splitter.adoc#splitter,Splitter>>)
|
||||
* `@Transformer` (see <<./transformer.adoc#transformer,Transformer>>)
|
||||
* `@InboundChannelAdapter` (see <<./channel-adapter.adoc#channel-adapter,Channel Adapter>>)
|
||||
* `@BridgeFrom` (see <<./bridge.adoc#bridge-annot,Configuring a Bridge with Java Configuration>>)
|
||||
* `@BridgeTo` (see <<./bridge.adoc#bridge-annot,Configuring a Bridge with Java Configuration>>)
|
||||
* `@MessagingGateway` (see <<./gateway.adoc#gateway,Messaging Gateways>>)
|
||||
* `@IntegrationComponentScan` (see <<./overview.adoc#configuration-enable-integration,Configuration and `@EnableIntegration`>>)
|
||||
|
||||
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.
|
||||
@@ -415,12 +415,12 @@ The processing of these annotations creates the same beans as the corresponding
|
||||
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>>.
|
||||
The `MessageHandler` instances (`MessageSource` instances) are also eligible to be tracked by <<./message-history.adoc#message-history,, the message history>>.
|
||||
|
||||
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.adoc#control-bus,Control Bus>>).
|
||||
For these purposes, you should use the `beanName` mentioned earlier in the preceding paragraph.
|
||||
|
||||
[[configuration-using-poller-annotation]]
|
||||
@@ -511,7 +511,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.adoc#endpoint-namespace,Endpoint Namespace Support>> for more information.
|
||||
|
||||
==== Using the `@InboundChannelAdapter` Annotation
|
||||
|
||||
@@ -546,12 +546,12 @@ The first example requires that the default poller has been declared elsewhere i
|
||||
|
||||
Using the `@MessagingGateway` Annotation
|
||||
|
||||
See <<messaging-gateway-annotation>>.
|
||||
See <<./gateway.adoc#messaging-gateway-annotation,`@MessagingGateway` 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 <<./gateway.adoc#messaging-gateway-annotation,`@MessagingGateway` 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.
|
||||
@@ -677,7 +677,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 <<./overview.adoc#endpoint-bean-names,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.
|
||||
@@ -736,7 +736,7 @@ You can use these annotations as meta-annotations as well.
|
||||
|
||||
==== Advising Annotated Endpoints
|
||||
|
||||
See <<advising-with-annotations>>.
|
||||
See <<./handler-advice.adoc#advising-with-annotations,Advising Endpoints Using Annotations>>.
|
||||
|
||||
[[message-mapping-rules]]
|
||||
=== Message Mapping Rules and Conventions
|
||||
|
||||
@@ -11,13 +11,13 @@ The Spring Integration `Core` module includes two enrichers:
|
||||
|
||||
It also includes three adapter-specific header enrichers:
|
||||
|
||||
* <<xml-xpath-header-enricher,XPath Header Enricher (XML Module)>>
|
||||
* <<mail-namespace,Mail Header Enricher (Mail Module)>>
|
||||
* <<xmpp-message-outbound-channel-adapter,XMPP Header Enricher (XMPP Module)>>
|
||||
* <<./xml.adoc#xml-xpath-header-enricher,,XPath Header Enricher (XML Module)>>
|
||||
* <<./mail.adoc#mail-namespace,,Mail Header Enricher (Mail Module)>>
|
||||
* <<./xmpp.adoc#xmpp-message-outbound-channel-adapter,,XMPP Header Enricher (XMPP Module)>>
|
||||
|
||||
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.adoc#spel,Spring Expression Language (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 <<./router.adoc#routing-slip,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.adoc#samples,Spring Integration Samples>>.
|
||||
|
||||
In the following example, a `User` object is passed as the payload of the `Message`:
|
||||
|
||||
|
||||
21
src/reference/asciidoc/core.adoc
Normal file
21
src/reference/asciidoc/core.adoc
Normal file
@@ -0,0 +1,21 @@
|
||||
[[spring-integration-core-messaging]]
|
||||
= Core Messaging
|
||||
|
||||
[[spring-integration-core-msg]]
|
||||
This section covers all aspects of the core messaging API in Spring Integration.
|
||||
It covers messages, message channels, and message endpoints.
|
||||
It also covers many of the enterprise integration patterns, such as filter, router, transformer, service activator , splitter, and aggregator.
|
||||
|
||||
This section also contains material about system management, including the control bus and message history support.
|
||||
|
||||
[[messaging-channels-section]]
|
||||
== Messaging Channels
|
||||
|
||||
// BE SURE TO PRECEDE ALL include:: with a blank line - see https://github.com/asciidoctor/asciidoctor/issues/1297
|
||||
include::./channel.adoc[]
|
||||
|
||||
include::./polling-consumer.adoc[]
|
||||
|
||||
include::./channel-adapter.adoc[]
|
||||
|
||||
include::./bridge.adoc[]
|
||||
@@ -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 <<./configuration.adoc#namespace-taskscheduler,Configuring the Task Scheduler>>.
|
||||
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,7 +186,7 @@ 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.adoc#system-management-chapter,System Management>>.
|
||||
|
||||
[[delayer-release-failures]]
|
||||
==== Release Failures
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
[[spring-integration-endpoints]]
|
||||
= Integration Endpoints
|
||||
|
||||
[[spring-integration-adapters]]
|
||||
This section covers the various channel adapters and messaging gateways provided by Spring Integration to support message-based communication with external systems.
|
||||
|
||||
Each system, from AMQP to Zookeeper, has its own integration requirements, and this section covers them.
|
||||
|
||||
[[endpoint-summary]]
|
||||
== Endpoint Quick Reference Table
|
||||
|
||||
@@ -41,97 +49,97 @@ The following table summarizes the various endpoints with quick links to the app
|
||||
| Outbound Gateway
|
||||
|
||||
| *AMQP*
|
||||
| <<amqp-inbound-channel-adapter>>
|
||||
| <<amqp-outbound-channel-adapter>>
|
||||
| <<amqp-inbound-gateway>>
|
||||
| <<amqp-outbound-gateway>>
|
||||
| <<./amqp.adoc#amqp-inbound-channel-adapter,Inbound Channel Adapter>>
|
||||
| <<./amqp.adoc#amqp-outbound-channel-adapter,Outbound Channel Adapter>>
|
||||
| <<./amqp.adoc#amqp-inbound-gateway,Inbound Gateway>>
|
||||
| <<./amqp.adoc#amqp-outbound-gateway,Outbound Gateway>>
|
||||
|
||||
| *Events*
|
||||
| <<appevent-inbound>>
|
||||
| <<appevent-outbound>>
|
||||
| <<./event.adoc#appevent-inbound,Receiving Spring Application Events>>
|
||||
| <<./event.adoc#appevent-outbound,Sending Spring Application Events>>
|
||||
| N
|
||||
| N
|
||||
|
||||
| *Feed*
|
||||
| <<feed-inbound-channel-adapter>>
|
||||
| <<./feed.adoc#feed-inbound-channel-adapter,Feed Inbound Channel Adapter>>
|
||||
| N
|
||||
| N
|
||||
| N
|
||||
|
||||
| *File*
|
||||
| <<file-reading>> and <<file-tailing>>
|
||||
| <<file-writing>>
|
||||
| <<./file.adoc#file-reading,Reading Files>> and <<./file.adoc#file-tailing,'tail'ing Files>>
|
||||
| <<./file.adoc#file-writing,Writing files>>
|
||||
| N
|
||||
| <<file-writing>>
|
||||
| <<./file.adoc#file-writing,Writing files>>
|
||||
|
||||
| *FTP(S)*
|
||||
| <<ftp-inbound>>
|
||||
| <<ftp-outbound>>
|
||||
| <<./ftp.adoc#ftp-inbound,FTP Inbound Channel Adapter>>
|
||||
| <<./ftp.adoc#ftp-outbound,FTP Outbound Channel Adapter>>
|
||||
| N
|
||||
| <<ftp-outbound-gateway>>
|
||||
| <<./ftp.adoc#ftp-outbound-gateway,FTP Outbound Gateway>>
|
||||
|
||||
| *Gemfire*
|
||||
| <<gemfire-inbound>> and <<gemfire-cq>>
|
||||
| <<gemfire-outbound>>
|
||||
| <<./gemfire.adoc#gemfire-inbound,Inbound Channel Adapter>> and <<./gemfire.adoc#gemfire-cq,Continuous Query Inbound Channel Adapter>>
|
||||
| <<./gemfire.adoc#gemfire-outbound,Outbound Channel Adapter>>
|
||||
| N
|
||||
| N
|
||||
|
||||
| *HTTP*
|
||||
| <<http-namespace>>
|
||||
| <<http-namespace>>
|
||||
| <<http-inbound>>
|
||||
| <<http-outbound>>
|
||||
| <<./http.adoc#http-namespace,HTTP Namespace Support>>
|
||||
| <<./http.adoc#http-namespace,HTTP Namespace Support>>
|
||||
| <<./http.adoc#http-inbound,Http Inbound Components>>
|
||||
| <<./http.adoc#http-outbound,HTTP Outbound Components>>
|
||||
|
||||
| *JDBC*
|
||||
| <<jdbc-inbound-channel-adapter>> and <<stored-procedure-inbound-channel-adapter>>
|
||||
| <<jdbc-outbound-channel-adapter>> and <<stored-procedure-outbound-channel-adapter>>
|
||||
| <<./jdbc.adoc#jdbc-inbound-channel-adapter,Inbound Channel Adapter>> and <<./jdbc.adoc#stored-procedure-inbound-channel-adapter,Stored Procedure Inbound Channel Adapter>>
|
||||
| <<./jdbc.adoc#jdbc-outbound-channel-adapter,Outbound Channel Adapter>> and <<./jdbc.adoc#stored-procedure-outbound-channel-adapter,Stored Procedure Outbound Channel Adapter>>
|
||||
| N
|
||||
| <<jdbc-outbound-gateway>> and <<stored-procedure-outbound-gateway>>
|
||||
| <<./jdbc.adoc#jdbc-outbound-gateway,Outbound Gateway>> and <<./jdbc.adoc#stored-procedure-outbound-gateway,Stored Procedure Outbound Gateway>>
|
||||
|
||||
| *JMS*
|
||||
| <<jms-inbound-channel-adapter>> and <<jms-message-driven-channel-adapter>>
|
||||
| <<jms-outbound-channel-adapter>>
|
||||
| <<jms-inbound-gateway>>
|
||||
| <<jms-outbound-gateway>>
|
||||
| <<./jms.adoc#jms-inbound-channel-adapter,Inbound Channel Adapter>> and <<./jms.adoc#jms-message-driven-channel-adapter,Message-driven Channel Adapter>>
|
||||
| <<./jms.adoc#jms-outbound-channel-adapter,Outbound Channel Adapter>>
|
||||
| <<./jms.adoc#jms-inbound-gateway,Inbound Gateway>>
|
||||
| <<./jms.adoc#jms-outbound-gateway,Outbound Gateway>>
|
||||
|
||||
| *JMX*
|
||||
| <<jmx-notification-listening-channel-adapter>> and <<jmx-attribute-polling-channel-adapter>> and <<tree-polling-channel-adapter>>
|
||||
| <<jmx-notification-publishing-channel-adapter>> and <<jmx-operation-invoking-channel-adapter>>
|
||||
| <<./jmx.adoc#jmx-notification-listening-channel-adapter,Notification-listening Channel Adapter>> and <<./jmx.adoc#jmx-attribute-polling-channel-adapter,Attribute-polling Channel Adapter>> and <<./jmx.adoc#tree-polling-channel-adapter,Tree-polling Channel Adapter>>
|
||||
| <<./jmx.adoc#jmx-notification-publishing-channel-adapter,Notification-publishing Channel Adapter>> and <<./jmx.adoc#jmx-operation-invoking-channel-adapter,Operation-invoking Channel Adapter>>
|
||||
| N
|
||||
| <<jmx-operation-invoking-outbound-gateway>>
|
||||
| <<./jmx.adoc#jmx-operation-invoking-outbound-gateway,Operation-invoking Outbound Gateway>>
|
||||
|
||||
| *JPA*
|
||||
| <<jpa-inbound-channel-adapter>>
|
||||
| <<jpa-outbound-channel-adapter>>
|
||||
| <<./jpa.adoc#jpa-inbound-channel-adapter,Inbound Channel Adapter>>
|
||||
| <<./jpa.adoc#jpa-outbound-channel-adapter,Outbound Channel Adapter>>
|
||||
| N
|
||||
| <<jpa-updating-outbound-gateway>> and <<jpa-retrieving-outbound-gateway>>
|
||||
| <<./jpa.adoc#jpa-updating-outbound-gateway,Updating Outbound Gateway>> and <<./jpa.adoc#jpa-retrieving-outbound-gateway,Retrieving Outbound Gateway>>
|
||||
|
||||
| *Mail*
|
||||
| <<mail-inbound>>
|
||||
| <<mail-outbound>>
|
||||
| <<./mail.adoc#mail-inbound,Mail-receiving Channel Adapter>>
|
||||
| <<./mail.adoc#mail-outbound,Mail-sending Channel Adapter>>
|
||||
| N
|
||||
| N
|
||||
|
||||
| *MongoDB*
|
||||
| <<mongodb-inbound-channel-adapter>>
|
||||
| <<mongodb-outbound-channel-adapter>>
|
||||
| <<./mongodb.adoc#mongodb-inbound-channel-adapter,MongoDB Inbound Channel Adapter>>
|
||||
| <<./mongodb.adoc#mongodb-outbound-channel-adapter,MongoDB Outbound Channel Adapter>>
|
||||
| N
|
||||
| N
|
||||
|
||||
| *MQTT*
|
||||
| <<mqtt-inbound>>
|
||||
| <<mqtt-outbound>>
|
||||
| <<./mqtt.adoc#mqtt-inbound,Inbound (Message-driven) Channel Adapter>>
|
||||
| <<./mqtt.adoc#mqtt-outbound,Outbound Channel Adapter>>
|
||||
| N
|
||||
| N
|
||||
|
||||
| *Redis*
|
||||
| <<redis-inbound-channel-adapter>> and <<redis-queue-inbound-channel-adapter>> and <<redis-store-inbound-channel-adapter>>
|
||||
| <<redis-outbound-channel-adapter>> and <<redis-queue-outbound-channel-adapter>> and <<redis-store-outbound-channel-adapter>>
|
||||
| <<redis-queue-inbound-gateway>>
|
||||
| <<redis-outbound-gateway>> and <<redis-queue-outbound-gateway>>
|
||||
| <<./redis.adoc#redis-inbound-channel-adapter,Redis Inbound Channel Adapter>> and <<./redis.adoc#redis-queue-inbound-channel-adapter,Redis Queue Inbound Channel Adapter>> and <<./redis.adoc#redis-store-inbound-channel-adapter,Redis Store Inbound Channel Adapter>>
|
||||
| <<./redis.adoc#redis-outbound-channel-adapter,Redis Outbound Channel Adapter>> and <<./redis.adoc#redis-queue-outbound-channel-adapter,Redis Queue Outbound Channel Adapter>> and <<./redis.adoc#redis-store-outbound-channel-adapter,RedisStore Outbound Channel Adapter>>
|
||||
| <<./redis.adoc#redis-queue-inbound-gateway,Redis Queue Inbound Gateway>>
|
||||
| <<./redis.adoc#redis-outbound-gateway,Redis Outbound Command Gateway>> and <<./redis.adoc#redis-queue-outbound-gateway,Redis Queue Outbound Gateway>>
|
||||
|
||||
| *Resource*
|
||||
| <<resource-inbound-channel-adapter>>
|
||||
| <<./resource.adoc#resource-inbound-channel-adapter,Resource Inbound Channel Adapter>>
|
||||
| N
|
||||
| N
|
||||
| N
|
||||
@@ -139,68 +147,68 @@ The following table summarizes the various endpoints with quick links to the app
|
||||
| *RMI*
|
||||
| N
|
||||
| N
|
||||
| <<rmi-inbound>>
|
||||
| <<rmi-outbound>>
|
||||
| <<./rmi.adoc#rmi-inbound,Inbound RMI>>
|
||||
| <<./rmi.adoc#rmi-outbound,Outbound RMI>>
|
||||
|
||||
|
||||
| *SFTP*
|
||||
| <<sftp-inbound>>
|
||||
| <<sftp-outbound>>
|
||||
| <<./sftp.adoc#sftp-inbound,SFTP Inbound Channel Adapter>>
|
||||
| <<./sftp.adoc#sftp-outbound,SFTP Outbound Channel Adapter>>
|
||||
| N
|
||||
| <<sftp-outbound-gateway>>
|
||||
| <<./sftp.adoc#sftp-outbound-gateway,SFTP Outbound Gateway>>
|
||||
|
||||
| *STOMP*
|
||||
| <<stomp-inbound-adapter>>
|
||||
| <<stomp-outbound-adapter>>
|
||||
| <<./stomp.adoc#stomp-inbound-adapter,STOMP Inbound Channel Adapter>>
|
||||
| <<./stomp.adoc#stomp-outbound-adapter,STOMP Outbound Channel Adapter>>
|
||||
| N
|
||||
| N
|
||||
|
||||
| *Stream*
|
||||
| <<stream-reading>>
|
||||
| <<stream-writing>>
|
||||
| <<./stream.adoc#stream-reading,Reading from Streams>>
|
||||
| <<./stream.adoc#stream-writing,Writing to Streams>>
|
||||
| N
|
||||
| N
|
||||
|
||||
| *Syslog*
|
||||
| <<syslog-inbound-adapter>>
|
||||
| <<./syslog.adoc#syslog-inbound-adapter,Syslog Inbound Channel Adapter>>
|
||||
| N
|
||||
| N
|
||||
| N
|
||||
|
||||
| *TCP*
|
||||
| <<tcp-adapters>>
|
||||
| <<tcp-adapters>>
|
||||
| <<tcp-gateways>>
|
||||
| <<tcp-gateways>>
|
||||
| <<./ip.adoc#tcp-adapters,TCP Adapters>>
|
||||
| <<./ip.adoc#tcp-adapters,TCP Adapters>>
|
||||
| <<./ip.adoc#tcp-gateways,TCP Gateways>>
|
||||
| <<./ip.adoc#tcp-gateways,TCP Gateways>>
|
||||
|
||||
| *UDP*
|
||||
| <<udp-adapters>>
|
||||
| <<udp-adapters>>
|
||||
| <<./ip.adoc#udp-adapters,UDP Adapters>>
|
||||
| <<./ip.adoc#udp-adapters,UDP Adapters>>
|
||||
| N
|
||||
| N
|
||||
|
||||
| *Web Services*
|
||||
| N
|
||||
| N
|
||||
| <<webservices-inbound>>
|
||||
| <<webservices-outbound>>
|
||||
| <<./ws.adoc#webservices-inbound,Inbound Web Service Gateways>>
|
||||
| <<./ws.adoc#webservices-outbound,Outbound Web Service Gateways>>
|
||||
|
||||
| *Web Sockets*
|
||||
| <<web-socket-inbound-adapter>>
|
||||
| <<web-socket-outbound-adapter>>
|
||||
| <<./web-sockets.adoc#web-socket-inbound-adapter,WebSocket Inbound Channel Adapter>>
|
||||
| <<./web-sockets.adoc#web-socket-outbound-adapter,WebSocket Outbound Channel Adapter>>
|
||||
| N
|
||||
| N
|
||||
|
||||
| *XMPP*
|
||||
| <<xmpp-messages>> and <<xmpp-presence>>
|
||||
| <<xmpp-messages>> and <<xmpp-presence>>
|
||||
| <<./xmpp.adoc#xmpp-messages,XMPP Messages>> and <<./xmpp.adoc#xmpp-presence,XMPP Presence>>
|
||||
| <<./xmpp.adoc#xmpp-messages,XMPP Messages>> and <<./xmpp.adoc#xmpp-presence,XMPP Presence>>
|
||||
| N
|
||||
| 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 <<./core.adoc#spring-integration-core-messaging,Core Messaging>>, Spring Integration provides endpoints for interfacing with Plain Old Java Objects (POJOs).
|
||||
As discussed in <<./channel-adapter.adoc#channel-adapter,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.adoc#gateway,Messaging Gateways>>, 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.
|
||||
The equivalent of an outbound gateway in this context is using a service activator (see <<./service-activator.adoc#service-activator,Service Activator>>) to invoke a method that returns an `Object` of some kind.
|
||||
|
||||
@@ -9,7 +9,7 @@ As mentioned in the overview, message endpoints are responsible for connecting t
|
||||
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.adoc#channel,Message Channels>>, 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: https://www.enterpriseintegrationpatterns.com/PollingConsumer.html[polling consumers] and https://www.enterpriseintegrationpatterns.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.adoc#channel-interfaces-subscribablechannel,`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.adoc#polling-consumer,Poller>> and <<./channel-adapter.adoc#channel-adapter,Channel Adapter>>.
|
||||
|
||||
There are many other configuration options for the polling consumer.
|
||||
For example, the trigger is a required property.
|
||||
@@ -231,7 +231,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.adoc#channel-adapter-namespace-inbound,Configuring An Inbound Channel Adapter>> 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`.
|
||||
@@ -349,7 +349,7 @@ The following example shows the available attributes:
|
||||
</int:poller>
|
||||
----
|
||||
|
||||
For more information, see <<transaction-poller>>.
|
||||
For more information, see <<./transactions.adoc#transaction-poller,Poller Transaction Support>>.
|
||||
|
||||
[[aop-advice-chains]]
|
||||
===== AOP Advice chains
|
||||
@@ -379,7 +379,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 <<./transactions.adoc#transaction-poller,Poller Transaction Support>> for complete configuration details.
|
||||
|
||||
[[taskexecutor-support]]
|
||||
====== TaskExecutor Support
|
||||
@@ -405,7 +405,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 <<./configuration.adoc#namespace-taskscheduler,Configuring the Task Scheduler>>).
|
||||
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.
|
||||
|
||||
@@ -780,7 +780,7 @@ The component name is usually the bean name.
|
||||
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.adoc#file-reading,Reading Files>>).
|
||||
|
||||
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.
|
||||
@@ -825,4 +825,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 <<./zookeeper.adoc#zk-leadership,Zookeeper Leadership Event Handling>> for more information about leadership election and events that use Zookeeper.
|
||||
|
||||
@@ -76,7 +76,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 <<./meta-data-store.adoc#metadata-store,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.
|
||||
|
||||
|
||||
@@ -69,7 +69,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 <<./meta-data-store.adoc#metadata-store,Metadata Store>>).
|
||||
This filter matches on the filename and modified time.
|
||||
|
||||
Since version 4.0, this filter requires a `ConcurrentMetadataStore`.
|
||||
@@ -608,7 +608,7 @@ By default, they append `.writing` to the file name and remove it when the trans
|
||||
Another common technique is to write a second "`marker`" file to indicate that the file transfer is complete.
|
||||
In this scenario, you should not consider `somefile.txt` (for example) to be available for use until `somefile.txt.complete` is also present.
|
||||
Spring Integration version 5.0 introduced new filters to support this mechanism.
|
||||
Implementations are provided for the file system (`FileSystemMarkerFilePresentFileListFilter`), <<ftp-incomplete, FTP>> and <<sftp-incomplete, SFTP>>.
|
||||
Implementations are provided for the file system (`FileSystemMarkerFilePresentFileListFilter`), <<./ftp.adoc#ftp-incomplete,, FTP>> and <<./sftp.adoc#sftp-incomplete,, SFTP>>.
|
||||
They are configurable such that the marker file can have any name, although it is usually related to the file being transferred.
|
||||
See the https://docs.spring.io/spring-integration/api/org/springframework/integration/file/filters/FileSystemMarkerFilePresentFileListFilter.html[Javadoc] for more information.
|
||||
|
||||
@@ -950,7 +950,7 @@ It is often better to use a sequence of transformers than to put all transformat
|
||||
In that case the `File` to `byte[]` conversion might be a logical first step.
|
||||
|
||||
`FileToStringTransformer` extends `AbstractFilePayloadTransformer` convert a `File` object to a `String`.
|
||||
If nothing else, this can be useful for debugging (consider using it with a <<channel-wiretap,wire tap>>).
|
||||
If nothing else, this can be useful for debugging (consider using it with a <<./channel.adoc#channel-wiretap,,wire tap>>).
|
||||
|
||||
To configure file-specific transformers, you can use the appropriate elements from the file namespace, as the following example shows:
|
||||
|
||||
@@ -1038,7 +1038,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 information about these facilities.
|
||||
See <<./ftp.adoc#ftp-streaming,FTP Streaming Inbound Channel Adapter>> and <<./sftp.adoc#sftp-streaming,SFTP Streaming Inbound Channel Adapter>> as well as <<./ftp.adoc#ftp-outbound-gateway,FTP Outbound Gateway>> and <<./sftp.adoc#sftp-outbound-gateway,SFTP Outbound Gateway>> for more information about these facilities.
|
||||
|
||||
When using Java configuration, an additional constructor is available, as the following example shows:
|
||||
|
||||
@@ -1057,7 +1057,7 @@ This line is not included in the sequence header (if `applySequence` is true) no
|
||||
If a file contains only the header line, the file is treated as empty and, therefore, only `FileMarker` instances are emitted during splitting (if markers are enabled -- otherwise, no messages are emitted).
|
||||
By default (if no header name is set), the first line is considered to be data and becomes the payload of the first emitted message.
|
||||
|
||||
If you need more complex logic about header extraction from the file content (not first line, not the whole content of the line, not one particular header, and so on), consider using <<header-enricher, header enricher>> ahead of the `FileSplitter`.
|
||||
If you need more complex logic about header extraction from the file content (not first line, not the whole content of the line, not one particular header, and so on), consider using <<./content-enrichment.adoc#header-enricher,, header enricher>> ahead of the `FileSplitter`.
|
||||
Note that the lines that have been moved to the headers might be filtered downstream from the normal content process.
|
||||
|
||||
==== Configuring with Java Configuration
|
||||
@@ -1119,7 +1119,7 @@ public class FileSplitterApplication {
|
||||
=== Remote Persistent File List Filters
|
||||
|
||||
Inbound and streaming inbound remote file channel adapters (`FTP`, `SFTP`, and other technologies) are configured with corresponding implementations of `AbstractPersistentFileListFilter` by default, configured with an in-memory `MetadataStore`.
|
||||
To run in a cluster, these can be replaced with filters using a shared `MetadataStore` (see <<metadata-store>> for more information).
|
||||
To run in a cluster, these can be replaced with filters using a shared `MetadataStore` (see <<./meta-data-store.adoc#metadata-store,Metadata Store>> for more information).
|
||||
These filters are used to prevent fetching the same file multiple times (unless it's modified time changes).
|
||||
Starting with version 5.2, a file is added to the filter immediately before the file is fetched (and reversed if the fetch fails).
|
||||
|
||||
|
||||
@@ -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 <<./handler-advice.adoc#advising-filters,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).
|
||||
@@ -195,4 +195,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 <<./handler-advice.adoc#advising-with-annotations,Advising Endpoints Using Annotations>>.
|
||||
|
||||
@@ -327,7 +327,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 <<./meta-data-store.adoc#metadata-store,Metadata Store>>).
|
||||
This filter matches on the filename and the remote modified time.
|
||||
|
||||
Since version 4.0, this filter requires a `ConcurrentMetadataStore`.
|
||||
@@ -344,17 +344,17 @@ Unless your application removes files after processing, the adapter will re-proc
|
||||
|
||||
Also, if you configure the `filter` to use a `FtpPersistentAcceptOnceFileListFilter` and the remote file timestamp changes (causing it to be re-fetched), the default local filter does not let this new file be processed.
|
||||
|
||||
For more information about this filter, and how it is used, see <<remote-persistent-flf>>.
|
||||
For more information about this filter, and how it is used, see <<./file.adoc#remote-persistent-flf,Remote Persistent File List Filters>>.
|
||||
|
||||
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 <<./meta-data-store.adoc#metadata-store,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
|
||||
metadata store on every update (if the store implements `Flushable`).
|
||||
|
||||
IMPORTANT: Further, if you use a distributed `MetadataStore` (such as <<redis-metadata-store,Redis>> or <<gemfire-metadata-store,GemFire>>), you can have multiple instances of the same adapter or application and be sure that each file is processed only once.
|
||||
IMPORTANT: Further, if you use a distributed `MetadataStore` (such as <<./redis.adoc#redis-metadata-store,,Redis>> or <<./gemfire.adoc#gemfire-metadata-store,,GemFire>>), you can have multiple instances of the same adapter or application and be sure that each file is processed only once.
|
||||
|
||||
The actual local filter is a `CompositeFileListFilter` that contains the supplied filter and a pattern filter that prevents processing files that are in the process of being downloaded (based on the `temporary-file-suffix`).
|
||||
Files are downloaded with this suffix (the default is `.writing`), and the file is renamed to its final name when the transfer is complete, making it 'visible' to the filter.
|
||||
@@ -474,7 +474,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 <<./file.adoc#watch-service-directory-scanner,`WatchServiceDirectoryScanner`>> for more information.
|
||||
|
||||
|
||||
==== Configuring with Java Configuration
|
||||
@@ -580,7 +580,7 @@ public class FtpJavaApplication {
|
||||
[[ftp-incomplete]]
|
||||
==== Dealing With Incomplete Data
|
||||
|
||||
See <<file-incomplete>>.
|
||||
See <<./file.adoc#file-incomplete,Dealing With Incomplete Data>>.
|
||||
|
||||
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.
|
||||
@@ -595,7 +595,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.adoc#file-splitter,File Splitter>> and <<./transformer.adoc#stream-transformer,Stream Transformer>> for more information about these components.
|
||||
The following example shows how to configure an `inbound-streaming-channel-adapter`:
|
||||
|
||||
====
|
||||
@@ -625,7 +625,7 @@ If you need to allow duplicates, you can use `AcceptAllFileListFilter`.
|
||||
Any other use cases can be handled by `CompositeFileListFilter` (or `ChainFileListFilter`).
|
||||
The Java configuration (<<ftp-streaming-java,later in the document>>) shows one technique to remove the remote file after processing to avoid duplicates.
|
||||
|
||||
For more information about the `FtpPersistentAcceptOnceFileListFilter`, and how it is used, see <<remote-persistent-flf>>.
|
||||
For more information about the `FtpPersistentAcceptOnceFileListFilter`, and how it is used, see <<./file.adoc#remote-persistent-flf,Remote Persistent File List Filters>>.
|
||||
|
||||
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.
|
||||
@@ -783,7 +783,7 @@ public IntegrationFlow flow() {
|
||||
}
|
||||
----
|
||||
|
||||
IMPORTANT: Do not configure a `TaskExecutor` on the poller when using this advice; see <<conditional-pollers>> for more information.
|
||||
IMPORTANT: Do not configure a `TaskExecutor` on the poller when using this advice; see <<./polling-consumer.adoc#conditional-pollers,Conditional Pollers for Message Sources>> for more information.
|
||||
|
||||
[[ftp-max-fetch]]
|
||||
=== Inbound Channel Adapters: Controlling Remote File Fetching
|
||||
@@ -805,7 +805,7 @@ When all files are consumed, the remote fetch is attempted again, to pick up any
|
||||
IMPORTANT: When you deploy multiple instances of an application, we recommend a small `max-fetch-size`, to avoid one instance "`grabbing`" all the files and starving other instances.
|
||||
|
||||
Another use for `max-fetch-size` is if you want to stop fetching remote files but continue to process files that have already been fetched.
|
||||
Setting the `maxFetchSize` property on the `MessageSource` (programmatically, with JMX, or with a <<control-bus,control bus>>) effectively stops the adapter from fetching more files but lets the poller continue to emit messages for files that have previously been fetched.
|
||||
Setting the `maxFetchSize` property on the `MessageSource` (programmatically, with JMX, or with a <<./control-bus.adoc#control-bus,,control bus>>) effectively stops the adapter from fetching more files but lets the poller continue to emit messages for files that have previously been fetched.
|
||||
If the poller is active when the property is changed, the change takes effect on the next poll.
|
||||
|
||||
Starting with version 5.1, the synchronizer can be provided with a `Comparator<FTPFile>`.
|
||||
@@ -1068,7 +1068,7 @@ The `file_remoteDirectory` header provides the remote directory name, and the `f
|
||||
|
||||
The message payload resulting from a `get` operation is a `File` object that represents the retrieved file or an `InputStream` when you use the `-stream` option.
|
||||
The `-stream` option allows retrieving the file as a stream.
|
||||
For text files, a common use case is to combine this operation with a <<file-splitter,file splitter>> or a <<stream-transformer,stream transformer>>.
|
||||
For text files, a common use case is to combine this operation with a <<./file.adoc#file-splitter,,file splitter>> or a <<./transformer.adoc#stream-transformer,,stream transformer>>.
|
||||
When consuming remote files as streams, you are responsible for closing the `Session` after the stream is consumed.
|
||||
For convenience, the `Session` is provided in the `closeableResource` header, which you can access with a convenience method on `IntegrationMessageHeaderAccessor`
|
||||
The following example shows how to do use the covenience method:
|
||||
@@ -1083,7 +1083,7 @@ if (closeable != null) {
|
||||
----
|
||||
====
|
||||
|
||||
Framework components such as the <<file-splitter,file splitter>> and the <<stream-transformer,stream transformer>> automatically close the session after the data is transferred.
|
||||
Framework components such as the <<./file.adoc#file-splitter,,file splitter>> and the <<./transformer.adoc#stream-transformer,,stream transformer>> automatically close the session after the data is transferred.
|
||||
|
||||
The following example shows how to consume a file as a stream:
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
Starting with version 5.1, Spring Integration provides direct support for interfaces in the `java.util.function` package.
|
||||
All messaging endpoints, (Service Activator, Transformer, Filter, etc.) can now refer to `Function` (or `Consumer`) beans.
|
||||
The <<annotations,Messaging Annotations>> can be applied directly on these beans similar to regular `MessageHandler` definitions.
|
||||
The <<./configuration.adoc#annotations,,Messaging Annotations>> can be applied directly on these beans similar to regular `MessageHandler` definitions.
|
||||
For example if you have this `Function` bean definition:
|
||||
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ It lets you configure an interface as a service, as the following example shows:
|
||||
|
||||
With this configuration defined, the `cafeService` can now be injected into other beans, and the code that invokes the methods on that proxied instance of the `Cafe` interface has no awareness of the Spring Integration API.
|
||||
The general approach is similar to that of Spring Remoting (RMI, HttpInvoker, and so on).
|
||||
See the <<samples,"`Samples`">> Appendix for an example that uses the `gateway` element (in the Cafe demo).
|
||||
See the <<./samples.adoc#samples,,"`Samples`">> Appendix for an example that uses the `gateway` element (in the Cafe demo).
|
||||
|
||||
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.
|
||||
@@ -79,7 +79,7 @@ By defining a `default-reply-channel` you can point to a channel of your choosin
|
||||
In this case, that is a `publish-subscribe-channel`.
|
||||
The gateway creates a bridge from it to the temporary, anonymous reply channel that is stored in the header.
|
||||
|
||||
You might also want to explicitly provide a reply channel for monitoring or auditing through an interceptor (for example, <<channel-wiretap, wiretap>>).
|
||||
You might also want to explicitly provide a reply channel for monitoring or auditing through an interceptor (for example, <<./channel.adoc#channel-wiretap,, wiretap>>).
|
||||
To configure a channel interceptor, you need a named channel.
|
||||
|
||||
[[gateway-configuration-annotations]]
|
||||
@@ -311,12 +311,12 @@ 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 <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
Along with the `@MessagingGateway` annotation you can mark a service interface with the `@Profile` annotation to avoid the bean creation, if such a profile is not active.
|
||||
|
||||
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 <<./overview.adoc#configuration-enable-integration,Configuration and `@EnableIntegration`>> for more information.
|
||||
|
||||
[[gateway-calling-no-argument-methods]]
|
||||
==== Invoking No-Argument Methods
|
||||
@@ -463,7 +463,7 @@ This can be useful in asynchronous situations when when you need to propagate an
|
||||
To do so, you can either return an `Exception` (as the `reply` from some service) or throw it.
|
||||
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>>) and a `MessagingTimeoutException` reply on the discard flow.
|
||||
It emulates a socket IO error to the waiting thread by using an `aggregator` with `group-timeout` (see <<./aggregator.adoc#agg-and-group-to,Aggregator and Group Timeout>>) and a `MessagingTimeoutException` reply on the discard flow.
|
||||
|
||||
[[gateway-timeouts]]
|
||||
==== Gateway Timeouts
|
||||
@@ -854,4 +854,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 <<./dsl.adoc#java-dsl-gateway,`IntegrationFlow` as Gateway>> in the Java DSL chapter for options to define gateways through `IntegrationFlows`.
|
||||
|
||||
@@ -262,14 +262,14 @@ Another constructor requires a `Cache`, and the `Region` is created with `GLOBAL
|
||||
[[gemfire-metadata-store]]
|
||||
=== Gemfire Metadata Store
|
||||
|
||||
Version 4.0 introduced a new Gemfire-based `MetadataStore` (<<metadata-store>>) implementation.
|
||||
Version 4.0 introduced a new Gemfire-based `MetadataStore` (<<./meta-data-store.adoc#metadata-store,Metadata Store>>) implementation.
|
||||
You can use the `GemfireMetadataStore` to maintain metadata state across application restarts.
|
||||
This new `MetadataStore` implementation can be used with adapters such as:
|
||||
|
||||
* <<feed-inbound-channel-adapter>>
|
||||
* <<file-reading>>
|
||||
* <<ftp-inbound>>
|
||||
* <<sftp-inbound>>
|
||||
* <<./feed.adoc#feed-inbound-channel-adapter,Feed Inbound Channel Adapter>>
|
||||
* <<./file.adoc#file-reading,Reading Files>>
|
||||
* <<./ftp.adoc#ftp-inbound,FTP Inbound Channel Adapter>>
|
||||
* <<./sftp.adoc#sftp-inbound,SFTP Inbound Channel Adapter>>
|
||||
|
||||
To get these adapters to use the new `GemfireMetadataStore`, declare a Spring bean with a bean name of `metadataStore`.
|
||||
The feed inbound channel adapter automatically picks up and use the declared `GemfireMetadataStore`.
|
||||
|
||||
@@ -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.adoc#metrics-management,Metrics and 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:
|
||||
|
||||
@@ -177,7 +177,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.adoc#gateway,Messaging Gateways>>) 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:
|
||||
|
||||
====
|
||||
@@ -230,11 +230,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 <<./overview.adoc#programming-tips,Programming Tips and Tricks>> 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.adoc#http,HTTP Support>> and <<./webflux.adoc#webflux,WebFlux Support>>, 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`.
|
||||
|
||||
@@ -27,7 +27,7 @@ compile "org.springframework.integration:spring-integration-groovy:{project-vers
|
||||
[[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.adoc#scripting,Scripting Support>> 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:
|
||||
|
||||
@@ -89,7 +89,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.adoc#scripting-script-variable-bindings,Script Variable Bindings>>.
|
||||
|
||||
==== Groovy Script Compiler Customization
|
||||
|
||||
|
||||
@@ -630,7 +630,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.adoc#amqp-strict-ordering,Strict Message 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.
|
||||
@@ -682,9 +682,9 @@ The following example shows `<transactional>` in use:
|
||||
</bean>
|
||||
----
|
||||
|
||||
If you are familiar with the <<jpa, JPA integration components>>, such a configuration is not new, but now we can start a transaction from any point in our flow -- not only from the `<poller>` or a message-driven channel adapter such as <<jms-message-driven-channel-adapter, JMS>>.
|
||||
If you are familiar with the <<./jpa.adoc#jpa,, JPA integration components>>, such a configuration is not new, but now we can start a transaction from any point in our flow -- not only from the `<poller>` or a message-driven channel adapter such as <<./jms.adoc#jms-message-driven-channel-adapter,, JMS>>.
|
||||
|
||||
Java configuration can be simplified by using the `TransactionInterceptorBuilder`, and the result bean name can be used in the <<annotations, messaging annotations>> `adviceChain` attribute, as the following example shows:
|
||||
Java configuration can be simplified by using the `TransactionInterceptorBuilder`, and the result bean name can be used in the <<./configuration.adoc#annotations,, messaging annotations>> `adviceChain` attribute, as the following example shows:
|
||||
|
||||
[source,java]
|
||||
----
|
||||
@@ -829,7 +829,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.adoc#filter,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.
|
||||
|
||||
@@ -840,7 +840,7 @@ Rather, it is discarded.
|
||||
If you want to discard (do nothing with) the duplicate message, the `discardChannel` should be configured with a `NullChannel`, such as the default `nullChannel` bean.
|
||||
|
||||
To maintain state between messages and provide the ability to compare messages for the idempotency, we provide the `MetadataStoreSelector`.
|
||||
It accepts a `MessageProcessor` implementation (which creates a lookup key based on the `Message`) and an optional `ConcurrentMetadataStore` (<<metadata-store>>).
|
||||
It accepts a `MessageProcessor` implementation (which creates a lookup key based on the `Message`) and an optional `ConcurrentMetadataStore` (<<./meta-data-store.adoc#metadata-store,Metadata Store>>).
|
||||
See the https://docs.spring.io/spring-integration/api/org/springframework/integration/selector/MetadataStoreSelector.html[`MetadataStoreSelector` Javadoc] for more information.
|
||||
You can also customize the `value` for `ConcurrentMetadataStore` by using an additional `MessageProcessor`.
|
||||
By default, `MetadataStoreSelector` uses the `timestamp` message header.
|
||||
|
||||
@@ -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.adoc#webflux,WebFlux Support>>.
|
||||
|
||||
You need to include this dependency into your project:
|
||||
|
||||
@@ -1013,7 +1013,7 @@ 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 <<./graph.adoc#integration-graph,Integration Graph>> for more information.
|
||||
|
||||
[[http-samples]]
|
||||
=== HTTP Samples
|
||||
|
||||
12
src/reference/asciidoc/index-header.adoc
Normal file
12
src/reference/asciidoc/index-header.adoc
Normal file
@@ -0,0 +1,12 @@
|
||||
[[spring-integration-reference]]
|
||||
= Spring Integration Reference Guide
|
||||
Mark Fisher; Marius Bogoevici; Iwein Fuld; Jonas Partner; Oleg Zhurakousky; Gary Russell; Dave Syer; Josh Long; David Turanski; Gunnar Hillert; Artem Bilan; Amol Nayak; Jay Bryant
|
||||
|
||||
ifdef::backend-html5[]
|
||||
*{project-version}*
|
||||
endif::[]
|
||||
|
||||
(C) 2009 - 2019 Pivotal Software, Inc.
|
||||
All rights reserved.
|
||||
|
||||
Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.
|
||||
117
src/reference/asciidoc/index-single.adoc
Normal file
117
src/reference/asciidoc/index-single.adoc
Normal file
@@ -0,0 +1,117 @@
|
||||
:numbered:
|
||||
:icons: font
|
||||
:hide-uri-scheme:
|
||||
|
||||
// BE SURE TO PRECEDE ALL include:: with a blank line - see https://github.com/asciidoctor/asciidoctor/issues/1297
|
||||
include::./index-header.adoc[]
|
||||
|
||||
include::./preface.adoc[]
|
||||
|
||||
include::./whats-new.adoc[]
|
||||
|
||||
include::./overview.adoc[]
|
||||
|
||||
include::./core.adoc[]
|
||||
|
||||
include::./message.adoc[leveloffset=-1]
|
||||
|
||||
include::./message-routing.adoc[]
|
||||
|
||||
include::./message-transformation.adoc[]
|
||||
|
||||
include::./messaging-endpoints.adoc[]
|
||||
|
||||
include::./dsl.adoc[]
|
||||
|
||||
include::./system-management.adoc[]
|
||||
|
||||
include::./endpoint-summary.adoc[]
|
||||
|
||||
include::./amqp.adoc[]
|
||||
|
||||
include::./event.adoc[]
|
||||
|
||||
include::./feed.adoc[]
|
||||
|
||||
include::./file.adoc[]
|
||||
|
||||
include::./ftp.adoc[]
|
||||
|
||||
include::./gemfire.adoc[]
|
||||
|
||||
include::./http.adoc[]
|
||||
|
||||
include::./jdbc.adoc[]
|
||||
|
||||
include::./jpa.adoc[]
|
||||
|
||||
include::./jms.adoc[]
|
||||
|
||||
include::./mail.adoc[]
|
||||
|
||||
include::./mongodb.adoc[]
|
||||
|
||||
include::./mqtt.adoc[]
|
||||
|
||||
include::./redis.adoc[]
|
||||
|
||||
include::./resource.adoc[]
|
||||
|
||||
include::./rmi.adoc[]
|
||||
|
||||
include::./sftp.adoc[]
|
||||
|
||||
include::./stomp.adoc[]
|
||||
|
||||
include::./stream.adoc[]
|
||||
|
||||
include::./syslog.adoc[]
|
||||
|
||||
include::./ip.adoc[]
|
||||
|
||||
include::./webflux.adoc[]
|
||||
|
||||
include::./web-sockets.adoc[]
|
||||
|
||||
include::./ws.adoc[]
|
||||
|
||||
include::./xml.adoc[]
|
||||
|
||||
include::./xmpp.adoc[]
|
||||
|
||||
include::./zookeeper.adoc[]
|
||||
|
||||
[[spring-integration-appendices]]
|
||||
= Appendices
|
||||
|
||||
[[spring-integration-adapters-advanced]]
|
||||
The appendices cover advanced topics and additional resources.
|
||||
|
||||
The last appendix covers the history of Spring Integration.
|
||||
|
||||
[appendix]
|
||||
include::./spel.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./message-publishing.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./transactions.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./security.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./configuration.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./testing.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./samples.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./resources.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./history.adoc[]
|
||||
@@ -1,167 +1,65 @@
|
||||
[[spring-integration-reference]]
|
||||
= Spring Integration
|
||||
:toc: left
|
||||
:toclevels: 4
|
||||
:numbered:
|
||||
:icons: font
|
||||
:hide-uri-scheme:
|
||||
Mark Fisher; Marius Bogoevici; Iwein Fuld; Jonas Partner; Oleg Zhurakousky; Gary Russell; Dave Syer; Josh Long; David Turanski; Gunnar Hillert; Artem Bilan; Amol Nayak; Jay Bryant
|
||||
|
||||
ifdef::backend-html5[]
|
||||
*{project-version}*
|
||||
endif::[]
|
||||
|
||||
(C) 2009 - 2019 Pivotal Software, Inc.
|
||||
All rights reserved.
|
||||
|
||||
Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.
|
||||
|
||||
include::./preface.adoc[]
|
||||
|
||||
[[whats-new-part]]
|
||||
= What's New?
|
||||
|
||||
[[spring-integration-intro-new]]
|
||||
For those who are already familiar with Spring Integration, this chapter provides a brief overview of the new features of version 5.2.
|
||||
|
||||
If you are interested in the changes and features that were introduced in earlier versions, see the <<history>>.
|
||||
|
||||
include::./whats-new.adoc[]
|
||||
|
||||
[[spring-integration-introduction]]
|
||||
= Overview of Spring Integration Framework
|
||||
|
||||
[[spring-integration-intro]]
|
||||
Spring Integration provides an extension of the Spring programming model to support the well known https://www.enterpriseintegrationpatterns.com/[Enterprise Integration Patterns].
|
||||
It enables lightweight messaging within Spring-based applications and supports integration with external systems through declarative adapters.
|
||||
Those adapters provide a higher level of abstraction over Spring's support for remoting, messaging, and scheduling.
|
||||
|
||||
Spring Integration's primary goal is to provide a simple model for building enterprise integration solutions while maintaining the separation of concerns that is essential for producing maintainable, testable code.
|
||||
|
||||
include::./overview.adoc[]
|
||||
|
||||
[[spring-integration-core-messaging]]
|
||||
= Core Messaging
|
||||
|
||||
[[spring-integration-core-msg]]
|
||||
This section covers all aspects of the core messaging API in Spring Integration.
|
||||
It covers messages, message channels, and message endpoints.
|
||||
It also covers many of the enterprise integration patterns, such as filter, router, transformer, service activator , splitter, and aggregator.
|
||||
|
||||
This section also contains material about system management, including the control bus and message history support.
|
||||
|
||||
// BE SURE TO PRECEDE ALL include:: with a blank line - see https://github.com/asciidoctor/asciidoctor/issues/1297
|
||||
include::./messaging-channels.adoc[]
|
||||
|
||||
include::./message.adoc[leveloffset=-1]
|
||||
|
||||
include::./message-routing.adoc[]
|
||||
|
||||
include::./message-transformation.adoc[]
|
||||
|
||||
include::./messaging-endpoints.adoc[]
|
||||
|
||||
include::./dsl.adoc[]
|
||||
|
||||
include::./system-management.adoc[]
|
||||
|
||||
[[spring-integration-endpoints]]
|
||||
= Integration Endpoints
|
||||
|
||||
[[spring-integration-adapters]]
|
||||
This section covers the various channel adapters and messaging gateways provided by Spring Integration to support message-based communication with external systems.
|
||||
|
||||
Each system, from AMQP to Zookeeper, has its own integration requirements, and this section covers them.
|
||||
|
||||
// BE SURE TO PRECEDE ALL include:: with a blank line - see https://github.com/asciidoctor/asciidoctor/issues/1297
|
||||
include::./endpoint-summary.adoc[]
|
||||
|
||||
include::./amqp.adoc[]
|
||||
|
||||
include::./event.adoc[]
|
||||
|
||||
include::./feed.adoc[]
|
||||
|
||||
include::./file.adoc[]
|
||||
|
||||
include::./ftp.adoc[]
|
||||
|
||||
include::./gemfire.adoc[]
|
||||
|
||||
include::./http.adoc[]
|
||||
|
||||
include::./jdbc.adoc[]
|
||||
|
||||
include::./jpa.adoc[]
|
||||
|
||||
include::./jms.adoc[]
|
||||
|
||||
include::./mail.adoc[]
|
||||
|
||||
include::./mongodb.adoc[]
|
||||
|
||||
include::./mqtt.adoc[]
|
||||
|
||||
include::./redis.adoc[]
|
||||
|
||||
include::./resource.adoc[]
|
||||
|
||||
include::./rmi.adoc[]
|
||||
|
||||
include::./sftp.adoc[]
|
||||
|
||||
include::./stomp.adoc[]
|
||||
|
||||
include::./stream.adoc[]
|
||||
|
||||
include::./syslog.adoc[]
|
||||
|
||||
include::./ip.adoc[]
|
||||
|
||||
include::./webflux.adoc[]
|
||||
|
||||
include::./web-sockets.adoc[]
|
||||
|
||||
include::./ws.adoc[]
|
||||
|
||||
include::./xml.adoc[]
|
||||
|
||||
include::./xmpp.adoc[]
|
||||
|
||||
include::./zookeeper.adoc[]
|
||||
// BE SURE TO PRECEDE ALL include:: with a blank line - see https://github.com/asciidoctor/asciidoctor/issues/1297
|
||||
|
||||
[[spring-integration-appendices]]
|
||||
= Appendices
|
||||
|
||||
[[spring-integration-adapters-advanced]]
|
||||
The appendices cover advanced topics and additional resources.
|
||||
|
||||
The last appendix covers the history of Spring Integration.
|
||||
|
||||
[appendix]
|
||||
include::./spel.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./message-publishing.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./transactions.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./security.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./configuration.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./testing.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./samples.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./resources.adoc[]
|
||||
|
||||
[appendix]
|
||||
include::./history.adoc[]
|
||||
:toc!:
|
||||
|
||||
include::./index-header.adoc[]
|
||||
|
||||
Welcome to the Spring Integration reference documentation! This documentation is also available
|
||||
as single searchable link:index-single.html[html] and link:../pdf/spring-integration-reference.pdf[pdf] documents.
|
||||
|
||||
[horizontal]
|
||||
<<./preface.adoc#preface,Preface>> ::
|
||||
<<./whats-new.adoc#whats-new,What's New>> ::
|
||||
<<./overview.adoc#spring-integration-introduction,Overview>> ::
|
||||
<<./core.adoc#spring-integration-core-messaging,Core Messaging>> ::
|
||||
<<./message.adoc#message,Message>> ::
|
||||
<<./message-routing.adoc#messaging-routing-chapter,Message Routing>> ::
|
||||
<<./message-transformation.adoc#messaging-transformation-chapter]],Message Transformation>> ::
|
||||
<<./messaging-endpoints.adoc#messaging-endpoints-chapter,Messaging Endpoints>> ::
|
||||
<<./dsl.adoc#java-dsl,Java DSL>> ::
|
||||
<<./system-management.adoc#system-management-chapter,System Management>> ::
|
||||
|
||||
[horizontal]
|
||||
**Integration Endpoints** ::
|
||||
|
||||
[horizontal]
|
||||
<<./endpoint-summary.adoc#spring-integration-endpoints,Integration Endpoint Summary>> ::
|
||||
<<./amqp.adoc#amqp,AMQP Support>> ::
|
||||
<<./event.adoc#applicationevent,Spring `ApplicationEvent` Support>> ::
|
||||
<<./feed.adoc#feed,Feed Adapter>> ::
|
||||
<<./file.adoc#files,File Support>> ::
|
||||
<<./ftp.adoc#ftp,FTP/FTPS Adapters>> ::
|
||||
<<./gemfire.adoc#gemfire,Pivotal GemFire and Apache Geode Support>> ::
|
||||
<<./http.adoc#http,HTTP Support>> ::
|
||||
<<./jdbc.adoc#jdbc,JDBC Support>> ::
|
||||
<<./jpa.adoc#jpa,JPA Support>> ::
|
||||
<<./jms.adoc#jms,JMS Support>> ::
|
||||
<<./mail.adoc#mail,Mail Support>> ::
|
||||
<<./mongodb.adoc#mongodb,MongoDb Support>> ::
|
||||
<<./mqtt.adoc#mqtt,MQTT Support>> ::
|
||||
<<./redis.adoc#redis,Redis Support>> ::
|
||||
<<./resource.adoc#resource,Resource Support>> ::
|
||||
<<./rmi.adoc#[[rmi,RMI Support>> ::
|
||||
<<./sftp.adoc#sftp,SFTP Adapters>> ::
|
||||
<<./stomp.adoc#stomp,STOMP Support>> ::
|
||||
<<./stream.adoc#stream,Stream Support>> ::
|
||||
<<./syslog.adoc#syslog,Syslog Support>> ::
|
||||
<<./ip.adoc#ip,TCP and UDP Support>> ::
|
||||
<<./webflux.adoc#webflux,WebFlux Support>> ::
|
||||
<<./web-sockets.adoc#web-sockets,WebSockets Support>> ::
|
||||
<<./ws.adoc#ws,Web Services Support>> ::
|
||||
<<./xml.adoc#xml,XML Support - Dealing with XML Payloads>> ::
|
||||
<<./xmpp.adoc#xmpp,XMPP Support>> ::
|
||||
<<./zookeeper.adoc#zookeeper,Zookeeper Support>> ::
|
||||
|
||||
[horizontal]
|
||||
**Appendices** ::
|
||||
|
||||
[horizontal]
|
||||
<<./spel.adoc#spel,Spring Expression Language (SpEL)>> ::
|
||||
<<./message-publishing.adoc#message-publishing,Message Publishing>> ::
|
||||
<<./transactions.adoc#transactions,Transaction Support>> ::
|
||||
<<./security.adoc#security,Security in Spring Integration>> ::
|
||||
<<./configuration.adoc#configuration,Configuration>> ::
|
||||
<<./testing.adoc#testing,Testing support>> ::
|
||||
<<./samples.adoc#samples,Spring Integration Samples>> ::
|
||||
<<./resources.adoc#resources,Additional Resources>> ::
|
||||
<<./history.adoc#history,Change History>> ::
|
||||
|
||||
@@ -54,7 +54,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.adoc#gateway-proxy,Enter the `GatewayProxyFactoryBean`>>.
|
||||
|
||||
[[udp-adapters]]
|
||||
=== UDP Adapters
|
||||
@@ -631,7 +631,7 @@ The following example shows how to configure a connection interceptor factory ch
|
||||
=== TCP Connection Events
|
||||
|
||||
Beginning with version 3.0, changes to `TcpConnection` instances are reported by `TcpConnectionEvent` instances.
|
||||
`TcpConnectionEvent` is a subclass of `ApplicationEvent` and can thus be received by any `ApplicationListener` defined in the `ApplicationContext` -- for example <<appevent-inbound,an event inbound channel adapter>>.
|
||||
`TcpConnectionEvent` is a subclass of `ApplicationEvent` and can thus be received by any `ApplicationListener` defined in the `ApplicationContext` -- for example <<./event.adoc#appevent-inbound,,an event inbound channel adapter>>.
|
||||
|
||||
`TcpConnectionEvents` have the following properties:
|
||||
|
||||
@@ -643,7 +643,7 @@ You can use this, for example, to determine the remote IP Address with `getHostA
|
||||
|
||||
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 <<./event.adoc#appevent-inbound,Receiving Spring Application Events>>) 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.
|
||||
@@ -738,7 +738,7 @@ Two additional attributes support this mechanism.
|
||||
The `retry-interval` specifies (in milliseconds) how often the framework attempts to reconnect after a connection failure.
|
||||
The `scheduler` supplies a `TaskScheduler` to schedule the connection attempts and to test that the connection is still active.
|
||||
|
||||
If you don't provide a scheduler, the framework's default <<namespace-taskscheduler, taskScheduler>> bean is used.
|
||||
If you don't provide a scheduler, the framework's default <<./configuration.adoc#namespace-taskscheduler,, taskScheduler>> bean is used.
|
||||
|
||||
For an outbound adapter, the connection is normally established when the first message is sent.
|
||||
The `client-mode="true"` on an outbound adapter causes the connection to be established when the adapter is started.
|
||||
@@ -1819,7 +1819,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 <<./configuration.adoc#namespace-taskscheduler,Configuring the Task Scheduler>>.
|
||||
|===
|
||||
|
||||
The following table describes attributes that you can set to configure TCP outbound channel adapters:
|
||||
@@ -1857,7 +1857,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 <<./configuration.adoc#namespace-taskscheduler,Configuring the Task Scheduler>>.
|
||||
|===
|
||||
|
||||
The following table describes attributes that you can set to configure TCP inbound gateways:
|
||||
@@ -1908,7 +1908,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 <<./configuration.adoc#namespace-taskscheduler,Configuring the Task Scheduler>>.
|
||||
|===
|
||||
|
||||
The following table describes attributes that you can set to configure TCP outbound gateways:
|
||||
|
||||
@@ -175,7 +175,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.adoc#channel-adapter-namespace-inbound,Configuring An Inbound Channel Adapter>>.
|
||||
|
||||
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.
|
||||
@@ -670,7 +670,7 @@ 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.adoc#jmx-mbean-exporter,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`.
|
||||
@@ -1089,15 +1089,15 @@ 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 <<./meta-data-store.adoc#metadata-store,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:
|
||||
|
||||
|
||||
* <<feed-inbound-channel-adapter,Feed inbound channel adapters>>
|
||||
* <<file-reading,files>>
|
||||
* <<ftp-inbound,FTP inbound channel adapters>>
|
||||
* <<sftp-inbound,SFTP inbound channel adapters>>
|
||||
* <<./feed.adoc#feed-inbound-channel-adapter,,Feed inbound channel adapters>>
|
||||
* <<./file.adoc#file-reading,,files>>
|
||||
* <<./ftp.adoc#ftp-inbound,,FTP inbound channel adapters>>
|
||||
* <<./sftp.adoc#sftp-inbound,,SFTP inbound channel adapters>>
|
||||
|
||||
To configure these adapters to use the `JdbcMetadataStore`, declare a Spring bean by using a bean name of `metadataStore`.
|
||||
The Feed inbound channel adapter and the feed inbound channel adapter both automatically pick up and use the declared `JdbcMetadataStore`, as the following example shows:
|
||||
|
||||
@@ -147,7 +147,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.adoc#gateway-proxy,Enter the `GatewayProxyFactoryBean`>>.
|
||||
The following example shows how to set an error channel on a message-driven channel adapter:
|
||||
|
||||
====
|
||||
@@ -274,7 +274,7 @@ 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.adoc#gateway-proxy,Enter the `GatewayProxyFactoryBean`>>.
|
||||
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>>.
|
||||
|
||||
@@ -370,7 +370,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.adoc#metrics-management,Metrics and 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`.
|
||||
@@ -397,7 +397,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.adoc#metrics-management,Metrics and Management>>.
|
||||
|
||||
@IntegrationManagedResource::
|
||||
Similar to the `@ManagedResource` annotation, the `@IntegrationManagedResource` marks a class as being eligible to be exported as an MBean.
|
||||
@@ -459,4 +459,4 @@ public void stopActiveComponents(long howLong)
|
||||
----
|
||||
====
|
||||
|
||||
Its use and operation are described in <<jmx-shutdown>>.
|
||||
Its use and operation are described in <<./shutdown.adoc#jmx-shutdown,Orderly Shutdown>>.
|
||||
|
||||
@@ -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.adoc#channel-wiretap,Wire Tap>>.
|
||||
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`.
|
||||
|
||||
@@ -47,7 +47,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.adoc#transformer-namespace,Configuring a Transformer with XML>> 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.
|
||||
@@ -118,7 +118,7 @@ This property now controls the rendering regardless of whether a header mapper i
|
||||
It now allows body-only rendering when a header mapper is provided.
|
||||
|
||||
Starting with version 5.2, the `autoCloseFolder` option is provided on the mail receiver.
|
||||
Setting it to `false` doesn't close the folder automatically after a fetch, but instead an `IntegrationMessageHeaderAccessor.CLOSEABLE_RESOURCE` header (see <<message-header-accessor>> for more information) is populated into every message to producer from the channel adapter.
|
||||
Setting it to `false` doesn't close the folder automatically after a fetch, but instead an `IntegrationMessageHeaderAccessor.CLOSEABLE_RESOURCE` header (see <<./message.adoc#message-header-accessor,`MessageHeaderAccessor` API>> for more information) is populated into every message to producer from the channel adapter.
|
||||
It is the target application's responsibility to call the `close()` on this header whenever it is necessary in the downstream flow:
|
||||
|
||||
====
|
||||
@@ -262,7 +262,7 @@ mail.smtp.port=587
|
||||
----
|
||||
====
|
||||
|
||||
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.adoc#endpoint-namespace,Endpoint Namespace Support>>).
|
||||
|
||||
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.
|
||||
@@ -515,7 +515,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 <<./transactions.adoc#transaction-synchronization,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.
|
||||
|
||||
@@ -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.adoc#jmx-mbean-exporter,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`.
|
||||
|
||||
@@ -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 <<./overview.adoc#configuration-enable-integration,Configuration and `@EnableIntegration`>> 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.
|
||||
|
||||
@@ -316,7 +316,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>>.
|
||||
See <<./channel.adoc#channel-wiretap,Wire Tap>>.
|
||||
|
||||
[[scheduled-producer]]
|
||||
==== Producing and Publishing Messages Based on a Scheduled Trigger
|
||||
|
||||
@@ -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.adoc#channel-configuration-queuechannel,,QueueChannel>>, <<./aggregator.adoc#aggregator,,Aggregator>>, <<./delayer.adoc#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
|
||||
@@ -40,10 +40,10 @@ However, the typical production application needs a more robust option, not only
|
||||
Therefore, we also provide `MessageStore` implementations for a variety of data-stores.
|
||||
The following is a complete list of supported implementations:
|
||||
|
||||
* <<jdbc-message-store>>: Uses an RDBMS to store messages
|
||||
* <<redis-message-store>>: Uses a Redis key/value datastore to store messages
|
||||
* <<mongodb-message-store>>: Uses a MongoDB document store to store messages
|
||||
* <<gemfire-message-store>>: Uses a Gemfire distributed cache to store messages
|
||||
* <<./jdbc.adoc#jdbc-message-store,JDBC Message Store>>: Uses an RDBMS to store messages
|
||||
* <<./redis.adoc#redis-message-store,Redis Message Store>>: Uses a Redis key/value datastore to store messages
|
||||
* <<./mongodb.adoc#mongodb-message-store,MongoDB Message Store>>: Uses a MongoDB document store to store messages
|
||||
* <<./gemfire.adoc#gemfire-message-store,Gemfire Message Store>>: Uses a Gemfire distributed cache to store messages
|
||||
|
||||
[IMPORTANT]
|
||||
=====
|
||||
@@ -66,7 +66,7 @@ Also, consider what happens when you configure a message-flow as follows: gatewa
|
||||
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 <<./content-enrichment.adoc#header-enricher,Header Enricher>>.
|
||||
=====
|
||||
|
||||
Spring Integration 4.0 introduced two new interfaces:
|
||||
@@ -77,9 +77,9 @@ Spring Integration 4.0 introduced two new interfaces:
|
||||
The real behavior depends on the implementation.
|
||||
The framework provides the following implementations, which can be used as a persistent `MessageStore` for `QueueChannel` and `PriorityChannel`:
|
||||
|
||||
* <<redis-cms>>
|
||||
* <<mongodb-priority-channel-message-store>>
|
||||
* <<jdbc-message-store-channels>>
|
||||
* <<./redis.adoc#redis-cms,Redis Channel Message Stores>>
|
||||
* <<./mongodb.adoc#mongodb-priority-channel-message-store,MongoDB Channel Message Store>>
|
||||
* <<./jdbc.adoc#jdbc-message-store-channels,Backing Message Channels>>
|
||||
|
||||
[[sms-caution]]
|
||||
[WARNING]
|
||||
@@ -115,13 +115,13 @@ 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.adoc#aggregator,Aggregator>> and <<./resequencer.adoc#resequencer,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.
|
||||
|
||||
Our performance tests for lazy-load on MongoDB `MessageStore` (<<mongodb-message-store>>) and
|
||||
`<aggregator>` (<<aggregator>>)
|
||||
Our performance tests for lazy-load on MongoDB `MessageStore` (<<./mongodb.adoc#mongodb-message-store,MongoDB Message Store>>) and
|
||||
`<aggregator>` (<<./aggregator.adoc#aggregator,Aggregator>>)
|
||||
use a custom `release-strategy` similar to the following:
|
||||
|
||||
====
|
||||
|
||||
@@ -152,7 +152,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 <<./handler-advice.adoc#idempotent-receiver,Idempotent Receiver Enterprise Integration Pattern>>.
|
||||
|
||||
| IntegrationMessageHeaderAccessor.
|
||||
CLOSEABLE_RESOURCE
|
||||
@@ -172,7 +172,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 <<./polling-consumer.adoc#deferred-acks-message-source,Deferred Acknowledgment Pollable Message Source>>.
|
||||
|===
|
||||
|
||||
Convenient typed getters for some of these headers are provided on the `IntegrationMessageHeaderAccessor` class, as the following example shows:
|
||||
@@ -207,7 +207,7 @@ List<List<Object>>
|
||||
ROUTING_SLIP
|
||||
| java.util.
|
||||
Map<List<Object>, Integer>
|
||||
| See <<routing-slip>>.
|
||||
| See <<./router.adoc#routing-slip,Routing Slip>>.
|
||||
|===
|
||||
|
||||
[[message-id-generation]]
|
||||
@@ -239,18 +239,18 @@ The `MessageHeaders.ID` and `MessageHeaders.TIMESTAMP` are read-only headers and
|
||||
|
||||
Since version 4.3.2, the `MessageBuilder` provides the `readOnlyHeaders(String... readOnlyHeaders)` API to customize a list of headers that should not be copied from an upstream `Message`.
|
||||
Only the `MessageHeaders.ID` and `MessageHeaders.TIMESTAMP` are read only by default.
|
||||
The global `spring.integration.readOnly.headers` property (see <<global-properties>>) is provided to customize `DefaultMessageBuilderFactory` for framework components.
|
||||
This can be useful when you would like do not populate some out-of-the-box headers, such as `contentType` by the `ObjectToJsonTransformer` (see <<json-transformers>>).
|
||||
The global `spring.integration.readOnly.headers` property (see <<./configuration.adoc#global-properties,Global Properties>>) is provided to customize `DefaultMessageBuilderFactory` for framework components.
|
||||
This can be useful when you would like do not populate some out-of-the-box headers, such as `contentType` by the `ObjectToJsonTransformer` (see <<./transformer.adoc#json-transformers,JSON Transformers>>).
|
||||
|
||||
When you try to build a new message using `MessageBuilder`, this kind of header is ignored and a particular `INFO` message is emitted to logs.
|
||||
|
||||
Starting with version 5.0, <<gateway,Messaging Gateway>>, <<header-enricher,Header Enricher>>, <<payload-enricher,Content Enricher>> and <<header-filter,Header Filter>> do not let you configure the `MessageHeaders.ID` and `MessageHeaders.TIMESTAMP` header names when `DefaultMessageBuilderFactory` is used, and they throw `BeanInitializationException`.
|
||||
Starting with version 5.0, <<./gateway.adoc#gateway,,Messaging Gateway>>, <<./content-enrichment.adoc#header-enricher,,Header Enricher>>, <<./content-enrichment.adoc#payload-enricher,,Content Enricher>> and <<./transformer.adoc#header-filter,,Header Filter>> do not let you configure the `MessageHeaders.ID` and `MessageHeaders.TIMESTAMP` header names when `DefaultMessageBuilderFactory` is used, and they throw `BeanInitializationException`.
|
||||
|
||||
[[header-propagation]]
|
||||
===== Header Propagation
|
||||
|
||||
When messages are processed (and modified) by message-producing endpoints (such as a <<service-activator,service activator>>), in general, inbound headers are propagated to the outbound message.
|
||||
One exception to this is a <<transformer,transformer>>, when a complete message is returned to the framework.
|
||||
When messages are processed (and modified) by message-producing endpoints (such as a <<./service-activator.adoc#service-activator,,service activator>>), in general, inbound headers are propagated to the outbound message.
|
||||
One exception to this is a <<./transformer.adoc#transformer,,transformer>>, when a complete message is returned to the framework.
|
||||
In that case, the user code is responsible for the entire outbound message.
|
||||
When a transformer just returns the payload, the inbound headers are propagated.
|
||||
Also, a header is only propagated if it does not already exist in the outbound message, letting you change header values as needed.
|
||||
@@ -268,7 +268,7 @@ In that case, the service activator behaves the same way as a transformer and an
|
||||
The `notPropagatedHeaders()` option is available in the `ConsumerEndpointSpec` for the Java DSL
|
||||
It is also available for XML configuration of the `<service-activator>` component as a `not-propagated-headers` attribute.
|
||||
|
||||
IMPORTANT: Header propagation suppression does not apply to those endpoints that do not modify the message, such as <<bridge,bridges>> and <<router,routers>>.
|
||||
IMPORTANT: Header propagation suppression does not apply to those endpoints that do not modify the message, such as <<./bridge.adoc#bridge,,bridges>> and <<./router.adoc#router,,routers>>.
|
||||
|
||||
[[message-implementations]]
|
||||
==== Message Implementations
|
||||
|
||||
@@ -1,11 +0,0 @@
|
||||
[[messaging-channels-section]]
|
||||
== Messaging Channels
|
||||
|
||||
// BE SURE TO PRECEDE ALL include:: with a blank line - see https://github.com/asciidoctor/asciidoctor/issues/1297
|
||||
include::./channel.adoc[]
|
||||
|
||||
include::./polling-consumer.adoc[]
|
||||
|
||||
include::./channel-adapter.adoc[]
|
||||
|
||||
include::./bridge.adoc[]
|
||||
@@ -14,11 +14,11 @@ This means that, upon restart, you may end up with duplicate entries.
|
||||
If you need to persist metadata between application context restarts, the framework provides the following persistent `MetadataStores`:
|
||||
|
||||
* `PropertiesPersistingMetadataStore`
|
||||
* <<gemfire-metadata-store>>
|
||||
* <<jdbc-metadata-store>>
|
||||
* <<mongodb-metadata-store>>
|
||||
* <<redis-metadata-store>>
|
||||
* <<zk-metadata-store>>
|
||||
* <<./gemfire.adoc#gemfire-metadata-store,Gemfire Metadata Store>>
|
||||
* <<./jdbc.adoc#jdbc-metadata-store,JDBC Metadata Store>>
|
||||
* <<./mongodb.adoc#mongodb-metadata-store,MongoDB Metadata Store>>
|
||||
* <<./redis.adoc#redis-metadata-store,Redis Metadata Store>>
|
||||
* <<./zookeeper.adoc#zk-metadata-store,Zookeeper Metadata Store>>
|
||||
|
||||
The `PropertiesPersistingMetadataStore` is backed by a properties file and a https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/util/PropertiesPersister.html[`PropertiesPersister`].
|
||||
|
||||
@@ -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 <<./handler-advice.adoc#idempotent-receiver,Idempotent Receiver Enterprise Integration Pattern>>.
|
||||
|
||||
[[metadatastore-listener]]
|
||||
==== `MetadataStoreListener`
|
||||
|
||||
@@ -8,7 +8,7 @@ In recent versions, we have relied more on Micrometer (see https://micrometer.io
|
||||
==== Configuring Metrics Capture
|
||||
|
||||
NOTE: Prior to version 4.2, metrics were only available when JMX was enabled.
|
||||
See <<jmx>>.
|
||||
See <<./jmx.adoc#jmx,JMX Support>>.
|
||||
|
||||
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.
|
||||
@@ -87,7 +87,7 @@ At runtime, counts and statistics can be obtained by calling `getChannelMetrics`
|
||||
|
||||
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.adoc#jmx,JMX Support>>), `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.
|
||||
|
||||
@@ -176,15 +176,15 @@ 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 <<./meta-data-store.adoc#metadata-store,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:
|
||||
|
||||
|
||||
* <<feed-inbound-channel-adapter,Feed>>
|
||||
* <<file-reading,File>>
|
||||
* <<ftp-inbound,FTP>>
|
||||
* <<sftp-inbound,SFTP>>
|
||||
* <<./feed.adoc#feed-inbound-channel-adapter,,Feed>>
|
||||
* <<./file.adoc#file-reading,,File>>
|
||||
* <<./ftp.adoc#ftp-inbound,,FTP>>
|
||||
* <<./sftp.adoc#sftp-inbound,,SFTP>>
|
||||
|
||||
To instruct these adapters to use the new `MongoDbMetadataStore`, declare a Spring bean with a bean name of `metadataStore`.
|
||||
The feed inbound channel adapter automatically picks up and use the declared `MongoDbMetadataStore`.
|
||||
@@ -304,7 +304,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 <<./transactions.adoc#transaction-synchronization,Transaction Synchronization>>.
|
||||
|
||||
[[mongodb-outbound-channel-adapter]]
|
||||
=== MongoDB Outbound Channel Adapter
|
||||
|
||||
@@ -1,3 +1,13 @@
|
||||
[[spring-integration-introduction]]
|
||||
= Overview of Spring Integration Framework
|
||||
|
||||
[[spring-integration-intro]]
|
||||
Spring Integration provides an extension of the Spring programming model to support the well known https://www.enterpriseintegrationpatterns.com/[Enterprise Integration Patterns].
|
||||
It enables lightweight messaging within Spring-based applications and supports integration with external systems through declarative adapters.
|
||||
Those adapters provide a higher level of abstraction over Spring's support for remoting, messaging, and scheduling.
|
||||
|
||||
Spring Integration's primary goal is to provide a simple model for building enterprise integration solutions while maintaining the separation of concerns that is essential for producing maintainable, testable code.
|
||||
|
||||
[[overview]]
|
||||
== Spring Integration Overview
|
||||
|
||||
@@ -92,7 +102,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.adoc#channel-implementations,Message Channel Implementations>> has a detailed discussion of the variety of channel implementations available in Spring Integration.
|
||||
|
||||
[[overview-components-endpoint]]
|
||||
==== Message Endpoint
|
||||
@@ -330,7 +340,7 @@ There is one special case where a third bean is created: For architectural reaso
|
||||
This wrapper supports request handler advice handling and emits the normal 'produced no reply' debug log messages.
|
||||
Its bean name is the handler bean name plus `.wrapper` (when there is an `@EndpointId` -- otherwise, it is the normal generated handler name).
|
||||
|
||||
Similarly <<pollable-message-source, Pollable Message Sources>> create two beans, a `SourcePollingChannelAdapter` (SPCA) and a `MessageSource`.
|
||||
Similarly <<./polling-consumer.adoc#pollable-message-source,, Pollable Message Sources>> create two beans, a `SourcePollingChannelAdapter` (SPCA) and a `MessageSource`.
|
||||
|
||||
Consider the following XML configuration:
|
||||
|
||||
@@ -414,14 +424,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 <<./gateway.adoc#messaging-gateway-annotation,`@MessagingGateway` 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 <<./message-publishing.adoc#publisher-annotation,Annotation-driven Configuration with the `@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 <<./channel.adoc#global-channel-configuration-interceptors,Global Channel Interceptor Configuration>>).
|
||||
`@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,10 +439,10 @@ 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 <<./endpoint.adoc#payload-type-conversion,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 annotations.
|
||||
See <<./configuration.adoc#annotations,Annotation Support>> for more information about messaging annotations.
|
||||
|
||||
[[programming-considerations]]
|
||||
=== Programming Considerations
|
||||
@@ -579,9 +589,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.adoc#message,Message>>;
|
||||
* `org.springframework.messaging.MessageChannel`: See <<./channel.adoc#channel,Message Channels>>;
|
||||
* `org.springframework.integration.endpoint.AbstractEndpoint`: See <<./polling-consumer.adoc#polling-consumer,Poller>>.
|
||||
|
||||
The first two are simple enough to understand how to implement, configure, and use.
|
||||
The last one deserves more attention
|
||||
@@ -601,7 +611,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.adoc#xmpp,XMPP Support>>) you should configure something like the following:
|
||||
|
||||
====
|
||||
[source,java]
|
||||
|
||||
@@ -25,7 +25,7 @@ You can find a description of the pattern on the https://www.enterpriseintegrati
|
||||
|
||||
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.adoc#ftp-inbound,FTP Inbound Channel Adapter>> 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:
|
||||
|
||||
* https://docs.spring.io/spring-integration/api/org/springframework/integration/endpoint/PollingConsumer.html[`PollingConsumer`]
|
||||
@@ -50,8 +50,8 @@ To resume polling, call `reset()`.
|
||||
Version 4.2 added more flexibility in this area.
|
||||
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.adoc#channel,Message Channels>>) and channel adapters (see <<./channel-adapter.adoc#channel-adapter,Channel Adapter>>).
|
||||
For more information regarding messaging endpoints in general and polling consumers in particular, see <<./endpoint.adoc#endpoint,Message Endpoints>>.
|
||||
|
||||
[[deferred-acks-message-source]]
|
||||
==== Deferred Acknowledgment Pollable Message Source
|
||||
@@ -59,7 +59,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 `spring-integration-kafka` https://github.com/spring-projects/spring-integration-kafka[extension project].
|
||||
|
||||
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.adoc#message-header-accessor,`MessageHeaderAccessor` API>>) is added to the message.
|
||||
The value of the header is an instance of `AcknowledgmentCallback`, as the following example shows:
|
||||
|
||||
[source, java]
|
||||
|
||||
@@ -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.adoc#configuration-namespace,Namespace Support>>.
|
||||
|
||||
NOTE: The namespace prefix can be freely chosen.
|
||||
You may even choose not to use any namespace prefixes at all.
|
||||
|
||||
@@ -421,15 +421,15 @@ 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 https://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 https://docs.spring.io/spring-integration/docs/latest-ga/api/org/springframework/integration/metadata/MetadataStore.html[`MetadataStore`] (see <<./meta-data-store.adoc#metadata-store,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:
|
||||
|
||||
|
||||
* <<feed-inbound-channel-adapter,Feed>>
|
||||
* <<file-reading,File>>
|
||||
* <<ftp-inbound,FTP>>
|
||||
* <<sftp-inbound,SFTP>>
|
||||
* <<./feed.adoc#feed-inbound-channel-adapter,,Feed>>
|
||||
* <<./file.adoc#file-reading,,File>>
|
||||
* <<./ftp.adoc#ftp-inbound,,FTP>>
|
||||
* <<./sftp.adoc#sftp-inbound,,SFTP>>
|
||||
|
||||
To instruct these adapters to use the new `RedisMetadataStore`, declare a Spring bean named `metadataStore`.
|
||||
The Feed inbound channel adapter and the feed inbound channel adapter both automatically pick up and use the declared `RedisMetadataStore`.
|
||||
@@ -556,7 +556,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 <<./transactions.adoc#transaction-synchronization,Transaction Synchronization>>.
|
||||
|
||||
[[redis-store-outbound-channel-adapter]]
|
||||
=== RedisStore Outbound Channel Adapter
|
||||
|
||||
@@ -19,7 +19,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 <<./dsl.adoc#java-dsl-aggregators,Aggregators and Resequencers>> for configuring a resequencer in Java DSL.
|
||||
|
||||
Configuring a resequencer requires only including the appropriate element in XML.
|
||||
|
||||
@@ -72,7 +72,7 @@ Optional.
|
||||
<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 <<./aggregator.adoc#reaper,Managing State in an Aggregator: `MessageGroupStore`>>.
|
||||
<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'.
|
||||
@@ -107,10 +107,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.adoc#aggregator-xml,Configuring an Aggregator with XML>>.
|
||||
<17> See <<./aggregator.adoc#aggregator-xml,Configuring an Aggregator with XML>>.
|
||||
<18> See <<./aggregator.adoc#aggregator-xml,Configuring an Aggregator with XML>>.
|
||||
<19> See <<./aggregator.adoc#aggregator-xml,Configuring an Aggregator with 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.
|
||||
|
||||
@@ -22,7 +22,7 @@ Spring Integration provides the following routers:
|
||||
* <<router-implementations-payloadtyperouter,Payload Type Router>>
|
||||
* <<router-implementations-headervaluerouter,Header Value Router>>
|
||||
* <<router-implementations-recipientlistrouter,Recipient List Router>>
|
||||
* <<xml-xpath-routing,XPath Router (part of the XML module)>>
|
||||
* <<./xml.adoc#xml-xpath-routing,,XPath Router (part of the XML module)>>
|
||||
* <<router-implementations-exception-router,Error Message Exception Type Router>>
|
||||
* <<router-namespace,(Generic) Router>>
|
||||
|
||||
@@ -427,7 +427,7 @@ A `PayloadTypeRouter` sends messages to the channel defined by payload-type mapp
|
||||
----
|
||||
====
|
||||
|
||||
Configuration of the `PayloadTypeRouter` is also supported by the namespace provided by Spring Integration (see `<<configuration-namespace>>`), which essentially simplifies configuration by combining the `<router/>` configuration and its corresponding implementation (defined by using a `<bean/>` element) into a single and more concise configuration element.
|
||||
Configuration of the `PayloadTypeRouter` is also supported by the namespace provided by Spring Integration (see `<<./configuration.adoc#configuration-namespace,Namespace Support>>`), which essentially simplifies configuration by combining the `<router/>` configuration and its corresponding implementation (defined by using a `<bean/>` element) into a single and more concise configuration element.
|
||||
The following example shows a `PayloadTypeRouter` configuration that is equivalent to the one above but uses the namespace support:
|
||||
|
||||
====
|
||||
@@ -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.adoc#configuration-namespace,Namespace Support>>) 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.adoc#channel-configuration-pubsubchannel,`PublishSubscribeChannel` Configuration>> 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.adoc#control-bus,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.adoc#xml-xpath-routing,Routing XML Messages with XPath>>.
|
||||
|
||||
[[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 <<./configuration.adoc#annotations,Annotation Support>>:
|
||||
|
||||
====
|
||||
[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.adoc#xml,XML Support - Dealing with XML Payloads>>.
|
||||
|
||||
See also <<java-dsl-routers>> in the Java DSL chapter for more information about router configuration.
|
||||
See also <<./dsl.adoc#java-dsl-routers,Message 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.adoc#jmx,JMX Support>>) or the Spring Integration control bus (see <<./control-bus.adoc#control-bus,Control Bus>>) functionality.
|
||||
|
||||
[[dynamic-routers-control-bus]]
|
||||
===== Manage Router Mappings using the Control Bus
|
||||
|
||||
One way to manage the router mappings is through the https://www.enterpriseintegrationpatterns.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.adoc#control-bus,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.adoc#jmx,JMX Support>>.
|
||||
|
||||
[[routing-slip]]
|
||||
===== Routing Slip
|
||||
@@ -1222,7 +1222,7 @@ For this reason, be careful when you use routing slips in conjunction with POJO
|
||||
next path.
|
||||
|
||||
IMPORTANT: If a routing slip is involved in a distributed environment, we recommend not using inline expressions for the Routing Slip `path`.
|
||||
This recommendation applies to distributed environments such as cross-JVM applications, using a `request-reply` through a message broker (such as<<amqp>> or <<jms>>), or using a persistent `MessageStore` (<<message-store>>) in the integration flow.
|
||||
This recommendation applies to distributed environments such as cross-JVM applications, using a `request-reply` through a message broker (such as<<./amqp.adoc#amqp,AMQP Support>> or <<./jms.adoc#jms,JMS Support>>), or using a persistent `MessageStore` (<<./message-store.adoc#message-store,Message Store>>) in the integration flow.
|
||||
The framework uses `RoutingSlipHeaderValueMessageProcessor` to convert them to `ExpressionEvaluatingRoutingSlipRouteStrategy` objects, and they are used in the `routingSlip` message header.
|
||||
Since this class is not `Serializable` (it cannot be, because it depends on the `BeanFactory`), the entire `Message` becomes non-serializable and, in any distributed operation, we end up with a `NotSerializableException`.
|
||||
To overcome this limitation, register an `ExpressionEvaluatingRoutingSlipRouteStrategy` bean with the desired SpEL and use its bean name in the routing slip `path` configuration.
|
||||
|
||||
@@ -17,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.adoc#aggregator,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-enrichment.adoc#content-enricher,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.adoc#router-implementations-recipientlistrouter,`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`.
|
||||
@@ -163,7 +163,7 @@ In other cases something like a "`compensation message`" should be considered fo
|
||||
|
||||
Every async sub-flow should be configured with a `errorChannel` header for the proper error message sending from the `MessagePublishingErrorHandler`.
|
||||
Otherwise, an error will be sent to the global `errorChannel` with the common error handling logic.
|
||||
See <<namespace-errorhandler>> for more information about async error processing.
|
||||
See <<./configuration.adoc#namespace-errorhandler,Error Handling>> for more information about async error processing.
|
||||
|
||||
Synchronous flows may use an `ExpressionEvaluatingRequestHandlerAdvice` for ignoring the exception or returning a compensation message.
|
||||
When an exception is thrown from one of the sub-flows to the `ScatterGatherHandler`, it is just re-thrown to upstream.
|
||||
|
||||
@@ -49,7 +49,7 @@ The https://groovy-lang.org/[Groovy] and https://www.jruby.org[JRuby] projects p
|
||||
IMPORTANT: Various JSR223 language implementations have been developed by third parties.
|
||||
A particular implementation's compatibility with Spring Integration depends on how well it conforms to the specification and the implementer's interpretation of the specification.
|
||||
|
||||
TIP: If you plan to use Groovy as your scripting language, we recommended you use <<groovy,Spring-Integration's Groovy Support>> as it offers additional features specific to Groovy.
|
||||
TIP: If you plan to use Groovy as your scripting language, we recommended you use <<./groovy.adoc#groovy,,Spring-Integration's Groovy Support>> as it offers additional features specific to Groovy.
|
||||
However, this section is relevant as well.
|
||||
|
||||
[[scripting-config]]
|
||||
|
||||
@@ -132,7 +132,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 <<./handler-advice.adoc#message-handler-advice-chain,Adding Behavior to Endpoints>>) 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:
|
||||
@@ -159,7 +159,7 @@ This means that, when the thread that processes the handed-off message finishes
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
When working with an <<async-gateway,asynchronous gateway>>, you should use an appropriate `AbstractDelegatingSecurityContextSupport` implementation from Spring Security https://docs.spring.io/spring-security/site/docs/current/reference/html/servlet-webclient.html#concurrency[Concurrency Support], to let security context propagation be ensured over gateway invocation.
|
||||
When working with an <<./gateway.adoc#async-gateway,,asynchronous gateway>>, you should use an appropriate `AbstractDelegatingSecurityContextSupport` implementation from Spring Security https://docs.spring.io/spring-security/site/docs/current/reference/html/servlet-webclient.html#concurrency[Concurrency Support], to let security context propagation be ensured over gateway invocation.
|
||||
The following example shows how to do so:
|
||||
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ The preceding configuration selects all the methods from the `exampleHandler` th
|
||||
The target method for invocation at runtime is selected for each request message by their `payload` type or as a fallback to the `Message<?>` type if such a method is present on target class.
|
||||
|
||||
Starting with version 5.0, one service method can be marked with the `@org.springframework.integration.annotation.Default` as a fallback for all non-matching cases.
|
||||
This can be useful when using <<content-type-conversion, content-type conversion>> with the target method being invoked after conversion.
|
||||
This can be useful when using <<./endpoint.adoc#content-type-conversion,, content-type conversion>> with the target method being invoked after conversion.
|
||||
|
||||
To delegate to an explicitly defined method of any object, you can add the `method` attribute, as the following example shows:
|
||||
|
||||
@@ -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.adoc#channel-special-channels,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 <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
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 <<./dsl.adoc#java-dsl-handle,Service Activators and the `.handle()` method>> in the Java DSL chapter for more information about configuring service activator.
|
||||
|
||||
[[async-service-activator]]
|
||||
==== Asynchronous Service Activator
|
||||
@@ -172,7 +172,7 @@ In this case a new `Message<?>` object is created and all the headers from a req
|
||||
This works the same way for most Spring Integration `MessageHandler` implementations, when interaction is based on a POJO method invocation.
|
||||
|
||||
A complete `Message<?>` object can also be returned from the method.
|
||||
However keep in mind that, unlike <<transformer, transformers>>, for a Service Activator this message will be modified by copying the headers from the request message if they are not already present in the returned message.
|
||||
However keep in mind that, unlike <<./transformer.adoc#transformer,, transformers>>, for a Service Activator this message will be modified by copying the headers from the request message if they are not already present in the returned message.
|
||||
So, if your method parameter is a `Message<?>` and you copy some, but not all, existing headers in your service method, they will reappear in the reply message.
|
||||
It is not a Service Activator responsibility to remove headers from a reply message and, pursuing the loosely-coupled principle, it is better to add a `HeaderFilter` in the integration flow.
|
||||
Alternatively, a Transformer can be used instead of a Service Activator but, in that case, when returning a full `Message<?>` the method is completely responsible for the message, including copying request message headers (if needed).
|
||||
|
||||
@@ -356,7 +356,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 <<./meta-data-store.adoc#metadata-store,Metadata Store>>).
|
||||
This filter matches on the filename and the remote modified time.
|
||||
|
||||
Since version 4.0, this filter requires a `ConcurrentMetadataStore`.
|
||||
@@ -373,17 +373,17 @@ Unless your application removes files after processing, the adapter re-processes
|
||||
|
||||
Also, if you configure the `filter` to use a `SftpPersistentAcceptOnceFileListFilter` and the remote file timestamp changes (causing it to be re-fetched), the default local filter does not allow this new file to be processed.
|
||||
|
||||
For more information about this filter, and how it is used, see <<remote-persistent-flf>>.
|
||||
For more information about this filter, and how it is used, see <<./file.adoc#remote-persistent-flf,Remote Persistent File List Filters>>.
|
||||
|
||||
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 <<./meta-data-store.adoc#metadata-store,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
|
||||
metadata store on every update (if the store implements `Flushable`).
|
||||
|
||||
IMPORTANT: Further, if you use a distributed `MetadataStore` (such as <<redis-metadata-store>> or <<gemfire-metadata-store>>), you can have multiple instances of the same adapter or application and be sure that one and only one instance processes a file.
|
||||
IMPORTANT: Further, if you use a distributed `MetadataStore` (such as <<./redis.adoc#redis-metadata-store,Redis Metadata Store>> or <<./gemfire.adoc#gemfire-metadata-store,Gemfire Metadata Store>>), you can have multiple instances of the same adapter or application and be sure that one and only one instance processes a file.
|
||||
|
||||
The actual local filter is a `CompositeFileListFilter` that contains the supplied filter and a pattern filter that prevents processing files that are in the process of being downloaded (based on the `temporary-file-suffix`).
|
||||
Files are downloaded with this suffix (the default is `.writing`), and the files are renamed to their final names when the transfer is complete, making them 'visible' to the filter.
|
||||
@@ -475,7 +475,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 <<./file.adoc#watch-service-directory-scanner,`WatchServiceDirectoryScanner`>> for more information.
|
||||
|
||||
==== Configuring with Java Configuration
|
||||
|
||||
@@ -581,7 +581,7 @@ public class SftpJavaApplication {
|
||||
[[sftp-incomplete]]
|
||||
==== Dealing With Incomplete Data
|
||||
|
||||
See <<file-incomplete>>.
|
||||
See <<./file.adoc#file-incomplete,Dealing With Incomplete Data>>.
|
||||
|
||||
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.
|
||||
@@ -594,7 +594,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.adoc#file-splitter,File Splitter>> and <<./transformer.adoc#stream-transformer,Stream Transformer>> for more information about these components.
|
||||
The following example shows how to configure an SFTP streaming inbound channel adapter:
|
||||
|
||||
====
|
||||
@@ -624,7 +624,7 @@ If you need to allow duplicates, you can use the `AcceptAllFileListFilter`.
|
||||
You can handle any other use cases by using `CompositeFileListFilter` (or `ChainFileListFilter`).
|
||||
The Java configuration <<sftp-streaming-java-config,shown later>> shows one technique to remove the remote file after processing, avoiding duplicates.
|
||||
|
||||
For more information about the `SftpPersistentAcceptOnceFileListFilter`, and how it is used, see <<remote-persistent-flf>>.
|
||||
For more information about the `SftpPersistentAcceptOnceFileListFilter`, and how it is used, see <<./file.adoc#remote-persistent-flf,Remote Persistent File List Filters>>.
|
||||
|
||||
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.
|
||||
@@ -704,7 +704,7 @@ Notice that, in this example, the message handler downstream of the transformer
|
||||
|
||||
Starting with _version 5.0.7_, the `RotatingServerAdvice` is available; when configured as a poller advice, the inbound adapters can poll multiple servers and directories.
|
||||
Configure the advice and add it to the poller's advice chain as normal.
|
||||
A `DelegatingSessionFactory` is used to select the server see <<ftp-dsf>> for more information.
|
||||
A `DelegatingSessionFactory` is used to select the server see <<./ftp.adoc#ftp-dsf,Delegating Session Factory>> for more information.
|
||||
The advice configuration consists of a list of `RotatingServerAdvice.KeyDirectory` objects.
|
||||
|
||||
.Example
|
||||
@@ -782,7 +782,7 @@ public IntegrationFlow flow() {
|
||||
}
|
||||
----
|
||||
|
||||
IMPORTANT: Do not configure a `TaskExecutor` on the poller when using this advice; see <<conditional-pollers>> for more information.
|
||||
IMPORTANT: Do not configure a `TaskExecutor` on the poller when using this advice; see <<./polling-consumer.adoc#conditional-pollers,Conditional Pollers for Message Sources>> for more information.
|
||||
|
||||
[[sftp-max-fetch]]
|
||||
=== Inbound Channel Adapters: Controlling Remote File Fetching
|
||||
@@ -805,7 +805,7 @@ When all are consumed, the remote fetch is attempted again, to pick up any new f
|
||||
IMPORTANT: When you deploy multiple instances of an application, we recommend setting a small `max-fetch-size`, to avoid one instance "`grabbing`" all the files and starving other instances.
|
||||
|
||||
Another use for `max-fetch-size` is when you want to stop fetching remote files but continue to process files that have already been fetched.
|
||||
Setting the `maxFetchSize` property on the `MessageSource` (programmatically, via JMX, or via a <<control-bus, control bus>>) effectively stops the adapter from fetching more files but lets the poller continue to emit messages for files that have previously been fetched.
|
||||
Setting the `maxFetchSize` property on the `MessageSource` (programmatically, via JMX, or via a <<./control-bus.adoc#control-bus,, control bus>>) effectively stops the adapter from fetching more files but lets the poller continue to emit messages for files that have previously been fetched.
|
||||
If the poller is active when the property is changed, the change takes effect on the next poll.
|
||||
|
||||
Starting with version 5.1, the synchronizer can be provided with a `Comparator<LsEntry>`.
|
||||
@@ -1026,8 +1026,8 @@ The `file_remoteDirectory` header holds the remote directory, and the `file_remo
|
||||
|
||||
The message payload resulting from a `get` operation is a `File` object representing the retrieved file.
|
||||
If you use the `-stream` option, the payload is an `InputStream` rather than a `File`.
|
||||
For text files, a common use case is to combine this operation with a <<file-splitter,file splitter>> or a
|
||||
<<stream-transformer,stream transformer>>.
|
||||
For text files, a common use case is to combine this operation with a <<./file.adoc#file-splitter,,file splitter>> or a
|
||||
<<./transformer.adoc#stream-transformer,,stream transformer>>.
|
||||
When consuming remote files as streams, you are responsible for closing the `Session` after the stream is consumed.
|
||||
For convenience, the `Session` is provided in the `closeableResource` header, and `IntegrationMessageHeaderAccessor` offers convenience method:
|
||||
|
||||
@@ -1041,7 +1041,7 @@ if (closeable != null) {
|
||||
----
|
||||
====
|
||||
|
||||
Framework components, such as the <<file-splitter,File Splitter>> and <<stream-transformer,Stream Transformer>>,
|
||||
Framework components, such as the <<./file.adoc#file-splitter,,File Splitter>> and <<./transformer.adoc#stream-transformer,,Stream Transformer>>,
|
||||
automatically close the session after the data is transferred.
|
||||
|
||||
The following example shows how to consume a file as a stream:
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
[[jmx-shutdown]]
|
||||
=== Orderly Shutdown
|
||||
|
||||
As described in "<<jmx-mbean-exporter>>", the MBean exporter provides a JMX operation called `stopActiveComponents`, which is used to stop the application in an orderly manner.
|
||||
As described in "<<./jmx.adoc#jmx-mbean-exporter,MBean Exporter>>", the MBean exporter provides a JMX operation called `stopActiveComponents`, which is used to stop the application in an orderly manner.
|
||||
The operation has a single `Long` parameter.
|
||||
The parameter indicates how long (in milliseconds) the operation waits to allow in-flight messages to complete.
|
||||
The operation works as follows:
|
||||
@@ -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.adoc#jmx-mbean-shutdown,Orderly Shutdown Managed Operation>>, 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`).
|
||||
|
||||
@@ -156,10 +156,10 @@ The following listing shows some usage examples:
|
||||
NOTE: Using this function requires the Jayway JsonPath library (`json-path.jar`) to be on the classpath.
|
||||
Otherwise the `#jsonPath` SpEL function is not registered.
|
||||
+
|
||||
For more information regarding JSON see 'JSON Transformers' in <<transformer>>.
|
||||
For more information regarding JSON see 'JSON Transformers' in <<./transformer.adoc#transformer,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.adoc#xml,XML Support - Dealing with XML Payloads>>.
|
||||
|
||||
[[spel-property-accessors]]
|
||||
=== Property Accessors
|
||||
|
||||
@@ -141,6 +141,6 @@ List<LineItem> extractItems(Order order) {
|
||||
----
|
||||
====
|
||||
|
||||
See also <<advising-with-annotations>>.
|
||||
See also <<./handler-advice.adoc#advising-with-annotations,Advising Endpoints Using Annotations>>.
|
||||
|
||||
See also <<java-dsl-splitters>> in the Java DSL chapter.
|
||||
See also <<./dsl.adoc#java-dsl-splitters,Splitters>> in the Java DSL chapter.
|
||||
|
||||
@@ -98,7 +98,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 <<./event.adoc#appevent-inbound,Receiving Spring Application Events>>).
|
||||
|
||||
Specifically, a `StompExceptionEvent` is emitted from the `AbstractStompSessionManager` when a `stompSessionListenableFuture` receives `onFailure()` due to failure to connect to STOMP broker.
|
||||
Another example is the `StompMessageHandler`.
|
||||
|
||||
@@ -104,7 +104,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.adoc#channel-adapter,Channel Adapter>>.
|
||||
|
||||
====
|
||||
[source,xml]
|
||||
|
||||
@@ -114,7 +114,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.adoc#ip-udp-ib-atts,.UDP Inbound Channel Adapter Attributes>>.
|
||||
|
||||
NOTE: When you use the `udp-attributes` element, you must provide the `port` attribute there rather than on the `inbound-channel-adapter` element itself.
|
||||
|
||||
@@ -133,7 +133,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 <<./ip.adoc#tcp-connection-factories,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.
|
||||
|
||||
|
||||
@@ -94,11 +94,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.adoc#jdbc-polling-transactions,Polling and 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 <<./polling-consumer.adoc#pollable-message-source,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.
|
||||
|
||||
@@ -12,7 +12,7 @@ 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.adoc#xml,XML Support - Dealing with XML Payloads>>.
|
||||
|
||||
[[transformer-namespace]]
|
||||
==== Configuring a Transformer with XML
|
||||
@@ -100,7 +100,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.adoc#channel-wiretap,Wire Tap>> for more detail.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
@@ -435,17 +435,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.adoc#spel,Spring Expression Language (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 <<./xml.adoc#xpath-spel-function,#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.adoc#spel-property-accessors,Property Accessors>> for more information.
|
||||
|
||||
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.
|
||||
|
||||
@@ -470,7 +470,7 @@ Order generateOrder(String productId) {
|
||||
----
|
||||
====
|
||||
|
||||
Transformer methods can also accept the `@Header` and `@Headers` annotations, as documented in `<<annotations>>`.
|
||||
Transformer methods can also accept the `@Header` and `@Headers` annotations, as documented in `<<./configuration.adoc#annotations,Annotation Support>>`.
|
||||
The following examples shows how to use the `@Header` annotation:
|
||||
|
||||
====
|
||||
@@ -483,7 +483,7 @@ Order generateOrder(String productId, @Header("customerName") String customer) {
|
||||
----
|
||||
====
|
||||
|
||||
See also <<advising-with-annotations>>.
|
||||
See also <<./handler-advice.adoc#advising-with-annotations,Advising Endpoints Using Annotations>>.
|
||||
|
||||
[[header-filter]]
|
||||
==== Header Filter
|
||||
@@ -491,7 +491,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 <<./content-enrichment.adoc#header-enricher,Header Enricher>>.
|
||||
The following example defines a header filter:
|
||||
|
||||
====
|
||||
@@ -510,4 +510,4 @@ So, in the preceding example, the headers named 'lastName' and 'state' are not p
|
||||
|
||||
==== Codec-Based Transformers
|
||||
|
||||
See <<codec>>.
|
||||
See <<./codec.adoc#codec,Codec>>.
|
||||
|
||||
@@ -130,7 +130,7 @@ The `WebSocketOutboundChannelAdapter`:
|
||||
On the client side, the `WebSocketSession` `id` message header is not required, because `ClientWebSocketContainer` deals only with a single connection and its `WebSocketSession` respectively.
|
||||
|
||||
To use the STOMP sub-protocol, you should configure this adapter with a `StompSubProtocolHandler`.
|
||||
Then you can send any STOMP message type to this adapter, using `StompHeaderAccessor.create(StompCommand...)` and a `MessageBuilder`, or just using a `HeaderEnricher` (see <<header-enricher>>).
|
||||
Then you can send any STOMP message type to this adapter, using `StompHeaderAccessor.create(StompCommand...)` and a `MessageBuilder`, or just using a `HeaderEnricher` (see <<./content-enrichment.adoc#header-enricher,Header Enricher>>).
|
||||
|
||||
The rest of this chapter covers largely additional configuration options.
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ The `io.projectreactor.netty:reactor-netty` dependency must be included in case
|
||||
|
||||
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.adoc#http,HTTP Support>> for more information, since many options are shared between reactive and regular HTTP components.
|
||||
|
||||
[[webflux-inbound]]
|
||||
=== WebFlux Inbound Components
|
||||
@@ -87,7 +87,7 @@ public IntegrationFlow sseFlow() {
|
||||
----
|
||||
====
|
||||
|
||||
See <<http-request-mapping>> and <<http-cors>> for more possible configuration options.
|
||||
See <<./http.adoc#http-request-mapping,Request Mapping Support>> and <<./http.adoc#http-cors,Cross-origin Resource Sharing (CORS) Support>> 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.
|
||||
|
||||
@@ -132,7 +132,7 @@ Otherwise, it is treated as an `async` mode, and the `Mono` response is adapted
|
||||
The target payload of the output message depends on the `WebFluxRequestExecutingMessageHandler` configuration.
|
||||
The `setExpectedResponseType(Class<?>)` or `setExpectedResponseTypeExpression(Expression)` identifies the target type of the response body element conversion.
|
||||
If `replyPayloadToFlux` is set to `true`, the response body is converted to a `Flux` with the provided `expectedResponseType` for each element, and this `Flux` is sent as the payload downstream.
|
||||
Afterwards, you can use a <<splitter,splitter>> to iterate over this `Flux` in a reactive manner.
|
||||
Afterwards, you can use a <<./splitter.adoc#splitter,,splitter>> to iterate over this `Flux` in a reactive manner.
|
||||
|
||||
In addition a `BodyExtractor<?, ClientHttpResponse>` can be injected into the `WebFluxRequestExecutingMessageHandler` instead of the `expectedResponseType` and `replyPayloadToFlux` properties.
|
||||
It can be used for low-level access to the `ClientHttpResponse` and more control over body and HTTP headers conversion.
|
||||
@@ -143,7 +143,7 @@ A respective `BodyInserter` is used internally to be populated into the `WebClie
|
||||
When the payload is a reactive `Publisher`, a configured `publisherElementType` or `publisherElementTypeExpression` can be used to determine a type for the publisher's element type.
|
||||
The expression must be resolved to a `Class<?>`, `String` which is resolved to the target `Class<?>` or `ParameterizedTypeReference`.
|
||||
|
||||
See <<http-outbound>> for more possible configuration options.
|
||||
See <<./http.adoc#http-outbound,HTTP Outbound Components>> for more possible configuration options.
|
||||
|
||||
[[webflux-namespace]]
|
||||
=== WebFlux Namespace Support
|
||||
@@ -338,4 +338,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.adoc#http-header-mapping,HTTP Header Mappings>> for more possible options and components to use for mapping headers.
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
[[whats-new-part]]
|
||||
= What's New?
|
||||
|
||||
[[spring-integration-intro-new]]
|
||||
For those who are already familiar with Spring Integration, this chapter provides a brief overview of the new features of version 5.2.
|
||||
|
||||
If you are interested in the changes and features that were introduced in earlier versions, see the <<./history.adoc#history,Change History>>.
|
||||
|
||||
[[whats-new]]
|
||||
|
||||
== What's New in Spring Integration 5.2?
|
||||
@@ -11,61 +19,61 @@ If you are interested in more details, see the Issue Tracker tickets that were r
|
||||
=== Rate Limit Advice Support
|
||||
|
||||
The `RateLimiterRequestHandlerAdvice` is now available for limiting requests rate on handlers.
|
||||
See <<rate-limiter-advice>> for more information.
|
||||
See <<./handler-advice.adoc#rate-limiter-advice,Rate Limiter Advice>> for more information.
|
||||
|
||||
[[x5.2-cacheAdvice]]
|
||||
=== Caching Advice Support
|
||||
|
||||
The `CacheRequestHandlerAdvice` is now available for caching request results on handlers.
|
||||
See <<cache-advice>> for more information.
|
||||
See <<./handler-advice.adoc#cache-advice,Caching Advice>> for more information.
|
||||
|
||||
[[x5.2-kotlinScripts]]
|
||||
=== Kotlin Scripts Support
|
||||
|
||||
The JSR223 scripting module now includes a support for Kotlin scripts.
|
||||
See <<scripting>> for more information.
|
||||
See <<./scripting.adoc#scripting,Scripting Support>> for more information.
|
||||
|
||||
[[x5.2-general]]
|
||||
=== General Changes
|
||||
|
||||
The `JsonToObjectTransformer` now supports generics for the target object to deserialize into.
|
||||
See <<json-transformers>> for more information.
|
||||
See <<./transformer.adoc#json-transformers,JSON Transformers>> for more information.
|
||||
|
||||
The `splitter` now supports a `discardChannel` configuration option.
|
||||
See <<splitter>> for more information.
|
||||
See <<./splitter.adoc#splitter,Splitter>> for more information.
|
||||
|
||||
[[x5.2-amqp]]
|
||||
==== AMQP Changes
|
||||
|
||||
The outbound endpoints can now be configured to synthesize a "nack" if no publisher confirm is received within a timeout.
|
||||
See <<amqp-outbound-endpoints>> for more information.
|
||||
See <<./amqp.adoc#amqp-outbound-endpoints,Outbound Channel Adapter>> for more information.
|
||||
|
||||
The inbound channel adapter can now receive batched messages as a `List<?>` payload instead of receiving a discrete message for each batch fragment.
|
||||
See <<amqp-debatching>> for more information.
|
||||
See <<./amqp.adoc#amqp-debatching,Batched Messages>> for more information.
|
||||
|
||||
[[x5.2-file]]
|
||||
==== File Changes
|
||||
|
||||
Some improvements to filtering remote files have been made.
|
||||
See <<remote-persistent-flf>> for more information.
|
||||
See <<./file.adoc#remote-persistent-flf,Remote Persistent File List Filters>> for more information.
|
||||
|
||||
[[x5.2-tcp]]
|
||||
==== TCP Changes
|
||||
|
||||
The length header used by the `ByteArrayLengthHeaderSerializer` can now include the length of the header in addition to the payload.
|
||||
See <<tcp-codecs>> for more information.
|
||||
See <<./ip.adoc#tcp-codecs,Message Demarcation (Serializers and Deserializers)>> for more information.
|
||||
|
||||
When using a `TcpNioServerConnectionFactory`, priority is now given to accepting new connections over reading from existing connections, but it is configurable.
|
||||
See <<note-nio>> for more information.
|
||||
See <<./ip.adoc#note-nio,About Non-blocking I/O (NIO)>> for more information.
|
||||
|
||||
[[x5.2-mail]]
|
||||
==== Mail Changes
|
||||
|
||||
The `AbstractMailReceiver` has now an `autoCloseFolder` option (`true` by default), to disable an automatic folder close after a fetch, but populate `IntegrationMessageHeaderAccessor.CLOSEABLE_RESOURCE` header instead for downstream interaction.
|
||||
See <<mail-inbound>> for more information.
|
||||
See <<./mail.adoc#mail-inbound,Mail-receiving Channel Adapter>> for more information.
|
||||
|
||||
[[x5.2-webflux]]
|
||||
==== WebFlux Changes
|
||||
|
||||
The `WebFluxRequestExecutingMessageHandler` now supports a `Publisher`, `Resource` and `MultiValueMap` as a request message `payload`.
|
||||
See <<webflux>> for more information.
|
||||
See <<./webflux.adoc#webflux,WebFlux Support>> for more information.
|
||||
|
||||
@@ -293,7 +293,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 <<./ws.adoc#mtom-support,MTOM Support>> for more information.
|
||||
|
||||
The following example shows how to define an unmarshalling transformer:
|
||||
|
||||
@@ -764,7 +764,7 @@ 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.adoc#splitter,Splitter>> for more information.
|
||||
|
||||
[[xml-xpath-routing]]
|
||||
=== Routing XML Messages with XPath
|
||||
@@ -782,7 +782,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.adoc#router-common-parameters,Common Router 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.
|
||||
@@ -933,7 +933,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 <<./endpoint.adoc#payload-type-conversion,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`.
|
||||
@@ -948,7 +948,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.adoc#filter,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.
|
||||
|
||||
@@ -1041,7 +1041,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.adoc#spel,Spring Expression Language (SpEL)>>.
|
||||
|
||||
[[xml-validating-filter]]
|
||||
=== XML Validating Filter
|
||||
|
||||
@@ -31,7 +31,7 @@ compile "org.springframework.integration:spring-integration-zookeeper:{project-v
|
||||
=== 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 <<./meta-data-store.adoc#metadata-store,Metadata Store>> for more information.
|
||||
The following example configures a Zookeeper metadata store with XML:
|
||||
|
||||
====
|
||||
@@ -102,7 +102,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.adoc#endpoint-roles,Endpoint Roles>> for more information.
|
||||
|
||||
You can use Java configuration to create an instance of the leader initiator, as the following example shows:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user