Remove spring-integration-gemfire module
Starting with Spring Data 2022.0.0 there is not going to be GemFire (Geode) support directly from Spring team A source code of the `spring-integration-gemfire` is moving to Spring Integration Extensions from where community may consider to pull it and support in their own manner
This commit is contained in:
Artem Bilan
@@ -477,7 +477,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.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.
|
||||
See <<./redis.adoc#redis-lock-registry,Redis Lock Registry>> or <<./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 which counts from the time the last message arrived.
|
||||
To set up a timeout which counts from the time the `MessageGroup` was created see `group-timeout-expression` information.
|
||||
|
||||
@@ -22,14 +22,6 @@ Now you have the ability to use any scripting language that supports JSR-223 inc
|
||||
|
||||
For further details, see <<./scripting.adoc#scripting,Scripting Support>>.
|
||||
|
||||
[[x2.1-new-gemfire-support]]
|
||||
===== GemFire Support
|
||||
|
||||
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.adoc#gemfire,Pivotal GemFire and Apache Geode Support>>.
|
||||
|
||||
[[x2.1-new-amqp-support]]
|
||||
===== AMQP Support
|
||||
|
||||
|
||||
@@ -101,12 +101,12 @@ For more information, see <<./security.adoc#security,Security in Spring Integrat
|
||||
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.adoc#redis-outbound-gateway,Redis Outbound Command Gateway>>.
|
||||
|
||||
[[x4.0-redis-gemfire-lock-registry]]
|
||||
===== `RedisLockRegistry` and `GemfireLockRegistry`
|
||||
[[x4.0-redis-lock-registry]]
|
||||
===== `RedisLockRegistry`
|
||||
|
||||
The `RedisLockRegistry` and `GemfireLockRegistry` are now available to support global locks visible to multiple application instances and servers.
|
||||
The `RedisLockRegistry` is 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.adoc#redis-lock-registry,Redis Lock Registry>>, <<./gemfire.adoc#gemfire-lock-registry,Gemfire Lock Registry>>, and <<./aggregator.adoc#aggregator,Aggregator>>.
|
||||
For more information, see <<./redis.adoc#redis-lock-registry,Redis Lock Registry>> and <<./aggregator.adoc#aggregator,Aggregator>>.
|
||||
|
||||
[[x4.0-poller-annotation]]
|
||||
===== `@Poller`
|
||||
@@ -130,12 +130,6 @@ We added a new twitter endpoint: `<int-twitter-search-outbound-gateway/>`.
|
||||
Unlike the search inbound adapter, which polls by using the same search query each time, the outbound gateway allows on-demand customized queries.
|
||||
For more information, see https://github.com/spring-projects/spring-integration-extensions/tree/main/spring-integration-social-twitter[Spring Integration Social Twitter].
|
||||
|
||||
[[x4.0-gemfire-metadata]]
|
||||
===== Gemfire Metadata Store
|
||||
|
||||
We added the `GemfireMetadataStore`, letting it be used, for example, in an `AbstractPersistentAcceptOnceFileListFilter` implementation in a multiple application instance or server environment.
|
||||
For more information, see <<./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
|
||||
|
||||
|
||||
@@ -271,11 +271,6 @@ We added a `ByteArrayElasticRawDeserializer` without `maxMessageSize` to control
|
||||
|
||||
See <<./ip.adoc#ip,TCP and UDP Support>> for more information.
|
||||
|
||||
===== Gemfire Changes
|
||||
|
||||
The `GemfireMetadataStore` now implements `ListenableMetadataStore`, letting you listen to cache events by providing `MetadataStoreListener` instances to the store.
|
||||
See <<./gemfire.adoc#gemfire,Pivotal GemFire and Apache Geode Support>> for more information.
|
||||
|
||||
===== JDBC Changes
|
||||
|
||||
The `JdbcMessageChannelStore` now provides a setter for `ChannelMessageStorePreparedStatementSetter`, letting you customize message insertion in the store.
|
||||
|
||||
@@ -78,12 +78,6 @@ The following table summarizes the various endpoints with quick links to the app
|
||||
| N
|
||||
| <<./ftp.adoc#ftp-outbound-gateway,FTP Outbound Gateway>>
|
||||
|
||||
| *Gemfire*
|
||||
| <<./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
|
||||
|
||||
| *GraphQL*
|
||||
| N
|
||||
| N
|
||||
|
||||
@@ -353,7 +353,7 @@ The default `MetadataStore` is a `SimpleMetadataStore`, which stores state in me
|
||||
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.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.
|
||||
IMPORTANT: Further, if you use a distributed `MetadataStore` (such as <<./redis.adoc#redis-metadata-store,Redis>>), 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.
|
||||
|
||||
@@ -1,295 +0,0 @@
|
||||
[[gemfire]]
|
||||
== VMware Tanzu GemFire and Apache Geode Support
|
||||
|
||||
Spring Integration provides support for VMware Tanzu GemFire and Apache Geode.
|
||||
|
||||
You need to include this dependency into your project:
|
||||
|
||||
====
|
||||
[source, xml, subs="normal", role="primary"]
|
||||
.Maven
|
||||
----
|
||||
<dependency>
|
||||
<groupId>org.springframework.integration</groupId>
|
||||
<artifactId>spring-integration-gemfire</artifactId>
|
||||
<version>{project-version}</version>
|
||||
</dependency>
|
||||
----
|
||||
[source, groovy, subs="normal", role="secondary"]
|
||||
.Gradle
|
||||
----
|
||||
compile "org.springframework.integration:spring-integration-gemfire:{project-version}"
|
||||
----
|
||||
====
|
||||
|
||||
GemFire is a distributed data management platform that provides a key-value data grid along with advanced distributed system features, such as event processing, continuous querying, and remote function execution.
|
||||
This guide assumes some familiarity with the commercial https://tanzu.vmware.com/gemfire[VMware Tanzu GemFire] or Open Source https://geode.apache.org[Apache Geode].
|
||||
|
||||
Spring integration provides support for GemFire by implementing inbound adapters for entry and continuous query events, an outbound adapter to write entries to the cache, and message and metadata stores and `GemfireLockRegistry` implementations.
|
||||
Spring integration leverages the https://projects.spring.io/spring-data-gemfire[Spring Data for VMware Tanzu GemFire] project, providing a thin wrapper over its components.
|
||||
|
||||
Starting with version 5.1, the Spring Integration GemFire module uses the https://github.com/spring-projects/spring-data-geode[Spring Data for Apache Geode] transitive dependency by default.
|
||||
To switch to the commercial VMware Tanzu GemFire-based Spring Data for VMware Tanzu GemFire, exclude `spring-data-geode` from dependencies and add `spring-data-gemfire`, as the following Maven snippet shows:
|
||||
|
||||
====
|
||||
[source,xml]
|
||||
----
|
||||
<dependency>
|
||||
<groupId>org.springframework.integration</groupId>
|
||||
<artifactId>spring-integration-gemfire</artifactId>
|
||||
<exclusions>
|
||||
<exclusion>
|
||||
<groupId>org.springframework.data</groupId>
|
||||
<artifactId>spring-data-geode</artifactId>
|
||||
</exclusion>
|
||||
</exclusions>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>org.springframework.data</groupId>
|
||||
<artifactId>spring-data-gemfire</artifactId>
|
||||
</dependency>
|
||||
----
|
||||
====
|
||||
|
||||
To configure the 'int-gfe' namespace, include the following elements within the headers of your XML configuration file:
|
||||
|
||||
====
|
||||
[source,xml]
|
||||
----
|
||||
xmlns:int-gfe="http://www.springframework.org/schema/integration/gemfire"
|
||||
xsi:schemaLocation="http://www.springframework.org/schema/integration/gemfire
|
||||
https://www.springframework.org/schema/integration/gemfire/spring-integration-gemfire.xsd"
|
||||
----
|
||||
====
|
||||
|
||||
[[gemfire-inbound]]
|
||||
=== Inbound Channel Adapter
|
||||
|
||||
The inbound channel adapter produces messages on a channel when triggered by a GemFire `EntryEvent`.
|
||||
GemFire generates events whenever an entry is `CREATED`, `UPDATED`, `DESTROYED`, or `INVALIDATED` in the associated region.
|
||||
The inbound channel adapter lets you filter on a subset of these events.
|
||||
For example, you may want to produce messages only in response to an entry being created.
|
||||
In addition, the inbound channel adapter can evaluate a SpEL expression if, for example, you want your message payload to contain an event property such as the new entry value.
|
||||
The following example shows how to configure an inbound channel adapter with a SpEL language (in the `expression` attribute):
|
||||
|
||||
====
|
||||
[source,xml]
|
||||
----
|
||||
<gfe:cache/>
|
||||
<gfe:replicated-region id="region"/>
|
||||
<int-gfe:inbound-channel-adapter id="inputChannel" region="region"
|
||||
cache-events="CREATED" expression="newValue"/>
|
||||
----
|
||||
====
|
||||
|
||||
The preceding configuration creates a GemFire `Cache` and `Region` by using Spring GemFire's 'gfe' namespace.
|
||||
The `inbound-channel-adapter` element requires a reference to the GemFire region on which the adapter listens for events.
|
||||
Optional attributes include `cache-events`, which can contain a comma-separated list of event types for which a message is produced on the input channel.
|
||||
By default, `CREATED` and `UPDATED` are enabled.
|
||||
If no `channel` attribute is provided, the channel is created from the `id` attribute.
|
||||
This adapter also supports an `error-channel`.
|
||||
The GemFire https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EntryEvent.html[`EntryEvent`] is the `#root` object of the `expression` evaluation.
|
||||
The following example shows an expression that replaces a value for a key:
|
||||
|
||||
====
|
||||
[source]
|
||||
----
|
||||
expression="new something.MyEvent(key, oldValue, newValue)"
|
||||
----
|
||||
====
|
||||
|
||||
If the `expression` attribute is not provided, the message payload is the GemFire `EntryEvent` itself.
|
||||
|
||||
NOTE: This adapter conforms to Spring Integration conventions.
|
||||
|
||||
[[gemfire-cq]]
|
||||
=== Continuous Query Inbound Channel Adapter
|
||||
|
||||
The continuous query inbound channel adapter produces messages on a channel when triggered by a GemFire continuous query or `CqEvent` event.
|
||||
In release `1.1`, Spring Data introduced continuous query support, including `ContinuousQueryListenerContainer`, which provides a nice abstraction over the GemFire native API.
|
||||
This adapter requires a reference to a `ContinuousQueryListenerContainer` instance, creates a listener for a given `query`, and executes the query.
|
||||
The continuous query acts as an event source that fires whenever its result set changes state.
|
||||
|
||||
NOTE: GemFire queries are written in OQL and are scoped to the entire cache (not just one region).
|
||||
Additionally, continuous queries require a remote (that is, running in a separate process or remote host) cache server.
|
||||
See the https://gemfire82.docs.VMware Tanzu.io/docs-gemfire/gemfire_nativeclient/continuous-querying/continuous-querying.html[GemFire documentation] for more information on implementing continuous queries.
|
||||
|
||||
The following configuration creates a GemFire client cache (recall that a remote cache server is required for this implementation and its address is configured as a child element of the pool), a client region, and a `ContinuousQueryListenerContainer` that uses Spring Data:
|
||||
|
||||
====
|
||||
[source,xml]
|
||||
----
|
||||
<gfe:client-cache id="client-cache" pool-name="client-pool"/>
|
||||
|
||||
<gfe:pool id="client-pool" subscription-enabled="true" >
|
||||
<!--configure server or locator here required to address the cache server -->
|
||||
</gfe:pool>
|
||||
|
||||
<gfe:client-region id="test" cache-ref="client-cache" pool-name="client-pool"/>
|
||||
|
||||
<gfe:cq-listener-container id="queryListenerContainer" cache="client-cache"
|
||||
pool-name="client-pool"/>
|
||||
|
||||
<int-gfe:cq-inbound-channel-adapter id="inputChannel"
|
||||
cq-listener-container="queryListenerContainer"
|
||||
query="select * from /test"/>
|
||||
----
|
||||
====
|
||||
|
||||
The continuous query inbound channel adapter requires a `cq-listener-container` attribute, which must contain a reference to the `ContinuousQueryListenerContainer`.
|
||||
Optionally, it accepts an `expression` attribute that uses SpEL to transform the `CqEvent` or extract an individual property as needed.
|
||||
The `cq-inbound-channel-adapter` provides a `query-events` attribute that contains a comma-separated list of event types for which a message is produced on the input channel.
|
||||
The available event types are `CREATED`, `UPDATED`, `DESTROYED`, `REGION_DESTROYED`, and `REGION_INVALIDATED`.
|
||||
By default, `CREATED` and `UPDATED` are enabled.
|
||||
Additional optional attributes include `query-name` (which provides an optional query name), `expression` (which works as described in the preceding section), and `durable` (a boolean value indicating if the query is durable -- it is false by default).
|
||||
If you do not provide a `channel`, the channel is created from the `id` attribute.
|
||||
This adapter also supports an `error-channel`.
|
||||
|
||||
NOTE: This adapter conforms to Spring Integration conventions.
|
||||
|
||||
[[gemfire-outbound]]
|
||||
=== Outbound Channel Adapter
|
||||
|
||||
The outbound channel adapter writes cache entries that are mapped from the message payload.
|
||||
In its simplest form, it expects a payload of type `java.util.Map` and puts the map entries into its configured region.
|
||||
The following example shows how to configure an outbound channel adapter:
|
||||
|
||||
====
|
||||
[source,xml]
|
||||
----
|
||||
<int-gfe:outbound-channel-adapter id="cacheChannel" region="region"/>
|
||||
----
|
||||
====
|
||||
|
||||
Given the preceding configuration, an exception is thrown if the payload is not a `Map`.
|
||||
Additionally, you can configure the outbound channel adapter to create a map of cache entries by using SpEL.
|
||||
The following example shows how to do so:
|
||||
|
||||
====
|
||||
[source,xml]
|
||||
----
|
||||
<int-gfe:outbound-channel-adapter id="cacheChannel" region="region">
|
||||
<int-gfe:cache-entries>
|
||||
<entry key="payload.toUpperCase()" value="payload.toLowerCase()"/>
|
||||
<entry key="'thing1'" value="'thing2'"/>
|
||||
</int-gfe:cache-entries>
|
||||
</int-gfe:outbound-channel-adapter>
|
||||
----
|
||||
====
|
||||
|
||||
In the preceding configuration, the inner element (`cache-entries`) is semantically equivalent to a Spring 'map' element.
|
||||
The adapter interprets the `key` and `value` attributes as SpEL expressions with the message as the evaluation context.
|
||||
Note that this can contain arbitrary cache entries (not only those derived from the message) and that literal values must be enclosed in single quotes.
|
||||
In the preceding example, if the message sent to `cacheChannel` has a `String` payload with a value `Hello`, two entries (`[HELLO:hello, thing1:thing2]`) are written (either created or updated) in the cache region.
|
||||
This adapter also supports the `order` attribute, which may be useful if it is bound to a `PublishSubscribeChannel`.
|
||||
|
||||
[[gemfire-message-store]]
|
||||
=== Gemfire Message Store
|
||||
|
||||
As described in EIP, a https://www.enterpriseintegrationpatterns.com/MessageStore.html[message store] lets you persist messages.
|
||||
This can be useful when dealing with components that have a capability to buffer messages (`QueueChannel`, `Aggregator`, `Resequencer`, and others) if reliability is a concern.
|
||||
In Spring Integration, the `MessageStore` strategy interface also provides the foundation for the https://www.enterpriseintegrationpatterns.com/StoreInLibrary.html[claim check] pattern, which is described in EIP as well.
|
||||
|
||||
Spring Integration's Gemfire module provides `GemfireMessageStore`, which is an implementation of both the `MessageStore` strategy (mainly used by the `QueueChannel` and `ClaimCheck` patterns) and the `MessageGroupStore` strategy (mainly used by the `Aggregator` and `Resequencer` patterns).
|
||||
|
||||
The following example configures the cache and region by using the `spring-gemfire` namespace (not to be confused with the `spring-integration-gemfire` namespace):
|
||||
|
||||
====
|
||||
[source,xml]
|
||||
----
|
||||
<bean id="gemfireMessageStore" class="o.s.i.gemfire.store.GemfireMessageStore">
|
||||
<constructor-arg ref="myRegion"/>
|
||||
</bean>
|
||||
|
||||
<gfe:cache/>
|
||||
|
||||
<gfe:replicated-region id="myRegion"/>
|
||||
|
||||
|
||||
<int:channel id="somePersistentQueueChannel">
|
||||
<int:queue message-store="gemfireMessageStore"/>
|
||||
<int:channel>
|
||||
|
||||
<int:aggregator input-channel="inputChannel" output-channel="outputChannel"
|
||||
message-store="gemfireMessageStore"/>
|
||||
----
|
||||
====
|
||||
|
||||
Often, it is desirable for the message store to be maintained in one or more remote cache servers in a client-server configuration.
|
||||
In this case, you should configure a client cache, a client region, and a client pool and inject the region into the `MessageStore`.
|
||||
The following example shows how to do so:
|
||||
|
||||
====
|
||||
[source,xml]
|
||||
----
|
||||
<bean id="gemfireMessageStore"
|
||||
class="org.springframework.integration.gemfire.store.GemfireMessageStore">
|
||||
<constructor-arg ref="myRegion"/>
|
||||
</bean>
|
||||
|
||||
<gfe:client-cache/>
|
||||
|
||||
<gfe:client-region id="myRegion" shortcut="PROXY" pool-name="messageStorePool"/>
|
||||
|
||||
<gfe:pool id="messageStorePool">
|
||||
<gfe:server host="localhost" port="40404" />
|
||||
</gfe:pool>
|
||||
----
|
||||
====
|
||||
|
||||
Note that the `pool` element is configured with the address of a cache server (you can substitute a locator here).
|
||||
The region is configured as a 'PROXY' so that no data is stored locally.
|
||||
The region's `id` corresponds to a region with the same name in the cache server.
|
||||
|
||||
Starting with version 4.3.12, the `GemfireMessageStore` supports the key `prefix` option to allow distinguishing between instances of the store on the same GemFire region.
|
||||
|
||||
[[gemfire-lock-registry]]
|
||||
=== Gemfire Lock Registry
|
||||
|
||||
Starting with version 4.0, the `GemfireLockRegistry` is available.
|
||||
Certain components (for example, the aggregator and the resequencer) use a lock obtained from a `LockRegistry` instance to ensure that only one thread is manipulating a group at any given time.
|
||||
The `DefaultLockRegistry` performs this function within a single component.
|
||||
You can now configure an external lock registry on these components.
|
||||
When you use a shared `MessageGroupStore` with the `GemfireLockRegistry`, it can provide this functionality across multiple application instances, such that only one instance can manipulate the group at a time.
|
||||
|
||||
NOTE: One of the `GemfireLockRegistry` constructors requires a `Region` as an argument.
|
||||
It is used to obtain a `Lock` from the `getDistributedLock()` method.
|
||||
This operation requires `GLOBAL` scope for the `Region`.
|
||||
Another constructor requires a `Cache`, and the `Region` is created with `GLOBAL` scope and with the name, `LockRegistry`.
|
||||
|
||||
[[gemfire-metadata-store]]
|
||||
=== Gemfire Metadata Store
|
||||
|
||||
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.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`.
|
||||
|
||||
NOTE: The `GemfireMetadataStore` also implements `ConcurrentMetadataStore`, letting it be reliably shared across multiple application instances, where only one instance can store or modify a key's value.
|
||||
These methods give various levels of concurrency guarantees based on the scope and data policy of the region.
|
||||
They are implemented in the peer cache and client-server cache but are disallowed in peer regions that have `NORMAL` or `EMPTY` data policies.
|
||||
|
||||
NOTE: Since version 5.0, the `GemfireMetadataStore` also implements `ListenableMetadataStore`, which lets you listen to cache events by providing `MetadataStoreListener` instances to the store, as the following example shows:
|
||||
|
||||
====
|
||||
[source,java]
|
||||
----
|
||||
GemfireMetadataStore metadataStore = new GemfireMetadataStore(cache);
|
||||
metadataStore.addListener(new MetadataStoreListenerAdapter() {
|
||||
|
||||
@Override
|
||||
public void onAdd(String key, String value) {
|
||||
...
|
||||
}
|
||||
|
||||
});
|
||||
----
|
||||
====
|
||||
@@ -49,8 +49,6 @@ include::./file.adoc[]
|
||||
|
||||
include::./ftp.adoc[]
|
||||
|
||||
include::./gemfire.adoc[]
|
||||
|
||||
include::./graphql.adoc[]
|
||||
|
||||
include::./http.adoc[]
|
||||
|
||||
@@ -38,7 +38,6 @@ Welcome to the Spring Integration reference documentation!
|
||||
<<./feed.adoc#feed,Feed Adapter>> :: RSS and Atom channel adapters
|
||||
<<./file.adoc#files,File Support>> :: Channel adapters and gateways for file system support
|
||||
<<./ftp.adoc#ftp,FTP/FTPS Adapters>> :: Channel adapters and gateways for FTP protocol
|
||||
<<./gemfire.adoc#gemfire,Apache Geode Support>> :: Apache Geode channel adapters, message store
|
||||
<<./graphql.adoc#graphql,GraphQL Support>> :: Channel adapters for GraphQL
|
||||
<<./http.adoc#http,HTTP Support>> :: Channel adapters and gateways for HTTP communication
|
||||
<<./jdbc.adoc#jdbc,JDBC Support>> :: Channel adapters and gateways for JDBC, message and metadata stores
|
||||
|
||||
@@ -43,7 +43,6 @@ The following is a complete list of supported implementations:
|
||||
* <<./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]
|
||||
=====
|
||||
|
||||
@@ -14,7 +14,6 @@ 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.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>>
|
||||
|
||||
@@ -326,7 +326,7 @@ The default `MetadataStore` is a `SimpleMetadataStore` that stores state in memo
|
||||
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.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.
|
||||
IMPORTANT: Further, if you use a distributed `MetadataStore` (such as <<./redis.adoc#redis-metadata-store,Redis 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.
|
||||
|
||||
@@ -30,7 +30,7 @@ Examples of such tools include the following:
|
||||
* There are tools for embedded MongoDB and Redis.
|
||||
* Tomcat and Jetty have embedded libraries to test real HTTP, Web Services, or WebSockets.
|
||||
* The `FtpServer` and `SshServer` from the Apache Mina project can be used for testing the FTP and SFTP protocols.
|
||||
* Gemfire and Hazelcast can be run as real-data grid nodes in the tests.
|
||||
* Hazelcast can be run as real-data grid nodes in the tests.
|
||||
* The Curator Framework provides a `TestingServer` for Zookeeper interaction.
|
||||
* Apache Kafka provides admin tools to embed a Kafka Broker in the tests.
|
||||
* The GreenMail is an open source, intuitive and easy-to-use test suite of email servers for testing purposes.
|
||||
|
||||
@@ -86,18 +86,23 @@ See <<./gateway.adoc#async-gateway, Asynchronous Gateway>> for more information.
|
||||
|
||||
The `integrationGlobalProperties` bean is now declared by the framework as an instance of `org.springframework.integration.context.IntegrationProperties` instead of the previously deprecated `java.util.Properties`.
|
||||
|
||||
[[x6.0-http]]
|
||||
=== HTTP Changes
|
||||
|
||||
The `#cookies` variable for expression evaluation context, exposed in the `HttpRequestHandlingEndpointSupport`, is now a `MultiValueMap` to carry all the values for cookies set by the client.
|
||||
See <<./http.adoc#http,HTTP Support>> for more information.
|
||||
|
||||
[[x6.0-rmi]]
|
||||
=== RMI Removal
|
||||
|
||||
The `spring-integration-rmi` module has been removed altogether after being deprecated in previous versions.
|
||||
There is no replacement: it is recommended to migrate to more secure network and application protocols, such as WebSockets, RSockets, gRPC or REST.
|
||||
|
||||
[[x6.0-gemfire]]
|
||||
=== GemFire Removal
|
||||
|
||||
The `spring-integration-gemfire` module has been removed altogether since there is no Spring Data `2022.0.0` support for VMware GemFire or Apache Geode.
|
||||
|
||||
[[x6.0-http]]
|
||||
=== HTTP Changes
|
||||
|
||||
The `#cookies` variable for expression evaluation context, exposed in the `HttpRequestHandlingEndpointSupport`, is now a `MultiValueMap` to carry all the values for cookies set by the client.
|
||||
See <<./http.adoc#http,HTTP Support>> for more information.
|
||||
|
||||
=== Apache Kafka Changes
|
||||
|
||||
When providing a `RetryTemplate` on the inbound gateway or message-driven channel adapter, if an `errorChannel` is also provided, an `ErrorMessageSendingRecoverer` is automatically configured.
|
||||
|
||||
Reference in New Issue
Block a user