`lambda,它允许你为`PollerMetadata`或`SmartLifecycle`提供选项。下面的示例展示了如何使用 Fluent API 和 lambda 来创建`IntegrationFlow`:
@@ -296,7 +296,7 @@ public IntegrationFlow pollingFlow() {
对于那些不需要直接构建`Message`对象的情况,可以使用基于`java.util.function.Supplier`的`IntegrationFlows.fromSupplier()`变体。`Supplier.get()`的结果会自动包装在`Message`中(如果它还不是`Message`)。
-### [](#java-dsl-routers)消息路由器
+### 消息路由器
Spring 集成原生地提供了专门的路由器类型,包括:
@@ -366,7 +366,7 @@ public IntegrationFlow recipientListFlow() {
另请参见[lambdas 和`Message>`参数]。
-### [](#java-dsl-splitters)分离器
+### 分离器
要创建拆分器,请使用`split()`EIP 方法。默认情况下,如果有效负载是`Iterable`、`Iterator`、`Array`、`Stream`或活性`Publisher`,则`split()`方法将每个项输出为单独的消息。它接受 lambda、spel 表达式或任何`AbstractMessageSplitter`实现。或者,你可以使用它而不需要参数来提供`DefaultMessageSplitter`。下面的示例展示了如何通过提供 lambda 来使用`split()`方法:
@@ -384,7 +384,7 @@ public IntegrationFlow splitFlow() {
另请参见[lambdas 和`Message>`参数]。
-### [](#java-dsl-aggregators)聚合器和重排序程序
+### 聚合器和重排序程序
`Aggregator`在概念上与`Splitter`相反。它将单个消息的序列聚合到单个消息中,并且必然更复杂。默认情况下,聚合器返回一条包含来自传入消息的有效负载集合的消息。同样的规则也适用于`Resequencer`。下面的示例展示了拆分器-聚合器模式的典型示例:
@@ -415,7 +415,7 @@ public IntegrationFlow splitAggregateFlow() {
对于`resequence()`EIP 方法,提供了类似的 lambda 配置。
-### [](#java-dsl-handle)服务激活器和`.handle()`方法
+### `方法
`.handle()`EIP 方法的目标是在某些 POJO 上调用任何`MessageHandler`实现或任何方法。另一种选择是使用 lambda 表达式来定义“活动”。因此,我们引入了一个通用的`GenericHandler`功能接口。它的`handle`方法需要两个参数:`P payload`和`MessageHeaders headers`(从版本 5.1 开始)。有了这一点,我们可以将流定义如下:
@@ -461,7 +461,7 @@ public IntegrationFlow integerFlow() {
另请参见[lambdas 和`Message>`参数]。
-### [](#java-dsl-gateway)运营商网关()
+### 运营商网关()
在`IntegrationFlow`定义中的`gateway()`运算符是一种特殊的服务激活器实现,通过其输入通道调用一些其他端点或集成流并等待应答。从技术上讲,它在``定义中扮演与嵌套``组件相同的角色(参见[从一条链子中调用一条链子](./chain.html#chain-gateway)),并允许流更干净、更直接。从逻辑上和业务角度来看,它是一个消息传递网关,允许在目标集成解决方案的不同部分之间分配和重用功能(参见[消息传递网关](./gateway.html#gateway))。对于不同的目标,这个操作符有几个重载:
@@ -493,7 +493,7 @@ private static IntegrationFlow subFlow() {
| |如果下游流并不总是返回一个响应,你应该将`requestTimeout`设置为 0,以防止无限期地挂起调用线程。
在这种情况下,流将在该点结束,线程将被释放以进行进一步的工作。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#java-dsl-log)运算符日志()
+### 运算符日志()
为了方便起见,为了记录通过 Spring 集成流(``)的消息行程,呈现了一个`log()`操作符。在内部,它由`WireTap``ChannelInterceptor`表示,其订阅服务器为`LoggingHandler`。它负责将传入消息记录到下一个端点或当前通道中。下面的示例展示了如何使用`LoggingHandler`:
@@ -507,7 +507,7 @@ private static IntegrationFlow subFlow() {
当这个操作符在流程的末尾使用时,它是单向处理程序,流程结束。要使其成为一个产生回复的流,你可以在`log()`之后使用一个简单的`bridge()`,或者,从版本 5.1 开始,你可以使用一个`logAndReply()`操作符。`logAndReply`只能在流的末尾使用。
-### [](#java-dsl-intercept)操作符截获()
+### 操作符截获()
从版本 5.3 开始,`intercept()`操作符允许在流程中的当前`ChannelInterceptor`处注册一个或多个`ChannelInterceptor`实例。这是通过`MessageChannels`API 创建显式`MessageChannel`API 的一种替代方法。下面的示例使用`MessageSelectingInterceptor`来拒绝某些异常消息:
@@ -517,7 +517,7 @@ private static IntegrationFlow subFlow() {
.handle(...)
```
-### [](#java-dsl-wiretap)`MessageChannelSpec.wireTap()`
+### `
Spring 集成包括`.wireTap()`Fluent API`MessageChannelSpec`Builders。下面的示例展示了如何使用`wireTap`方法记录输入:
@@ -547,7 +547,7 @@ public IntegrationFlow loggingFlow() {
在前面的示例中(并且在没有信道被声明的任何时间),隐式的`DirectChannel`被注入在`IntegrationFlow`的当前位置中,并用作当前配置的`ServiceActivatingHandler`的输出信道(来自`.handle()`,[前面描述的](#java-dsl-handle))。
-### [](#java-dsl-flows)处理消息流
+### 处理消息流
`IntegrationFlowBuilder`提供了一个顶级 API 来生成连接到消息流的集成组件。当你的集成可以用单个流(通常是这种情况)来完成时,这是很方便的。交替地`IntegrationFlow`实例可以通过`MessageChannel`实例进行连接。
@@ -572,7 +572,7 @@ public IntegrationFlow lambdaFlow() {
从版本 5.0.6 开始,在`IntegrationFlow`中为组件生成的 Bean 名称包括流 Bean,后面跟着一个点(`.`)作为前缀。例如,前面示例中的`ConsumerEndpointFactoryBean`的`.transform("Hello "::concat)`的结果是 Bean 名称`lambdaFlow.o.s.i.config.ConsumerEndpointFactoryBean#0`。(`o.s.i`是从`org.springframework.integration`到适合页面的缩写。)该端点的`Transformer`实现 Bean 的 Bean 名称为`lambdaFlow.transformer#0`(从版本 5.1 开始),其中使用的是其组件类型,而不是`MethodInvokingTransformer`类的完全限定名称。当必须在流中生成 Bean 名称时,对所有`NamedComponent`s 应用相同的模式。 Bean 这些生成的名称与流 ID 一起前置,以用于诸如解析日志或在某些分析工具中将组件分组在一起的目的,以及在运行时并发注册集成流时避免竞争条件。有关更多信息,请参见[动态和运行时集成流](#java-dsl-runtime-flows)。
-### [](#java-dsl-function-expression)`FunctionExpression`
+### `FunctionExpression`
我们引入了`FunctionExpression`类(spel 的`Expression`接口的一种实现)来让我们使用 lambdas 和`generics`。当存在来自核心 Spring 集成的隐式`Strategy`变量时,将为 DSL 组件提供`Function`选项以及`expression`选项。下面的示例展示了如何使用函数表达式:
@@ -584,7 +584,7 @@ public IntegrationFlow lambdaFlow() {
`FunctionExpression`还支持运行时类型转换,就像`SpelExpression`中所做的那样。
-### [](#java-dsl-subflows)子流支持
+### 子流支持
一些`if…else`和`publish-subscribe`组件提供了通过使用子流指定其逻辑或映射的能力。最简单的示例是`.publishSubscribeChannel()`,如下例所示:
@@ -664,7 +664,7 @@ public IntegrationFlow routeFlow() {
| |在 DSL 支持子流配置的情况下,当所配置的组件通常需要一个通道,并且该子流以`channel()`元素开始时,框架会隐式地在组件输出通道和流的输入通道之间放置一个`bridge()`。,例如,在这个`filter`定义中:
```
.filter(p -> p instanceof String, e -> e
.discardFlow(df -> df
.channel(MessageChannels.queue())
...)
```
框架内部创建了一个`DirectChannel` Bean 用于注入`MessageFilter.discardChannel`。
然后它将子流包装到一个`IntegrationFlow`中,从这个隐式通道开始,用于订阅并在流中指定的`channel()`之前放置一个`bridge`。
当现有的`IntegrationFlow` Bean 被用作子流引用(而不是内置子流,例如 lambda)时,没有这样的桥需要,因为框架可以解析来自第一通道的流 Bean。具有内联子流的输入通道尚不可用。|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#java-dsl-protocol-adapters)使用协议适配器
+### 使用协议适配器
到目前为止所示的所有示例都说明了 DSL 如何通过使用 Spring 集成编程模型来支持消息传递体系结构。然而,我们还没有进行任何真正的整合。这样做需要通过 HTTP、JMS、AMQP、TCP、JDBC、FTP、SMTP 等访问远程资源,或者访问本地文件系统。 Spring 集成支持所有这些和更多内容。理想情况下,DSL 应该为所有这些功能提供一流的支持,但是实现所有这些功能并随着新的适配器被添加到 Spring 集成中而跟上,这是一项艰巨的任务。因此,期望是 DSL 不断赶上 Spring 集成。
@@ -742,7 +742,7 @@ public AbstractMappingMessageRouter xpathRouter(MessageChannel wrongMessagesChan
}
```
-### [](#java-dsl-flow-adapter)`IntegrationFlowAdapter`
+### `IntegrationFlowAdapter`
`IntegrationFlow`接口可以直接实现并指定为用于扫描的组件,如下例所示:
@@ -817,7 +817,7 @@ public class MyFlowAdapter extends IntegrationFlowAdapter {
}
```
-### [](#java-dsl-runtime-flows)动态和运行时集成流
+### 动态和运行时集成流
`IntegrationFlow`及其所有相关组件都可以在运行时注册。在版本 5.0 之前,我们使用`BeanFactory.registerSingleton()`钩子。从 Spring 框架`5.0`开始,我们使用`instanceSupplier`钩子进行程序化的`BeanDefinition`注册。下面的示例显示了如何以编程方式注册 Bean:
@@ -923,7 +923,7 @@ private IntegrationFlow buildFlow(int port) {
| |当你使用`useFlowIdAsPrefix()`时,需要一个`id`属性。|
|---|-----------------------------------------------------------------|
-### [](#integration-flow-as-gateway)`IntegrationFlow`作为网关
+### `IntegrationFlow`作为网关
`IntegrationFlow`可以从提供`GatewayProxyFactoryBean`组件的服务接口开始,如下例所示:
@@ -968,7 +968,7 @@ public IntegrationFlow errorRecovererFlow() {
private Function errorRecovererFlowGateway;
```
-### [](#java-dsl-extensions)DSL 扩展
+### DSL 扩展
从版本 5.3 开始,引入了`IntegrationFlowExtension`,以允许使用自定义或组合的 EIP 操作符扩展现有的 Java DSL。所需要的只是这个类的一个扩展,它提供了可以在`IntegrationFlow` Bean 定义中使用的方法。扩展类还可以用于自定义`IntegrationComponentSpec`配置;例如,可以在现有的`IntegrationComponentSpec`扩展中实现错过的或默认的选项。下面的示例演示了一个复合自定义运算符和`AggregatorSpec`扩展的使用,用于默认的自定义`outputProcessor`:
@@ -1017,7 +1017,7 @@ public IntegrationFlow customFlowDefinition() {
}
```
-### [](#integration-flows-composition)积分流组合
+### 积分流组合
在 Spring 集成中,将`MessageChannel`抽象作为第一类公民,始终假定集成流的组成。流中任何端点的输入通道都可以用于从任何其他端点发送消息,而不仅仅是从具有该通道作为输出的端点发送消息。此外,有了`@MessagingGateway`契约、内容更丰富的组件、像``这样的复合端点,以及现在有了`IntegrationFlow`bean(例如`IntegrationFlowAdapter`),在更短的、可重用的部分之间分配业务逻辑就足够简单了。最后一篇作文所需要的只是关于`MessageChannel`发送到或接收到的信息的知识。
diff --git a/docs/spring-integration/endpoint-summary.md b/docs/spring-integration/endpoint-summary.md
index 5821371b50b7d6063d81cc0ec0ba5d0366224c49..9281c0de0f119ca56158dcb0a426933cab9b5bea 100644
--- a/docs/spring-integration/endpoint-summary.md
+++ b/docs/spring-integration/endpoint-summary.md
@@ -1,6 +1,6 @@
# 集成端点
-## [](#endpoint-summary)端点快速参考表
+## 端点快速参考表
正如前面几节中所讨论的, Spring 集成提供了许多端点,这些端点用于与外部系统、文件系统和其他系统进行接口。
diff --git a/docs/spring-integration/error-handling.md b/docs/spring-integration/error-handling.md
index d5083725cec1b95098b53c1ba76e218f496f9ed5..c18b46759b057e1fafe212cda8f4617203ae1639 100644
--- a/docs/spring-integration/error-handling.md
+++ b/docs/spring-integration/error-handling.md
@@ -1,6 +1,6 @@
# 错误处理
-## [](#error-handling)错误处理
+## 错误处理
正如本手册开头的[overview](./overview.html#overview)中所描述的, Spring 集成之类的面向消息的框架背后的主要动机之一是促进组件之间的松耦合。消息渠道起着重要的作用,因为生产者和消费者不必相互了解。然而,这些优点也有一些缺点。在松散耦合的环境中,有些事情会变得更加复杂,其中一个例子就是错误处理。
diff --git a/docs/spring-integration/event.md b/docs/spring-integration/event.md
index 0c2ab73d506882f7b310a1f1276f763336aff78c..cc77271b8233fccfb0185fc3e9bfe20ad033b140 100644
--- a/docs/spring-integration/event.md
+++ b/docs/spring-integration/event.md
@@ -1,6 +1,6 @@
# Spring 应用事件支持
-## [](#applicationevent) Spring `ApplicationEvent`支持
+## Spring `ApplicationEvent`支持
Spring 集成提供了对入站和出站`ApplicationEvents`的支持,如底层 Spring 框架所定义的那样。有关 Spring 对事件和侦听器的支持的更多信息,请参见[Spring Reference Manual](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#context-functionality-events)。
@@ -22,7 +22,7 @@ Gradle
compile "org.springframework.integration:spring-integration-event:5.5.9"
```
-### [](#appevent-inbound)接收 Spring 应用事件
+### 接收 Spring 应用事件
要接收事件并将其发送到通道,你可以定义 Spring Integration 的`ApplicationEventListeningMessageProducer`实例。这个类是 Spring 的`ApplicationListener`接口的实现。默认情况下,它将所有接收到的事件作为 Spring 集成消息传递。要根据事件的类型进行限制,可以使用“eventTypes”属性来配置要接收的事件类型列表。如果接收到的事件有一个`Message`实例作为其“源”,则该`Message`将按原样传递。否则,如果提供了基于 SPEL 的`payloadExpression`,则根据`ApplicationEvent`实例对其进行求值。如果事件的源不是`Message`实例,并且没有提供`payloadExpression`,则`ApplicationEvent`本身将作为有效负载传递。
@@ -79,7 +79,7 @@ public IntegrationFlow eventFlow(ApplicationEventListeningMessageProducer events
}
```
-### [](#appevent-outbound)发送 Spring 应用程序事件
+### 发送 Spring 应用程序事件
要发送 Spring `ApplicationEvents`,请创建`ApplicationEventPublishingMessageHandler`的一个实例,并将其注册到一个端点中。`MessageHandler`接口的此实现还实现了 Spring 的`ApplicationEventPublisherAware`接口,因此充当 Spring 集成消息和`ApplicationEvents`之间的桥梁。
diff --git a/docs/spring-integration/feed.md b/docs/spring-integration/feed.md
index 19f0528357640ab8417f8645e2d2ccab0ea617dc..8ec04ef9ae90adb88bd791bd09da176a5f369055 100644
--- a/docs/spring-integration/feed.md
+++ b/docs/spring-integration/feed.md
@@ -1,6 +1,6 @@
# 馈源适配器
-## [](#feed)提要适配器
+## 提要适配器
Spring 集成通过提要适配器为聚合提供支持。该实现基于[罗马框架](https://rometools.github.io/rome/)。
@@ -32,7 +32,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/feed
https://www.springframework.org/schema/integration/feed/spring-integration-feed.xsd"
```
-### [](#feed-inbound-channel-adapter)feed 入站通道适配器
+### feed 入站通道适配器
你真正需要为检索提要提供支持的唯一适配器是入站通道适配器。它允许你订阅特定的 URL。下面的示例展示了一种可能的配置:
@@ -50,21 +50,21 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/feed
入站提要通道适配器是一个轮询消费者。这意味着你必须提供一个 Poller 配置。然而,关于提要,你必须了解的一件重要事情是,它的内部工作方式与大多数其他轮询消费者略有不同。启动入站提要适配器时,它执行第一次轮询,并接收`com.sun.syndication.feed.synd.SyndEntryFeed`实例。该对象包含多个`SyndEntry`对象。每个条目存储在本地条目队列中,并基于`max-messages-per-poll`属性中的值释放,这样每个消息都包含一个条目。如果在从条目队列检索条目的过程中,队列已为空,则适配器尝试更新提要,从而在队列中填充更多条目(`SyndEntry`实例)(如果有可用的话)。否则,下一次对提要进行轮询的尝试将由 Poller 的触发器决定(在前面的配置中,每十秒钟进行一次轮询)。
-### [](#duplicate-entries)重复条目
+### 重复条目
对提要进行轮询可能会导致条目已经被处理(“我已经阅读了该新闻项目,为什么要再次向我显示它?”) Spring 集成提供了一种方便的机制,以消除对重复条目的担心。每个提要条目都有一个“发布日期”字段。每次生成和发送新的`Message`时, Spring 集成都会在`MetadataStore`策略的实例中存储最新发布日期的值(参见[元数据存储](./meta-data-store.html#metadata-store))。
| |用于持久化最新发布日期的键是提要入站通道适配器组件的(必需的)`id`属性的值加上适配器配置中的`feedUrl`(如果有的话)。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#other-options)其他选项
+### 其他选项
从版本 5.0 开始,已废弃的`com.rometools.fetcher.FeedFetcher`选项已被删除,并提供了用于`org.springframework.core.io.Resource`的重载`FeedEntryMessageSource`构造函数。当提要源不是 HTTP 端点,而是任何其他资源(例如 FTP 上的本地或远程)时,这很有用。在`FeedEntryMessageSource`逻辑中,这样的资源(或提供`URL`)由`SyndFeedInput`解析到用于前面提到的处理的`SyndFeed`对象。还可以将自定义的`SyndFeedInput`(例如,使用`allowDoctypes`选项)实例注入`FeedEntryMessageSource`。
| |如果到提要的连接需要一些定制,例如连接和读取超时,则必须使用带有其`customizeConnection(HttpURLConnection)`覆盖功能的`org.springframework.core.io.UrlResource`扩展,而不是普通的`URL`注入到
例如:
```
@Bean
@InboundChannelAdapter("feedChannel")
FeedEntryMessageSource feedEntrySource() {
UrlResource urlResource =
new UrlResource(url) {
@Override
protected void customizeConnection(HttpURLConnection connection) throws IOException {
super.customizeConnection(connection);
connection.setConnectTimeout(10000);
connection.setReadTimeout(5000);
}
};
return new FeedEntryMessageSource(urlResource, "myKey");
}
```|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#feed-java-configuration)Java DSL 配置
+### Java DSL 配置
下面的 Spring 引导应用程序展示了如何使用 Java DSL 配置入站适配器的示例:
diff --git a/docs/spring-integration/file.md b/docs/spring-integration/file.md
index 9a6cb289521820b3924c89a86a973249857699f6..fa753d196f3173aa77a55fc8b888ea860516cde6 100644
--- a/docs/spring-integration/file.md
+++ b/docs/spring-integration/file.md
@@ -1,6 +1,6 @@
# 文件支持
-## [](#files)文件支持
+## 文件支持
Spring Integration 的文件支持扩展了 Spring Integration 核心,提供了一个专用词汇表来处理读、写和转换文件。
@@ -26,7 +26,7 @@ compile "org.springframework.integration:spring-integration-file:5.5.9"
本节解释`FileReadingMessageSource`和`FileWritingMessageHandler`的工作原理,以及如何将它们配置为 bean。它还讨论了通过`Transformer`的特定于文件的实现来处理文件的支持。最后,它解释了特定于文件的命名空间。
-### [](#file-reading)读取文件
+### 读取文件
可以使用`FileReadingMessageSource`来使用文件系统中的文件。这是`MessageSource`的一个实现,它从文件系统目录创建消息。下面的示例展示了如何配置`FileReadingMessageSource`:
@@ -117,7 +117,7 @@ compile "org.springframework.integration:spring-integration-file:5.5.9"
从版本 5.1 开始,`FileReadingMessageSource`不会检查一个目录是否存在,并且直到调用它的`start()`(通常通过包装`SourcePollingChannelAdapter`)才会创建它。在此之前,没有简单的方法可以防止在引用目录时出现操作系统权限错误,例如在测试中,或者在以后应用权限时。
-#### [](#message-headers)消息头
+#### 消息头
从版本 5.0 开始,`FileReadingMessageSource`(除了`payload`作为 polled`File`)将以下头填充到出站`Message`:
@@ -127,7 +127,7 @@ compile "org.springframework.integration:spring-integration-file:5.5.9"
* `FileHeaders.RELATIVE_PATH`:引入了一个新的头,用于表示相对于扫描的根目录的文件路径的一部分。当需要在其他地方恢复源目录层次结构时,这个头可能很有用。为此,可以将`DefaultFileNameGenerator`(参见“`[生成文件名](#file-writing-file-names))配置为使用此标头。
-#### [](#directory-scanning-and-polling)目录扫描和轮询
+#### 目录扫描和轮询
`FileReadingMessageSource`不会立即为目录中的文件生成消息。它对`scanner`返回的“合格文件”使用内部队列。`scanEachPoll`选项用于确保在每个轮询中使用最新的输入目录内容刷新内部队列。默认情况下(`scanEachPoll = false`),`FileReadingMessageSource`在再次扫描目录之前清空其队列。这种默认行为对于减少对目录中大量文件的扫描特别有用。然而,在需要自定义排序的情况下,重要的是要考虑将此标志设置为`true`的效果。文件处理的顺序可能不像预期的那样。默认情况下,队列中的文件按其自然(`path`)顺序进行处理。通过扫描添加的新文件(即使队列中已经有文件)被插入到适当的位置,以维护该 Natural Order。要定制顺序,`FileReadingMessageSource`可以接受`Comparator`作为构造函数参数。内部(`PriorityBlockingQueue`)使用它来根据业务需求对其内容进行重新排序。因此,要以特定的顺序处理文件,你应该为`FileReadingMessageSource`提供一个比较器,而不是对由自定义`DirectoryScanner`生成的列表进行排序。
@@ -136,7 +136,7 @@ compile "org.springframework.integration:spring-integration-file:5.5.9"
| |从版本 5.5 开始,爪哇 DSL 的`FileInboundChannelAdapterSpec`有一个方便的`recursive(boolean)`选项,可以在目标`RecursiveDirectoryScanner`中使用`RecursiveDirectoryScanner`,而不是默认的。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#file-namespace-support)名称空间支持
+#### 名称空间支持
通过使用特定于文件的命名空间,可以简化文件读取的配置。要做到这一点,请使用以下模板:
@@ -222,7 +222,7 @@ compile "org.springframework.integration:spring-integration-file:5.5.9"
| |默认情况下,`DefaultDirectoryScanner`使用`IgnoreHiddenFileListFilter`和`AcceptOnceFileListFilter`。
为了防止它们的使用,你可以配置自己的过滤器(例如`AcceptAllFileListFilter`),甚至将其设置为`null`。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#watch-service-directory-scanner)`WatchServiceDirectoryScanner`
+#### `WatchServiceDirectoryScanner`
当新文件被添加到目录时,`FileReadingMessageSource.WatchServiceDirectoryScanner`依赖于文件系统事件。在初始化过程中,目录被注册以生成事件。初始文件列表也是在初始化期间生成的。在遍历目录树时,还会注册遇到的任意子目录以生成事件。在第一次轮询时,将返回从遍历目录中获得的初始文件列表。在随后的投票中,将返回来自新创建事件的文件。如果添加了一个新的子目录,它的创建事件将用于遍历新的子树,以查找现有的文件并注册找到的任何新的子目录。
@@ -251,7 +251,7 @@ compile "org.springframework.integration:spring-integration-file:5.5.9"
watch-events="MODIFY"/>
```
-#### [](#limiting-memory-consumption)限制内存消耗
+#### 限制内存消耗
你可以使用`HeadDirectoryScanner`来限制保留在内存中的文件数量。这在扫描大型目录时可能很有用。对于 XML 配置,可以通过在入站通道适配器上设置`queue-size`属性来实现这一点。
@@ -260,7 +260,7 @@ compile "org.springframework.integration:spring-integration-file:5.5.9"
| |使用`HeadDirectoryScanner`与`AcceptOnceFileListFilter`不兼容。
由于在投票决定期间会参考所有过滤器,`AcceptOnceFileListFilter`不知道其他过滤器可能正在临时过滤文件。
即使以前由`HeadDirectoryScanner.HeadFilter`过滤的文件现在可用,`AcceptOnceFileListFilter`对它们进行过滤。
通常,在这种情况下,你应该删除处理过的文件,以便在未来的投票中可以使用以前过滤过的文件。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#configuring-with-java-configuration)使用 爪哇 配置进行配置
+#### 使用 爪哇 配置进行配置
下面的 Spring 引导应用程序展示了如何使用 Java 配置配置出站适配器的示例:
@@ -297,7 +297,7 @@ public class FileReadingJavaApplication {
}
```
-#### [](#configuring-with-the-java-dsl)使用 Java DSL 进行配置
+#### 使用 Java DSL 进行配置
Spring 以下引导应用程序展示了如何使用 Java DSL 配置出站适配器的示例:
@@ -325,7 +325,7 @@ public class FileReadingJavaApplication {
}
```
-#### [](#file-tailing)“tail”ing 文件
+#### “tail”ing 文件
另一个流行的用例是从文件的末尾(或尾部)获取“行”,在添加新行时捕获新行。提供了两种实现方式。第一个是`OSDelegatingFileTailingMessageProducer`,它使用本机`tail`命令(在具有该命令的操作系统上)。这通常是这些平台上最有效的实现。对于没有`tail`命令的操作系统,第二个实现`ApacheCommonsFileTailingMessageProducer`使用 Apache`commons-io``Tailer`类。
@@ -428,13 +428,13 @@ public class FileReadingJavaApplication {
| |指定`delay`、`end`或`reopen`属性将强制使用 Apache`commons-io`适配器,并使`native-options`属性不可用。|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#file-incomplete)处理不完整数据
+#### 处理不完整数据
在文件传输场景中,一个常见的问题是如何确定传输已经完成,这样你就不会开始读取不完整的文件。解决此问题的一种常见技术是使用一个临时名称编写文件,然后将其自动重命名为最终名称。这种技术,再加上屏蔽临时文件使其不被用户获取的过滤器,提供了一种健壮的解决方案。 Spring 编写文件(本地或远程)的集成组件使用这种技术。默认情况下,它们将`.writing`附加到文件名,并在传输完成后将其删除。
另一种常见的技术是编写第二个“标记”文件,以表明文件传输已经完成。在这种情况下,你不应该认为`somefile.txt`(例如)是可用的,直到`somefile.txt.complete`也存在。 Spring 集成版本 5.0 引入了新的过滤器以支持该机制。实现方式是为文件系统(`FileSystemMarkerFilePresentFileListFilter`)、[FTP](./ftp.html#ftp-incomplete)和[SFTP](./sftp.html#sftp-incomplete)提供的。它们是可配置的,使得标记文件可以有任何名称,尽管它通常与正在传输的文件相关。有关更多信息,请参见[Javadoc](https://docs.spring.io/spring-integration/api/org/springframework/integration/file/filters/FileSystemMarkerFilePresentFileListFilter.html)。
-### [](#file-writing)写入文件
+### 写入文件
要将消息写入文件系统,可以使用[`FileWritingMessageHandler`](https://DOCS. Spring.io/ Spring-integration/api/org/springframework/integration/file/FileWritingMessageHandler.html)。这个类可以处理以下有效负载类型:
@@ -454,7 +454,7 @@ public class FileReadingJavaApplication {
从版本 5.1 开始,你可以提供一个`BiConsumer>``newFileCallback`,如果你使用`FileExistsMode.APPEND`或`FileExistsMode.APPEND_NO_FLUSH`,并且必须创建一个新文件,则会触发该命令。此回调接收一个新创建的文件和触发该文件的消息。例如,这个回调可以用来编写在消息头中定义的 CSV 头。
-#### [](#file-writing-file-names)生成文件名
+#### 生成文件名
在最简单的形式中,`FileWritingMessageHandler`只需要一个目标目录来编写文件。要写入的文件的名称由处理程序的[`FileNameGenerator`](https://DOCS. Spring.io/ Spring-integration/api/org/springframework/integration/file/filenamegenerator.html)决定。[默认实现](https://docs.spring.io/spring-integration/api/org/springframework/integration/file/DefaultFileNameGenerator.html)查找一个消息头,其键与定义为[`FileHeaders.FILENAME`]的常量匹配(https://DOCS. Spring.io/ Spring-integration/api/constant-values.html#org.springframework.integration.file.fileheaders.filename)。
@@ -481,7 +481,7 @@ public class FileReadingJavaApplication {
从版本 4.2.5 开始,生成的文件名(作为`filename-generator`或`filename-generator-expression`求值的结果)可以与目标文件名一起表示子路径。和前面一样,它被用作`File(File parent, String child)`的第二个构造函数参数。然而,在过去,我们并没有为子路径创建(`mkdirs()`)目录,只假设了文件名。当我们需要恢复文件系统树以匹配源目录时,这种方法非常有用——例如,当解压缩归档并以原始顺序保存目标目录中的所有文件时。
-#### [](#file-writing-output-directory)指定输出目录
+#### 指定输出目录
文件出站通道适配器和文件出站网关都为指定输出目录提供了两个相互排斥的配置属性:
@@ -492,24 +492,24 @@ public class FileReadingJavaApplication {
| |Spring Integration2.2 引入了`directory-expression`属性。|
|---|-----------------------------------------------------------------------|
-##### [](#using-the-directory-attribute)使用`directory`属性
+##### 使用`directory`属性
当使用`directory`属性时,输出目录被设置为固定值,这是在初始化`FileWritingMessageHandler`时设置的。如果未指定此属性,则必须使用`directory-expression`属性。
-##### [](#using-the-directory-expression-attribute)使用`directory-expression`属性
+##### 使用`directory-expression`属性
如果你希望获得完整的 SPEL 支持,可以使用`directory-expression`属性。此属性接受一个 SPEL 表达式,该表达式是为正在处理的每条消息计算的。因此,在动态指定输出文件目录时,你可以完全访问消息的有效负载及其标题。
SPEL 表达式必须解析为`String`、`java.io.File`或`org.springframework.core.io.Resource`。(后面的值被计算为`File`)此外,得到的`String`或`File`必须指向一个目录。如果没有指定`directory-expression`属性,则必须设置`directory`属性。
-##### [](#using-the-auto-create-directory-attribute)使用`auto-create-directory`属性
+##### 使用`auto-create-directory`属性
默认情况下,如果目标目录不存在,则会自动创建相应的目标目录和任何不存在的父目录。为了防止这种行为,你可以将`auto-create-directory`属性设置为`false`。此属性同时适用于`directory`和`directory-expression`属性。
| |当使用`directory`属性并且`auto-create-directory`是`false`时,从 Spring Integration2.2 开始进行以下更改:
而不是在初始化适配器时检查目标目录的存在,现在将对正在处理的每条消息执行此检查。
此外,如果`auto-create-directory`是`true`并且在处理消息之间删除了目录,则将为正在处理的每条消息重新创建目录。|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#file-writing-destination-exists)处理现有的目标文件
+#### 处理现有的目标文件
当你写入文件并且目标文件已经存在时,默认的行为是覆盖该目标文件。可以通过在相关的文件出站组件上设置`mode`属性来更改此行为。存在以下备选方案:
@@ -555,7 +555,7 @@ SPEL 表达式必须解析为`String`、`java.io.File`或`org.springframework.co
| |当使用临时文件后缀(默认值是`.writing`)时,如果存在最终文件名或临时文件名,则`IGNORE`选项将应用。|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#file-flushing)使用`APPEND_NO_FLUSH`时刷新文件
+#### 使用`APPEND_NO_FLUSH`时刷新文件
在版本 4.3 中添加了`APPEND_NO_FLUSH`模式。使用它可以提高性能,因为文件不会在每条消息之后关闭。然而,如果发生故障,这可能会导致数据丢失。
@@ -573,15 +573,15 @@ Spring 集成提供了几种刷新策略来减轻这种数据损失:
当使用`flushInterval`时,间隔从最后一次写入开始。只有当文件空闲了一段时间时,才会刷新该文件。从版本 4.3.7 开始,可以将一个附加属性(`flushWhenIdle`)设置为`false`,这意味着该间隔从对先前刷新的(或新建的)文件的第一次写入开始。
-#### [](#file-timestamps)文件时间戳
+#### 文件时间戳
默认情况下,目标文件的`lastModified`时间戳是文件创建的时间(除了就地重命名保留当前时间戳)。从版本 4.3 开始,你现在可以配置`preserve-timestamp`(或者在使用 Java 配置时`setPreserveTimestamp(true)`)。对于`File`有效负载,这将时间戳从入站文件传输到出站文件(无论是否需要副本)。对于其他有效负载,如果存在`FileHeaders.SET_MODIFIED`报头(`file_setModified`),则用于设置目标文件的`lastModified`时间戳,只要报头是`Number`。
-#### [](#file-permissions)文件权限
+#### 文件权限
从版本 5.0 开始,当将文件写入支持 POSIX 权限的文件系统时,你可以在出站通道适配器或网关上指定这些权限。该属性是一个整数,通常以常见的八进制格式提供——例如,`0640`,这意味着所有者具有读/写权限,组具有只读权限,而其他组没有访问权限。
-#### [](#file-outbound-channel-adapter)文件出站通道适配器
+#### 文件出站通道适配器
以下示例配置文件出站通道适配器:
@@ -608,7 +608,7 @@ Spring 集成提供了几种刷新策略来减轻这种数据损失:
directory="${output.directory}"/>
```
-#### [](#file-writing-output-gateway)出站网关
+#### 出站网关
如果你希望继续基于写好的文件处理消息,则可以使用`outbound-gateway`代替。它的作用类似于`outbound-channel-adapter`。然而,在写入文件之后,它还将其作为消息的有效负载发送到应答通道。
@@ -630,7 +630,7 @@ Spring 集成提供了几种刷新策略来减轻这种数据损失:
如果你有更详细的需求,或者需要支持额外的有效负载类型作为要转换为文件内容的输入,则可以扩展`FileWritingMessageHandler`,但更好的选择是依赖[`Transformer`](#file-transforming)。
-#### [](#configuring-with-java-configuration-2)使用 Java 配置进行配置
+#### 使用 Java 配置进行配置
Spring 以下引导应用程序展示了如何使用 Java 配置配置入站适配器的示例:
@@ -667,7 +667,7 @@ public class FileWritingJavaApplication {
}
```
-#### [](#configuring-with-the-java-dsl-2)使用 Java DSL 进行配置
+#### 使用 Java DSL 进行配置
Spring 以下引导应用程序展示了如何使用 Java DSL 配置入站适配器的示例:
@@ -697,7 +697,7 @@ public class FileWritingJavaApplication {
}
```
-### [](#file-transforming)文件变形金刚
+### 文件变形金刚
要将从文件系统读取的数据转换为对象,或者反过来,你需要做一些工作。与`FileReadingMessageSource`和在较小程度上`FileWritingMessageHandler`不同,你可能需要自己的机制来完成工作。为此,你可以实现`Transformer`接口。或者,你可以为入站消息扩展`AbstractFilePayloadTransformer`。 Spring 集成提供了一些明显的实现方式。
@@ -719,7 +719,7 @@ public class FileWritingJavaApplication {
`delete-files`选项向 Transformer 发出信号,表示它应该在转换完成后删除入站文件。这绝不是在多线程环境中使用`FileReadingMessageSource`时使用`AcceptOnceFileListFilter`的替代方法(例如,通常使用 Spring 集成时)。
-### [](#file-splitter)文件拆分器
+### 文件拆分器
在版本 4.1.2 中添加了`FileSplitter`,并在版本 4.2 中添加了对名称空间的支持。基于`BufferedReader.readLine()`,`FileSplitter`将文本文件分割成单独的行。默认情况下,拆分器使用`Iterator`从文件中读取一行时,每次发出一行。将`iterator`属性设置为`false`会使它在将所有行作为消息发送之前将它们读入内存。这样做的一个用例可能是,如果你想在发送包含行的任何消息之前检测文件上的 I/O 错误。然而,它只适用于相对较短的文件。
@@ -845,7 +845,7 @@ public FileSplitter(boolean iterator, boolean markers, boolean markersJson)
如果需要从文件内容中提取有关头的更复杂的逻辑(不是第一行,不是整行的内容,也不是一个特定的头,等等),请考虑在[页眉 Enricher ](./content-enrichment.html#header-enricher)之前使用`FileSplitter`。请注意,已移动到标题的行可能会从正常的内容处理过程中向下游过滤。
-#### [](#idempotent-file-splitter)幂等下游处理拆分文件
+#### 幂等下游处理拆分文件
当`apply-sequence`为真时,拆分器在`SEQUENCE_NUMBER`标头中添加行号(当`markers`为真时,标记被计为行)。行号可以与[幂等接收机](./handler-advice.html#idempotent-receiver)一起使用,以避免重新启动后重新处理行。
@@ -884,7 +884,7 @@ public IntegrationFlow flow() {
}
```
-### [](#file-aggregator)文件聚合器
+### 文件聚合器
从版本 5.5 开始,在启用开始/结束标记时,引入了`FileAggregator`来覆盖`FileSplitter`用例的另一面。为了方便起见,`FileAggregator`实现了所有三种序列细节策略:
@@ -957,7 +957,7 @@ XML
如果`FileAggregator`的默认行为不满足目标逻辑,则建议使用单独的策略配置聚合器端点。有关更多信息,请参见`FileAggregator`Javadocs。
-### [](#remote-persistent-flf)远程持久文件列表过滤器
+### 远程持久文件列表过滤器
入站和流入站远程文件通道适配器(`FTP`,`SFTP`,以及其他技术)在默认情况下配置有相应的`AbstractPersistentFileListFilter`实现方式,在内存中配置有`MetadataStore`。要在集群中运行,可以使用共享的`MetadataStore`替换这些过滤器(有关更多信息,请参见[元数据存储](./meta-data-store.html#metadata-store))。这些过滤器用于防止多次抓取同一个文件(除非修改了时间)。从版本 5.2 开始,在获取文件之前立即将文件添加到筛选器中(如果获取失败,则进行反向操作)。
diff --git a/docs/spring-integration/ftp.md b/docs/spring-integration/ftp.md
index 44508c0b81a8cd8c4cb4afea243f362c9529ddaa..229767bf19f03adf9c0467bb7742cb0d627ab44f 100644
--- a/docs/spring-integration/ftp.md
+++ b/docs/spring-integration/ftp.md
@@ -1,6 +1,6 @@
# FTP/FTPS
-## [](#ftp)FTP/FTPS 适配器
+## FTP/FTPS 适配器
Spring 集成为使用 FTP 和 FTPS 的文件传输操作提供了支持。
@@ -36,11 +36,11 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/ftp
https://www.springframework.org/schema/integration/ftp/spring-integration-ftp.xsd"
```
-### [](#ftp-session-factory)ftp会话工厂
+### ftp会话工厂
Spring 集成提供了你可以用来创建 FTP(或 FTPS)会话的工厂。
-#### [](#default-factories)默认工厂
+#### 默认工厂
| |从版本 3.0 开始,默认情况下会话不再缓存。
参见[FTP Session Caching](#ftp-session-caching)。|
|---|-------------------------------------------------------------------------------------------------------------------------|
@@ -95,7 +95,7 @@ Spring 集成提供了你可以用来创建 FTP(或 FTPS)会话的工厂。
| |为 FTP 或 FTPS会话工厂提供值的一种更实用的方法是使用 Spring 的属性占位符支持(参见[https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-factory-placeholderconfigurer](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-factory-placeholderconfigurer))。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#advanced-configuration)高级配置
+### 高级配置
`DefaultFtpSessionFactory`提供了对底层客户机 API 的抽象,它(自 Spring Integration2.0 以来)是[Apache Commons 网](https://commons.apache.org/net/)。这将使你免于了解`org.apache.commons.net.ftp.FTPClient`的低级配置细节。在会话工厂上公开了几个常见的属性(自版本 4.0 以来,现在包括`connectTimeout`、`defaultTimeout`和`dataTimeout`)。然而,有时需要访问较低级别的`FTPClient`配置以实现更高级的配置(例如设置活动模式的端口范围)。为此,`AbstractFtpSessionFactory`(所有 FTP会话工厂的基类)以以下清单中所示的两种后处理方法的形式公开钩子:
@@ -126,7 +126,7 @@ public class AdvancedFtpSessionFactory extends DefaultFtpSessionFactory {
}
```
-#### [](#ftps-和-shared-sslsession)FTPS 和共享 SSLSession
+#### FTPS 和共享 SSLSession
当通过 SSL 或 TLS 使用 FTP 时,一些服务器需要在控制和数据连接上使用相同的`SSLSession`。这是为了防止“窃取”数据连接。有关更多信息,请参见[https://scarybeastsecurity.blogspot.cz/2009/02/vsftpd-210-released.html](https://scarybeastsecurity.blogspot.cz/2009/02/vsftpd-210-released.html)。
@@ -194,7 +194,7 @@ private static final class SharedSSLFTPSClient extends FTPSClient {
}
```
-### [](#ftp-dsf)委托会话工厂
+### 委托会话工厂
版本 4.2 引入了`DelegatingSessionFactory`,它允许在运行时选择实际的会话工厂。在调用 FTP 端点之前,在工厂上调用`setThreadKey()`将一个键与当前线程关联。然后使用该键查找要使用的实际会话工厂。使用后,你可以通过调用`clearThreadKey()`清除密钥。
@@ -225,7 +225,7 @@ private static final class SharedSSLFTPSClient extends FTPSClient {
从版本 5.0.7 开始,`DelegatingSessionFactory`可以与`RotatingServerAdvice`一起用于轮询多个服务器;请参见[入站通道适配器:轮询多个服务器和目录](#ftp-rotating-server-advice)。
-### [](#ftp-inbound)FTP 入站通道适配器
+### FTP 入站通道适配器
FTP 入站通道适配器是一种特殊的侦听器,它连接到 FTP 服务器并侦听远程目录事件(例如,创建的新文件),此时它将启动文件传输。下面的示例展示了如何配置`inbound-channel-adapter`:
@@ -290,7 +290,7 @@ FTP 入站通道适配器是一种特殊的侦听器,它连接到 FTP 服务
你还应该理解 FTP 入站通道适配器是一个轮询消费者。因此,你必须配置一个 Poller(通过使用全局默认值或局部子元素)。一旦文件被传输,将生成一条以`java.io.File`作为有效负载的消息,并将其发送到由`channel`属性标识的通道。
-#### [](#more-on-file-filtering-and-incomplete-files)更多关于文件过滤和不完整文件的信息
+#### 更多关于文件过滤和不完整文件的信息
有时,刚刚出现在监视(远程)目录中的文件是不完整的。通常,这样的文件是使用临时扩展名编写的(例如`somefile.txt.writing`),然后在编写过程完成后重新命名。在大多数情况下,你只对完整的文件感兴趣,并且只想筛选完整的文件。要处理这些场景,可以使用`filename-pattern`、`filename-regex`和`filter`属性提供的过滤支持。下面的示例使用了自定义过滤器实现:
@@ -307,7 +307,7 @@ FTP 入站通道适配器是一种特殊的侦听器,它连接到 FTP 服务
```
-#### [](#poller-configuration-notes-for-the-inbound-ftp-adapter)入站 FTP 适配器的 Poller 配置注意事项
+#### 入站 FTP 适配器的 Poller 配置注意事项
入站 FTP 适配器的工作包括两个任务:
@@ -321,7 +321,7 @@ FTP 入站通道适配器是一种特殊的侦听器,它连接到 FTP 服务
你也可以将“max-messages-per-poll”值设置为正值,该值指示从每个 poll 文件创建的消息的向上限制。例如,值`10`意味着,在每个轮询中,它尝试处理的文件不超过 10 个。
-#### [](#recovering-from-failures)从故障中恢复
+#### 从故障中恢复
理解适配器的体系结构是很重要的。有一个文件同步器来获取文件,还有一个`FileReadingMessageSource`为每个同步文件发出一条消息。正如前面所讨论的,涉及两个过滤器。`filter`属性(和模式)引用远程文件列表,以避免获取已经获取的文件。`local-filter`由`FileReadingMessageSource`用来确定哪些文件将作为消息发送。
@@ -359,7 +359,7 @@ FTP 入站通道适配器是一种特殊的侦听器,它连接到 FTP 服务
从版本 5.0 开始,入站通道适配器可以在本地构建与生成的本地文件名对应的子目录。这也可以是一个远程子路径。为了能够根据层次结构支持递归地读取本地目录以进行修改,你现在可以使用基于`Files.walk()`算法的新的`RecursiveDirectoryScanner`提供一个内部`FileReadingMessageSource`。参见[`AbstractInboundFileSynchronizingMessageSource.setScanner()`](https://DOCS. Spring.io/ Spring-integration/api/org/springframework/integration/file/remote/synchronizer/abstractinboundfilesynchronizingmessagesource.html#setscanner)了解更多信息。此外,你现在可以通过使用`setUseWatchService()`选项将`AbstractInboundFileSynchronizingMessageSource`切换到基于`WatchService`的`DirectoryScanner`。它还被配置为所有`WatchEventType`实例,以对本地目录中的任何修改做出反应。前面显示的再处理示例基于`FileReadingMessageSource.WatchServiceDirectoryScanner`的内置功能,当从本地目录中删除文件(`StandardWatchEventKinds.ENTRY_DELETE`)时执行`ResettableFileListFilter.remove()`。有关更多信息,请参见[`WatchServiceDirectoryScanner`](./file.html#watch-service-directory-scanner)。
-#### [](#configuring-with-java-configuration)使用 Java 配置进行配置
+#### 使用 Java 配置进行配置
Spring 以下引导应用程序展示了如何使用 Java 配置配置入站适配器的示例:
@@ -421,7 +421,7 @@ public class FtpJavaApplication {
}
```
-#### [](#configuring-with-the-java-dsl)使用 Java DSL 进行配置
+#### 使用 Java DSL 进行配置
Spring 以下引导应用程序展示了如何使用 Java DSL 配置入站适配器的示例:
@@ -453,13 +453,13 @@ public class FtpJavaApplication {
}
```
-#### [](#ftp-incomplete)处理不完整数据
+#### 处理不完整数据
见[处理不完整的数据](./file.html#file-incomplete)。
提供`FtpSystemMarkerFilePresentFileListFilter`以过滤远程系统上没有相应标记文件的远程文件。有关配置信息,请参见[Javadoc](https://docs.spring.io/spring-integration/api/org/springframework/integration/ftp/filters/FtpSystemMarkerFilePresentFileListFilter.html)(并浏览到父类)。
-### [](#ftp-streaming)FTP 流媒体入站通道适配器
+### FTP 流媒体入站通道适配器
版本 4.3 引入了流入站通道适配器。此适配器生成的消息的有效负载类型为`InputStream`,这样就可以在不将文件写入本地文件系统的情况下获取文件。由于会话保持打开,所以当文件已被消费时,消费应用程序负责关闭会话。会话在`closeableResource`报头(`IntegrationMessageHeaderAccessor.CLOSEABLE_RESOURCE`)中提供。标准框架组件,例如`FileSplitter`和`StreamTransformer`,会自动关闭会话。有关这些组件的更多信息,请参见[文件拆分器](./file.html#file-splitter)和[流变压器](./transformer.html#stream-transformer)。下面的示例展示了如何配置`inbound-streaming-channel-adapter`:
@@ -492,7 +492,7 @@ public class FtpJavaApplication {
从版本 5.1 开始,`comparator`的通用类型是`FTPFile`。以前,它是`AbstractFileInfo`。这是因为排序现在是在处理的较早阶段执行的,在过滤和应用`maxFetch`之前。
-#### [](#ftp-streaming-java)使用 Java 配置进行配置
+#### 使用 Java 配置进行配置
Spring 以下引导应用程序展示了如何使用 Java 配置配置入站适配器的示例:
@@ -547,7 +547,7 @@ public class FtpJavaApplication {
请注意,在本例中,Transformer 下游的消息处理程序有一个建议,该建议在处理后删除远程文件。
-### [](#ftp-rotating-server-advice)入站通道适配器:轮询多个服务器和目录
+### 入站通道适配器:轮询多个服务器和目录
从版本 5.0.7 开始,`RotatingServerAdvice`是可用的;当配置为 Poller 建议时,入站适配器可以轮询多个服务器和目录。配置建议,并将其正常添加到 Poller 的建议链中。a`DelegatingSessionFactory`用于选择服务器,有关更多信息,请参见[Delegating Session Factory](#ftp-dsf)。通知配置由`RotationPolicy.KeyDirectory`对象列表组成。
@@ -627,7 +627,7 @@ public IntegrationFlow flow() {
| |使用此建议时,不要在 poller 上配置`TaskExecutor`;有关更多信息,请参见[消息源的条件 Poller](./polling-consumer.html#conditional-pollers)。|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#ftp-max-fetch)入站通道适配器:控制远程文件获取
+### 入站通道适配器:控制远程文件获取
在配置入站通道适配器时,应该考虑两个属性。`max-messages-per-poll`,与所有 Poller 一样,可以用来限制在每个轮询上发出的消息的数量(如果超过配置的值已经准备好)。`max-fetch-size`(自版本 5.0 起)可以限制一次从远程服务器检索到的文件的数量。
@@ -648,7 +648,7 @@ public IntegrationFlow flow() {
从版本 5.1 开始,同步器可以提供`Comparator`。这在限制使用`maxFetchSize`获取的文件数量时很有用。
-### [](#ftp-outbound)FTP 出站通道适配器
+### FTP 出站通道适配器
FTP 出站通道适配器依赖于一个`MessageHandler`实现,该实现连接到 FTP 服务器,并为它在传入消息的有效负载中接收的每个文件发起 FTP 传输。它还支持一个文件的几种表示,因此你不仅限于`java.io.File`类型的有效负载。FTP 出站通道适配器支持以下有效负载:
@@ -705,7 +705,7 @@ FTP 出站通道适配器依赖于一个`MessageHandler`实现,该实现连接
版本 5.2 引入了`chmod`属性,你可以使用该属性在上传后更改远程文件权限。你可以使用常规的 UNIX 八进制格式(例如,`600`仅允许文件所有者进行读写)。当使用 Java 配置适配器时,可以使用`setChmodOctal("600")`或`setChmod(0600)`。仅当你的 FTP 服务器支持`SITE CHMOD`子命令时才适用。
-#### [](#avoiding-partially-written-files)避免部分写入的文件
+#### 避免部分写入的文件
处理文件传输时出现的一个常见问题是处理部分文件的可能性。也就是说,一个文件可能会在其传输真正完成之前出现在文件系统中。
@@ -715,7 +715,7 @@ Spring 为了处理这个问题,集成 FTP 适配器使用一种常见的算
但是,在某些情况下,你可能不想使用这种技术(例如,如果服务器不允许重命名文件)。对于这样的情况,你可以通过将`use-temporary-file-name`设置为`false`来禁用此功能(默认值为`true`)。当此属性`false`时,文件将以其最终名称写入,并且使用该应用程序的应用程序需要一些其他机制来检测该文件是否已完全上传,然后才能访问它。
-#### [](#configuring-with-java-configuration-2)使用 Java 配置进行配置
+#### 使用 Java 配置进行配置
Spring 以下引导应用程序展示了如何使用 Java 配置配置出站适配器的示例:
@@ -770,7 +770,7 @@ public class FtpJavaApplication {
}
```
-#### [](#configuring-with-the-java-dsl-2)使用 Java DSL 进行配置
+#### 使用 Java DSL 进行配置
Spring 以下引导应用程序展示了如何使用 Java DSL 配置出站适配器的示例:
@@ -820,7 +820,7 @@ public class FtpJavaApplication {
}
```
-### [](#ftp-outbound-gateway)FTP 出站网关
+### FTP 出站网关
FTP 出站网关提供了一组有限的命令来与远程 FTP 或 FTPS 服务器进行交互。支持的命令是:
@@ -840,7 +840,7 @@ FTP 出站网关提供了一组有限的命令来与远程 FTP 或 FTPS 服务
* `mput`(发送多个文件)
-#### [](#ftp-using-ls)使用`ls`命令
+#### 使用`ls`命令
`ls`列出了远程文件并支持以下选项:
@@ -866,7 +866,7 @@ FTP 出站网关提供了一组有限的命令来与远程 FTP 或 FTPS 服务
从版本 4.3 开始,`FtpSession`对`list()`和`listNames()`方法支持`null`。因此,你可以省略`expression`属性。为了方便起见,Java 配置有两个不具有`expression`参数的构造函数。或`LS`、`NLST`、`PUT`和`MPUT`命令,根据 FTP 协议,`null`被视为客户机工作目录。所有其他命令都必须提供`expression`,以根据请求消息计算远程路径。在扩展`DefaultFtpSessionFactory`并实现`postProcessClientAfterConnect()`回调时,可以使用`FTPClient.changeWorkingDirectory()`函数设置工作目录。
-#### [](#using-the-nlst-command)使用`nlst`命令
+#### 使用`nlst`命令
版本 5 引入了对`nlst`命令的支持。
@@ -880,7 +880,7 @@ FTP 出站网关提供了一组有限的命令来与远程 FTP 或 FTPS 服务
与[`ls`命令](#ftp-using-ls)的`-1`选项不同,该选项使用`LIST`命令,`nlst`命令向目标 FTP 服务器发送`NLST`命令。当服务器不支持`LIST`(例如由于安全限制)时,此命令很有用。`nlst`操作的结果是没有其他详细信息的名称。因此,框架不能确定一个实体是否是一个目录,例如执行筛选或递归列表。
-#### [](#using-the-get-command)使用`get`命令
+#### 使用`get`命令
`get`检索远程文件。它支持以下选项:
@@ -925,7 +925,7 @@ if (closeable != null) {
expression="headers['closeableResource'].close()" />
```
-#### [](#using-the-mget-command)使用`mget`命令
+#### 使用`mget`命令
`mget`基于模式检索多个远程文件,并支持以下选项:
@@ -971,7 +971,7 @@ if (closeable != null) {
另请参见[出站网关部分成功(`mget`和`mput`)]。
-#### [](#ftp-put-command)使用`put`命令
+#### 使用`put`命令
`put`commad 将文件发送到远程服务器。消息的有效负载可以是`java.io.File`、`byte[]`或`String`。使用`remote-filename-generator`(或表达式)为远程文件命名。其他可用的属性包括`remote-directory`,`temporary-remote-directory`,以及它们的`*-expression`等价物:`use-temporary-file-name`和`auto-create-directory`。有关更多信息,请参见[schema](https://github.com/spring-projects/spring-integration/tree/main/spring-integration-core/src/main/resources/org/springframework/integration/config)文档。
@@ -979,7 +979,7 @@ if (closeable != null) {
5.2 版本引入了`chmod`属性,该属性在上传后更改远程文件权限。你可以使用常规的 UNIX 八进制格式(例如,`600`仅允许文件所有者进行读写)。当使用 Java 配置适配器时,可以使用`setChmod(0600)`。仅当你的 FTP 服务器支持`SITE CHMOD`子命令时才适用。
-#### [](#using-the-mput-command)使用`mput`命令
+#### 使用`mput`命令
`mput`将多个文件发送到服务器,并且只支持一个选项:
@@ -995,7 +995,7 @@ if (closeable != null) {
版本 5.2 引入了`chmod`属性,它允许你在上传后更改远程文件权限。你可以使用常规的 UNIX 八进制格式(例如,`600`仅允许文件所有者进行读写)。当使用 Java 配置适配器时,可以使用`setChmodOctal("600")`或`setChmod(0600)`。仅当你的 FTP 服务器支持`SITE CHMOD`子命令时才适用。
-#### [](#using-the-rm-command)使用`rm`命令
+#### 使用`rm`命令
`rm`命令删除文件。
@@ -1003,7 +1003,7 @@ if (closeable != null) {
如果删除成功,则`rm`操作产生的消息有效负载为`Boolean.TRUE`,否则为`Boolean.FALSE`。`file_remoteDirectory`头提供远程目录,`file_remoteFile`头提供文件名。
-#### [](#using-the-mv-command)使用`mv`命令
+#### 使用`mv`命令
`mv`命令移动文件。
@@ -1013,7 +1013,7 @@ if (closeable != null) {
从版本 5.5.6 开始,`remoteDirectoryExpression`可以在`mv`命令中使用,以方便使用。如果“from”文件不是完整的文件路径,则将`remoteDirectoryExpression`的结果用作远程目录。这同样适用于“to”文件,例如,如果任务只是重命名某个目录中的远程文件。
-#### [](#additional-information-about-ftp-outbound-gateway-commands)有关 FTP 出站网关命令的其他信息
+#### 有关 FTP 出站网关命令的其他信息
`get`和`mget`命令支持`local-filename-generator-expression`属性。它定义了一个 SPEL 表达式,以便在传输过程中生成本地文件的名称。求值上下文的根对象是请求消息。对于`mget`特别有用的`remoteFileName`变量也是可用的——例如,`local-filename-generator-expression="#remoteFileName.toUpperCase() + headers.something"`。
@@ -1039,7 +1039,7 @@ if (closeable != null) {
从版本 5.0 开始,`setWorkingDirExpression()`(在 XML 中为`working-dir-expression`)选项在`FtpOutboundGateway`(在 XML 中为``)上提供。它允许你在运行时更改客户机工作目录。表达式根据请求消息进行求值。在每次网关操作之后,都会恢复以前的工作目录。
-#### [](#configuring-with-java-configuration-3)使用 Java 配置进行配置
+#### 使用 Java 配置进行配置
Spring 以下引导应用程序展示了如何使用 Java 配置出站网关的示例:
@@ -1076,7 +1076,7 @@ public class FtpJavaApplication {
}
```
-#### [](#configuring-with-the-java-dsl-3)使用 Java DSL 进行配置
+#### 使用 Java DSL 进行配置
Spring 以下引导应用程序展示了如何使用 Java DSL 配置出站网关的示例:
@@ -1121,7 +1121,7 @@ public class FtpJavaApplication {
}
```
-#### [](#ftp-partial)出站网关部分成功(`mget`和`mput`)
+#### 出站网关部分成功(`mget`和`mput`)
在对多个文件执行操作时(通过使用`mget`和`mput`),在传输了一个或多个文件后的一段时间内可能会发生异常。在这种情况下(从版本 4.2 开始),将抛出一个`PartialSuccessException`。除了通常的`MessagingException`属性(`failedMessage`和`cause`)外,该异常还具有两个附加属性:
@@ -1146,7 +1146,7 @@ root/
如果异常发生在`file3.txt`上,则网关抛出的`PartialSuccessException`具有`derivedInput`of`file1.txt`,`subdir`,以及`zoo.txt`和`partialResults`of`file1.txt`。其`cause`是另一个`PartialSuccessException`与`derivedInput`之`file2.txt`和`file3.txt`之`partialResults`之`file2.txt`之。
-### [](#ftp-session-caching)ftp会话缓存
+### ftp会话缓存
| |从 Spring Integration3.0 开始,默认情况下不再缓存会话。
端点不再支持`cache-sessions`属性。
如果你希望缓存会话,则必须使用`CachingSessionFactory`(如下一个示例所示)。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -1173,7 +1173,7 @@ root/
从版本 5.1 开始,`CachingSessionFactory`有一个新的属性`testSession`。当为真时,会话将通过发送一个 Noop 命令来进行测试,以确保它仍然处于活动状态;如果不是,它将从缓存中删除;如果缓存中没有活动会话,则创建一个新的会话。
-### [](#ftp-rft)使用`RemoteFileTemplate`
+### 使用`RemoteFileTemplate`
从 Spring Integration3.0 开始,在`FtpSession`对象上提供了一个新的抽象。该模板提供了发送、检索(作为`InputStream`)、删除和重命名文件的方法。此外还提供了一种方法,允许调用者在会话上执行多个操作。在所有情况下,模板都能可靠地关闭会话。有关更多信息,请参见[Javadoc for`RemoteFileTemplate`](https://DOCS. Spring.io/ Spring-integration/api/org/springframework/integration/file/remote/remotefiletemplate.html)。FTP 有一个子类:`FtpRemoteFileTemplate`。
@@ -1193,7 +1193,7 @@ root/
从版本 5.0 开始,新的`RemoteFileOperations.invoke(OperationsCallback action)`方法可用。这个方法允许在相同的、以线程为界的`Session`的范围内调用几个`RemoteFileOperations`调用。当你需要将`RemoteFileTemplate`作为一个工作单元执行多个高级操作时,这是非常有用的。例如,`AbstractRemoteFileOutboundGateway`将其与`mput`命令实现一起使用,其中我们对提供的目录中的每个文件执行`put`操作,并递归地对其子目录执行该操作。有关更多信息,请参见[Javadoc](https://docs.spring.io/spring-integration/api/org/springframework/integration/file/remote/RemoteFileOperations.html#invoke)。
-### [](#ftp-session-callback)使用`MessageSessionCallback`
+### 使用`MessageSessionCallback`
从 Spring Integration4.2 开始,你可以使用带有``(在 Java 中是`FtpOutboundGateway`)的`MessageSessionCallback`实现来执行带有`requestMessage`上下文的`Session`上的任何操作。它可以用于任何非标准或低级别的 FTP 操作,并允许从集成流定义和功能接口实现注入进行访问,如以下示例所示:
@@ -1213,7 +1213,7 @@ public MessageHandler ftpOutboundGateway(SessionFactory sessionFactory)
| |`session-callback`与`command`和`expression`属性是互斥的。
当使用 Java 进行配置时,在[`FtpOutboundGateway`](https://DOCS. Spring.io/ Spring-integration/api/org/boundspringframework/integration/ftp/gateway/ftpoutgateway.html)类中可以使用不同的构造函数。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#ftp-server-events)Apache Mina FTP 服务器事件
+### Apache Mina FTP 服务器事件
在版本 5.2 中添加的`ApacheMinaFtplet`监听某些 Apache Mina FTP 服务器事件,并将其发布为`ApplicationEvent`s,该事件可以由任何`ApplicationListener` Bean、`@EventListener` Bean 方法或[事件入站通道适配器](./event.html#appevent-inbound)方法接收。
@@ -1261,7 +1261,7 @@ public ApplicationEventListeningMessageProducer eventsAdapter() {
}
```
-### [](#ftp-remote-file-info)远程文件信息
+### 远程文件信息
从版本 5.2 开始,`FtpStreamingMessageSource`([FTP 流入站通道适配器](#ftp-streaming))、`FtpInboundFileSynchronizingMessageSource`([FTP 入站通道适配器](#ftp-inbound))和“read”---命令的`FtpOutboundGateway`([FTP 出站网关](#ftp-outbound-gateway))在消息中提供额外的头,以生成有关远程文件的信息:
diff --git a/docs/spring-integration/gemfire.md b/docs/spring-integration/gemfire.md
index 0930ea7131453870d0c6a93e5bb02b96d20114b2..d53d6e0343001a2268d02d659e03b270bb71c091 100644
--- a/docs/spring-integration/gemfire.md
+++ b/docs/spring-integration/gemfire.md
@@ -1,6 +1,6 @@
# Pivotal Gemfire 和 Apache Geode 支持
-## [](#gemfire)Pivotal Gemfire 和 Apache Geode 支持
+## Pivotal Gemfire 和 Apache Geode 支持
Spring 集成为 Pivotal Gemfire 和 Apache Geode 提供了支持。
@@ -54,7 +54,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/gemfire
https://www.springframework.org/schema/integration/gemfire/spring-integration-gemfire.xsd"
```
-### [](#gemfire-inbound)入站通道适配器
+### 入站通道适配器
当 Gemfire`EntryEvent`触发时,入站通道适配器在通道上生成消息。每当相关区域中的条目`CREATED`、`UPDATED`、`DESTROYED`或`INVALIDATED`时,Gemfire 都会生成事件。入站通道适配器允许你筛选这些事件的一个子集。例如,你可能希望仅在响应正在创建的条目时生成消息。此外,如果希望消息有效负载包含事件属性(如新的 entry 值),则入站通道适配器可以计算 SPEL 表达式。下面的示例展示了如何使用 SPEL 语言(在`expression`属性中)配置入站通道适配器:
@@ -76,7 +76,7 @@ expression="new something.MyEvent(key, oldValue, newValue)"
| |此适配器符合 Spring 集成约定。|
|---|--------------------------------------------------------|
-### [](#gemfire-cq)连续查询入站通道适配器
+### 连续查询入站通道适配器
当 Gemfire 连续查询或`CqEvent`事件触发时,连续查询入站通道适配器在通道上生成消息。在版本`1.1`中, Spring Data 引入了连续查询支持,包括`ContinuousQueryListenerContainer`,这在 Gemfire 原生 API 上提供了一个很好的抽象。这个适配器需要对`ContinuousQueryListenerContainer`实例的引用,为给定的`query`创建一个侦听器,并执行查询。连续查询充当事件源,每当其结果集更改状态时,它都会触发事件源。
@@ -107,7 +107,7 @@ expression="new something.MyEvent(key, oldValue, newValue)"
| |此适配器符合 Spring 集成约定。|
|---|--------------------------------------------------------|
-### [](#gemfire-outbound)出站通道适配器
+### 出站通道适配器
出站通道适配器写入从消息有效负载映射的缓存项。在其最简单的形式中,它期望类型`java.util.Map`的有效负载,并将映射条目放入其配置的区域中。下面的示例展示了如何配置出站通道适配器:
@@ -128,7 +128,7 @@ expression="new something.MyEvent(key, oldValue, newValue)"
在前面的配置中,内部元素(`cache-entries`)在语义上等同于 Spring’map’元素。适配器将`key`和`value`属性解释为 SPEL 表达式,并将消息作为求值上下文。请注意,这可以包含任意的缓存条目(不仅仅是从消息派生的条目),并且文字值必须用单引号括起来。在前面的示例中,如果发送到`cacheChannel`的消息具有`String`值`Hello`的有效负载,则在缓存区域中写入两个条目(`[HELLO:hello, thing1:thing2]`)(要么创建要么更新)。此适配器还支持`order`属性,如果将其绑定到`PublishSubscribeChannel`,则该属性可能很有用。
-### [](#gemfire-message-store)Gemfire 消息存储
+### Gemfire 消息存储
正如 EIP 中所描述的,[消息存储](https://www.enterpriseintegrationpatterns.com/MessageStore.html)允许你持久化消息。在处理具有缓冲消息能力的组件(`QueueChannel`,`Aggregator`,`Resequencer`,以及其他)时,如果可靠性是一个问题,这可能是有用的。在 Spring 集成中,`MessageStore`策略接口还为[索赔检查](https://www.enterpriseintegrationpatterns.com/StoreInLibrary.html)模式提供了基础,这也在 EIP 中进行了描述。
@@ -174,14 +174,14 @@ Spring Integration 的 Gemfire 模块提供了`GemfireMessageStore`,这是`Mes
从版本 4.3.12 开始,`GemfireMessageStore`支持键`prefix`选项,以允许在同一 Gemfire 区域上的存储实例之间进行区分。
-### [](#gemfire-lock-registry)Gemfire Lock 注册表
+### Gemfire Lock 注册表
从版本 4.0 开始,`GemfireLockRegistry`是可用的。某些组件(例如,聚合器和重排序程序)使用从`LockRegistry`实例获得的锁,以确保在任何给定的时间只有一个线程正在操作组。`DefaultLockRegistry`在单个组件中执行此功能。现在,你可以在这些组件上配置一个外部锁注册中心。当你使用与`GemfireLockRegistry`共享的`MessageGroupStore`时,它可以跨多个应用程序实例提供此功能,从而一次只有一个实例可以操作组。
| |其中一个`GemfireLockRegistry`构造函数需要一个`Region`作为参数。
它用于从`getDistributedLock()`方法获得一个`Lock`。
该操作需要`GLOBAL`用于`Region`的作用域。,
另一个构造函数需要一个`Cache`,而`Region`是用`GLOBAL`作用域和名称`LockRegistry`创建的。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#gemfire-metadata-store)Gemfire 元数据存储
+### Gemfire 元数据存储
4.0 版本引入了一个新的基于 Gemfire 的`MetadataStore`([元数据存储](./meta-data-store.html#metadata-store))实现。你可以使用`GemfireMetadataStore`在应用程序重新启动期间维护元数据状态。这个新的`MetadataStore`实现可以与适配器一起使用,例如:
diff --git a/docs/spring-integration/history.md b/docs/spring-integration/history.md
index b7734097e3734951c15f1faf21272da45fedc391..50394537c282853a954c3d190bb69207d02bda9c 100644
--- a/docs/spring-integration/history.md
+++ b/docs/spring-integration/history.md
@@ -1,12 +1,12 @@
# 变更历史
-## [](#history)变更历史
+## 变更历史
-### [](#migration-5.3-5.4)5.3 和 5.4 之间的变化
+### 5.3 和 5.4 之间的变化
-### [](#x5.4-new-components)新组件
+### 新组件
-#### [](#x5.4-sik)用于 Apache Kafka 的通道适配器
+#### 用于 Apache Kafka 的通道适配器
独立的[Spring Integration for Apache Kafka](https://projects.spring.io/spring-integration-kafka/)项目已合并为该项目的`spring-integration-kafka`模块。
@@ -16,23 +16,23 @@
有关更多信息,请参见[Spring for Apache Kafka Support](./kafka.html#kafka)。
-#### [](#x5.4-r2dbc)R2DBC 通道适配器
+#### R2DBC 通道适配器
介绍了用于 R2DBC 数据库交互的通道适配器。有关更多信息,请参见[R2DBC 支持](./r2dbc.html#r2dbc)。
-#### [](#x5.4-redis-stream)Redis 流支持
+#### Redis 流支持
Redis 流支持的通道适配器已经引入。有关更多信息,请参见[Redis 流出站通道适配器](./redis.html#redis-stream-outbound)。
-#### [](#x5.4-renewable-lock)可更新锁定注册中心
+#### 可更新锁定注册中心
引入了一个可更新的锁注册中心,以允许对分布式锁进行更新租赁。有关更多信息,请参见[JDBC 实现](./jdbc.html#jdbc-lock-registry)。
-#### [](#x5.4-zeromq)zeromq 支持
+#### zeromq 支持
已经引入了`ZeroMqChannel`、`ZeroMqMessageHandler`和`ZeroMqMessageProducer`。有关更多信息,请参见[ZeroMQ 支持](./zeromq.html#zeromq)。
-### [](#x5.4-general)一般变化
+### 一般变化
单向消息传递网关(`void`方法返回类型)现在将`nullChannel`显式地设置到`replyChannel`头中,以忽略任何可能的下游回复。有关更多信息,请参见[设置默认回复通道](./gateway.html#gateway-default-reply-channel)。
@@ -44,67 +44,67 @@ Redis 流支持的通道适配器已经引入。有关更多信息,请参见[R
[螺纹屏障](./barrier.html#barrier)现在有两个独立的超时选项:`requestTimeout`和`triggerTimeout`。
-### [](#x5.4-tcp)TCP/UDP 更改
+### TCP/UDP 更改
连接工厂现在支持多个发送组件(`TcpSender`);它们仍然限于一个接收组件(`TcpListener`)。例如,这允许入站网关和出站通道适配器共享相同的工厂,支持从服务器到客户机的请求/回复和任意消息传递。除非使用一次性连接或`ThreadAffinityClientConnectionFactory`,否则不应将共享工厂与出站网关一起使用。有关更多信息,请参见[协作通道适配器](./ip.html#ip-collaborating-adapters)和[TCP 网关](./ip.html#tcp-gateways)。
现在可以将 UDP 通道适配器配置为`SocketCustomizer`,这允许设置适配器不直接支持的套接字属性。有关更多信息,请参见[UDP 适配器](./ip.html#udp-adapters)。
-### [](#x5.4-rmi)RMI 变化
+### RMI 变化
`spring-integration-rmi`模块不推荐使用,不提供替换,并将在下一个主要版本中删除。有关更多信息,请参见[RMI 支助](./rmi.html#rmi)。
-### [](#x5.4-amqp)AMQP 变化
+### AMQP 变化
出站端点现在有了处理发布服务器确认和返回的新机制。有关更多信息,请参见[发布服务器确认和返回的替代机制](./amqp.html#alternative-confirms-returns)。
新的`BatchMode.EXTRACT_PAYLOAD_WITH_HEADERS`由`AmqpInboundChannelAdapter`支持。有关更多信息,请参见[入站通道适配器](./amqp.html#amqp-inbound-channel-adapter)。
-### [](#x5.4-mail)邮件更改
+### 邮件更改
`AbstractMailReceiver`现在可以生成`MimeMessage`as-is,而无需急于获取其内容。有关更多信息,请参见[邮件接收通道适配器](./mail.html#mail-inbound)。
-### [](#migration-5.2-5.3)5.2 与 5.3 之间的变化
+### 5.2 与 5.3 之间的变化
-### [](#x5.3-new-components)新组件
+### 新组件
-#### [](#x5.3-integration-pattern)集成模式
+#### 集成模式
引入了`IntegrationPattern`抽象,以指示哪个 Enterprise 集成模式(an`IntegrationPatternType`)和类别 A Spring 集成组件属于哪个。有关此抽象及其用例的更多信息,请参见其 Javadocs 和[积分图](./graph.html#integration-graph)。
-#### [](#x5.3-reactive-message-handler)`ReactiveMessageHandler`
+#### `ReactiveMessageHandler`
现在框架中原生支持`ReactiveMessageHandler`。有关更多信息,请参见[reactiveMessageHandler](./reactive-streams.html#reactive-message-handler)。
-#### [](#x5.3-reactive-message-source-producer)`ReactiveMessageSourceProducer`
+#### `ReactiveMessageSourceProducer`
`ReactiveMessageSourceProducer`是`MessageProducerSupport`的一个反应性实现,用于将所提供的`MessageSource`封装到`Flux`中,用于按需`receive()`调用。有关更多信息,请参见[反应流支持](./reactive-streams.html#reactive-streams)。
-#### [](#x5.3-java-dsl-extensions)Java DSL 扩展
+#### Java DSL 扩展
引入了一个新的`IntegrationFlowExtension`API,允许使用定制或组合的 EIP 操作符扩展现有的 Java DSL。这也可以用于为任何开箱即用的`IntegrationComponentSpec`扩展引入自定义程序。有关更多信息,请参见[DSL 扩展](./dsl.html#java-dsl-extensions)。
-#### [](#x5.3-kotlin-dsl) Kotlin dsl
+#### Kotlin dsl
Kotlin 介绍了用于集成流配置的 DSL。有关更多信息,请参见[Kotlin DSL Chapter](./kotlin-dsl.html#kotlin-dsl)。
-#### [](#x5.3-reactive-request-handler-advice)reactiverequesthandleradvice
+#### reactiverequesthandleradvice
提供了一个`ReactiveRequestHandlerAdvice`来自定义消息处理程序的`Mono`回复。有关更多信息,请参见[反应性建议](./handler-advice.html#reactive-advice)。
-#### [](#x5.3-handle-message-advice-adapter)处理 MessageAdviceAdapter
+#### 处理 MessageAdviceAdapter
提供了一个`HandleMessageAdviceAdapter`来包装任何`MethodInterceptor`,用于在`MessageHandler.handleMessage()`上应用,而不是默认的`AbstractReplyProducingMessageHandler.RequestHandler.handleRequestMessage()`行为。有关更多信息,请参见[处理消息建议](./handler-advice.html#handle-message-advice)。
-#### [](#x5.3-mongodb-reactive-channel-adapters)MongoDB 反应通道适配器
+#### MongoDB 反应通道适配器
`spring-integration-mongodb`模块现在为 Spring 数据中的反应式 MongoDB 驱动程序支持提供通道适配器实现。另外,对于 MongoDB 变更流支持的一个反应性实现存在于`MongoDbChangeStreamMessageProducer`中。有关更多信息,请参见[MongoDB 支持](./mongodb.html#mongodb)。
-#### [](#x5.3-receive-message-advice)收到邮件通知
+#### 收到邮件通知
一个特殊的`ReceiveMessageAdvice`已被引入到代理中,正好是`MessageSource.receive()`或`PollableChannel.receive()`。有关更多信息,请参见[智能轮询](./polling-consumer.html#smart-polling)。
-### [](#x5.3-general)一般更改
+### 一般更改
Gateway Proxy 现在默认不代理`default`方法。有关更多信息,请参见[调用`default`方法]。
@@ -122,21 +122,21 @@ Spring 集成中的事务支持现在还包括配置`ReactiveTransactionManager`
现在,`MessageProducerSupport`基类有一个`subscribeToPublisher(Publisher extends Message>>)`API,允许实现消息驱动的生产者端点,这些生产者端点通过反应性`Publisher`发送消息。有关更多信息,请参见[反应流支持](./reactive-streams.html#reactive-streams)。
-### [](#x5.3-amqp)AMQP 变化
+### AMQP 变化
出站通道适配器有一个新的属性`multiSend`,允许在一个`RabbitTemplate`调用的范围内发送多个消息。有关更多信息,请参见[AMQP 出站通道适配器](./amqp.html#amqp-outbound-channel-adapter)。
入站通道适配器现在支持一个侦听器容器,其`consumerBatchEnabled`属性设置为`true`。见[AMQP 入站通道适配器](./amqp.html#amqp-inbound-channel-adapter)
-### [](#x5.3-http)http 更改
+### http 更改
在`AbstractHttpRequestExecutingMessageHandler`上的`encodeUri`属性已被弃用,以支持新引入的`encodingMode`。有关更多信息,请参见`DefaultUriBuilderFactory.EncodingMode`Javadocs 和[控制 URI 编码](./http.html#http-uri-encoding)。这也会影响`WebFluxRequestExecutingMessageHandler`、相应的 Java DSL 和 XML 配置。将相同的选项添加到`AbstractWebServiceOutboundGateway`中。
-### [](#x5.3-ws)Web 服务变更
+### Web 服务变更
已经为 Web 服务组件添加了 Java DSL 支持。在`AbstractWebServiceOutboundGateway`上的`encodeUri`属性已被弃用,以支持新引入的`encodingMode`-类似于上面的 HTTP 更改。有关更多信息,请参见[Web 服务支持](./ws.html#ws)。
-### [](#x5.3-tcp)TCP 更改
+### TCP 更改
默认情况下,在当前连接失败之前,`FailoverClientConnectionFactory`不再会再次失败。有关更多信息,请参见[TCP 故障转移客户端连接工厂](./ip.html#failover-cf)。
@@ -144,69 +144,69 @@ Spring 集成中的事务支持现在还包括配置`ReactiveTransactionManager`
现在,你可以将客户端连接配置为对新连接执行一些任意的测试。有关更多信息,请参见[测试连接](./ip.html#testing-connections)。
-### [](#x5.3-rsocket)rsocket 更改
+### rsocket 更改
`decodeFluxAsUnit`选项已被添加到`RSocketInboundGateway`中,其含义是将传入的`Flux`作为单个单元进行解码,或对其中的每个事件应用解码。有关更多信息,请参见[RSocket 入站网关](./rsocket.html#rsocket-inbound)。
-### [](#x5.3-zookeeper)动物园管理员变更
+### 动物园管理员变更
`LeaderInitiatorFactoryBean`(以及其 XML``)公开了一个`candidate`选项,用于对`Candidate`配置进行更多控制。有关更多信息,请参见[领导事件处理](./zookeeper.html#zk-leadership)。
-### [](#x5.3-mqtt)MQTT 变化
+### MQTT 变化
现在可以将入站通道适配器配置为在消息被确认为已发送时为用户提供控制。有关更多信息,请参见[手动 ACK](./mqtt.html#mqtt-ack-mode)。
当连接无法创建或丢失时,出站适配器现在会发布`MqttConnectionFailedEvent`。以前,只有入站适配器才会这样做。见[MQTT 事件](./mqtt.html#mqtt-events)。
-### [](#x5.3-sftp)(s)FTP 更改
+### (s)FTP 更改
`FileTransferringMessageHandler`(例如对于 FTP 和 SFTP)除了`File`、`byte[]`、`String`和`InputStream`之外,现在还支持`org.springframework.core.io.Resource`。有关更多信息,请参见[SFTP 支持](./sftp.html#sftp)和[FTP 支持](./ftp.html#ftp)。
-### [](#x5.3-file)文件更改
+### 文件更改
对于`markersJson`模式,`FileSplitter`不再需要 Jackson 处理器(或类似的)依赖关系。它使用`SimpleJsonSerializer`表示`FileSplitter.FileMarker`实例的简单字符串表示。有关更多信息,请参见[文件夹](./file.html#file-splitter)。
-### [](#migration-5.1-5.2)5.1 和 5.2 之间的变化
+### 5.1 和 5.2 之间的变化
-### [](#x5.2-package-class)包和类的更改
+### 包和类的更改
`Pausable`已从`o.s.i.endpoint`移动到`o.s.i.core`。
-### [](#x5.2-behavior)行为变化
+### 行为变化
请参阅[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-5.1-to-5.2-Migration-Guide)关于此版本中的行为更改。
-### [](#x5.2-new-components)新组件
+### 新组件
-#### [](#x5.2-rsocket-support)RSocket 支持
+#### RSocket 支持
`spring-integration-rsocket`模块现在可以在支持 RSocket 协议的通道适配器实现中使用。有关更多信息,请参见[RSocket 支持](./rsocket.html#rsocket)。
-#### [](#x5.2-rate-limit-advice)利率限制建议支持
+#### 利率限制建议支持
`RateLimiterRequestHandlerAdvice`现在可用于限制处理程序的请求速率。有关更多信息,请参见[速率限制器建议](./handler-advice.html#rate-limiter-advice)。
-#### [](#x5.2-cache-advice)缓存建议支持
+#### 缓存建议支持
`CacheRequestHandlerAdvice`现在可用于在处理程序上缓存请求结果。有关更多信息,请参见[缓存建议](./handler-advice.html#cache-advice)。
-#### [](#x5.2-kotlin-scripts) Kotlin 脚本支持
+#### Kotlin 脚本支持
JSR223 脚本模块现在包括对 Kotlin 脚本的支持。有关更多信息,请参见[脚本支持](./scripting.html#scripting)。
-#### [](#x5.2-flux-aggregator)流量聚合器支持
+#### 流量聚合器支持
`FluxAggregatorMessageHandler`现在可用于基于 Project Reactor`Flux`操作符的消息逻辑的分组和窗口。有关更多信息,请参见[通量聚合器](./aggregator.html#flux-aggregator)。
-#### [](#x5.2-sftp-events)FTP/SFTP 事件发布者
+#### FTP/SFTP 事件发布者
FTP 和 SFTP 模块现在为某些 Apache Mina FTP/SFTP 服务器事件提供了一个事件侦听器。有关更多信息,请参见[Apache Mina FTP 服务器事件](./ftp.html#ftp-server-events)和[Apache Mina SFTP 服务器事件](./sftp.html#sftp-server-events)。
-#### [](#x5.2-avro)AVRO 变压器
+#### AVRO 变压器
现在提供了简单的 Apache AVRO 变压器。有关更多信息,请参见[AVRO 变压器](./transformers.html#avro-transformers)。
-### [](#x5.2-general)一般变化
+### 一般变化
现在,`JsonToObjectTransformer`支持将目标对象反序列化为泛型。有关更多信息,请参见[JSON 变形金刚](./transformer.html#json-transformers)。
@@ -220,7 +220,7 @@ FTP 和 SFTP 模块现在为某些 Apache Mina FTP/SFTP 服务器事件提供了
为了获得更好的最终用户体验,Java DSL 现在提供了一个配置变量,用于通过网关接口启动流。有关更多信息,请参见`IntegrationFlows.from(Class> serviceInterface, Consumer endpointConfigurer)`Javadocs。另外,`MethodArgsHolder`现在是用于`GatewayProxyFactoryBean`中所有表达式的求值上下文的根对象。现在不推荐`#args`和`#method`评估上下文变量。有关更多信息,请参见[消息传递网关](./gateway.html#gateway)。
-#### [](#x5.2-amqp)AMQP 变化
+#### AMQP 变化
如果在超时期间没有收到发布者确认,那么出站端点现在可以被配置为合成“NACK”。有关更多信息,请参见[出站通道适配器](./amqp.html#amqp-outbound-endpoints)。
@@ -228,11 +228,11 @@ FTP 和 SFTP 模块现在为某些 Apache Mina FTP/SFTP 服务器事件提供了
现在可以将出站通道适配器配置为阻止调用线程,直到收到发布者确认(确认)。有关更多信息,请参见[出站通道适配器](./amqp.html#amqp-outbound-channel-adapter)。
-#### [](#x5.2-file)文件更改
+#### 文件更改
对过滤远程文件进行了一些改进。有关更多信息,请参见[远程持久文件列表过滤器](./file.html#remote-persistent-flf)。
-#### [](#x5.2-tcp)TCP 更改
+#### TCP 更改
`ByteArrayLengthHeaderSerializer`使用的长度标头现在可以在有效负载之外包括标头的长度。有关更多信息,请参见[消息划分(序列化器和反序列化器)](./ip.html#tcp-codecs)。
@@ -244,57 +244,57 @@ FTP 和 SFTP 模块现在为某些 Apache Mina FTP/SFTP 服务器事件提供了
`SoftEndOfStreamException`现在是`RuntimeException`,而不是扩展`IOException`。
-#### [](#x5.2-mail)邮件更改
+#### 邮件更改
`AbstractMailReceiver`现在有一个`autoCloseFolder`选项(默认情况下是`true`),可以在获取后禁用自动文件夹关闭,但是填充`IntegrationMessageHeaderAccessor.CLOSEABLE_RESOURCE`头,以进行下游交互。有关更多信息,请参见[邮件接收通道适配器](./mail.html#mail-inbound)。
-#### [](#x5.2-http)http 更改
+#### http 更改
HTTP 入站端点现在支持请求有效负载验证。有关更多信息,请参见[HTTP 支持](./http.html#http)。
-#### [](#x5.2-webflux)WebFlux 更改
+#### WebFlux 更改
`WebFluxRequestExecutingMessageHandler`现在支持`Publisher`、`Resource`和`MultiValueMap`作为请求消息`payload`。`WebFluxInboundEndpoint`现在支持请求有效负载验证。有关更多信息,请参见[WebFlux 支持](./webflux.html#webflux)。
-#### [](#x5.2-mongodb)MongoDB 变更
+#### MongoDB 变更
现在可以将`MongoDbMessageStore`配置为自定义转换器。有关更多信息,请参见[MongoDB 支持](./mongodb.html#mongodb)。
-#### [](#x5.2-routers)路由器变更
+#### 路由器变更
现在你可以禁用返回通道键作为通道 Bean 名称。有关更多信息,请参见[动态路由器](./router.html#dynamic-routers)。
-#### [](#x5.2--ftp-sftp)ftp/sftp 更改
+#### ftp/sftp 更改
现在将`RotatingServerAdvice`与`RotationPolicy`及其`StandardRotationPolicy`解耦。
远程文件信息,包括主机/端口和目录,现在包含在`AbstractInboundFileSynchronizingMessageSource`和`AbstractRemoteFileStreamingMessageSource`实现中的消息头中。这一信息也包括在`AbstractRemoteFileOutboundGateway`实现的读取操作结果中的标题中。FTP 出站端点现在支持`chmod`更改上载文件的权限。(SFTP 从 4.3 版本开始就支持它了)。有关更多信息,请参见[FTP 支持](./ftp.html#ftp)和[SFTP 支持](./sftp.html#sftp)。
-### [](#migration-5.0-5.1)5.0 和 5.1 之间的变化
+### 5.0 和 5.1 之间的变化
-#### [](#x5.1-new-components)新组件
+#### 新组件
以下组件是 5.1 中的新组件:
* [`AmqpDedicatedChannelAdvice`](#x5.1-amqpdedicatedchanneladvice)
-##### [](#x5.1-AmqpDedicatedChannelAdvice)`AmqpDedicatedChannelAdvice`
+##### `AmqpDedicatedChannelAdvice`
见[严格的消息排序](./amqp.html#amqp-strict-ordering)。
-##### [](#x5.1-Functions)功能支持改进
+##### 功能支持改进
`java.util.function`接口现在在框架组件中具有改进的集成支持。 Kotlin Lambdas 现在也可以用于处理程序和源方法。
参见[`java.util.function`接口支持]。
-##### [](#x5.1-LongRunningTest)`@LongRunningTest`
+##### `@LongRunningTest`
提供了一个 JUnit5`@LongRunningTest`条件注释,用于检查值为`RUN_LONG_INTEGRATION_TESTS`的`true`条目的环境或系统属性,以确定是否应该运行或跳过测试。
见[JUnit 规则和条件](./testing.html#test-junit-rules)。
-#### [](#x5.1-general)一般变动
+#### 一般变动
在版本 5.1 中进行了以下更改:
@@ -318,7 +318,7 @@ HTTP 入站端点现在支持请求有效负载验证。有关更多信息,请
* [`receiveTimeout`for`@Poller`](#x51.-poller-annotation)
-##### [](#x5.1-java-dsl)Java DSL
+##### Java DSL
`IntegrationFlowContext`现在是一个接口,`IntegrationFlowRegistration`是`IntegrationFlowContext`的一个内部接口。
@@ -328,7 +328,7 @@ Bean 在集成流中为任何`NamedComponent`生成的名称现在基于组件
`GenericHandler.handle()`现在排除了第二个参数的`MessageHeaders`类型。
-##### [](#x5.1-dispatcher-exceptions)Dispatcher 异常
+##### Dispatcher 异常
由`AbstractDispatcher`捕获和重新抛出的异常现在更加一致:
@@ -346,27 +346,27 @@ Bean 在集成流中为任何`NamedComponent`生成的名称现在基于组件
* 选中的异常被包装在带有`failedMessage`属性集的`MessageDeliveryException`中。
-##### [](#x5.1-global-channel-interceptors)全局信道拦截器
+##### 全局信道拦截器
全局信道拦截器现在应用于动态注册的信道,例如在使用 Java DSL 或使用`beanFactory.initializeBean()`初始化的 bean 时通过`IntegrationFlowContext`。以前,当应用程序上下文被刷新后创建 bean 时,拦截程序不会被应用。
-##### [](#x5.1-channel-interceptors)信道拦截器
+##### 信道拦截器
当没有收到消息时,将不再调用`ChannelInterceptor.postReceive()`;不再需要检查`null``Message>`。以前,这种方法被称为。如果你的拦截器依赖于前面的行为,那么可以实现`afterReceiveCompleted()`,因为无论是否接收到消息,该方法都会被调用。此外,`PolledAmqpChannel`和`PolledJmsChannel`以前不会用`afterReceiveCompleted()`调用`afterReceiveCompleted()`;现在它们会调用。
-##### [](#x5.1-object-to-json-transformer)`ObjectToJsonTransformer`
+##### `ObjectToJsonTransformer`
为`ObjectToJsonTransformer`引入了一个新的`ResultType.BYTES`模式。
有关更多信息,请参见[JSON 变形金刚](./transformer.html#json-transformers)。
-##### [](#x5.1-integration-flows-generated-bean-names)集成流:生成的 Bean 名称
+##### 集成流:生成的 Bean 名称
从版本 5.0.5 开始,在`IntegrationFlow`中为组件生成的 Bean 名称包括流 Bean 名称,然后是一个点,作为前缀。例如,如果一个流 Bean 被命名为`flowBean`,那么生成的 Bean 可能被命名为`flowBean.generatedBean`。
有关更多信息,请参见[处理消息流](./dsl.html#java-dsl-flows)。
-##### [](#x5.1-aggregator)聚合器更改
+##### 聚合器更改
如果`groupTimeout`被求值为负值,聚合器现在立即使该组过期。只有`null`被认为是对当前消息不做任何事情的信号。
@@ -374,13 +374,13 @@ Bean 在集成流中为任何`NamedComponent`生成的名称现在基于组件
有关更多信息,请参见[Aggregator](./aggregator.html#aggregator)。
-##### [](#x5.1-publisher)@publisher 注释更改
+##### @publisher 注释更改
从版本 5.1 开始,你必须使用`@EnablePublisher`或在``上使用``子元素来显式地打开`@Publisher` AOP 功能。还添加了`proxy-target-class`和`order`属性,用于优化`ProxyFactory`配置。
有关更多信息,请参见[使用`@Publisher`注释的注释驱动配置]。
-#### [](#x5.1-files)文件更改
+#### 文件更改
如果使用`FileExistsMode.APPEND`或`FileExistsMode.APPEND_NO_FLUSH`,则可以提供一个`newFileCallback`,在创建新文件时将调用它。此回调接收新创建的文件和触发回调的消息。例如,这可以用来编写一个 CSV 标头。
@@ -388,7 +388,7 @@ Bean 在集成流中为任何`NamedComponent`生成的名称现在基于组件
有关更多信息,请参见[文件支持](./file.html#files)。
-#### [](#x5.1-amqp)AMQP 变化
+#### AMQP 变化
我们已经在`ID`和`Timestamp`头映射中对`DefaultAmqpHeaderMapper`进行了更改。有关更多信息,请参见[AMQP 消息头](./amqp.html#amqp-message-headers)底部附近的注释。
@@ -396,7 +396,7 @@ Bean 在集成流中为任何`NamedComponent`生成的名称现在基于组件
从版本 5.1.3 开始,如果在使用手动确认时发生消息转换异常,并且定义了错误通道,则有效负载是带有额外`ManualAckListenerExecutionFailedException`和`deliveryTag`属性的`ManualAckListenerExecutionFailedException`。这使错误流能够 ACK/NACK 原始消息。有关更多信息,请参见[入站消息转换](./amqp.html#amqp-conversion-inbound)。
-#### [](#x5.1-jdbc)JDBC 更改
+#### JDBC 更改
在 JDBC 入站通道适配器和 JDBC 出站网关上的一个令人困惑的`max-rows-per-poll`属性已被弃用,取而代之的是新引入的`max-rows`属性。
@@ -406,7 +406,7 @@ Bean 在集成流中为任何`NamedComponent`生成的名称现在基于组件
有关更多信息,请参见[JDBC 支持](./jdbc.html#jdbc)。
-#### [](#x5.1-ftp-sftp)FTP 和 SFTP 更改
+#### FTP 和 SFTP 更改
现在可以使用`RotatingServerAdvice`用入站通道适配器轮询多个服务器和目录。有关更多信息,请参见[入站通道适配器:轮询多个服务器和目录](./ftp.html#ftp-rotating-server-advice)和[入站通道适配器:轮询多个服务器和目录](./sftp.html#sftp-rotating-server-advice)。
@@ -420,101 +420,101 @@ Bean 在集成流中为任何`NamedComponent`生成的名称现在基于组件
出站网关 mput 命令现在支持带有文件或字符串集合的消息有效负载。有关更多信息,请参见[SFTP 出站网关](./sftp.html#sftp-outbound-gateway)和[FTP 出站网关](./ftp.html#ftp-outbound-gateway)。
-#### [](#x51.-tcp)TCP 支持
+#### TCP 支持
在使用 SSL 时,现在默认情况下启用了主机验证,以防止使用受信任证书的中间人攻击。有关更多信息,请参见[主机验证](./ip.html#tcp-ssl-host-verification)。
此外,键和信任存储类型现在可以在`DefaultTcpSSLContextSupport`上配置。
-#### [](#x5.1-twitter)Twitter 支持
+#### Twitter 支持
由于 Spring 社交项目已经转移到[生命终结状态](https://spring.io/blog/2018/07/03/spring-social-end-of-life-announcement), Spring 集成中的 Twitter 支持已经转移到扩展项目中。有关更多信息,请参见[Spring Integration Social Twitter](https://github.com/spring-projects/spring-integration-extensions/tree/main/spring-integration-social-twitter)。
-#### [](#x51.-jms)JMS 支持
+#### JMS 支持
`JmsSendingMessageHandler`现在提供`deliveryModeExpression`和`timeToLiveExpression`选项,以确定在运行时要发送的 JMS 消息的相应 QoS 选项。现在,`DefaultJmsHeaderMapper`允许通过设置`true`相应的`setMapInboundDeliveryMode()`和`setMapInboundExpiration()`选项来映射入站`JMSExpiration`属性。当`JmsMessageDrivenEndpoint`或`JmsInboundGateway`被停止时,关联的侦听器容器现在被关闭;这将关闭其共享连接和任何使用者。你可以将端点配置为恢复到以前的行为。
有关更多信息,请参见[JMS 支持](./jms.html#jms)。
-#### [](#x51.-http)http/webflux 支持
+#### http/webflux 支持
`statusCodeExpression`(和`Function`)现在提供了`RequestEntity>`作为求值上下文的根对象,因此可以使用请求头、方法、URI 和主体来计算目标状态代码。
有关更多信息,请参见[HTTP 支持](./http.html#http)和[WebFlux 支持](./webflux.html#webflux)。
-#### [](#x51.-jmx)JMX 更改
+#### JMX 更改
如果对象名称键值包含 Java 标识符(或句点`.`)中所允许的字符以外的任何字符,则现在引用它们。例如`org.springframework.integration:type=MessageChannel,``name="input:foo.myGroup.errors"`。这样做的副作用是,以前“允许”的名字,加上这样的字符,现在会被引用。例如`org.springframework.integration:type=MessageChannel,``name="input#foo.myGroup.errors"`。
-#### [](#x51.-micrometer)千分尺支持变更
+#### 千分尺支持变更
现在可以更简单地定制由该框架创建的标准千分表。有关更多信息,请参见[千分尺积分](./metrics.html#micrometer-integration)。
-#### [](#x51.-integration-graph)集成图定制
+#### 集成图定制
现在可以在`IntegrationGraphServer`上通过`Function> additionalPropertiesCallback`向`IntegrationNode`s 添加附加属性。有关更多信息,请参见[积分图](./graph.html#integration-graph)。
-#### [](#x51.-global-properties)集成全局属性
+#### 集成全局属性
当打开`org.springframework.integration`类别的`DEBUG`逻辑级别时,现在可以在日志中打印集成全局属性(包括默认值)。有关更多信息,请参见[全局属性](./configuration.html#global-properties)。
-#### [](#x51.-poller-annotation)`receiveTimeout`的`@Poller`
+#### `receiveTimeout`的`@Poller`
为了方便起见,`@Poller`注释现在提供了`receiveTimeout`选项。请参阅[使用`@Poller`注释](./configuration.html#configuration-using-poller-annotation)以获取更多信息。
-### [](#migration-4.3-5.0)4.3 到 5.0 之间的变化
+### 4.3 到 5.0 之间的变化
有关可能影响应用程序的重要更改,请参见[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-4.3-to-5.0-Migration-Guide)。你可以在[wiki](https://github.com/spring-projects/spring-integration/wiki)上找到所有回到 2.1 版本的迁移指南。
-#### [](#x5.0-new-components)新组件
+#### 新组件
5.0 版本增加了许多新的组件。
-##### [](#java-dsl)Java DSL
+##### Java DSL
单独的[Spring Integration Java DSL](https://github.com/spring-projects/spring-integration-java-dsl)项目现在已合并到核心 Spring 集成项目中。用于通道适配器和网关的`IntegrationComponentSpec`实现被分发到它们的特定模块。有关 Java DSL 支持的更多信息,请参见[Java DSL](./dsl.html#java-dsl)。另请参见[4.3 到 5.0 迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-4.3-to-5.0-Migration-Guide#java-dsl),以了解移动到 Spring Integration5.0 所需的步骤。
-##### [](#testing-support)测试支持
+##### 测试支持
我们创建了一个新的 Spring 集成测试框架,以帮助测试 Spring 集成应用程序。现在,使用测试类上的`@SpringIntegrationTest`注释和`MockIntegration`工厂,你可以使集成流的 JUnit 测试变得更容易一些。
有关更多信息,请参见[测试支持](./testing.html#testing)。
-##### [](#mongodb-outbound-gateway)MongoDB 出站网关
+##### MongoDB 出站网关
新的`MongoDbOutboundGateway`允许你通过向数据库的请求通道发送消息,按需对数据库进行查询。
有关更多信息,请参见[MongoDB 出站网关](./mongodb.html#mongodb-outbound-gateway)。
-##### [](#webflux-gateways-and-channel-adapters)WebFlux 网关和通道适配器
+##### WebFlux 网关和通道适配器
我们介绍了用于 Spring WebFlux 框架网关和通道适配器的新的 WebFlux 支持模块。
有关更多信息,请参见[WebFlux 支持](./webflux.html#webflux)。
-##### [](#content-type-conversion)内容类型转换
+##### 内容类型转换
既然我们使用了新的基于`InvocableHandlerMethod`的基础架构来进行服务方法调用,那么我们就可以执行`contentType`从有效负载到目标方法参数的转换。
有关更多信息,请参见[内容类型转换](./endpoint.html#content-type-conversion)。
-##### [](#errormessagepublisher-and-errormessagestrategy)`ErrorMessagePublisher`和`ErrorMessageStrategy`
+##### `ErrorMessagePublisher`和`ErrorMessageStrategy`
我们添加了`ErrorMessagePublisher`和`ErrorMessageStrategy`来创建`ErrorMessage`实例。
有关更多信息,请参见[错误处理](./error-handling.html#error-handling)。
-##### [](#jdbc-metadata-store)JDBC 元数据存储
+##### JDBC 元数据存储
我们添加了`MetadataStore`实现的 JDBC 实现。当你需要确保元数据的事务边界时,这是非常有用的。
有关更多信息,请参见[JDBC 元数据存储](./jdbc.html#jdbc-metadata-store)。
-#### [](#x5.0-general)一般更改
+#### 一般更改
Spring 集成现在完全基于 Spring 框架`5.0`和项目反应堆`3.1`。以前的 Project Reactor 版本不再支持。
-##### [](#core-changes)核心变化
+##### 核心变化
`@Poller`注释现在具有`errorChannel`属性,以便更轻松地配置底层`MessagePublishingErrorHandler`。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
@@ -538,7 +538,7 @@ Spring 集成现在完全基于 Spring 框架`5.0`和项目反应堆`3.1`。以
当候选者未能获得锁时,`LockRegistryLeaderInitiator`现在通过`DefaultLeaderEventPublisher`发出一个新的`OnFailedToAcquireMutexEvent`。有关更多信息,请参见`[Leadership Event Handling](./endpoint.html#leadership-event-handling)`。
-##### [](#gateway-changes)网关更改
+##### 网关更改
当网关方法具有`void`返回类型并且提供了错误通道时,网关现在正确地设置`errorChannel`报头。在此之前,头文件是不填充的。这导致同步下游流(在调用线程上运行)将异常发送到配置的通道,但是异步下游流上的异常将被发送到默认的`errorChannel`。
@@ -546,29 +546,29 @@ Spring 集成现在完全基于 Spring 框架`5.0`和项目反应堆`3.1`。以
现在可以使用 SPEL 表达式指定请求和回复超时。有关更多信息,请参见[消息传递网关](./gateway.html#gateway)。
-##### [](#aggregator-performance-changes)聚合器性能更改
+##### 聚合器性能更改
默认情况下,聚合器现在使用`SimpleSequenceSizeReleaseStrategy`,这更有效,尤其是对于大型组。空组现在被安排在`empty-group-min-timeout`之后被删除。有关更多信息,请参见[Aggregator](./aggregator.html#aggregator)。
-##### [](#splitter-changes)拆分器更改
+##### 拆分器更改
Splitter 组件现在可以处理和分割 Java`Stream`和反应流`Publisher`对象。如果输出通道是`ReactiveStreamsSubscribableChannel`,则`AbstractMessageSplitter`构建一个`Flux`用于后续迭代,而不是常规的`Iterator`,这与被分割的对象无关。此外,`AbstractMessageSplitter`提供了`protected obtainSizeIfPossible()`方法,以允许确定`Iterable`和`Iterator`对象的大小,如果这是可能的话。有关更多信息,请参见[Splitter](./splitter.html#splitter)。
-##### [](#jms-changes)JMS 更改
+##### JMS 更改
以前, Spring Integration JMS XML 配置对 JMS 连接工厂使用默认的 Bean 名称`connectionFactory`,这使得组件定义中省略了该属性。我们将其重命名为`jmsConnectionFactory`,这是 Spring 引导用于自动配置 JMS 连接工厂 Bean 的 Bean 名称。
如果你的应用程序依赖于先前的行为,那么你可以将你的`connectionFactory` Bean 重命名为`jmsConnectionFactory`,或者通过使用其当前名称来专门配置组件以使用你的 Bean。有关更多信息,请参见[JMS 支持](./jms.html#jms)。
-##### [](#mail-changes)邮件更改
+##### 邮件更改
一些与呈现 IMAP 邮件内容的不一致之处已得到解决。有关更多信息,请参见[“邮件接收通道适配器”部分中的注释](./mail.html#imap-format-important)。
-##### [](#feed-changes)提要更改
+##### 提要更改
而不是`com.rometools.fetcher.FeedFetcher`,这在罗马是不受欢迎的,我们为`FeedEntryMessageSource`引入了一个新的`Resource`属性。有关更多信息,请参见[馈源适配器](./feed.html#feed)。
-##### [](#file-changes)文件更改
+##### 文件更改
我们引入了新的`FileHeaders.RELATIVE_PATH`消息头来表示`FileReadingMessageSource`中的相对路径。
@@ -586,7 +586,7 @@ Splitter 组件现在可以处理和分割 Java`Stream`和反应流`Publisher`
有关更多信息,请参见[文件支持](./file.html#files)。
-##### [](#ftp-and-sftp-changes)FTP 和 SFTP 更改
+##### FTP 和 SFTP 更改
入站通道适配器现在具有一个名为`max-fetch-size`的属性,该属性用于在当前本地目录中没有文件时限制轮询期间获取的文件数量。默认情况下,它们还在`local-filter`中配置了`FileSystemPersistentAcceptOnceFileListFilter`。
@@ -616,19 +616,19 @@ FTP 和 SFTP 出站通道适配器(以及用于出站网关的`PUT`命令)
有关更多信息,请参见[FTP/FTPS 适配器](./ftp.html#ftp)和[SFTP 适配器](./sftp.html#sftp)。
-##### [](#integration-properties)积分属性
+##### 积分属性
版本 4.3.2 添加了一个新的`spring.integration.readOnly.headers`全局属性,使你可以自定义不应该由`MessageBuilder`复制到新创建的`Message`的标题列表。有关更多信息,请参见[全局属性](./configuration.html#global-properties)。
-##### [](#stream-changes)流变化
+##### 流变化
我们在`CharacterStreamReadingMessageSource`上添加了一个新选项,以使其用于“pipe”stdin,并在管道关闭时发布应用程序事件。有关更多信息,请参见[从流中阅读](./stream.html#stream-reading)。
-##### [](#barrier-changes)障碍变化
+##### 障碍变化
`BarrierMessageHandler`现在支持一个丢弃通道,可以将延迟到达的触发消息发送到该通道。有关更多信息,请参见[螺纹屏障](./barrier.html#barrier)。
-##### [](#amqp-changes)AMQP 变化
+##### AMQP 变化
AMQP 出站端点现在支持在使用 RabbitMQ 延迟消息交换插件时设置延迟表达式。
@@ -638,7 +638,7 @@ AMQP 出站端点现在支持在使用 RabbitMQ 延迟消息交换插件时设
消息转换器添加到消息属性中的标题(例如`contentType`)现在在最终消息中使用。在此之前,它依赖于转换器类型,即最终消息中出现了哪些标头和消息属性。要覆盖转换器设置的标题,请将`headersMappedLast`属性设置为`true`。有关更多信息,请参见[AMQP 支持](./amqp.html#amqp)。
-##### [](#http-changes)http 更改
+##### http 更改
默认情况下,`DefaultHttpHeaderMapper.userDefinedHeaderPrefix`属性现在是一个空字符串,而不是`X-`。有关更多信息,请参见[HTTP 头映射](./http.html#http-header-mapping)。
@@ -646,17 +646,17 @@ AMQP 出站端点现在支持在使用 RabbitMQ 延迟消息交换插件时设
有关更多信息,请参见[映射 URI 变量](./http.html#mapping-uri-variables)。
-##### [](#mqtt-changes)MQTT 变化
+##### MQTT 变化
入站消息现在被映射为`RECEIVED_TOPIC`、`RECEIVED_QOS`和`RECEIVED_RETAINED`头,以避免在应用程序中继消息时无意中传播到出站消息。
出站通道适配器现在支持主题、QoS 和保留属性的表达式。默认值保持不变。有关更多信息,请参见[MQTT 支持](./mqtt.html#mqtt)。
-##### [](#stomp-changes)stomp 变化
+##### stomp 变化
基于项目反应器`3.1`和`reactor-netty`扩展,我们将 Stomp 模块改为使用`ReactorNettyTcpStompClient`。根据`ReactorNettyTcpStompClient`基础,我们将`Reactor2TcpStompSessionManager`重命名为`ReactorNettyTcpStompSessionManager`。有关更多信息,请参见[Stomp 支持](./stomp.html#stomp)。
-##### [](#web-services-changes)Web 服务变更
+##### Web 服务变更
现在可以使用外部配置的`WebServiceTemplate`实例来提供`WebServiceOutboundGateway`实例。
@@ -666,7 +666,7 @@ AMQP 出站端点现在支持在使用 RabbitMQ 延迟消息交换插件时设
有关更多信息,请参见[Web 服务支持](./ws.html#ws)。
-##### [](#redis-changes)Redis 变更
+##### Redis 变更
现在为`RedisStoreWritingMessageHandler`提供了额外的用于 SPEL 表达式的基于`String`的 setter(为了方便 Java 配置)。你现在也可以在`RedisStoreWritingMessageHandler`上配置`zsetIncrementExpression`。此外,由于`ZADD`Redis 命令上的`INCR`选项是可选的,因此此属性已从`true`更改为`false`。
@@ -674,7 +674,7 @@ AMQP 出站端点现在支持在使用 RabbitMQ 延迟消息交换插件时设
有关更多信息,请参见[Redis 支持](./redis.html#redis)。
-##### [](#tcp-changes)TCP 更改
+##### TCP 更改
我们添加了一个新的`ThreadAffinityClientConnectionFactory`来将 TCP 连接绑定到线程。
@@ -684,11 +684,11 @@ AMQP 出站端点现在支持在使用 RabbitMQ 延迟消息交换插件时设
有关更多信息,请参见[TCP 和 UDP 支持](./ip.html#ip)。
-##### [](#gemfire-changes)Gemfire 变化
+##### Gemfire 变化
`GemfireMetadataStore`现在实现`ListenableMetadataStore`,通过向存储提供`MetadataStoreListener`实例,让你监听缓存事件。有关更多信息,请参见[Pivotal Gemfire 和 Apache Geode 支持](./gemfire.html#gemfire)。
-##### [](#jdbc-changes)JDBC 更改
+##### JDBC 更改
`JdbcMessageChannelStore`现在提供了`ChannelMessageStorePreparedStatementSetter`的 setter,允许你在存储中自定义消息插入。
@@ -696,258 +696,258 @@ AMQP 出站端点现在支持在使用 RabbitMQ 延迟消息交换插件时设
有关更多信息,请参见[JDBC 支持](./jdbc.html#jdbc)。
-##### [](#metrics-changes)指标变化
+##### 指标变化
[Micrometer](https://micrometer.io/)现在支持应用程序监视(自版本 5.0.2 起)。有关更多信息,请参见[千分尺积分](./metrics.html#micrometer-integration)。
| |在版本 5.0.3 中对千分尺`Meters`进行了更改,以使其更适合在多维系统中使用。
在 5.0.4 中进行了进一步的更改。
如果你使用千分尺,我们建议至少使用版本 5.0.4。|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#endpointid-annotations)`@EndpointId`注释
+##### `@EndpointId`注释
在版本 5.0.4 中引入了此注释,当你使用 Java 配置时,此注释提供了对 Bean 命名的控制。有关更多信息,请参见[Endpoint Bean Names](./overview.html#endpoint-bean-names)。
-### [](#migration-4.2-4.3)4.2 与 4.3 之间的变化
+### 4.2 与 4.3 之间的变化
有关可能影响应用程序的重要更改,请参见[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-4.2-to-4.3-Migration-Guide)。你可以在[Wiki](https://github.com/spring-projects/spring-integration/wiki)上找到所有回到 2.1 版本的迁移指南。
-#### [](#x4.3-new-components)新组件
+#### 新组件
版本 4.3 增加了一些新的组件。
-##### [](#amqp-async-outbound-gateway)AMQP 异步出站网关
+##### AMQP 异步出站网关
见[异步出站网关](./amqp.html#amqp-async-outbound-gateway)。
-##### [](#messagegroupfactory)`MessageGroupFactory`
+##### `MessageGroupFactory`
我们引入了`MessageGroupFactory`策略,以允许在`MessageGroupStore`逻辑中控制`MessageGroup`实例。我们为`SimpleMessageGroup`添加了`SimpleMessageGroupFactory`实现,并将`GroupType.HASH_SET`作为标准`MessageGroupStore`实现的默认工厂。有关更多信息,请参见[消息存储](./message-store.html#message-store)。
-##### [](#persistentmessagegroup)`PersistentMessageGroup`
+##### `PersistentMessageGroup`
我们为持久的`getMessageGroup()`实例添加了`PersistentMessageGroup`(lazy-load proxy)实现,当`getMessageGroup()`的`lazyLoadMessageGroups`是`true`(默认)时,它为`getMessageGroup()`实例返回这个实例。有关更多信息,请参见[消息存储](./message-store.html#message-store)。
-##### [](#ftp-and-sftp-streaming-inbound-channel-adapters)FTP 和 SFTP 流入站通道适配器
+##### FTP 和 SFTP 流入站通道适配器
我们添加了入站通道适配器,这些适配器为每个文件返回`InputStream`,这样你就可以检索远程文件,而无需将它们写入本地文件系统。有关更多信息,请参见[FTP 流入站通道适配器](./ftp.html#ftp-streaming)和[SFTP 流入站通道适配器](./sftp.html#sftp-streaming)。
-##### [](#streamtransformer)`StreamTransformer`
+##### `StreamTransformer`
我们添加了`StreamTransformer`来将`InputStream`有效载荷转换为`byte[]`或`String`。有关更多信息,请参见[流变压器](./transformer.html#stream-transformer)。
-##### [](#integration-graph)积分图
+##### 积分图
我们添加了`IntegrationGraphServer`,以及`IntegrationGraphController`REST 服务,以将 Spring 集成应用程序的运行时模型公开为一个图。有关更多信息,请参见[积分图](./graph.html#integration-graph)。
-##### [](#jdbc-lock-registry)JDBC 锁定注册表
+##### JDBC 锁定注册表
对于通过数据库表共享的分布式锁,我们添加了`JdbcLockRegistry`。有关更多信息,请参见[JDBC 锁定注册表](./jdbc.html#jdbc-lock-registry)。
-##### [](#leaderinitiator-for-lockregistry)`LeaderInitiator`表示`LockRegistry`
+##### `LeaderInitiator`表示`LockRegistry`
我们添加了基于`LockRegistry`策略的`LeaderInitiator`实现。有关更多信息,请参见[领导事件处理](./endpoint.html#leadership-event-handling)。
-#### [](#x4.3-general)一般变化
+#### 一般变化
本节描述了版本 4.3 为 Spring 集成带来的一般更改。
-##### [](#core-changes-2)核心变化
+##### 核心变化
本节描述对 Spring 集成的核心的一般更改。
-###### [](#outbound-gateway-within-a-chain)链中的出站网关
+###### 链中的出站网关
以前,你可以在链中的出站网关上指定`reply-channel`。它被完全忽视了。网关的回复将发送到下一个链元素,或者,如果网关是最后一个元素,则发送到链的输出通道。这种情况现在已被发现并被禁止。如果你有这样的配置,请删除`reply-channel`。
-###### [](#asynchronous-service-activator)异步服务激活器
+###### 异步服务激活器
我们添加了一个选项,使服务激活器是同步的。有关更多信息,请参见[异步服务激活器](./service-activator.html#async-service-activator)。
-###### [](#messaging-annotation-support-changes)消息传递注释支持更改
+###### 消息传递注释支持更改
消息传递注释支持在类级别上不需要`@MessageEndpoint`(或任何其他`@Component`)注释声明。要恢复以前的行为,请将`spring.integration.properties`的`spring.integration.messagingAnnotations.require.componentAnnotation`设置为`true`。有关更多信息,请参见[全局属性](./configuration.html#global-properties)和[注释支持](./configuration.html#annotations)。
-##### [](#mail-changes-2)邮件更改
+##### 邮件更改
本节描述对 Spring 集成邮件功能的一般更改。
-###### [](#customizable-user-flag)可定制用户标志
+###### 可定制用户标志
可定制的`userFlag`(在 4.2.2 中添加,以提供用于表示已看到邮件的标志的定制)现在在 XML 命名空间中可用。有关更多信息,请参见[不支持`\Recent`时标记 IMAP 消息]。
-###### [](#mail-message-mapping)邮件消息映射
+###### 邮件消息映射
现在,你可以使用包含邮件头和包含电子邮件内容的有效负载的`MessageHeaders`映射入站邮件。以前,有效载荷总是 RAW`MimeMessage`。有关更多信息,请参见[入站邮件消息映射](./mail.html#mail-mapping)。
-##### [](#jms-changes-2)JMS 更改
+##### JMS 更改
本节描述对 Spring 集成 JMS 功能的一般更改。
-###### [](#header-mapper)Header Mapper
+###### Header Mapper
现在,`DefaultJmsHeaderMapper`通过调用其`toString()`方法,将标准`correlationId`标头映射为消息属性。有关更多信息,请参见[映射消息头到和来自 JMS 消息](./jms.html#jms-header-mapping)。
-###### [](#asynchronous-gateway)异步网关
+###### 异步网关
JMS 出站网关现在具有`async`属性。有关更多信息,请参见[异步网关](./jms.html#jms-async-gateway)。
-##### [](#aggregator-changes)聚合器更改
+##### 聚合器更改
当 POJO 聚合器释放`Message>`对象的集合时,行为会发生变化。这是很少见的,但是,如果你的应用程序做到了这一点,你需要对 POJO 进行一个小的更改。有关更多信息,请参见[重要信息:`SimpleMessageGroup.getMessages()`方法返回`unmodifiableCollection`。](./AGGregator.html#agg-message-collection)注释。
-##### [](#tcpudp-changes)TCP/UDP 更改
+##### TCP/UDP 更改
本节描述对 Spring 集成 TCP/UDP 功能的一般更改。
-###### [](#events)事件
+###### 事件
在启动服务器连接工厂时,将发出一个新的`TcpConnectionServerListeningEvent`。有关更多信息,请参见[TCP 连接事件](./ip.html#tcp-events)。
现在可以在``上使用`destination-expression`和`socket-expression`属性。有关更多信息,请参见[UDP 适配器](./ip.html#udp-adapters)。
-###### [](#stream-deserializers)流反序列化器
+###### 流反序列化器
各种反序列化器在组装完整个消息之前不能分配最终的缓冲区,现在它们支持池合并接收数据的原始缓冲区,而不是为每个消息创建和丢弃缓冲区。有关更多信息,请参见[TCP 连接工厂](./ip.html#tcp-connection-factories)。
-###### [](#tcp-message-mapper)TCP 消息映射器
+###### TCP 消息映射器
消息映射器现在可选地设置一个已配置的内容类型标头。有关更多信息,请参见[IP 消息头](./ip.html#ip-msg-headers)。
-##### [](#file-changes-2)文件更改
+##### 文件更改
本节描述对 Spring 集成文件功能的一般更改。
-###### [](#destination-directory-creation)目标目录创建
+###### 目标目录创建
为`FileWritingMessageHandler`生成的文件名可以表示为目标目录中的文件保存所需的目录结构的子路径。有关更多信息,请参见[生成文件名](./file.html#file-writing-file-names)。
`FileReadingMessageSource`现在隐藏了内部类中的`WatchService`目录扫描逻辑。我们添加了`use-watch-service`和`watch-events`选项来启用此行为。由于 API 的不一致性,我们不推荐顶级`WatchServiceDirectoryScanner`。有关更多信息,请参见[`WatchServiceDirectoryScanner`](./file.html#watch-service-directory-scanner)。
-###### [](#buffer-size)缓冲区大小
+###### 缓冲区大小
写文件时,现在可以指定缓冲区大小。
-###### [](#appending-and-flushing)追加和刷新
+###### 追加和刷新
现在,你可以避免在追加文件时刷新文件,并在空闲期间使用许多策略来刷新数据。有关更多信息,请参见[在使用`APPEND_NO_FLUSH`时刷新文件]。
-###### [](#preserving-timestamps)保存时间戳
+###### 保存时间戳
现在可以配置出站通道适配器来设置目标文件的`lastmodified`时间戳。有关更多信息,请参见[文件时间戳](./file.html#file-timestamps)。
-###### [](#splitter-changes-2)拆分器更改
+###### 拆分器更改
现在,当文件被完全读取时,`FileSplitter`会自动关闭一个 FTP 或 SFTP会话。当出站网关返回`InputStream`或者当你使用新的 FTP 或 SFTP 流媒体通道适配器时,这一点将得到应用。我们还引入了一个新的`markers-json`选项,将`FileSplitter.FileMarker`转换为 JSON`String`,以进行放松的下游网络交互。有关更多信息,请参见[文件拆分器](./file.html#file-splitter)。
-###### [](#file-filters)文件过滤器
+###### 文件过滤器
我们添加了`ChainFileListFilter`作为`CompositeFileListFilter`的替代方案。有关更多信息,请参见[读取文件](./file.html#file-reading)。
-##### [](#amqp-changes-2)AMQP 变化
+##### AMQP 变化
本节描述对 Spring 集成 AMQP 功能的一般更改。
-###### [](#content-type-message-converter)内容类型消息转换器
+###### 内容类型消息转换器
出站端点现在支持配置为`RabbitTemplate`的`ContentTypeDelegatingMessageConverter`,这样你就可以根据消息内容类型选择转换器。有关更多信息,请参见[出站消息转换](./amqp.html#content-type-conversion-outbound)。
-###### 用于延迟消息处理的[](#headers-for-delayed-message-handling)头
+###### 用于延迟消息处理的头
Spring AMQP1.6 增加了对[延迟的消息交换](https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq/)的支持。头映射现在支持此功能使用的头(`amqp_delay`和`amqp_receivedDelay`)。
-###### [](#amqp-backed-channels)AMQP 支持的通道
+###### AMQP 支持的通道
AMQP 支持的通道现在支持消息映射。有关更多信息,请参见[AMQP 支持的消息通道](./amqp.html#amqp-channels)。
-##### [](#redis-changes-2)Redis 变更
+##### Redis 变更
本节描述对 Spring 集成 Redis 功能的一般更改。
-###### [](#list-pushpop-direction)列表推送/弹出方向
+###### 列表推送/弹出方向
以前,队列通道适配器总是在固定的方向上使用 Redis 列表,将其推到左端并从右端读取。现在,你可以分别使用`rightPop`和`leftPush`选项来配置读写方向和`RedisQueueMessageDrivenEndpoint`选项。有关更多信息,请参见[Redis 队列入站通道适配器](./redis.html#redis-queue-inbound-channel-adapter)和[Redis 队列出站通道适配器](./redis.html#redis-queue-outbound-channel-adapter)。
-###### [](#queue-inbound-gateway-default-serializer)队列入站网关默认序列化器
+###### 队列入站网关默认序列化器
为了与出站网关兼容,入站网关中的默认序列化器已更改为`JdkSerializationRedisSerializer`。有关更多信息,请参见[Redis 队列入站网关](./redis.html#redis-queue-inbound-gateway)。
-##### [](#http-changes-2)http 更改
+##### http 更改
在此之前,如果请求的主体(如`POST`)中没有`content-type`头,则主体将被忽略。在此版本中,此类请求的内容类型被认为是 RFC2616 推荐的`application/octet-stream`。有关更多信息,请参见[HTTP 入站组件](./http.html#http-inbound)。
`uriVariablesExpression`现在默认使用`SimpleEvaluationContext`(自 4.3.15 起)。有关更多信息,请参见[映射 URI 变量](./http.html#mapping-uri-variables)。
-##### [](#sftp-changes)SFTP 更改
+##### SFTP 更改
本节描述对 Spring Integration SFTP 功能的一般更改。
-###### [](#factory-bean)工厂 Bean
+###### 工厂 Bean
我们添加了一个新的工厂 Bean,以简化 SFTP 的 JSCH 代理的配置。有关更多信息,请参见[Proxy Factory Bean](./sftp.html#sftp-proxy-factory-bean)。
-###### [](#chmod-changes)`chmod`变更
+###### `chmod`变更
SFTP 出站网关(用于`put`和`mput`命令)和 SFTP 出站通道适配器现在支持`chmod`属性,以在上传后更改远程文件权限。有关更多信息,请参见`[SFTP Outbound Channel Adapter](./sftp.html#sftp-outbound)`和`[SFTP Outbound Gateway](./sftp.html#sftp-outbound-gateway)`。
-##### [](#ftp-changes)FTP 更改
+##### FTP 更改
本节描述对 Spring 集成 FTP 功能的一般更改。
-###### [](#session-changes)会话变化
+###### 会话变化
`FtpSession`现在支持`null`和`listNames()`方法的`null`,因为底层的 FTP 客户机可以使用它。这样,你就可以在不使用`remoteDirectory`表达式的情况下配置`FtpOutboundGateway`表达式。你也可以配置``而不使用`remote-directory`或`remote-directory-expression`。有关更多信息,请参见[FTP/FTPS 适配器](./ftp.html#ftp)。
-##### [](#router-changes)路由器变更
+##### 路由器变更
`ErrorMessageExceptionTypeRouter`现在支持`Exception`超类映射,以避免在存在多个继承者的情况下对相同通道进行重复。为此,`ErrorMessageExceptionTypeRouter`在初始化`ClassNotFoundException`的 fail-fast 期间加载映射类。
有关更多信息,请参见[Routers](./router.html#router)。
-##### [](#header-mapping)标头映射
+##### 标头映射
本节描述了在版本 4.2 和 4.3 之间对头映射的更改。
-###### [](#general)一般
+###### 一般
AMQP、WS 和 XMPP 头映射(例如`request-header-mapping`和`reply-header-mapping`)现在支持否定模式。有关更多信息,请参见[AMQP 消息头](./amqp.html#amqp-message-headers),[WS 消息头](./ws.html#ws-message-headers)和[XMPP 消息头](./xmpp.html#xmpp-message-headers)。
-###### [](#amqp-header-mapping)AMQP 头映射
+###### AMQP 头映射
以前,默认情况下只对标准的 AMQP 头进行映射。你必须显式地启用用户定义标头的映射。在这个版本中,默认情况下所有的头都是映射的。此外,入站`amqp_deliveryMode`头在默认情况下不再映射。有关更多信息,请参见[AMQP 消息头](./amqp.html#amqp-message-headers)。
-##### [](#groovy-scripts)Groovy 脚本
+##### Groovy 脚本
现在可以使用`compile-static`提示或任何其他`CompilerConfiguration`选项配置 Groovy 脚本。有关更多信息,请参见[Groovy 配置](./groovy.html#groovy-config)。
-##### [](#inboundchanneladapter-changes)`@InboundChannelAdapter`变化
+##### `@InboundChannelAdapter`变化
`@InboundChannelAdapter`现在为常规的`value`提供了一个别名`channel`属性。此外,目标`SourcePollingChannelAdapter`组件现在可以从其提供的名称(`outputChannel` Bean 选项)以后期绑定的方式解析目标`outputChannelName`。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-##### [](#xmpp-changes)XMPP 更改
+##### XMPP 更改
XMPP 通道适配器现在支持 XMPP 扩展。有关更多信息,请参见[XMPP 扩展](./xmpp.html#xmpp-extensions)。
-##### [](#wiretap-late-binding)窃听延迟绑定
+##### 窃听延迟绑定
`WireTap``ChannelInterceptor`现在可以接受一个`channelName`,它将在以后的第一次活动拦截器操作期间解析为目标`MessageChannel`。有关更多信息,请参见[Wire Tap](./channel.html#channel-wiretap)。
-##### [](#channelmessagestorequeryprovider-changes)`ChannelMessageStoreQueryProvider`变化
+##### `ChannelMessageStoreQueryProvider`变化
`ChannelMessageStoreQueryProvider`现在支持 H2 数据库。有关更多信息,请参见[支持消息通道](./jdbc.html#jdbc-message-store-channels)。
-##### [](#websocket-changes) WebSocket 变化
+##### WebSocket 变化
`ServerWebSocketContainer`现在公开一个`allowedOrigins`选项,`SockJsServiceOptions`公开一个`suppressCors`选项。有关更多信息,请参见[WebSockets 支持](./web-sockets.html#web-sockets)。
-### [](#migration-4.1-4.2)4.1 和 4.2 之间的变化
+### 4.1 和 4.2 之间的变化
有关可能影响应用程序的重要更改,请参见[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-4.1-to-4.2-Migration-Guide)。你可以在[wiki](https://github.com/spring-projects/spring-integration/wiki)上找到所有回到 2.1 版本的迁移指南。
-#### [](#x4.2-new-components)新组件
+#### 新组件
版本 4.2 增加了一些新的组件。
-##### [](#x4.2-JMX)主要管理/JMX 返工
+##### 主要管理/JMX 返工
我们添加了一个新的`MetricsFactory`策略界面。这一变化以及 JMX 和管理基础设施中的其他变化,为管理配置和运行时性能提供了更多的控制。
@@ -955,23 +955,23 @@ XMPP 通道适配器现在支持 XMPP 扩展。有关更多信息,请参见[XM
有关完整的详细信息,请参见[度量和管理](./metrics.html#metrics-management)和[JMX 改进](./jmx.html#jmx-42-improvements)。
-##### [](#x4.2-mongodb-metadata-store)MongoDB 元数据存储
+##### MongoDB 元数据存储
`MongoDbMetadataStore`现在可用。有关更多信息,请参见[MongoDB 元数据存储](./mongodb.html#mongodb-metadata-store)。
-##### [](#x4.2-secured-channel-annotation)安全通道注释
+##### 安全通道注释
我们引入了`@SecuredChannel`注释,替换了不推荐的`ChannelSecurityInterceptorFactoryBean`。有关更多信息,请参见[Security in Spring Integration](./security.html#security)。
-##### [](#x4.2-security-context-propagation)`SecurityContext`传播
+##### `SecurityContext`传播
我们为从一个消息流的线程传播到另一个消息流的`SecurityContext`引入了`SecurityContextPropagationChannelInterceptor`。有关更多信息,请参见[Security in Spring Integration](./security.html#security)。
-##### [](#x4.2-file-splitter)文件夹
+##### 文件夹
在 4.1.2 中,我们添加了`FileSplitter`,它将文本文件分割成行。它现在在`int-file:`命名空间中获得了完全支持。有关更多信息,请参见[文件拆分器](./file.html#file-splitter)。
-##### [](#x4.2-zk)动物园管理员支持
+##### 动物园管理员支持
我们在框架中添加了 ZooKeeper 支持,以在集群或多主机环境中运行时提供帮助。这一变化影响到以下特征:
@@ -983,85 +983,85 @@ XMPP 通道适配器现在支持 XMPP 扩展。有关更多信息,请参见[XM
有关更多信息,请参见[动物园管理员支持](./zookeeper.html#zookeeper)。
-##### [](#x4.2-barrier)螺纹屏障
+##### 螺纹屏障
一个新的线程``组件是可用的,它允许一个线程被挂起,直到某个异步事件发生。有关更多信息,请参见[螺纹屏障](./barrier.html#barrier)。
-##### [](#x4.2-stomp)stomp 支持
+##### stomp 支持
我们将 STOMP 支持添加到框架中,作为入站和出站通道适配器对。有关更多信息,请参见[Stomp 支持](./stomp.html#stomp)。
-##### [](#x4.2-codec)编解码器
+##### 编解码器
引入了一个新的`Codec`抽象,用于对`Codec`之间的对象进行编码和解码。我们添加了一个使用 Kryo 的实现。我们还添加了基于编解码的变压器和消息转换器。有关更多信息,请参见[Codec](./codec.html#codec)。
-##### [](#x4.2-prepared-statement-setter)消息 PreparedStatement setter
+##### 消息 PreparedStatement setter
一个新的`MessagePreparedStatementSetter`函数接口回调可用于`JdbcMessageHandler`(``和``),作为使用`SqlParameterSourceFactory`填充`PreparedStatement`上下文上的参数的一种替代方法。有关更多信息,请参见[出站通道适配器](./jdbc.html#jdbc-outbound-channel-adapter)。
-#### [](#x4.2-general)一般变动
+#### 一般变动
本部分描述了从版本 4.1 到版本 4.2 的一般更改。
-##### [](#x4.2-wire-tap)窃听
+##### 窃听
作为现有`selector`属性的替代选项,``元素现在支持`selector-expression`属性。
-##### [](#x4.2-file-changes)文件更改
+##### 文件更改
有关这些更改的更多信息,请参见[文件支持](./file.html#files)。
-###### [](#appending-new-lines)追加新行
+###### 追加新行
``和``现在支持`append-new-line`属性。如果设置为`true`,则在写入消息后会在文件中添加新的行。默认属性值是`false`。
-###### [](#ignoring-hidden-files)忽略隐藏文件
+###### 忽略隐藏文件
我们为``添加了`ignore-hidden`属性,使你可以设置是否从源目录中获取隐藏的文件。它默认为`true`。
-###### [](#writing-inputstream-payloads)写入`InputStream`有效载荷
+###### 写入`InputStream`有效载荷
`FileWritingMessageHandler`现在也接受`InputStream`作为有效的消息有效负载类型。
-###### [](#headdirectoryscanner)`HeadDirectoryScanner`
+###### `HeadDirectoryScanner`
你现在可以将`HeadDirectoryScanner`与其他`FileListFilter`实现一起使用。
-###### [](#last-modified-filter)上次修改的过滤器
+###### 上次修改的过滤器
我们添加了`LastModifiedFileListFilter`。
-###### [](#watch-service-directory-scanner)手表服务目录扫描仪
+###### 手表服务目录扫描仪
我们添加了`WatchServiceDirectoryScanner`。
-###### [](#persistent-file-list-filter-changes)持久文件列表过滤器更改
+###### 持久文件列表过滤器更改
`AbstractPersistentFileListFilter`具有一个新属性(`flushOnUpdate`),当将其设置为`true`时,如果实现`Flushable`(例如,`PropertiesPersistingMetadataStore`),则在元数据存储上调用`flush()`。
-##### [](#x4.2-class-package-change)类包更改
+##### 类包更改
我们将`org.springframework.integration.scattergather`类从`org.springframework.integration.handler`移到了`org.springframework.integration.scattergather`。
-##### [](#tcp-changes-2)TCP 更改
+##### TCP 更改
本节描述对 Spring Integration TCP 功能的一般更改。
-###### [](#x4.2-tcp-serializers)TCP 序列化器
+###### TCP 序列化器
tcp`Serializers`不再`flush()``OutputStream`。现在这是由`TcpNxxConnection`类完成的。如果直接在代码中使用序列化器,则可能需要`flush()``OutputStream`。
-###### [](#x4.2-tcp-server-exceptions)服务器套接字异常
+###### 服务器套接字异常
`TcpConnectionServerExceptionEvent`现在,每当 TCP 服务器套接字上发生意外异常时,都会发布实例(也添加到 4.1.3 和 4.0.7 中)。有关更多信息,请参见[TCP 连接事件](./ip.html#tcp-events)。
-###### [](#x4.2-tcp-server-port)TCP 服务器端口
+###### TCP 服务器端口
如果将 TCP 服务器套接字工厂配置为侦听随机端口,那么现在可以通过使用`getPort()`获得 OS 选择的实际端口。`getServerSocketAddress()`也是可用的。
有关更多信息,请参见“[TCP 连接工厂](./ip.html#tcp-connection-factories)”。
-###### [](#x4.2-tcp-gw-rto)TCP 网关远程超时
+###### TCP 网关远程超时
`TcpOutboundGateway`现在支持`remote-timeout-expression`作为现有`remote-timeout`属性的替代选项。这允许根据每条消息设置超时。
@@ -1069,11 +1069,11 @@ tcp`Serializers`不再`flush()``OutputStream`。现在这是由`TcpNxxConnection
有关更多信息,请参见[.TCP 出站网关属性](./ip.html#tcp-ob-gateway-attributes)。
-###### [](#x4.2-tcp-ssl)TCP SSLSession 可用于头映射
+###### TCP SSLSession 可用于头映射
`TcpConnection`实现现在支持`getSslSession()`,让你从会话中提取信息以添加到消息头中。有关更多信息,请参见`null`。
-###### [](#x4.2-tcp-events)TCP 事件
+###### TCP 事件
现在,每当出现关联异常时,就会发布新的事件——例如向不存在的套接字发送消息。
@@ -1081,35 +1081,35 @@ tcp`Serializers`不再`flush()``OutputStream`。现在这是由`TcpNxxConnection
有关更多信息,请参见[TCP 连接事件](./ip.html#tcp-events)。
-##### [](#x4.2-inbound-channel-adapter-annotation)`@InboundChannelAdapter`变更
+##### `@InboundChannelAdapter`变更
以前,入站通道适配器上的`@Poller`将`TcpNxxConnection`属性默认为`-1`(无穷大)。这与``的 XML 配置不一致,后者缺省为`1`。注解现在默认此属性为`1`。
-##### [](#x4.2-api-changes)API 更改
+##### API 更改
`o.s.integration.util.FunctionIterator`现在需要一个`o.s.integration.util.Function`,而不是一个`reactor.function.Function`。这样做是为了消除对反应堆不必要的硬性依赖。这个迭代器的任何使用都需要更改导入。
对于`Promise`网关等功能,仍然支持 Reactor。对于那些不需要该依赖项的用户,该依赖项已被删除。
-##### [](#x4.2-jms-changes)JMS 更改
+##### JMS 更改
本节描述对 Spring Integration TCP 功能的一般更改。
-###### [](#reply-listener-lazy-initialization)回复侦听器惰性初始化
+###### 回复侦听器惰性初始化
现在,你可以将 JMS 出站网关中的应答侦听器配置为按需初始化,并在空闲一段时间后停止,而不是由网关的生命周期来控制。有关更多信息,请参见[出站网关](./jms.html#jms-outbound-gateway)。
-###### 消息驱动端点中的[](#conversion-errors-in-message-driven-endpoints)转换错误
+###### 消息驱动端点中的转换错误
`error-channel`现在用于转换错误。在以前的版本中,它们会导致事务回滚和消息重新交付。
有关更多信息,请参见[消息驱动通道适配器](./jms.html#jms-message-driven-channel-adapter)和`confirm-ack-channel`。
-###### [](#default-acknowledge-mode)默认确认模式
+###### 默认确认模式
当使用隐式定义的`DefaultMessageListenerContainer`时,默认的`acknowledge`现在是`transacted`。我们建议在使用此容器时使用`transacted`,以避免消息丢失。这个默认值现在应用于消息驱动的入站适配器和入站网关。它已经是 JMS 支持的通道的默认设置。
-有关更多信息,请参见[消息驱动通道适配器](./jms.html#jms-message-driven-channel-adapter)和[](#x4.2-api-changes)。
+有关更多信息,请参见[消息驱动通道适配器](./jms.html#jms-message-driven-channel-adapter)和。
###### `@EnableIntegration`共享订阅
@@ -1117,99 +1117,99 @@ tcp`Serializers`不再`flush()``OutputStream`。现在这是由`TcpNxxConnection
有关更多信息,请参见`default-reply-to`。
-##### [](#x4.2-conditional-pollers)条件 Pollers
+##### 条件 Pollers
现在,我们为动态轮询提供了更大的灵活性。
有关更多信息,请参见[消息源的条件 Poller](./polling-consumer.html#conditional-pollers)。
-##### [](#x4.2-amqp-changes)AMQP 变化
+##### AMQP 变化
本节描述 Spring 集成 AMQP 功能的一般更改。
-###### [](#publisher-confirmations)发布者确认
+###### 发布者确认
``现在支持`confirm-correlation-expression`、`confirm-ack-channel`和`confirm-nack-channel`属性(其目的类似于``)。
-###### [](#correlation-data)相关数据
+###### 相关数据
对于出站通道适配器和入站网关,如果相关数据是`Message>`,则它将成为 ACK 或 NACK 通道上消息的基础,并添加额外的头。以前,任何相关数据(包括`Message>`)都作为 ACK 或 NACK 消息的有效负载返回。
-###### [](#inbound-gateway-properties)入站网关属性
+###### 入站网关属性
``现在公开`amqp-template`属性,以允许对外部 Bean 的答复`o.s.integration.util.Function`进行更多控制。你还可以提供自己的`AmqpTemplate`实现。此外,如果请求消息没有`replyTo`属性,则可以使用`default-reply-to`。
有关更多信息,请参见[AMQP 支持](./amqp.html#amqp)。
-##### [](#x4.2-xpath-splitter)XPath 拆分器改进
+##### XPath 拆分器改进
现在,`XPathMessageSplitter`(``)允许为内部`output-properties`配置`output-properties`,并支持用于 XPath 评估`Iterator`结果的`true`模式(默认为`true`)。
有关更多信息,请参见[分割 XML 消息](./xml.html#xml-xpath-splitting)。
-##### [](#x4.2-http-changes)http 更改
+##### http 更改
本节描述对 Spring 集成 HTTP 功能的一般更改。
-###### [](#cors)CORS
+###### CORS
HTTP 入站端点(``和``)现在允许跨源资源共享的配置。
有关更多信息,请参见[跨源资源共享支持](./http.html#http-cors)。
-###### [](#inbound-gateway-timeout)入站网关超时
+###### 入站网关超时
你可以将 HTTP 入站门方式配置为在请求超时时返回指定的状态码。现在的默认值是`500 Internal Server Error`,而不是`200 OK`。
有关更多信息,请参见[响应状态代码](./http.html#http-response-statuscode)。
-###### [](#form-data)表单数据
+###### 表单数据
我们添加了代理`multipart/form-data`请求的文档。有关更多信息,请参见[HTTP 支持](./http.html#http)。
-##### [](#x4.2-gw)网关更改
+##### 网关更改
本节描述对 Spring 集成网关功能的一般更改。
-###### [](#gateway-methods-can-return-completablefuture)网关方法可以返回`CompletableFuture>`
+###### 网关方法可以返回`CompletableFuture>`
当使用 Java8 时,网关方法现在可以返回`CompletableFuture>`。有关更多信息,请参见[`CompletableFuture`](./gateway.html#gw-completable-future)。
-###### [](#messaginggateway-annotation)MessagingGateway 注释
+###### MessagingGateway 注释
-请求和回复超时属性现在是[](#messaginggateway-annotation),而不是`Long`,以允许使用属性占位符或 SPEL 进行配置。参见[`@MessagingGateway`注释]。
+请求和回复超时属性现在是,而不是`Long`,以允许使用属性占位符或 SPEL 进行配置。参见[`@MessagingGateway`注释]。
-##### [](#x4.2-aggregator-changes)聚合器更改
+##### 聚合器更改
本节描述对 Spring 集成聚合器功能的一般更改。
-###### [](#aggregator-performance)聚合器性能
+###### 聚合器性能
该版本通过在发布组消息时更有效地从组中删除消息,对聚合组件(聚合器、重排序程序和其他组件)进行了一些性能改进。新的方法(`removeMessagesFromGroup`)已添加到消息存储中。设置`removeBatchSize`属性(默认:`CompletableFuture>`)以调整每个操作中删除的消息数量。目前,JDBC、Redis 和 MongoDB 消息存储支持此属性。
-###### [](#output-message-group-processor)输出消息组处理器
+###### 输出消息组处理器
当使用`ref`或 inner Bean 作为聚合器时,现在可以直接绑定`MessageGroupProcessor`。此外,我们还添加了一个`SimpleMessageGroupProcessor`,它传回组中的消息集合。当输出处理器生成`@MessagingGateway`的集合时,聚合器将单独释放这些消息。配置`SimpleMessageGroupProcessor`会使聚合器成为消息屏障,在这里,消息会一直保留到所有消息到达,然后单独发布。有关更多信息,请参见[Aggregator](./aggregator.html#aggregator)。
-##### [](#ftp-and-sftp-changes-2)FTP 和 SFTP 更改
+##### FTP 和 SFTP 更改
本节描述对 Spring 集成 FTP 和 SFTP 功能的一般更改。
-###### [](#inbound-channel-adapters)入站通道适配器
+###### 入站通道适配器
现在可以在入站通道适配器上指定`remote-directory-expression`,以在运行时确定目录。有关更多信息,请参见[FTP/FTPS 适配器](./ftp.html#ftp)和[SFTP 适配器](./sftp.html#sftp)。
-###### [](#gateway-partial-results)网关部分结果
+###### 网关部分结果
当你使用 FTP 或 SFTP 出站网关对多个文件(使用`mget`和`mput`)进行操作时,在部分请求完成后可能会发生异常。如果出现这样的条件,将抛出一个包含部分结果的`PartialSuccessException`。有关更多信息,请参见[FTP 出站网关](./ftp.html#ftp-outbound-gateway)和[SFTP 出站网关](./sftp.html#sftp-outbound-gateway)。
-###### [](#delegating-session-factory)委托会话工厂
+###### 委托会话工厂
我们添加了一个委托会话工厂,允许基于某些线程上下文值来选择特定的会话工厂。
有关更多信息,请参见[Delegating Session Factory](./ftp.html#ftp-dsf)和[Delegating Session Factory](./sftp.html#sftp-dsf)。
-###### [](#default-sftp-session-factory)默认 SFTP会话工厂
+###### 默认 SFTP会话工厂
以前,`DefaultSftpSessionFactory`无条件地允许与未知主机的连接。这现在是可配置的(默认值:`false`)。
@@ -1217,45 +1217,45 @@ HTTP 入站端点(``和``以在``中使用`requestMessage`上下文执行任何自定义`Session`操作。
有关更多信息,请参见[使用`MessageSessionCallback`](./ftp.html#ftp-会话-callback)和[MessagesessionCallback](./sftp.html#sftp-session-callback)。
-##### [](#websocket-changes-2) WebSocket 变化
+##### WebSocket 变化
我们在`WebSocketHandlerDecoratorFactory`中添加了`ServerWebSocketContainer`支持,以允许对内部`WebSocketHandler`进行链式定制。有关更多信息,请参见[WebSockets 名称空间支持](./web-sockets.html#web-sockets-namespace)。
-##### [](#application-event-adapters-changes)应用程序事件适配器更改
+##### 应用程序事件适配器更改
`ApplicationEvent`适配器现在可以使用`payload`作为`event`来操作,从而直接允许省略自定义`ApplicationEvent`扩展。为此,我们在``上引入了`publish-payload`布尔属性。有关更多信息,请参见[ Spring `ApplicationEvent`支持]。
-### [](#migration-4.0-4.1)4.0 和 4.1 之间的变化
+### 4.0 和 4.1 之间的变化
有关可能影响应用程序的重要更改,请参见[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-4.0-to-4.1-Migration-Guide)。你可以在[wiki](https://github.com/spring-projects/spring-integration/wiki)上找到所有回到 2.1 版本的迁移指南。
-#### [](#new-components)新组件
+#### 新组件
版本 4.1 增加了一些新的组件。
-##### [](#x4.1-promise-gateway)promise\\>gateway
+##### promise\\>gateway
消息传递网关方法现在支持 reactor`Promise`返回类型。见[异步网关](./gateway.html#async-gateway)。
-##### [](#x4.1-web-socket-adapters) WebSocket 支持
+##### WebSocket 支持
`WebSocket`模块现已可用。它完全基于 Spring WebSocket 和 Spring 消息传递模块,并提供了``和``。有关更多信息,请参见[WebSockets 支持](./web-sockets.html#web-sockets)。
-##### [](#x4.1-scatter-gather)散集 Enterprise 集成模式
+##### 散集 Enterprise 集成模式
实现了散集 Enterprise 集成模式。有关更多信息,请参见[分散收集](./scatter-gather.html#scatter-gather)。
-##### [](#x4.1-Routing-Slip)布线滑移模式
+##### 布线滑移模式
我们添加了路由条 EIP 模式的实现。有关更多信息,请参见[布线滑移](./router.html#routing-slip)。
-##### [](#x4.1-idempotent-receiver)幂等接收器模式
+##### 幂等接收器模式
通过在 XML 中添加[布线滑移](./router.html#routing-slip)组件或在 Java 配置中添加`IdempotentReceiverInterceptor`和`IdempotentReceiver`注释,我们添加了幂等接收器 Enterprise 集成模式实现。有关更多信息,请参见`JsonObjectMapper`和[Javadoc](https://docs.spring.io/spring-integration/api/index.html)。
@@ -1263,39 +1263,39 @@ HTTP 入站端点(``和``和``组件。见[Redis 队列入站网关](./redis.html#redis-queue-inbound-gateway)和[Redis 队列出站网关](./redis.html#redis-queue-outbound-gateway)。
-##### [](#x4.1-PollSkipAdvice)`PollSkipAdvice`
+##### `PollSkipAdvice`
我们添加了``,你可以在``的``中使用它来确定当前轮询是否应该被你用`PollSkipStrategy`实现的某些条件所抑制(跳过)。有关更多信息,请参见[Poller](./polling-consumer.html#polling-consumer)。
-#### [](#x4.1-general)一般变化
+#### 一般变化
本节描述了从 4.0 到 4.1 版本的一般更改。
-##### [](#x4.1-amqp-inbound-missing-queues)AMQP 入站端点,通道
+##### AMQP 入站端点,通道
使用消息侦听器容器(入站端点和通道)的元素现在支持`missing-queues-fatal`属性。有关更多信息,请参见[AMQP 支持](./amqp.html#amqp)。
-##### [](#x4.1-amqp-outbound-lazy-connect)AMQP 出站端点
+##### AMQP 出站端点
AMQP 出站端点支持一个名为`lazy-connect`的新属性(默认:`true`)。当`true`时,直到第一条消息到达(假设没有入站端点,这些端点总是在启动过程中尝试建立连接),才会建立到代理的连接。当设置为[Poller](./polling-consumer.html#polling-consumer)时,将在应用程序启动期间尝试建立连接。有关更多信息,请参见[AMQP 支持](./amqp.html#amqp)。
-##### [](#x4.1-sms-copy-on-get)SimpleMessageStore
+##### SimpleMessageStore
在调用`getMessageGroup()`时,`SimpleMessageStore`不再复制该组。有关更多信息,请参见[[warning](./message-store.html#sms-caution)。
-##### [](#x4.1-ws-encode-uri)Web 服务出站网关:`encode-uri`
+##### Web 服务出站网关:`encode-uri`
``现在提供了一个`encode-uri`属性,允许在发送请求之前禁用 URI 对象的编码。
-##### [](#x4.1-http-status-code)HTTP 入站通道适配器和状态代码
+##### HTTP 入站通道适配器和状态代码
-现在可以将``配置为[](#x4.1-sms-copy-on-get),以覆盖默认的`200 OK`状态。有关更多信息,请参见[HTTP 命名空间支持](./http.html#http-namespace)。
+现在可以将``配置为。
-##### [](#x4.1-mqtt)MQTT 适配器更改
+##### MQTT 适配器更改
现在,你可以将 MQTT 通道适配器配置为连接到多个服务器——例如,以支持高可用性。有关更多信息,请参见[MQTT 支持](./mqtt.html#mqtt)。
@@ -1305,13 +1305,13 @@ MQTT 出站通道适配器现在支持异步发送,在确认发送之前避免
现在可以在运行时以编程方式订阅和取消订阅主题。有关更多信息,请参见[入站(消息驱动)通道适配器](./mqtt.html#mqtt-inbound)。
-##### [](#x4.1-sftp)FTP 和 SFTP 适配器更改
+##### FTP 和 SFTP 适配器更改
FTP 和 SFTP 出站通道适配器现在支持追加到远程文件,并在远程文件已经存在时采取特定的操作。远程文件模板现在也支持这一点,以及`rmdir()`和`exists()`。此外,远程文件模板提供了对底层客户机对象的访问,从而能够访问底层 API。
有关更多信息,请参见[FTP/FTPS 适配器](./ftp.html#ftp)和[SFTP 适配器](./sftp.html#sftp)。
-##### [](#x4.1-splitter-iterator)拆分器和迭代器
+##### 拆分器和迭代器
`Splitter`组件现在支持将`Iterator`作为生成输出消息的结果对象。有关更多信息,请参见[Splitter](./splitter.html#splitter)。
@@ -1319,259 +1319,259 @@ FTP 和 SFTP 出站通道适配器现在支持追加到远程文件,并在远
`Aggregator`Instancess 现在支持一个新属性`expire-groups-upon-timeout`。有关更多信息,请参见[Aggregator](./aggregator.html#aggregator)。
-##### [](#x4.1-content-enricher-improvement)内容更丰富的改进
+##### 内容更丰富的改进
我们添加了一个`null-result-expression`属性,如果``返回`null`,则对该属性进行求值并返回。你可以在``和``中添加它。有关更多信息,请参见[内容更丰富](./content-enrichment.html#content-enricher)。
我们添加了一个`error-channel`属性,如果`Exception`发生在`request-channel`的下游,该属性将用于处理错误流。这使你可以返回一个替代对象来用于充实。有关更多信息,请参见[内容更丰富](./content-enrichment.html#content-enricher)。
-##### [](#x4.1-header-channel-registry)header 通道注册表
+##### header 通道注册表
``元素的``子元素现在可以重写 header 通道注册中心保留通道映射的默认时间。有关更多信息,请参见[报头通道注册表](./content-enrichment.html#header-channel-registry)。
-##### [](#x4.1-orderly-shutdown)有序关机
+##### 有序关机
我们对有序关机算法进行了改进。有关更多信息,请参见[有序关机](./shutdown.html#jmx-shutdown)。
-##### [](#x4.1-recipientListRouter)`RecipientListRouter`的管理
+##### `RecipientListRouter`的管理
`RecipientListRouter`现在提供了几个管理操作,以在运行时配置收件人。这样,你现在就可以配置``,而不需要从一开始就配置任何``。有关更多信息,请参见[`RecipientListRouterManagement`]。
-##### [](#x4.1-AbstractHeaderMapper-changes)AbstracTheAderMapper:非 \_Standard\_Headers 令牌
+##### AbstracTheAderMapper:非 \_Standard\_Headers 令牌
`AbstractHeaderMapper`实现现在提供了额外的`NON_STANDARD_HEADERS`令牌来映射任何用户定义的标头,这些标头在默认情况下是不映射的。有关更多信息,请参见[AMQP 消息头](./amqp.html#amqp-message-headers)。
-##### [](#x4.1-amqp-channels)AMQP 信道:`template-channel-transacted`
+##### AMQP 信道:`template-channel-transacted`
我们为 AMQP`MessageChannel`实例引入了`template-channel-transacted`属性。有关更多信息,请参见[AMQP 支持的消息通道](./amqp.html#amqp-channels)。
-##### [](#x4.1-syslog)syslog 适配器
+##### syslog 适配器
默认的 Syslog 消息转换器现在有一个选项,可以在设置消息头的同时保留有效负载中的原始消息。有关更多信息,请参见[Syslog 入站通道适配器](./syslog.html#syslog-inbound-adapter)。
-##### [](#x4.1-async-gateway)异步网关
+##### 异步网关
除了`Promise`返回类型[前面提到过](#x4.1-promise-gateway)外,网关方法现在还可以返回`Promise`,这是 Spring Framework4.0 中介绍的。你还可以在网关中禁用异步处理,让下游流直接返回`Future`。见[异步网关](./gateway.html#async-gateway)。
-##### [](#x4.1-aggregator-advice-chain)聚合器建议链
+##### 聚合器建议链
`Aggregator`和`Resequencer`现在支持``和``子元素来建议`forceComplete`操作。有关更多信息,请参见[使用 XML 配置聚合器](./aggregator.html#aggregator-xml)。
-##### [](#x4.1-script-outbound-channel-adapter)出站通道适配器和脚本
+##### 出站通道适配器和脚本
[重测序器](./resequencer.html#resequencer)现在支持``子元素。底层脚本必须具有`void`返回类型或`null`返回类型。见[Groovy 支持](./groovy.html#groovy)和[脚本支持](./scripting.html#scripting)。
-##### [](#x4.1-reseq)重测序器更改
+##### 重测序器更改
当重排序程序中的消息组超时(使用`group-timeout`或`MessageGroupStoreReaper`)时,现在默认情况下,将立即丢弃延迟到达的消息。见[重测序器](./resequencer.html#resequencer)。
-##### [](#x4.1-Optional-Parameter)可选 POJO 方法参数
+##### 可选 POJO 方法参数
Spring 集成现在一致地处理 Java8 的`Optional`类型。见[配置服务激活器](./service-activator.html#service-activator-namespace)。
-##### [](#x4.1-queue-channel-queue.typ)`QueueChannel`backed 队列类型
+##### `QueueChannel`backed 队列类型
支持`QueueChannel`的`Queue type`已从`BlockingQueue`更改为更通用的`Queue`。此更改允许使用任何外部`Queue`实现(例如,Reactor 的`PersistentQueue`)。参见[`QueueChannel`配置]。
-##### [](#x4.1-channel-interceptor)`ChannelInterceptor`变化
+##### `ChannelInterceptor`变化
`ChannelInterceptor`现在支持额外的`afterSendCompletion()`和`afterReceiveCompletion()`方法。见[出站通道适配器](./mqtt.html#mqtt-outbound)。
-##### [](#x4.1-mail-peek)IMAP PEEK
+##### IMAP PEEK
从版本 4.1.1 开始,如果将`mail.[protocol].peek`JavaMail 属性显式地设置为`false`(其中`[protocol]`是`imap`或`imaps`),则行为会发生变化。参见[[重要]]。
-### [](#migration-3.0-4.0)3.0 和 4.0 之间的变化
+### 3.0 和 4.0 之间的变化
有关可能影响应用程序的重要更改,请参见[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-3.0-to-4.0-Migration-Guide)。你可以在[wiki](https://github.com/spring-projects/spring-integration/wiki)上找到所有回到 2.1 版本的迁移指南。
-#### [](#x4.0-new-components)新组件
+#### 新组件
4.0 版本增加了许多新的组件。
-##### [](#x4.0-mqtt)MQTT 通道适配器
+##### MQTT 通道适配器
MQTT 通道适配器(以前在 Spring 集成扩展存储库中可用)现在可以作为正常 Spring 集成分布的一部分使用。见[MQTT 支持](./mqtt.html#mqtt)。
-##### [](#x4.0-enable-configuration)`@EnableIntegration`
+##### `@EnableIntegration`
我们添加了`@EnableIntegration`注释,以允许在使用`@Configuration`类时声明标准 Spring 集成 bean。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-##### [](#x4.0-component-scan)`@IntegrationComponentScan`
+##### `@IntegrationComponentScan`
我们添加了`@IntegrationComponentScan`注释,以允许 Classpath 扫描 Spring 特定于集成的组件。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-##### [](#x4.0-message-history)“@enableMessageHistory”
+##### “@enableMessageHistory”
现在可以在`@Configuration`类中使用`@EnableMessageHistory`注释来启用消息历史记录。此外,JMX MBean 还可以修改消息历史设置。此外,`MessageHistory`可以跟踪自动创建的带有注释的端点的`MessageHandler`实例(例如`@ServiceActivator`,`@Splitter`,以及其他)。有关更多信息,请参见[消息历史](./message-history.html#message-history)。
-##### [](#x4.0-messaging-gateway)`@MessagingGateway`
+##### `@MessagingGateway`
现在可以使用`@MessagingGateway`注释配置消息传递网关接口。它类似于``XML 元素。有关更多信息,请参见[`@MessagingGateway`注释]。
-##### [](#x4.0-boot) Spring boot`@EnableAutoConfiguration`
+##### Spring boot`@EnableAutoConfiguration`
除了前面提到的`@EnableIntegration`注释之外,我们还引入了一个钩子,允许 Spring 集成基础架构 bean 配置 Spring boot 的`@EnableAutoConfiguration`注释。有关更多信息,请参见 Spring 引导参考指南中的[“自动配置”](https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html)。
-##### [](#x4.0-global-channel-interceptor)`@GlobalChannelInterceptor`
+##### `@GlobalChannelInterceptor`
除了上面提到的`@EnableIntegration`注释之外,我们还引入了`@GlobalChannelInterceptor`注释。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-##### [](#x4.0-integration-converter)`@IntegrationConverter`
+##### `@IntegrationConverter`
我们引入了`@IntegrationConverter`注释,作为``组件的类似物。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-##### [](#x4.0-enable-publisher)`@EnablePublisher`
+##### `@EnablePublisher`
我们添加了`@EnablePublisher`注释,以便为`@Publisher`注释提供`default-publisher-channel`的规范。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-##### [](#x4.0-redis-cms)Redis Channel 消息存储
+##### Redis Channel 消息存储
我们添加了一个 REDIS`MessageGroupStore`,该 REDIS 对支持`QueueChannel`以实现持久性进行了优化。有关更多信息,请参见[Redis Channel 消息存储](./redis.html#redis-cms)。
我们添加了一个 redis`ChannelPriorityMessageStore`。你可以使用它来按优先级检索消息。有关更多信息,请参见[Redis Channel 消息存储](./redis.html#redis-cms)。
-##### [](#x4.0-priority-channel-mondodb)MongodDB 频道消息存储
+##### MongodDB 频道消息存储
MongoDB 支持现在提供了`MongoDbChannelMessageStore`,这是一个特定于通道的`MessageStore`实现。使用`priorityEnabled = true`,你可以在``元素中使用它来实现持久消息的优先顺序轮询。有关更多信息,请参见[MongoDB 通道消息存储](./mongodb.html#mongodb-priority-channel-message-store)。
-##### [](#x4.0-MBeanExport-annotation)`@EnableIntegrationMBeanExport`
+##### `@EnableIntegrationMBeanExport`
现在可以在`@Configuration`类中启用`IntegrationMBeanExporter`注释。有关更多信息,请参见[MBean 出口商](./jmx.html#jmx-mbean-exporter)。
-##### [](#x4.0-channel-security-interceptor)`ChannelSecurityInterceptorFactoryBean`
+##### `ChannelSecurityInterceptorFactoryBean`
`ChannelSecurityInterceptorFactoryBean`现在支持为使用`@Configuration`类的消息通道配置 Spring 安全性。有关更多信息,请参见[Security in Spring Integration](./security.html#security)。
-##### [](#x4.0-redis-outbound-gateway)Redis 命令网关
+##### Redis 命令网关
Redis 支持现在提供``组件,以通过使用`RedisConnection#execute`方法执行通用的 Redis 命令。有关更多信息,请参见[Redis 出站命令网关](./redis.html#redis-outbound-gateway)。
-##### [](#x4.0-redis-gemfire-lock-registry)`RedisLockRegistry`和`GemfireLockRegistry`
+##### `RedisLockRegistry`和`GemfireLockRegistry`
`RedisLockRegistry`和`GemfireLockRegistry`现在可用于支持多个应用程序实例和服务器可见的全局锁。这些可以用于跨多个应用程序实例的聚合消息处理程序,从而仅在一个实例上发生组发布。有关更多信息,请参见[Redis 锁注册表](./redis.html#redis-lock-registry),[Gemfire Lock 注册表](./gemfire.html#gemfire-lock-registry)和[Aggregator](./aggregator.html#aggregator)。
-##### [](#x4.0-poller-annotation)`@Poller`
+##### `@Poller`
基于注释的消息传递配置现在可以具有`poller`属性。这意味着用`@ServiceActivator`、`@Aggregator`注释的方法和类似的注释现在可以使用`inputChannel`,这是对`PollableChannel`的引用。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-##### [](#x4.0-inbound-channel-adapter-annotation)`@InboundChannelAdapter`和`SmartLifecycle`用于带注释的端点
+##### `@InboundChannelAdapter`和`SmartLifecycle`用于带注释的端点
我们添加了`@InboundChannelAdapter`方法注释。它类似于``XML 组件。此外,所有消息传递注释现在都提供`SmartLifecycle`选项。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-##### [](#x4.0-twitter-sog)Twitter 搜索出站网关
+##### Twitter 搜索出站网关
我们添加了一个新的 Twitter 端点:``。与每次使用相同搜索查询进行轮询的搜索入站适配器不同,出站网关允许按需定制查询。有关更多信息,请参见[Spring Integration Social Twitter](https://github.com/spring-projects/spring-integration-extensions/tree/main/spring-integration-social-twitter)。
-##### [](#x4.0-gemfire-metadata)Gemfire 元数据存储
+##### Gemfire 元数据存储
我们添加了`GemfireMetadataStore`,让它在例如多个应用程序实例或服务器环境中的`AbstractPersistentAcceptOnceFileListFilter`实现中使用。有关更多信息,请参见[元数据存储](./meta-data-store.html#metadata-store),[读取文件](./file.html#file-reading),[FTP 入站通道适配器](./ftp.html#ftp-inbound)和[SFTP 入站通道适配器](./sftp.html#sftp-inbound)。
-##### [](#x4.0-bridge-annotations)`@BridgeFrom`和`@BridgeTo`注释
+##### `@BridgeFrom`和`@BridgeTo`注释
我们引入了`@BridgeFrom`和`@BridgeTo``@Bean`方法注释,以在`@Configuration`类中标记`MessageChannel`bean。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-##### [](#x4.0-meta-messaging-annotations)元消息传递注释
+##### 元消息传递注释
消息注释(`@ServiceActivator`、`@Router`、`@MessagingGateway`等)现在可以配置为用户定义消息注释的元注释。此外,用户定义的注释可以具有相同的属性(`inputChannel`、`@Poller`、`autoStartup`等)。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-#### [](#x4.0-general)一般变化
+#### 一般变化
本部分描述了从 3.0 到 4.0 版本的一般更改。
-##### [](#requires-spring-framework-4-0)需要 Spring 框架 4.0
+##### 需要 Spring 框架 4.0
我们将核心消息抽象(`Message`、`MessageChannel`等)移动到了 Spring 框架`spring-messaging`模块。在代码中直接引用这些类的开发人员需要进行更改,如[3.0 到 4.0 迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-3.0-to-4.0-Migration-Guide)的第一部分所述。
-##### [](#x4.0-xpath-header-enricher-header-type)XPath header Enricher 的 header 类型
+##### XPath header Enricher 的 header 类型
我们为``的`header`子元素引入了`header-type`属性。此属性为标头值提供目标类型(XPath 表达式求值的结果被转换为该标头值)。有关更多信息,请参见[XPath 报头 Enricher](./xml.html#xml-xpath-header-enricher)。
-##### [](#x4.0-object-to-json-transformer-result-type)Object to JSON Transformer:Node Result
+##### Object to JSON Transformer:Node Result
我们为``引入了`result-type`属性。此属性为将对象映射到 JSON 的结果提供目标类型。它支持`STRING`(默认值)和`NODE`。有关更多信息,请参见[自版本 3.0 起, Spring Integration 还提供了用于表达式的内置`#xpath`spel 函数。](./Transformer.html#Transformer-XPath-Spel-function)。
-##### [](#x4.0-jms-header-mapping)JMS 头映射
+##### JMS 头映射
现在,`DefaultJmsHeaderMapper`将传入的`JMSPriority`标头映射到 Spring Integration`priority`标头。以前,`priority`仅被考虑用于出站消息。有关更多信息,请参见[映射消息头到和来自 JMS 消息](./jms.html#jms-header-mapping)。
-##### [](#x4.0-jms-ob)JMS 出站通道适配器
+##### JMS 出站通道适配器
JMS 出站通道适配器现在支持`session-transacted`属性(默认:`false`)。以前,你必须插入自定义的`JmsTemplate`才能使用事务。见[出站通道适配器](./jms.html#jms-outbound-channel-adapter)。
-##### [](#x4.0-jms-ib)JMS 入站通道适配器
+##### JMS 入站通道适配器
JMS 入站通道适配器现在支持`session-transacted`属性(默认:`false`)。以前,你必须插入自定义的`JmsTemplate`才能使用事务。适配器允许在`acknowledgeMode`中进行“事务处理”,这是不正确的,并且不工作。这个值不再被允许。见[入站通道适配器](./jms.html#jms-inbound-channel-adapter)。
-##### [](#x4.0-datatype-channel)数据类型通道
+##### 数据类型通道
现在,你可以指定一个`MessageConverter`,用于在数据类型通道中将有效载荷转换为已接受的`datatype`实例之一时使用。有关更多信息,请参见[数据类型通道配置](./channel.html#channel-datatype-channel)。
-##### [](#x4.0-retry-config)更简单的重试建议配置
+##### 更简单的重试建议配置
我们添加了简化的名称空间支持来配置`RequestHandlerRetryAdvice`。有关更多信息,请参见[配置重试建议](./handler-advice.html#retry-config)。
-##### [](#x4.0-release-strategy-group-timeout)相关端点:基于时间的发布策略
+##### 相关端点:基于时间的发布策略
我们将互斥的`group-timeout`和`group-timeout-expression`属性添加到``和``中。这些属性允许强制完成部分`MessageGroup`,前提是`ReleaseStrategy`不释放一个组并且在指定的时间内没有进一步的消息到达。有关更多信息,请参见[使用 XML 配置聚合器](./aggregator.html#aggregator-xml)。
-##### [](#x4.0-redis-metadata)Redis 元数据存储
+##### Redis 元数据存储
`RedisMetadataStore`现在实现`ConcurrentMetadataStore`,例如,在多个应用程序实例或服务器环境中的`AbstractPersistentAcceptOnceFileListFilter`实现中使用它。有关更多信息,请参见[Redis 元数据存储](./redis.html#redis-metadata-store),[读取文件](./file.html#file-reading),[FTP 入站通道适配器](./ftp.html#ftp-inbound)和[SFTP 入站通道适配器](./sftp.html#sftp-inbound)。
-##### [](#x4.0-jdbc-cs)`JdbcChannelMessageStore`和`PriorityChannel`
+##### `JdbcChannelMessageStore`和`PriorityChannel`
t`JdbcChannelMessageStore`现在实现`PriorityCapableChannelMessageStore`,让它被用作`message-store`实例的`priority-queue`引用。有关更多信息,请参见[支持消息通道](./jdbc.html#jdbc-message-store-channels)。
-##### [](#x4.0-amqp)AMQP 端点交付模式
+##### AMQP 端点交付模式
Spring 默认情况下,AMQP 在代理上创建持久性消息。你可以通过设置`amqp_deliveryMode`标头或自定义映射程序来重写此行为。我们向适配器添加了一个方便的`default-delivery-mode`属性,以提供对这一重要设置的更简单配置。有关更多信息,请参见[出站通道适配器](./amqp.html#amqp-outbound-channel-adapter)和[出站网关](./amqp.html#amqp-outbound-gateway)。
-##### [](#x4.0-ftp)FTP 超时
+##### FTP 超时
现在`DefaultFtpSessionFactory`公开了`connectTimeout`、`defaultTimeout`和`dataTimeout`属性,从而避免了需要子类工厂来设置这些公共属性。对于更高级的配置,`postProcess*`方法仍然可用。有关更多信息,请参见[FTP Session Factory](./ftp.html#ftp-session-factory)。
-##### [](#x4.0-twitter-status-updating)推特:`StatusUpdatingMessageHandler`
+##### 推特:`StatusUpdatingMessageHandler`
`StatusUpdatingMessageHandler`(``)现在支持`tweet-data-expression`属性来构建用于更新时间轴状态的`org.springframework.social.twitter.api.TweetData`对象。例如,此功能允许附加图像。有关更多信息,请参见[Spring Integration Social Twitter](https://github.com/spring-projects/spring-integration-extensions/tree/main/spring-integration-social-twitter)。
-##### [](#x4.0-jpa-id-expression) JPA 检索网关:`id-expression`
+##### JPA 检索网关:`id-expression`
我们为``引入了`id-expression`属性来执行`EntityManager.find(Class entityClass, Object primaryKey)`。有关更多信息,请参见[检索出站网关](./jpa.html#jpa-retrieving-outbound-gateway)。
-##### [](#x4.0-tcp-deserializer-events)TCP 反序列化事件
+##### TCP 反序列化事件
当一个标准的反序列化器遇到将输入流解码为消息的问题时,它现在会发出`TcpDeserializationExceptionEvent`,让应用程序在发生异常的地方检查数据。有关更多信息,请参见[TCP 连接事件](./ip.html#tcp-events)。
-##### [](#x4.0-bean-messaging-annotations)上的消息传递注释`@Bean`定义
+##### 上的消息传递注释`@Bean`定义
现在,你可以在`@Bean`中的`@ServiceActivator`、`@Router`、`@InboundChannelAdapter`和其他定义上配置消息传递注释(`@Configuration`类)。有关更多信息,请参见[注释支持](./configuration.html#annotations)。
-### [](#migration-2.2-3.0)2.2 和 3.0 之间的变化
+### 2.2 和 3.0 之间的变化
有关可能影响应用程序的重要更改,请参见[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-2.2-to-3.0-Migration-Guide)。你可以在[wiki](https://github.com/spring-projects/spring-integration/wiki)上找到所有回到 2.1 版本的迁移指南。
-#### [](#x3.0-new-components)新组件
+#### 新组件
3.0 版本增加了一些新的组件。
-##### [](#x3.0-request-mapping)HTTP 请求映射
+##### HTTP 请求映射
HTTP 模块现在为入站端点提供了强大的请求映射支持。我们将`UriPathHandlerMapping`类替换为`IntegrationRequestMappingHandlerMapping`类,该类在应用程序上下文中以 Bean 名`integrationRequestMappingHandlerMapping`注册。在解析 HTTP 入站端点时,要么注册一个新的`IntegrationRequestMappingHandlerMapping` Bean,要么重用一个现有的 Bean。为了实现灵活的请求映射配置, Spring 集成为``和``提供了``的子元素。这两个 HTTP 入站端点现在完全基于 Spring MVC3.1 中引入的请求映射基础设施。例如,在单个入站端点上支持多个路径。有关更多信息,请参见[HTTP 命名空间支持](./http.html#http-namespace)。
-##### [](#x3.0-spel-customization) Spring 表达式语言配置
+##### Spring 表达式语言配置
我们添加了一个新的`IntegrationEvaluationContextFactoryBean`,以允许在整个框架的 SPEL 表达式中配置自定义`PropertyAccessor`实现和函数。有关更多信息,请参见[Spring Expression Language (SpEL)](./spel.html#spel)。
-##### [](#x3.0-spel-functions)spel 函数支持
+##### spel 函数支持
为了使用静态`Method`函数定制 SPEL`EvaluationContext`函数,我们引入了``组件。我们还添加了两个内置函数:`#jsonPath`和`#xpath`。有关更多信息,请参见[SPEL 函数](./spel.html#spel-functions)。
-##### [](#x3.0-spel-property-accessors)spel PropertyAccessors 支持
+##### spel PropertyAccessors 支持
为了使用`PropertyAccessor`实现来定制 SPEL`EvaluationContext`,我们添加了``组件。有关更多信息,请参见[属性访问器](./spel.html#spel-property-accessors)。
-##### [](#x3.0-redis-new-components)Redis:新组件
+##### Redis:新组件
我们添加了一个新的基于 Redis 的[`MetadataStore`](https://DOCS. Spring.io/ Spring-integration/api/org/springframework/integration/metadata/metadatastore.html)实现。你可以使用`RedisMetadataStore`在应用程序重新启动时维护`MetadataStore`的状态。这个新的`MetadataStore`实现可以与适配器一起使用,例如:
@@ -1583,23 +1583,23 @@ HTTP 模块现在为入站端点提供了强大的请求映射支持。我们将
有关更多信息,请参见“[Redis 支持](./redis.html#redis)”。
-##### [](#x3.0-hcr)header 通道注册表
+##### header 通道注册表
现在,你可以指示框架在注册表中存储应答通道和错误通道,以便以后进行解析。这对于`replyChannel`或`errorChannel`可能丢失的情况很有用(例如,在序列化消息时)。有关更多信息,请参见[页眉 Enricher](./content-enrichment.html#header-enricher)。
-##### [](#x3.0-configurable-mongo-MS)MongoDB 支持:new`ConfigurableMongoDbMessageStore`
+##### MongoDB 支持:new`ConfigurableMongoDbMessageStore`
除了现有的`eMongoDbMessageStore`,我们还引入了一个新的`ConfigurableMongoDbMessageStore`。这为 MongoDB 提供了一个更加健壮和灵活的`MessageStore`实现。它与现有的存储不具有向后兼容性,但我们建议将其用于新的应用程序。现有的应用程序可以使用它,但是旧商店中的消息不可用。有关更多信息,请参见[MongoDB 支持](./mongodb.html#mongodb)。
-##### [](#x3.0-syslog)syslog 支持
+##### syslog 支持
Spring Integration3.0 以 2.2`SyslogToMapTransformer`为基础,引入了`UDP`和`TCP`入站通道适配器,这些适配器是专门为接收 SYSLOG 消息而定制的。有关更多信息,请参见[syslog 支持](./syslog.html#syslog)。
-##### [](#x3.0-tail)`tail`支持
+##### `tail`支持
我们添加了文件入站通道适配器,该适配器使用`tail`命令在将行添加到文本文件的末尾时生成消息。见[“跟踪”文件](./file.html#file-tailing)。
-##### [](#x3.0-jmx)JMX 支持
+##### JMX 支持
我们添加了``。这个适配器查询 JMX MBean 树,并发送一条带有有效负载的消息,该负载是与查询匹配的对象的图形。默认情况下,MBean 映射到原语和简单对象(例如`Map`、`List`和数组)。它允许对例如 JSON 进行简单的转换。
@@ -1607,7 +1607,7 @@ Spring Integration3.0 以 2.2`SyslogToMapTransformer`为基础,引入了`UDP`
有关更多信息,请参见[JMX 支持](./jmx.html#jmx)。
-##### [](#x3.0-tcp-events)TCP/IP 连接事件和连接管理
+##### TCP/IP 连接事件和连接管理
`TcpConnection`实例现在在连接打开或关闭或发生异常时发出`ApplicationEvent`实例(特别是`TcpConnectionEvent`实例)。此更改使应用程序能够通过使用正常的 Spring `ApplicationListener`机制被告知对 TCP 连接的更改。
@@ -1621,23 +1621,23 @@ Spring Integration3.0 以 2.2`SyslogToMapTransformer`为基础,引入了`UDP`
有关更多信息,请参见[TCP 连接事件](./ip.html#tcp-events)。
-##### [](#x3.0-inbound-script)入站通道适配器脚本支持
+##### 入站通道适配器脚本支持
``现在支持使用``和``子元素来创建`MessageSource`。见[通道适配器表达式和脚本](./channel-adapter.html#channel-adapter-expressions-and-scripts)。
-##### [](#x3.0-content-enricher-headers)Content Enricher:Headers Enrichment 支持
+##### Content Enricher:Headers Enrichment 支持
Content Enricher 现在提供了``子元素的配置,以根据来自底层消息流的回复消息使用头来丰富出站消息。有关更多信息,请参见[有效载荷 Enricher](./content-enrichment.html#payload-enricher)。
-#### [](#x3.0-general)一般变化
+#### 一般变化
本节介绍从 2.2 版到 3.0 版的一般更改。
-##### [](#x3.0-message-id)消息 ID 生成
+##### 消息 ID 生成
以前,消息 ID 是通过使用 JDK`UUID.randomUUID()`方法生成的。有了这个版本,默认的机制已经改变,使用了更有效和显著更快的算法。此外,我们还添加了更改用于生成消息 ID 的策略的功能。有关更多信息,请参见[消息 ID 生成](./message.html#message-id-generation)。
-##### [](#x3.0-gateway)“\”变化
+##### “\”变化
现在,你可以在所有网关方法中设置公共标头,并且我们还添加了更多选项,用于向消息中添加有关调用了哪个方法的信息。
@@ -1647,7 +1647,7 @@ Content Enricher 现在提供了``子元素的配置,以根据来自
有关更多信息,请参见[消息传递网关](./gateway.html#gateway)。
-##### [](#x3.0-http-endpointss)http 端点变更
+##### http 端点变更
* **出站端点`encode-uri`**:``和``现在提供一个`encode-uri`属性,允许在发送请求之前禁用 URI 对象的编码。
@@ -1661,7 +1661,7 @@ Content Enricher 现在提供了``子元素的配置,以根据来自
有关更多信息,请参见[HTTP 支持](./http.html#http)。
-##### [](#x3.0-json-transformers)Jackson 支持
+##### Jackson 支持
* 介绍了一种新的 JSON 转换抽象方法。 Classpath 当前提供了用于 Jackson1.x 和 Jackson2 的实现方式,其版本是通过存在于 Classpath 上来确定的。在此之前,只支持 Jackson1.x。
@@ -1669,31 +1669,31 @@ Content Enricher 现在提供了``子元素的配置,以根据来自
有关更多信息,请参见[变压器](./transformer.html#transformer)中的“JSON Transformers”。
-##### [](#x3.0-id-for-chain-sub-components)链元素`id`属性
+##### 链元素`id`属性
以前,``中元素的`id`属性被忽略,并且在某些情况下被禁止。现在,`id`属性对于``中的所有元素都是允许的。 Bean 链元素的名称是周围链的`id`和元素本身的`id`的组合。例如:“mychain$child.myTransformer.handler”。有关更多信息,请参见[消息处理程序链](./chain.html#chain)。
-##### [](#x3.0-corr-endpoint-empty-groups)聚合器“empty-group-min-timeout”属性
+##### 聚合器“empty-group-min-timeout”属性
`AbstractCorrelatingMessageHandler`提供了一个名为`empty-group-min-timeout`的新属性,以允许空组到期在比到期部分组更长的时间表上运行。空组不会从`MessageStore`中删除,直到至少在此毫秒内未对其进行修改。有关更多信息,请参见[使用 XML 配置聚合器](./aggregator.html#aggregator-xml)。
-##### [](#x3.0-filelistfilter)持久文件列表过滤器
+##### 持久文件列表过滤器
使用持久性`MetadataStore`的新`FileListFilter`实现现在可用。你可以使用这些功能来防止系统重新启动后出现重复文件。有关更多信息,请参见[读取文件](./file.html#file-reading),[FTP 入站通道适配器](./ftp.html#ftp-inbound)和[SFTP 入站通道适配器](./sftp.html#sftp-inbound)。
-##### [](#x3.0-scripting-variables)脚本支持:变量更改
+##### 脚本支持:变量更改
我们为脚本组件引入了一个新的`variables`属性。此外,内联脚本现在也允许变量绑定。有关更多信息,请参见[Groovy 支持](./groovy.html#groovy)和[脚本支持](./scripting.html#scripting)。
-##### [](#x3.0-direct-channel-lb-ref)直接通道负载平衡配置
+##### 直接通道负载平衡配置
以前,在通道的`LoadBalancingStrategy`子元素上配置`dispatcher`时,唯一可用的选项是使用预定义的值枚举,这不允许开发人员设置`LoadBalancingStrategy`的自定义实现。现在可以使用`load-balancer-ref`提供对`LoadBalancingStrategy`的自定义实现的引用。有关更多信息,请参见[`DirectChannel`]。
-##### [](#x3.0-pub-sub)发布订阅行为
+##### 发布订阅行为
在此之前,发送到没有订阅服务器的 \将返回`false`结果。如果与`MessagingTemplate`一起使用,这将导致抛出异常。现在,`PublishSubscribeChannel`有一个名为`minSubscribers`的属性(默认值:`0`)。如果消息至少发送到最小数量的订阅服务器,则认为发送操作成功(即使该数量为零)。如果应用程序希望在这些情况下获得异常,请将最小订阅服务器设置为至少 1。
-##### [](#x3.0--s-ftp-changes)ftp、sftp 和 ftps 的变化
+##### ftp、sftp 和 ftps 的变化
默认情况下,FTP、SFTP 和 FTPS 端点不再缓存会话。
@@ -1703,7 +1703,7 @@ Content Enricher 现在提供了``子元素的配置,以根据来自
`DefaultSftpSessionFactory`(与`CachingSessionFactory`一起使用)现在支持在单个 SSH 连接上的多路复用通道(仅支持 SFTP)。
-###### [](#ftp-sftp-and-ftps-inbound-adapters)FTP、SFTP 和 FTPS 入站适配器
+###### FTP、SFTP 和 FTPS 入站适配器
以前,无法覆盖用于处理从远程服务器检索的文件的默认过滤器。`filter`属性决定检索哪些文件,但`FileReadingMessageSource`使用`AcceptOnceFileListFilter`。这意味着,如果以与先前复制的文件相同的名称检索文件的新副本,则适配器不会发送任何消息。
@@ -1713,7 +1713,7 @@ Content Enricher 现在提供了``子元素的配置,以根据来自
入站通道适配器现在支持`preserve-timestamp`属性,该属性将本地文件修改后的时间戳设置为来自服务器的时间戳(默认:`false`)。
-###### [](#ftp-sftp-and-ftps-gateways)FTP、SFTP 和 FTPS 网关
+###### FTP、SFTP 和 FTPS 网关
网关现在支持`mv`命令,从而可以重命名远程文件。
@@ -1725,13 +1725,13 @@ Content Enricher 现在提供了``子元素的配置,以根据来自
现在支持`local-directory-expression`属性,从而能够在检索过程中(基于远程目录)命名本地目录。
-###### [](#remote-file-template)远程文件模板
+###### 远程文件模板
在 FTP 和 SFTP 模块使用的`Session`实现上提供了一个新的高级抽象(`RemoteFileTemplate`)。虽然端点在内部使用它,但你也可以以编程方式使用此抽象。与所有 Spring 实现方式一样,它可靠地关闭底层会话,同时允许对会话的低级访问。
有关更多信息,请参见[FTP/FTPS 适配器](./ftp.html#ftp)和[SFTP 适配器](./sftp.html#sftp)。
-##### 用于出站网关的[](#x3.0-outbound-gateway-requires-reply)“requires-reply”属性
+##### 用于出站网关的“requires-reply”属性
所有出站网关(例如``或``)都是为“请求-回复”场景设计的。期望从外部服务获得响应,并将其发布到`reply-channel`或`replyChannel`消息头。然而,在某些情况下,外部系统可能并不总是返回一个结果(例如,当一个 SELECT 以一个空的`ResultSet`结束时,一个``或者一个单向 Web 服务)。因此,开发人员需要一个选项来配置是否需要回复。为此,我们为出站网关组件引入了`requires-reply`属性。在大多数情况下,`requires-reply`的默认值是`true`。如果没有结果,则抛出一个`ReplyRequiredException`。将值更改为`false`意味着,如果外部服务不返回任何东西,消息流将在该点结束,类似于出站通道适配器。
@@ -1743,13 +1743,13 @@ Content Enricher 现在提供了``子元素的配置,以根据来自
| |以前,没有收到回复的网关将静默地结束流(带有调试日志消息)。
默认情况下,通过此更改,大多数网关现在都会引发异常。
要恢复到以前的行为,请将`requires-reply`设置为`false`。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#x3.0-amqp-mapping)AMQP 出站网关报头映射
+##### AMQP 出站网关报头映射
在此之前,\在调用消息转换器之前映射头文件,并且转换器可以覆盖诸如`content-type`之类的头文件。出站适配器映射转换后的头,这意味着使用出站`content-type`(如果存在)中的`Message`之类的头。
从这个版本开始,网关现在映射消息转换后的头,与适配器保持一致。如果你的应用程序依赖于以前的行为(在此情况下,转换器的标头会覆盖映射的标头),那么你需要过滤这些标头(在消息到达网关之前),或者适当地设置它们。受`SimpleMessageConverter`影响的头是`content-type`和`content-encoding`。自定义消息转换器可以设置其他头。
-##### [](#x3.0-stored-proc-sql-return-type)存储过程组件的改进
+##### 存储过程组件的改进
对于标准`CallableStatement.getObject`方法不支持的更复杂的特定于数据库的类型,我们向带有外向的``元素引入了两个新的附加属性:
@@ -1761,11 +1761,11 @@ Content Enricher 现在提供了``子元素的配置,以根据来自
有关更多信息,请参见[存储过程](./jdbc.html#stored-procedures)。
-##### [](#x3.0-ws-outbound-uri-substitution)Web 服务出站 URI 配置
+##### Web 服务出站 URI 配置
Web 服务出站网关“URI”属性现在支持对 Spring Web 服务支持的所有 URI 方案的``替换。有关更多信息,请参见[出站 URI 配置](./ws.html#outbound-uri)。
-##### [](#x3.0-redis)Redis 适配器更改
+##### Redis 适配器更改
Redis 入站通道适配器现在可以为`serializer`属性使用`null`值,原始数据是消息有效负载。
@@ -1775,19 +1775,19 @@ Redis 出站通道适配器现在具有`topic-expression`属性,以在运行
有关更多信息,请参见[Redis 支持](./redis.html#redis)。
-##### [](#x3.0-advising-filters)建议过滤器
+##### 建议过滤器
以前,当 a``具有 a``时,丢弃操作全部在建议链的范围内执行(包括`discard-channel`上的任何下游流)。过滤器元素现在有一个名为`discard-within-advice`的属性(默认:`true`),以允许在建议链完成后执行丢弃操作。见[建议过滤器](./handler-advice.html#advising-filters)。
-##### [](#x3.0-annotation-advice)使用注释通知端点
+##### 使用注释通知端点
现在可以使用注释来配置请求处理程序建议链。见[使用注释为端点提供建议](./handler-advice.html#advising-with-annotations)。
-##### [](#x3.0-o-t-s-t)ObjectToStringTransformer 改进
+##### ObjectToStringTransformer 改进
这个转换器现在将`byte[]`和`char[]`有效负载正确地转换为`String`。有关更多信息,请参见[变压器](./transformer.html#transformer)。
-##### [](#x3.0-jpa-changes) JPA 支持变更
+##### JPA 支持变更
要持久化或合并的有效负载现在可以是`[java.lang.Iterable](https://docs.oracle.com/javase/7/docs/api/java/lang/Iterable.html)`类型。
@@ -1801,51 +1801,51 @@ JPA 检索网关和入站适配器现在具有一个属性,该属性将结果
有关更多信息,请参见[JPA Support](./jpa.html#jpa)。
-##### [](#x3.0-dalay-expression)DeLayer:延迟表达式
+##### DeLayer:延迟表达式
以前,``提供了一个`delay-header-name`属性来确定运行时的延迟值。在复杂的情况下,``之前必须加上``。 Spring Integration3.0 引入了`expression`属性和`expression`子元素来进行动态延迟确定。现在不推荐`delay-header-name`属性,因为你可以在`expression`中指定 header 求值。此外,我们引入了`ignore-expression-failures`来控制表达式求值失败时的行为。有关更多信息,请参见[Delayer](./delayer.html#delayer)。
-##### [](#x3.0-jdbc-mysql-v5_6_4)JDBC 消息存储的改进
+##### JDBC 消息存储的改进
Spring Integration3.0 为 MySQL 版本 5.6.4 及更高版本添加了一组新的 DDL 脚本。现在,MySQL 支持小数秒,因此在基于 MySQL 的消息存储中进行轮询时,FIFO 排序得到了改善。有关更多信息,请参见[通用的 JDBC 消息存储](./jdbc.html#jdbc-message-store-generic)。
-##### [](#x3.0-event-for-imap-idle)IMAP 空闲连接异常
+##### IMAP 空闲连接异常
以前,如果 IMAP 空闲连接失败,它将被记录,但是没有通知应用程序的机制。这样的异常现在生成`ApplicationEvent`实例。应用程序可以通过使用``或任何`ApplicationListener`配置为接收`ImapIdleExceptionEvent`(或其超类之一)来获得这些事件。
-##### [](#x3.0-tcp-headers)消息头和 TCP
+##### 消息头和 TCP
TCP 连接工厂现在启用了一种灵活机制的配置,可以在 TCP 上传输选定的报头(以及有效负载)。一个新的`TcpMessageMapper`启用了对头的选择,并且你需要配置一个适当的序列化器或反序列化器来将生成的`Map`写入 TCP 流。我们添加了`MapJsonSerializer`作为在 TCP 上传输报头和有效负载的方便机制。有关更多信息,请参见[传输头](./ip.html#ip-headers)。
-##### [](#x3.0-jms-mdca-te)JMS 消息驱动通道适配器
+##### JMS 消息驱动通道适配器
以前,在配置``时,如果希望使用特定的`TaskExecutor`,则必须声明一个容器 Bean,并通过设置`container`属性将其提供给适配器。我们添加了`task-executor`,让它直接在适配器上设置。这是对已经可用的其他几个容器属性的补充。
-##### [](#x3.0-rmi-ec)RMI 入站网关
+##### RMI 入站网关
RMI 入站网关现在支持`error-channel`属性。见[入站 RMI](./rmi.html#rmi-inbound)。
-##### [](#x3.0-xslt-transformer)`XsltPayloadTransformer`
+##### `XsltPayloadTransformer`
现在可以通过设置`transformer-factory-class`属性来指定 Transformer 工厂类名称。见`[XsltPayloadTransformer](./xml.html#xml-xslt-payload-transformers)`。
-### [](#migration-2.1-2.2)2.1 与 2.2 之间的变化
+### 2.1 与 2.2 之间的变化
有关可能影响应用程序的重要更改,请参见[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-2.1-to-2.2-Migration-Guide)。你可以在[wiki](https://github.com/spring-projects/spring-integration/wiki)上找到所有回到 2.1 版本的迁移指南。
-#### [](#x2.2-new-components)新组件
+#### 新组件
2.2 版增加了一些新的组件。
-##### [](#x2.2-redis-store-adapters)`RedisStore`入站和出站通道适配器
+##### `RedisStore`入站和出站通道适配器
Spring 集成现在具有`RedisStore`入站和出站通道适配器,允许你写入和读取与 Redis 集合之间的`Message`有效负载。有关更多信息,请参见[恢复存储出站通道适配器](./redis.html#redis-store-outbound-channel-adapter)和[Redis 存储入站通道适配器](./redis.html#redis-store-inbound-channel-adapter)。
-##### [](#x2.2-mongo-adapters)MongoDB 入站和出站通道适配器
+##### MongoDB 入站和出站通道适配器
Spring 集成现在具有 MongoDB 入站和出站通道适配器,允许你编写和读取与 MongoDB 文档存储之间的`Message`有效负载。有关更多信息,请参见[MongoDB 出站通道适配器](./mongodb.html#mongodb-outbound-channel-adapter)和[MongoDB 入站通道适配器](./mongodb.html#mongodb-inbound-channel-adapter)。
-##### [](#x2.2-jpa) JPA 端点
+##### JPA 端点
Spring 集成现在包括用于检索和持久化 JPA 实体对象的 Java 持久化 API( JPA)的组件。 JPA 适配器包括以下组件:
@@ -1859,15 +1859,15 @@ Spring 集成现在包括用于检索和持久化 JPA 实体对象的 Java 持
有关更多信息,请参见[JPA Support](./jpa.html#jpa)。
-#### [](#x2.2-general)一般变动
+#### 一般变动
本部分描述了从版本 2.1 到版本 2.2 的一般更改。
-##### [](#x2.2-spring-31) Spring 3.1 默认使用
+##### Spring 3.1 默认使用
Spring 集成现在使用 Spring 3.1。
-##### [](#x2.2-handler-advice)向端点添加行为
+##### 向端点添加行为
向 poller 添加``的功能已经有一段时间了。然而,由此添加的行为会影响整个集成流。它没有解决向单个端点添加(例如)重试的功能。2.2 版本向许多端点引入了``。
@@ -1881,7 +1881,7 @@ Spring 集成现在使用 Spring 3.1。
有关更多信息,请参见[向端点添加行为](./handler-advice.html#message-handler-advice-chain)。
-##### [](#x2.2-transaction-sync)事务同步与伪事务
+##### 事务同步与伪事务
Pollers 现在可以参与 Spring 的事务同步功能。这允许同步诸如由入站通道适配器重命名文件这样的操作,这取决于事务是提交还是回滚。
@@ -1889,7 +1889,7 @@ Pollers 现在可以参与 Spring 的事务同步功能。这允许同步诸如
有关更多信息,请参见[事务同步](./transactions.html#transaction-synchronization)。
-##### [](#x2.2-file-adapter)文件适配器:改进的文件覆盖和追加处理
+##### 文件适配器:改进的文件覆盖和追加处理
当使用文件出站通道适配器或文件出站网关时,可以使用新的`mode`属性。在 Spring Integration2.2 之前,目标文件在它们存在时被替换。现在你可以指定以下选项:
@@ -1903,7 +1903,7 @@ Pollers 现在可以参与 Spring 的事务同步功能。这允许同步诸如
有关更多信息,请参见[处理现有的目标文件](./file.html#file-writing-destination-exists)。
-##### [](#x2.2-outbound-gateways)回复-超时添加到更多出站网关
+##### 回复-超时添加到更多出站网关
XML 名称空间支持将 Reply-Timeout 属性添加到以下出站网关:
@@ -1917,7 +1917,7 @@ XML 名称空间支持将 Reply-Timeout 属性添加到以下出站网关:
* WS 出站网关
-##### [](#x2.2-amqp-11) Spring-AMQP1.1
+##### Spring-AMQP1.1
Spring 集成现在使用 Spring AMQP1.1。这使得能够在 Spring 集成应用程序中使用几个特征,包括以下内容:
@@ -1931,15 +1931,15 @@ Spring 集成现在使用 Spring AMQP1.1。这使得能够在 Spring 集成应
* 支持死信交换和死信队列
-##### [](#x2.2-jdbc-11)JDBC 支持-存储过程组件
+##### JDBC 支持-存储过程组件
-###### [](#spel-support)spel 支持
+###### spel 支持
当使用 Spring 集成 JDBC 适配器的存储过程组件时,现在可以通过使用 Spring 表达式语言提供存储过程名称或存储函数名称。
这样做可以让你指定要在运行时调用的存储过程。例如,你可以提供希望通过消息头执行的存储过程名。有关更多信息,请参见[存储过程](./jdbc.html#stored-procedures)。
-###### [](#jmx-support)JMX 支持
+###### JMX 支持
存储过程组件现在提供了基本的 JMX 支持,将它们的一些属性公开为 MBean:
@@ -1949,27 +1949,27 @@ Spring 集成现在使用 Spring AMQP1.1。这使得能够在 Spring 集成应
* `JdbcCallOperations`缓存统计
-##### [](#x2.2-jdbc-gateway-update-optional)JDBC 支持:出站网关
+##### JDBC 支持:出站网关
当你使用 JDBC 出站网关时,更新查询不再是强制性的。现在,你可以使用请求消息作为参数源,仅提供一个 SELECT 查询。
-##### [](#x2.2-jdbc-message-store-channels)JDBC 支持:通道特定的消息存储实现
+##### JDBC 支持:通道特定的消息存储实现
我们添加了一个新的消息通道特定的消息存储实现,使用数据库特定的 SQL 查询提供了一个更具可伸缩性的解决方案。有关更多信息,请参见[支持消息通道](./jdbc.html#jdbc-message-store-channels)。
-##### [](#x2.2-shutdown)有序关停
+##### 有序关停
我们在`IntegrationMBeanExporter`中添加了一个名为`stopActiveComponents()`的方法。 Spring 它允许以有序的方式关闭集成应用程序,不允许向某些适配器发送新的入站消息,并等待一段时间以允许飞行中的消息完成。
-##### [](#x2.2-jms-og)JMS 出站网关改进
+##### JMS 出站网关改进
现在,你可以将 JMS 出站网关配置为使用`MessageListener`容器来接收回复。这样做可以提高网关的性能。
-##### [](#x2.2-o-t-j-t)`ObjectToJsonTransformer`
+##### `ObjectToJsonTransformer`
默认情况下,`ObjectToJsonTransformer`现在将`content-type`头设置为`application/json`。有关更多信息,请参见[变压器](./transformer.html#transformer)。
-##### [](#httpChanges)http 支持
+##### http 支持
默认情况下,HTTP 上的 Java 序列化不再启用。以前,在`Serializable`对象上设置`expected-response-type`时,`Accept`头没有正确设置。我们更新了`SerializingHttpMessageConverter`,将`Accept`标头设置为`application/x-java-serialized-object`。但是,由于这可能会导致与现有应用程序不兼容,因此我们决定不再自动将此转换器添加到 HTTP 端点。
@@ -1977,15 +1977,15 @@ Spring 集成现在使用 Spring AMQP1.1。这使得能够在 Spring 集成应
或者,你也可以考虑使用 JSON。在 Classpath 上有`Jackson`使其成为可能。
-### [](#migration-2.0-2.1)2.0 和 2.1 之间的变化
+### 2.0 和 2.1 之间的变化
有关可能影响应用程序的重要更改,请参见[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-2.0-to-2.1-Migration-Guide)。
-#### [](#x2.1-new-components)新组件
+#### 新组件
版本 2.1 增加了一些新的组件。
-##### [](#x2.1-new-scripting-support)JSR-223 脚本支持
+##### JSR-223 脚本支持
在 Spring Integration2.0 中,我们添加了对[Groovy](https://groovy.codehaus.org/)的支持。在 Spring Integration2.1 中,我们通过实现对[JSR-223](https://www.jcp.org/en/jsr/detail?id=223)(“Java 平台的脚本”)的支持,在很大程度上扩展了对其他语言的支持。现在你可以使用任何支持 JSR-223 的脚本语言了,包括:
@@ -1999,37 +1999,37 @@ Spring 集成现在使用 Spring AMQP1.1。这使得能够在 Spring 集成应
详情见[脚本支持](./scripting.html#scripting)。
-##### [](#x2.1-new-gemfire-support)Gemfire 支援
+##### Gemfire 支援
Spring Integration 通过提供用于条目和连续查询事件的入站适配器、用于将条目写入缓存的出站适配器和[](https://DOCS. Spring.io/ Spring-Integration/api/org/SpringAgestore.html)和[](https://DOCS. Spring.io/ Spring-integration/api/api/groupIntegration/org/org/store.html)来提供对的支持。 Spring 集成利用了[Spring Gemfire](https://spring.io/projects/spring-data-gemfire)项目,在其组件上提供了一个薄的包装器。
详情见[Pivotal Gemfire 和 Apache Geode 支持](./gemfire.html#gemfire)。
-##### [](#x2.1-new-amqp-support)AMQP 支持
+##### AMQP 支持
Spring Integration2.1 添加了几个用于通过使用[高级消息队列协议](https://www.amqp.org/)接收和发送消息的通道适配器。 Spring 此外,集成还提供了点对点消息通道和发布-订阅消息通道,这两个通道都由 AMQP 交换和队列支持。
详情见[AMQP 支持](./amqp.html#amqp)。
-##### [](#x2.1-new-mongodb-support)MongoDB 支持
+##### MongoDB 支持
在版本 2.1 中, Spring 集成通过提供基于 MongoDB 的`MessageStore`,为[MongoDB](https://www.mongodb.org/)提供了支持。
详情见[MongoDB 支持](./mongodb.html#mongodb)。
-##### [](#x2.1-new-redis-support)Redis 支持
+##### Redis 支持
从版本 2.1 开始, Spring 集成通过提供基于 REDIS 的`MessageStore`以及发布-订阅消息适配器,支持[Redis](https://redis.io/),这是一种高级的键值存储。
详情见[Redis 支持](./redis.html#redis)。
-##### [](#x2.1-new-resource-support)对 Spring 资源抽象的支持
+##### 对 Spring 资源抽象的支持
在版本 2.1 中,我们引入了一个新的资源入站通道适配器,该适配器基于 Spring 的资源抽象,以支持跨各种实际类型的底层资源(例如文件、URL 或 Classpath 资源)的更大灵活性。因此,它与文件入站通道适配器类似,但更通用。
详情见[资源入站通道适配器](./resource.html#resource-inbound-channel-adapter)。
-##### [](#x2.1-new-stored-proc-support)存储过程组件
+##### 存储过程组件
借助 Spring Integration2.1,`JDBC`模块还通过添加几个新组件来提供存储过程支持,这些组件包括入站和出站通道适配器以及出站网关。存储过程支持利用 Spring 的[`SimpleJdbcCall`](https://DOCS. Spring.io/ Spring-framework/DOCS/current/javadoc-api/org/springframework/jdbc/core/simplejdbccall.html)类,因此支持以下存储过程:
@@ -2059,19 +2059,19 @@ Spring Integration2.1 添加了几个用于通过使用[高级消息队列协议
详情见[存储过程](./jdbc.html#stored-procedures)。
-##### [](#x2.1-new-xpath-filter-support)XPath 和 XML 验证过滤器
+##### XPath 和 XML 验证过滤器
Spring Integration2.1 提供了一种新的基于 XPath 的消息过滤器。它是`XML`模块的一部分。XPath 过滤器允许你通过使用 XPath 表达式来过滤消息。我们还为 XML 验证过滤器添加了文档。
有关更多详细信息,请参见[使用 XPath 过滤器](./xml.html#xml-xpath-filter)和[XML 验证过滤器](./xml.html#xml-validating-filter)。
-##### [](#x2.1-new-payload-enricher-support)有效载荷 Enricher
+##### 有效载荷 Enricher
自 Spring 集成 2.1 以来,我们添加了有效负载 Enricher。有效负载 Enricher 定义了一个端点,该端点通常将[`Message`](https://DOCS. Spring.io/ Spring-integration/api/org/springframework/integration/message.html)传递到公开的请求通道,然后期望得到一条回复消息。然后,回复消息将成为表达式求值的根对象,以丰富目标有效负载。
详情见[有效载荷 Enricher](./content-enrichment.html#payload-enricher)。
-##### [](#x2.1-new-ftp-outbound-gateway)FTP 和 SFTP 出站网关
+##### FTP 和 SFTP 出站网关
Spring Integration2.1 提供了两个新的出站网关,以与远程文件传输协议或 SFT 服务器进行交互。这两个网关允许你直接执行一组有限的远程命令。
@@ -2079,7 +2079,7 @@ Spring Integration2.1 提供了两个新的出站网关,以与远程文件传
详情见[FTP 出站网关](./ftp.html#ftp-outbound-gateway)和[SFTP 出站网关](./sftp.html#sftp-outbound-gateway)。
-##### [](#x2.1-new-ftp-session-caching)ftp会话缓存
+##### ftp会话缓存
从版本 2.1 开始,我们在会话远程文件适配器(例如,FTP、SFTP 和其他)的管理方面展示了更大的灵活性。
@@ -2087,11 +2087,11 @@ Spring Integration2.1 提供了两个新的出站网关,以与远程文件传
详情见[FTP Session Caching](./ftp.html#ftp-session-caching)和[SFTP Session Caching](./sftp.html#sftp-session-caching)。
-#### [](#x2.1-framework-refactorings)框架重构
+#### 框架重构
我们以多种方式重构了 Spring 集成框架,所有这些都在本节中进行了描述。
-##### [](#x2.1-router-standardization)标准化路由器配置
+##### 标准化路由器配置
我们使用 Spring Integration2.1 在所有路由器实现中标准化了路由器参数,以提供更一致的用户体验。
@@ -2106,7 +2106,7 @@ Spring Integration2.1 提供了两个新的出站网关,以与远程文件传
详情见`[Routers](./router.html#router)`。
-##### [](#x2.1-schema-updated)XML 模式更新到 2.1
+##### XML 模式更新到 2.1
Spring Integration2.1 附带了更新的 XML 模式(版本 2.1)。它提供了许多改进,例如路由器标准化[前面讨论过](#x2.1-router-standardization)。
@@ -2144,29 +2144,29 @@ Spring Integration2.1 附带了更新的 XML 模式(版本 2.1)。它提供
旧的 1.0 和 2.0 模式仍然存在。但是,如果应用程序上下文仍然引用那些不受欢迎的模式之一,则验证器在初始化时将失败。
-#### [](#x2.1-source-control-infrastructure)源控制管理和构建基础设施
+#### 源控制管理和构建基础设施
版本 2.1 引入了对源代码控制管理和构建基础架构的一些更改。这一节涵盖了这些变化。
-##### [](#x2.1-move-to-github)现在托管在 GitHub 上的源代码
+##### 现在托管在 GitHub 上的源代码
自版本 2.0 以来, Spring 集成项目使用[Git](https://git-scm.com/)进行版本控制。为了进一步提高社区可见性,该项目从 SpringSource 托管的 Git 存储库转移到[Github](https://www.github.com/)。 Spring 集成 Git 存储库位于:[spring-integration](https://github.com/spring-projects/spring-integration)。
对于该项目,我们还改进了提供代码贡献的过程。此外,我们确保每一项承诺都经过同行评审。实际上,核心提交者现在遵循与贡献者相同的过程。有关更多详细信息,请参见[贡献](https://github.com/spring-projects/spring-integration/blob/main/CONTRIBUTING.adoc)。
-##### [](#x2.1-sonar)改进了声纳的源代码可见性
+##### 改进了声纳的源代码可见性
为了提供更好的源代码可见性,从而监视 Spring Integration 的源代码的质量,我们设置了[Sonar](https://www.sonarqube.org/)的实例。我们每天晚上收集指标,并在[sonar.spring.io](https://sonar.spring.io/dashboard?id=org.springframework.integration%3Aspring-integration%3Amain)上提供这些指标。
-#### [](#x2.1-new-samples)新样本
+#### 新样本
对于 Spring 集成的 2.1 版本,我们还扩展了 Spring 集成示例项目,并添加了许多新的示例,例如涵盖 AMQP 支持的示例,一个示例展示了新的有效负载 Enricher,一个示例演示了用于测试 Spring 集成流片段的技术,以及针对 Oracle 数据库执行存储过程的示例。详情请访问[spring-integration-samples](https://github.com/spring-projects/spring-integration-samples)。
-### [](#migration-1.0-2.0)1.0 和 2.0 版本之间的变化
+### 1.0 和 2.0 版本之间的变化
有关可能影响应用程序的重要更改,请参见[迁移指南](https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-1.0-to-2.0-Migration-Guide)。
-#### [](#migration-spring-30-support) Spring 3 支持
+#### Spring 3 支持
Spring Integration2.0 是建立在 Spring 3.0.5 之上的,并使其许多功能可供我们的用户使用。
@@ -2174,98 +2174,98 @@ Spring Integration2.0 是建立在 Spring 3.0.5 之上的,并使其许多功
现在,你可以在 Spring Integration Core 命名空间的 Transformer、Router、Filter、Splitter、Aggregator、Service-Activator、Header-Enrich 和许多其他元素中以及在各种适配器中使用 SPEL 表达式。这本指南包括许多样本。
-##### [](#conversion-support)转换服务和转换器
+##### 转换服务和转换器
现在可以在配置许多 Spring 集成组件时受益于 Spring 提供的转换服务支持,例如[数据类型通道](https://www.enterpriseintegrationpatterns.com/DatatypeChannel.html)。见[消息通道实现](./channel.html#channel-implementations)和[服务激活器](./service-activator.html#service-activator)。同样,前面提到的 SPEL 支持也依赖于转换服务。因此,你可以注册转换器一次,并在任何使用 SPEL 表达式的地方利用它们。
-##### [](#task-scheduler-poller-support)`TaskScheduler`和`Trigger`
+##### `TaskScheduler`和`Trigger`
Spring 3.0 定义了两种与调度相关的新策略:`TaskScheduler`和`Trigger`。 Spring 集成(它使用大量的调度)现在建立在这些基础上。实际上, Spring Integration1.0 最初定义了一些组件(例如`CronTrigger`),这些组件现在已经迁移到 Spring 3.0 的核心 API 中。现在,你可以在整个应用程序上下文中重用相同的组件(而不仅仅是 Spring 集成配置)。通过提供用于直接配置速率、延迟、CRON 表达式和触发器引用的属性,我们还极大地简化了 Spring Integration Pollers 的配置。有关示例配置,请参见[通道适配器](./channel-adapter.html#channel-adapter)。
-##### [](#rest-support)`RestTemplate`和`HttpMessageConverter`
+##### `RestTemplate`和`HttpMessageConverter`
我们的出站 HTTP 适配器现在委托给 Spring 的`RestTemplate`以执行 HTTP 请求并处理其响应。这也意味着你可以重用任何自定义`HttpMessageConverter`实现。有关更多详细信息,请参见[HTTP 出站组件](./http.html#http-outbound)。
-#### [](#new-eip)Enterprise 集成模式添加
+#### Enterprise 集成模式添加
同样在 2.0 中,我们增加了对 Hohpe 和 Woolf 的[Enterprise 整合模式](https://www.enterpriseintegrationpatterns.com/)书中描述的更多模式的支持。
-##### [](#new-message-history)消息历史记录
+##### 消息历史记录
我们现在提供对[消息历史](https://www.enterpriseintegrationpatterns.com/MessageHistory.html)模式的支持,让你跟踪所有遍历的组件,包括每个通道和端点的名称以及遍历的时间戳。有关更多详细信息,请参见[消息历史](./message-history.html#message-history)。
-##### [](#new-message-store)消息存储
+##### 消息存储
我们现在为[消息存储](https://www.enterpriseintegrationpatterns.com/MessageStore.html)模式提供支持。消息存储提供了一种策略,用于代表其作用域超出单个事务的任何进程(例如聚合器和重排序程序)持久化消息。本指南的许多部分包括如何使用消息存储的示例,因为它会影响 Spring 集成的几个领域。更多详情请参见[消息存储](./message-store.html#message-store),[索赔检查](./claim-check.html#claim-check),[消息通道](./channel.html#channel),[Aggregator](./aggregator.html#aggregator),[JDBC 支持](./jdbc.html#jdbc)“,以及[重测序器](./resequencer.html#resequencer)。
-##### [](#new-claim-check)索赔检查
+##### 索赔检查
我们添加了[索赔检查](https://www.enterpriseintegrationpatterns.com/StoreInLibrary.html)模式的实现。索赔检查模式背后的想法是,你可以将消息有效载荷交换为“索赔票据”。这使你可以减少带宽,并避免跨通道发送消息时潜在的安全问题。有关更多详细信息,请参见[索赔检查](./claim-check.html#claim-check)。
-##### [](#new-control-bus)控制总线
+##### 控制总线
我们已经提供了[控制总线](https://www.enterpriseintegrationpatterns.com/ControlBus.html)模式的实现,它允许你使用消息传递来管理和监视端点和通道。这些实现包括基于 SPEL 的方法和运行 Groovy 脚本的方法。有关更多详细信息,请参见[控制总线](./control-bus.html#control-bus)和[控制总线](./groovy.html#groovy-control-bus)。
-#### [](#new-adapters)新通道适配器和网关
+#### 新通道适配器和网关
在 Spring Integration2.0 中,我们添加了几个新的通道适配器和消息传递网关。
-##### [](#new-ip)TCP 和 UDP 适配器
+##### TCP 和 UDP 适配器
我们添加了用于通过 TCP 和 UDP Internet 协议接收和发送消息的通道适配器。有关更多详细信息,请参见[TCP 和 UDP 支持](./ip.html#ip)。另见以下博客:[“Using UDP and TCP Adapters in Spring Integration 2.0 M3”](https://spring.io/blog/2010/03/29/using-udp-and-tcp-adapters-in-spring-integration-2-0-m3/)。
-##### [](#new-twitter)Twitter 适配器
+##### Twitter 适配器
Twitter 适配器支持发送和接收 Twitter 状态更新以及直接消息。你还可以使用入站通道适配器执行 Twitter 搜索。有关更多详细信息,请参见[Spring Integration Social Twitter](https://github.com/spring-projects/spring-integration-extensions/tree/main/spring-integration-social-twitter)。
-##### [](#new-xmpp)XMPP 适配器
+##### XMPP 适配器
新的 XMPP 适配器支持聊天消息和存在事件。有关更多详细信息,请参见[XMPP 支持](./xmpp.html#xmpp)。
-##### [](#new-ftp)FTP 和 FTPS 适配器
+##### FTP 和 FTPS 适配器
通过 FTP 和 FTPS 的入站和出站文件传输支持现在可用。有关更多详细信息,请参见[FTP/FTPS 适配器](./ftp.html#ftp)。
-##### [](#new-sftp)SFTP 适配器
+##### SFTP 适配器
通过 SFTP 的入站和出站文件传输支持现在可用。有关更多详细信息,请参见[SFTP 适配器](./sftp.html#sftp)。
-##### [](#new-feed)提要适配器
+##### 提要适配器
我们还添加了用于接收新闻提要的通道适配器(Atom 和 RSS)。有关更多详细信息,请参见[馈源适配器](./feed.html#feed)。
-#### [](#new-other)其他添加项
+#### 其他添加项
Spring 集成添加了许多其他功能。这一节对它们进行了描述。
-##### [](#new-groovy)Groovy 支持
+##### Groovy 支持
Spring Integration2.0 增加了 Groovy 支持,允许你使用 Groovy 脚本语言来提供集成和业务逻辑。有关更多详细信息,请参见[Groovy 支持](./groovy.html#groovy)。
-##### [](#new-map-transformer)地图变形金刚
+##### 地图变形金刚
这些对称的转换器将有效负载对象转换为`Map`对象。有关更多详细信息,请参见[变压器](./transformer.html#transformer)。
-##### [](#new-json-transformer)JSON 变形金刚
+##### JSON 变形金刚
这些对称的转换器将有效负载对象转换成 JSON 和 JSON。有关更多详细信息,请参见[变压器](./transformer.html#transformer)。
-##### [](#new-serialize-transformer)连载变形金刚
+##### 连载变形金刚
这些对称的转换器将有效负载对象与字节数组进行转换。它们还支持 Spring 3.0.5 添加的序列化器和反序列化器策略接口。有关更多详细信息,请参见[变压器](./transformer.html#transformer)。
-#### [](#new-refactoring)框架重构
+#### 框架重构
核心 API 进行了一些重要的重构,以使其更简单、更可用。尽管我们预计对开发人员的影响应该是最小的,但你应该通读本文档以找到更改的内容。具体地说,你应该阅读[动态路由器](./router.html#dynamic-routers),[消息传递网关](./gateway.html#gateway),[HTTP 出站组件](./http.html#http-outbound),[Message](./message.html#message),以及[Aggregator](./aggregator.html#aggregator)。如果直接依赖一些核心组件(`Message`、`MessageHeaders`、`MessageChannel`、`MessageBuilder`等),则需要更新任何导入语句。我们重组了一些打包,以提供扩展域模型所需的灵活性,同时避免任何周期性的依赖关系(这是框架的一项策略,以避免此类“混乱”)。
-#### [](#new-infrastructure)新的源代码控制管理和构建基础架构
+#### 新的源代码控制管理和构建基础架构
在 Spring Integration2.0 中,我们将构建环境转换为使用 Git 进行源代码控制。要访问我们的存储库,请访问[https://git.springsource.org/spring-integration](https://git.springsource.org/spring-integration)。我们还将构建系统切换到[Gradle](https://gradle.org/)。
-#### [](#new-samples)新 Spring 集成样本
+#### 新 Spring 集成样本
在 Spring Integration2.0 中,我们已经将样本与我们的主发布分布进行了解耦。请阅读以下博客获取更多信息:[New Spring Integration Samples](https://spring.io/blog/2010/09/29/new-spring-integration-samples/)。我们还创建了许多新的示例,包括每个新适配器的示例。
-#### [](#new-sts)用于 Spring 集成的工具套件可视化编辑器
+#### 用于 Spring 集成的工具套件可视化编辑器
在最新版本的 SpringSource 工具套件中包含一个用于 Spring 集成的令人惊讶的新可视化编辑器。如果你还没有使用 STS,你可以在[Spring Tool Suite](https://spring.io/tools/sts)下载它。
\ No newline at end of file
diff --git a/docs/spring-integration/http.md b/docs/spring-integration/http.md
index 0bf9f2ee51145a225233512aa25703cf3b287725..b1aec4d7096cd2d4c530d688dc0be1a379b2ece5 100644
--- a/docs/spring-integration/http.md
+++ b/docs/spring-integration/http.md
@@ -1,6 +1,6 @@
# HTTP 支持
-## [](#http)http 支持
+## http 支持
Spring 集成的 HTTP 支持允许运行 HTTP 请求和处理入站 HTTP 请求。HTTP 支持由以下网关实现组成:`HttpInboundEndpoint`和`HttpRequestExecutingMessageHandler`。另见[WebFlux 支持](./webflux.html#webflux)。
@@ -24,7 +24,7 @@ compile "org.springframework.integration:spring-integration-http:5.5.9"
必须在目标 Servlet 容器上提供`javax.servlet:javax.servlet-api`依赖项。
-### [](#http-inbound)HTTP 入站组件
+### HTTP 入站组件
要通过 HTTP 接收消息,需要使用 HTTP 入站通道适配器或 HTTP 入站网关。为了支持 HTTP 入站适配器,它们需要部署在 Servlet 容器中,例如[Apache Tomcat](https://tomcat.apache.org/)或[Jetty](https://www.eclipse.org/jetty/)。最简单的方法是使用 Spring 的[`HttpRequestHandlerServlet`](https://DOCS. Spring.io/ Spring/DOCS/current/javadoc-api/org/springframework/web/context/support/httprequesthandlerservlet.html),在`web.xml`文件中提供以下 Servlet 定义:
@@ -86,15 +86,15 @@ Spring 集成 2.0 实现了对多部分文件的支持。如果请求被包装
回复消息可在模型图中获得。默认情况下,该映射条目的键是“replyKey”,但是你可以通过在端点的配置上设置“replyKey”属性来覆盖此缺省项。
-#### [](#http-validation)有效载荷验证
+#### 有效载荷验证
从版本 5.2 开始,HTTP 入站端点可以提供`Validator`,以在发送到通道之前检查有效负载。这个有效负载已经是`payloadExpression`之后的转换和提取的结果,以缩小关于有价值数据的验证范围。验证失败处理与 Spring MVC[错误处理](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc-exceptionhandlers)中的处理完全相同。
-### [](#http-outbound)HTTP 出站组件
+### HTTP 出站组件
本节描述 Spring 集成的 HTTP 出站组件。
-#### [](#using-httprequestexecutingmessagehandler)使用`HttpRequestExecutingMessageHandler`
+#### 使用`HttpRequestExecutingMessageHandler`
要配置`HttpRequestExecutingMessageHandler`,请编写一个 Bean 定义,类似于以下内容:
@@ -123,7 +123,7 @@ Bean 这个定义通过将 HTTP 请求委托给`RestTemplate`来运行。然后
| |对于出站网关,网关产生的回复消息包含请求消息中存在的所有消息头。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#using-cookies)使用 cookies
+#### 使用 cookies
出站网关上的`transfer-cookies`属性提供了基本的 cookie 支持。当设置为`true`(默认值为`false`)时,从服务器接收到的响应中的`Set-Cookie`头将在回复消息中转换为`Cookie`。然后在后续的发送中使用这个头。这使得能够进行简单的有状态交互,例如:
@@ -139,7 +139,7 @@ Bean 这个定义通过将 HTTP 请求委托给`RestTemplate`来运行。然后
从版本 5.5 开始,`HttpRequestExecutingMessageHandler`公开了一个`extractResponseBody`标志(默认情况下是`true`),以仅返回响应主体,或返回整个`ResponseEntity`作为回复消息的有效负载,独立于所提供的`expectedResponseType`。如果`ResponseEntity`中不存在主体,则忽略此标志,并返回整个`ResponseEntity`。
-### [](#http-namespace)http 名称空间支持
+### http 名称空间支持
Spring 集成提供了`http`名称空间和相应的模式定义。要将其包含在配置中,请在应用程序上下文配置文件中提供以下名称空间声明:
@@ -160,7 +160,7 @@ Spring 集成提供了`http`名称空间和相应的模式定义。要将其包
```
-#### [](#inbound)入站
+#### 入站
XML 命名空间为处理 HTTP 入站请求提供了两个组件:`inbound-channel-adapter`和`inbound-gateway`。为了在不返回专用响应的情况下处理请求,请使用`inbound-channel-adapter`。下面的示例展示了如何配置一个:
@@ -177,7 +177,7 @@ XML 命名空间为处理 HTTP 入站请求提供了两个组件:`inbound-chan
reply-channel="responses"/>
```
-#### [](#http-request-mapping)请求映射支持
+#### 请求映射支持
| |Spring Integration3.0 通过引入[](https://DOCS. Spring.io/ Spring-Integration/API/org/SpringFramework/Integration/HTTP/Inbound/IntegrationRequestMappinghandlerMapping.html)改进了 REST 支持。实现依赖于 Spring Framework3.1 或更高版本提供的增强型 REST 支持。|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -243,7 +243,7 @@ HTTP 入站网关或 HTTP 入站通道适配器的解析注册了类型为[`inte
| |`IntegrationRequestMappingHandlerMapping`扩展了 Spring MVC`RequestMappingHandlerMapping`类,继承了它的大部分逻辑,尤其是`handleNoMatch(Set, String, HttpServletRequest)`,当映射由于某种原因不匹配时,它会为 HTTP 响应抛出一个特定的`4xx`错误,防止调用应用程序上下文中的任何剩余映射处理程序。
因此,为 Spring 集成和 Spring MVC 请求映射(例如,不支持`POST`in one 和`GET`in the other);将找不到 MVC 映射。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#http-cors)跨源资源共享支持
+#### 跨源资源共享支持
从版本 4.2 开始,你可以使用``元素配置``和``。它表示与 Spring MVC 的`@CrossOrigin`用于`@Controller`注释的选项相同的选项,并允许为 Spring 集成 HTTP 端点配置跨源资源共享:
@@ -261,7 +261,7 @@ HTTP 入站网关或 HTTP 入站通道适配器的解析注册了类型为[`inte
CORS Java 配置由`org.springframework.integration.http.inbound.CrossOrigin`类表示,其实例可以注入到`HttpRequestHandlingEndpointSupport`bean 中。
-#### [](#http-response-statuscode)响应状态代码
+#### 响应状态代码
从版本 4.1 开始,你可以将``配置为`status-code-expression`,以覆盖默认的`200 OK`状态。表达式必须返回一个可以转换为`org.springframework.http.HttpStatus`enum 值的对象。`evaluationContext`具有`BeanResolver`,并且从版本 5.1 开始,提供了作为根对象的`RequestEntity>`。一个例子可能是在运行时解析某个范围 Bean,该范围返回一个状态代码值。然而,最有可能的是,它被设置为固定值,如`status-code=expression="204"`(没有内容),或`status-code-expression="T(org.springframework.http.HttpStatus).NO_CONTENT"`。默认情况下,`status-code-expression`为 null,这意味着返回正常的’200OK’响应状态。使用`RequestEntity>`作为根对象,状态码可以是有条件的,例如在请求方法、一些头、URI 内容甚至请求体上。下面的示例展示了如何将状态代码设置为`ACCEPTED`:
@@ -340,7 +340,7 @@ Spring Integration3.0 之后,除了现有的`#pathVariables`和`#requestParams
requestAttributes.request.queryString"/>
```
-#### [](#outbound)出站
+#### 出站
要配置出站网关,你可以使用名称空间支持。以下代码片段显示了出站 HTTP 网关的可用配置选项:
@@ -398,7 +398,7 @@ Spring Integration3.0 之后,除了现有的`#pathVariables`和`#requestParams
| |要指定 URL,可以使用“url”属性或“url-expression”属性。
“url”属性接受一个简单的字符串(对于 URI 变量有占位符,如下所述)。
“url-expression”是一个 SPEL 表达式,以`Message`作为根对象,
表达式求值结果的 URL 仍然可以有 URI 变量的占位符。
在以前的版本中,一些用户使用占位符用 URI 变量替换整个 URL,
Spring 3.1 中的更改可能会导致转义字符的一些问题,例如“?”。
出于这个原因,我们建议,如果你希望在运行时完全生成 URL,那么可以使用“url-expression”属性。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#mapping-uri-variables)映射 URI 变量
+#### 映射 URI 变量
如果你的 URL 包含 URI 变量,那么你可以使用`uri-variable`元素来映射它们。此元素可用于 HTTP 出站网关和 HTTP 出站通道适配器。下面的示例将`zipCode`URI 变量映射到一个表达式:
@@ -486,7 +486,7 @@ List nameValuePairs =
.collect(Collectors.toList());
```
-#### [](#http-uri-encoding)控制 URI 编码
+#### 控制 URI 编码
默认情况下,URL 字符串在发送请求之前被编码(参见[`UriComponentsBuilder`](https://DOCS. Spring.io/ Spring/DOCS/current/javadoc-api/org/springframework/web/util/uricomponentsbuilder.html))到 URI 对象。在使用非标准 URI(例如 RabbitMQ REST API)的某些场景中,不希望执行编码。``和``提供了一个`encoding-mode`属性。要禁用对 URL 进行编码,请将此属性设置为`NONE`(默认情况下,它是`TEMPLATE_AND_VALUES`)。如果希望对某些 URL 进行部分编码,请在``中使用`expression`,如下例所示:
@@ -500,7 +500,7 @@ List nameValuePairs =
使用 Java DSL,这个选项可以由`BaseHttpMessageHandlerSpec.encodingMode()`选项控制。相同的配置适用于[WebFlux 模块](./webflux.html#webflux)和[Web 服务模块](./ws.html#ws)中的类似出站组件。对于非常复杂的场景,建议在外部提供的`RestTemplate`上配置`UriTemplateHandler`;或者在 WebFlux-`WebClient`的情况下配置`UriBuilderFactory`。
-### [](#http-java-config)用 Java 配置 HTTP 端点
+### 用 Java 配置 HTTP 端点
下面的示例展示了如何使用 Java 配置入站网关:
@@ -572,7 +572,7 @@ public IntegrationFlow outbound() {
}
```
-### [](#http-timeout)超时处理
+### 超时处理
在 HTTP 组件的上下文中,必须考虑两个计时区域:
@@ -633,7 +633,7 @@ public IntegrationFlow outbound() {
*发送超时*属性的值默认为“-1”,并将应用于连接的`MessageChannel`。这意味着,根据实现方式,消息通道的*发送*方法可能无限期地阻塞。此外,*发送超时*属性仅在实际的 MessageChannel 实现具有阻塞发送(例如’full’bounded queuechannel)时使用。
-#### [](#http-inbound-gateway)HTTP 入站网关
+#### HTTP 入站网关
对于 HTTP 入站网关,XML 模式定义了`request-timeout`属性,该属性用于在`HttpRequestHandlingMessagingGateway`类上(在扩展的`MessagingGatewaySupport`类上)设置`requestTimeout`属性。你还可以使用`reply-timeout`属性映射到同一个类上的`replyTimeout`属性。
@@ -642,11 +642,11 @@ public IntegrationFlow outbound() {
| |要模拟连接超时,可以连接到不可路由的 IP 地址,例如 10.255.255.10。|
|---|-----------------------------------------------------------------------------------------------------|
-### [](#http-proxy)HTTP 代理配置
+### HTTP 代理配置
如果你支持代理,并且需要为 HTTP 出站适配器或网关配置代理设置,那么可以应用以下两种方法中的一种。在大多数情况下,你可以依赖控制代理设置的标准 Java 系统属性。否则,你可以为 HTTP 客户机请求工厂实例显式配置一个 Spring Bean。
-#### [](#standard-java-proxy-configuration)标准 Java 代理配置
+#### 标准 Java 代理配置
你可以设置三个系统属性来配置 HTTP 协议处理程序使用的代理设置:
@@ -664,7 +664,7 @@ public IntegrationFlow outbound() {
有关更多信息,请参见[https://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html](https://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html)
-#### [](#springs-simpleclienthttprequestfactory) Spring 的`SimpleClientHttpRequestFactory`
+#### Spring 的`SimpleClientHttpRequestFactory`
如果需要对代理配置进行更明确的控制,可以使用 Spring 的`SimpleClientHttpRequestFactory`并配置其’代理’属性,如下例所示:
@@ -687,7 +687,7 @@ public IntegrationFlow outbound() {
```
-### [](#http-header-mapping)HTTP 标头映射
+### HTTP 标头映射
Spring 集成为 HTTP 请求和 HTTP 响应提供了对 HTTP 头映射的支持。
@@ -726,15 +726,15 @@ Spring 集成为 HTTP 请求和 HTTP 响应提供了对 HTTP 头映射的支持
如果你需要执行`DefaultHttpHeaderMapper`所支持的以外的操作,则可以直接实现`HeaderMapper`策略接口,并提供对你的实现的引用。
-### [](#int-graph-controller)积分图控制器
+### 积分图控制器
从版本 4.3 开始,HTTP 模块提供了`@EnableIntegrationGraphController`配置类注释和``XML 元素,以将`IntegrationGraphServer`作为 REST 服务公开。有关更多信息,请参见[积分图](./graph.html#integration-graph)。
-### [](#http-samples)http 样本
+### http 样本
本节用几个例子来概括我们对 Spring Integration 的 HTTP 支持的介绍。
-#### [](#multipart-rest-inbound)多部分 HTTP 请求—RESTTemplate(客户端)和 HTTP 入站网关(服务器)
+#### 多部分 HTTP 请求—RESTTemplate(客户端)和 HTTP 入站网关(服务器)
这个示例展示了用 Spring 的`RestTemplate`发送多部分 HTTP 请求并用 Spring 集成 HTTP 入站适配器接收它是多么简单。我们创建`MultiValueMap`并用多部分数据填充它。`RestTemplate`通过将其转换为`MultipartHttpServletRequest`来处理其余部分(没有双关语)。这个特定的客户机发送一个包含公司名称和一个图像文件(公司标识)的多部分 HTTP 请求。下面的清单展示了这个示例:
diff --git a/docs/spring-integration/ip.md b/docs/spring-integration/ip.md
index 7ce00392c7d9c9409aacc9ce207f7a140552cf74..14630d23e60eccacfa17e61eafb24b9fb8b679c8 100644
--- a/docs/spring-integration/ip.md
+++ b/docs/spring-integration/ip.md
@@ -1,6 +1,6 @@
# TCP 和 UDP 支持
-## [](#ip)TCP 和 UDP 支持
+## TCP 和 UDP 支持
Spring 集成提供了用于通过 Internet 协议接收和发送消息的通道适配器。同时提供了 UDP(用户数据报协议)和 TCP(传输控制协议)适配器。每个适配器都提供了通过底层协议进行单向通信的功能。此外, Spring 集成提供了简单的入站和出站 TCP 网关。当需要双向交流时,就会使用这些工具。
@@ -22,7 +22,7 @@ Gradle
compile "org.springframework.integration:spring-integration-ip:5.5.9"
```
-### [](#ip-intro)引言
+### 引言
UDP 入站和出站通道适配器各提供两种类型:
@@ -46,11 +46,11 @@ UDP 入站和出站通道适配器各提供两种类型:
TCP 和 UDP 入站通道适配器以及 TCP 入站网关支持`error-channel`属性。这提供了与[Enter the`GatewayProxyFactoryBean`](./gateway.html#gateway-proxy)中所描述的相同的基本功能。
-### [](#udp-adapters)UDP 适配器
+### UDP 适配器
本节介绍如何配置和使用 UDP 适配器。
-#### [](#outbound-udp-adapters-xml-configuration)出站 UDP 适配器(XML 配置)
+#### 出站 UDP 适配器(XML 配置)
以下示例配置了一个 UDP 出站通道适配器:
@@ -111,7 +111,7 @@ UDP 是一种高效但不可靠的协议。 Spring 集成添加了两个属性
从版本 4.3 开始,你可以将`ackPort`设置为`0`,在这种情况下,操作系统选择端口。
-#### [](#outbound-udp-adapters-java-configuration)出站 UDP 适配器(Java 配置)
+#### 出站 UDP 适配器(Java 配置)
下面的示例展示了如何使用 Java 配置出站 UDP 适配器:
@@ -125,7 +125,7 @@ public UnicastSendingMessageHandler handler() {
(或`MulticastSendingChannelAdapter`表示多播)。
-#### [](#outbound-udp-adapters-java-dsl-configuration)出站 UDP 适配器(Java DSL 配置)
+#### 出站 UDP 适配器(Java DSL 配置)
下面的示例展示了如何使用 Java DSL 配置出站 UDP 适配器:
@@ -138,7 +138,7 @@ public IntegrationFlow udpOutFlow() {
}
```
-#### [](#inbound-udp-adapters-xml-configuration)入站 UDP 适配器(XML 配置)
+#### 入站 UDP 适配器(XML 配置)
下面的示例展示了如何配置基本的单播入站 UDP 通道适配器。
@@ -168,7 +168,7 @@ public IntegrationFlow udpOutFlow() {
从版本 5.3.3 开始,你可以添加一个`SocketCustomizer` Bean 来修改创建后的`DatagramSocket`。它被称为接收套接字和为发送 ACK 而创建的任何套接字。
-#### [](#inbound-udp-adapters-java-configuration)入站 UDP 适配器(Java 配置)
+#### 入站 UDP 适配器(Java 配置)
下面的示例展示了如何使用 Java 配置入站 UDP 适配器:
@@ -183,7 +183,7 @@ public UnicastReceivingChannelAdapter udpIn() {
下面的示例展示了如何使用 Java DSL 配置入站 UDP 适配器:
-#### [](#inbound-udp-adapters-java-dsl-configuration)入站 UDP 适配器(Java DSL 配置)
+#### 入站 UDP 适配器(Java DSL 配置)
```
@Bean
@@ -194,11 +194,11 @@ public IntegrationFlow udpIn() {
}
```
-#### [](#server-listening-events)服务器监听事件
+#### 服务器监听事件
从版本 5.0.2 开始,当入站适配器启动并开始监听时,会发出`UdpServerListeningEvent`。当适配器被配置为侦听端口 0 时,这是有用的,这意味着操作系统选择端口。如果在启动将连接到套接字的其他进程之前需要等待,也可以使用它来代替轮询`isListening()`。
-#### [](#advanced-outbound-configuration)高级出站配置
+#### 高级出站配置
``(`UnicastSendingMessageHandler`)具有`destination-expression`和`socket-expression`选项。
@@ -235,9 +235,9 @@ public IntegrationFlow udpEchoUpcaseServer() {
}
```
-### [](#tcp-connection-factories)TCP 连接工厂
+### TCP 连接工厂
-#### [](#overview)概述
+#### 概述
对于 TCP,底层连接的配置是通过使用连接工厂提供的。提供了两种类型的连接工厂:客户端连接工厂和服务器连接工厂。客户端连接工厂建立传出连接。服务器连接工厂监听传入的连接。
@@ -300,7 +300,7 @@ Spring 集成提供了使用`java.net.Socket`和`java.nio.channel.SocketChannel`
另见[基于注释的配置](#ip-annotation)和[对 TCP 组件使用 Java DSL](#ip-dsl)。
-#### [](#tcp-codecs)消息划分(序列化器和反序列化器)
+#### 消息划分(序列化器和反序列化器)
TCP 是一种流协议。这意味着必须为通过 TCP 传输的数据提供某种结构,以便接收者可以将数据划分为离散的消息。连接工厂被配置为使用序列化器和反序列化器在消息有效负载和通过 TCP 发送的位之间进行转换。这是通过分别为入站消息和出站消息提供反序列化器和序列化器来实现的。 Spring 集成提供了许多标准序列化器和反序列化器。
@@ -365,7 +365,7 @@ TCP 是一种流协议。这意味着必须为通过 TCP 传输的数据提供
另见[基于注释的配置](#ip-annotation)和[对 TCP 组件使用 Java DSL](#ip-dsl)。
-#### [](#custom-serializers-and-deserializers)自定义序列化器和反序列化器
+#### 自定义序列化器和反序列化器
如果你的数据不是标准反序列化器之一支持的格式,那么你可以实现自己的;还可以实现自定义序列化器。
@@ -375,7 +375,7 @@ TCP 是一种流协议。这意味着必须为通过 TCP 传输的数据提供
从版本 5.2 开始,`SoftEndOfStreamException`现在是`RuntimeException`,而不是扩展`IOException`。
-#### [](#caching-cf)TCP 缓存客户端连接工厂
+#### TCP 缓存客户端连接工厂
由于[早些时候注意到](#ip-intro),TCP 套接字可以是“一次性”(一个请求或响应)或共享的。在大容量环境中,共享套接字在出站网关中的性能不佳,因为该套接字一次只能处理一个请求或响应。
@@ -383,7 +383,7 @@ TCP 是一种流协议。这意味着必须为通过 TCP 传输的数据提供
Spring Integration2.2 引入了一种缓存客户端连接工厂,它使用共享套接字池,让网关通过共享连接池处理多个并发请求。
-#### [](#failover-cf)TCP 故障转移客户端连接工厂
+#### TCP 故障转移客户端连接工厂
你可以配置一个 TCP 连接工厂,该工厂支持对一个或多个其他服务器的故障转移。在发送消息时,工厂会对其所有配置的工厂进行迭代,直到可以发送消息或找不到连接为止。最初,使用配置列表中的第一个工厂。如果连接随后失败,则下一个工厂将成为当前工厂。下面的示例展示了如何配置故障转移客户机连接工厂:
@@ -420,7 +420,7 @@ Spring Integration2.2 引入了一种缓存客户端连接工厂,它使用共
另见[测试连接](#testing-connections)。
-#### [](#tcp-affinity-cf)TCP 线程关联连接工厂
+#### TCP 线程关联连接工厂
Spring 集成版本 5.0 介绍了这种连接工厂。它将连接绑定到调用线程,并且每次线程发送消息时都会重用相同的连接。这将一直持续到连接被关闭(由服务器或网络关闭),或者直到线程调用`releaseConnection()`方法。连接本身由另一个客户端工厂实现提供,必须将其配置为提供非共享(一次性使用)连接,以便每个线程获得一个连接。
@@ -450,7 +450,7 @@ public TcpOutboundGateway outGate() {
}
```
-### [](#testing-connections)测试连接
+### 测试连接
在某些情况下,在连接首次打开时发送某种健康检查请求可能是有用的。一个这样的场景可能是当使用[TCP 故障转移客户端连接工厂](#failover-cf)时,如果所选的服务器允许打开连接但报告它不健康,那么我们可能会失败。
@@ -499,7 +499,7 @@ clientFactory.setConnectionTest(conn -> {
});
```
-### [](#ip-interceptors)TCP 连接拦截器
+### TCP 连接拦截器
你可以使用对`TcpConnectionInterceptorFactoryChain`的引用来配置连接工厂。你可以使用拦截器将行为添加到连接中,例如协商、安全性和其他选项。该框架目前没有提供拦截器,但参见[`InterceptedSharedConnectionTests`在源库中](https://github.com/ Spring-projects/ Spring-integration/blob/main/ Spring-integration-ip/SRC/test/java/org/springframework/integration/ip/tcp/tcp/interceptedsharedconnectiontests.java)中的一个示例。
@@ -540,7 +540,7 @@ clientFactory.setConnectionTest(conn -> {
interceptor-factory-chain="helloWorldInterceptorFactory"/>
```
-### [](#tcp-events)TCP 连接事件
+### TCP 连接事件
从版本 3.0 开始,对`TcpConnection`实例的更改由`TcpConnectionEvent`实例报告。`TcpConnectionEvent`是`ApplicationEvent`的一个子类,因此可以由`ApplicationListener`中定义的任何`ApplicationListener`接收——例如[事件入站通道适配器](./event.html#appevent-inbound)。
@@ -567,7 +567,7 @@ clientFactory.setConnectionTest(conn -> {
从版本 4.3.2 开始,每当无法创建客户端连接时,都会发出`TcpConnectionFailedEvent`。事件的源是连接工厂,你可以使用它来确定无法建立连接的主机和端口。
-### [](#tcp-adapters)TCP 适配器
+### TCP 适配器
提供了使用连接工厂[前面提到过](#tcp-events)的 TCP 入站和出站通道适配器。这些适配器有两个相关的属性:`connection-factory`和`channel`。`connection-factory`属性指示将使用哪个连接工厂来管理适配器的连接。`channel`属性指定消息到达出站适配器的通道,以及由入站适配器放置的消息的通道。虽然入站和出站适配器可以共享一个连接工厂,但服务器连接工厂总是由入站适配器“拥有”的。客户端连接工厂总是由出站适配器“拥有”的。每种类型中只有一个适配器可以获得对连接工厂的引用。下面的示例展示了如何定义客户机和服务器 TCP 连接工厂:
@@ -635,7 +635,7 @@ clientFactory.setConnectionTest(conn -> {
对于入站和出站,如果适配器已启动,则可以通过发送``命令:`@adapter_id.retryConnection()`来强制适配器建立连接。然后,你可以使用`@adapter_id.isClientModeConnected()`检查当前状态。
-### [](#tcp-gateways)TCP 网关
+### TCP 网关
入站 TCP 网关`TcpInboundGateway`和出站 TCP 网关`TcpOutboundGateway`分别使用服务器和客户端连接工厂。每个连接一次可以处理一个请求或响应。
@@ -689,11 +689,11 @@ remote-timeout-expression="headers['timeout']" -->
另见[基于注释的配置](#ip-annotation)和[对 TCP 组件使用 Java DSL](#ip-dsl)。
-### [](#ip-correlation)TCP 消息相关性
+### TCP 消息相关性
IP 端点的一个目标是提供与 Spring 集成应用程序以外的系统的通信。由于这个原因,默认情况下只发送和接收消息有效负载。自 3.0 以来,你可以通过使用 JSON、Java 序列化或自定义序列化器和反序列化器来传输头文件。有关更多信息,请参见[传输头](#ip-headers)。框架(除了使用网关时)或服务器端的协作通道适配器不提供消息相关性。[在本文的后面部分](#ip-collaborating-adapters),我们讨论了可用于应用程序的各种相关技术。在大多数情况下,这需要消息的特定应用程序级相关性,即使消息有效负载包含一些自然的相关性数据(例如订单号)。
-#### [](#ip-gateways)网关
+#### 网关
网关自动关联消息。但是,对于相对小容量的应用程序,应该使用出站网关。当你将连接工厂配置为对所有消息对使用单个共享连接时(“single-use=“false”"),一次只能处理一个消息。新消息必须等待,直到收到对上一条消息的答复。当连接工厂为每个新消息配置为使用一个新连接(“single-use=“true”")时,此限制不适用。虽然此设置可以提供比共享连接环境更高的吞吐量,但它会带来为每个消息对打开和关闭新连接的开销。
@@ -701,7 +701,7 @@ IP 端点的一个目标是提供与 Spring 集成应用程序以外的系统的
Spring Integration2.2 中介绍的另一种解决方案是使用`CachingClientConnectionFactory`,它允许使用共享连接池。
-#### [](#ip-collaborating-adapters)协作出站和入站通道适配器
+#### 协作出站和入站通道适配器
为了实现大容量的吞吐量(避免使用网关的陷阱,如[前面提到过](#ip-gateways)),你可以配置一对协作的出站和入站通道适配器。你还可以使用协作适配器(服务器端或客户端)进行完全异步通信(而不是使用请求-回复语义)。在服务器端,消息相关性由适配器自动处理,因为入站适配器添加了一个头,使出站适配器能够确定在发送回复消息时使用哪个连接。
@@ -723,7 +723,7 @@ Spring Integration2.2 中介绍的另一种解决方案是使用`CachingClientCo
从版本 5.4 开始,多个出站通道适配器和一个`TcpInboundChannelAdapter`可以共享相同的连接工厂。这允许应用程序同时支持请求/回复和任意服务器客户端消息传递。有关更多信息,请参见[TCP 网关](#tcp-gateways)。
-#### [](#ip-headers)传输头文件
+#### 传输头文件
TCP 是一种流协议。`Serializers`和`Deserializers`在流内划分消息。在 3.0 之前,只有消息有效负载(`String`或`byte[]`)可以通过 TCP 传输。从 3.0 开始,你可以传输选定的报头以及有效负载。但是,“live”对象,例如`replyChannel`头,不能序列化。
@@ -777,7 +777,7 @@ Spring 集成提供了一个`MapJsonSerializer`来将一个`Map`转换为和从
{"headers":{"correlationId":"things","sequenceSize":5,"sequenceNumber":1},"payload":"something"}
```
-### [](#note-nio)关于非阻塞 I/O(蔚来)
+### 关于非阻塞 I/O(蔚来)
使用蔚来(参见`using-nio`中的[IP 配置属性](#ip-endpoint-reference))可以避免指定从每个套接字读取的线程。对于少量的套接字,你可能会发现,不使用蔚来,再加上异步切换(例如到`QueueChannel`),其性能与使用蔚来相同或更好。
@@ -790,7 +790,7 @@ Spring 集成提供了一个`MapJsonSerializer`来将一个`Map`转换为和从
| |从版本 5.1.4 开始,优先考虑接受新的连接,而不是从现有的连接中读取,
通常,这应该没有什么影响,除非你有非常高的新进入连接的速率,
如果你希望恢复到以前的行为,给予读取优先权,将`TcpNioServerConnectionFactory`上的`multiAccept`属性设置为`false`。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#pool-size)池大小
+#### 池大小
不再使用池大小属性。以前,当未指定任务执行器时,它会指定默认线程池的大小。它还用于设置服务器套接字上的连接待办事项。第一个功能不再需要了(见下一段)。第二个函数被`backlog`属性代替。
@@ -799,7 +799,7 @@ Spring 集成提供了一个`MapJsonSerializer`来将一个`Map`转换为和从
| |既然默认的任务执行器是无界的,如果消息处理需要较长的时间,那么在传入消息的速率很高的情况下,可能会出现内存不足的情况,
如果你的应用程序表现出这种类型的行为,则应该使用池大小适当的池任务执行器,但见[下一节](#io-thread-pool-task-executor-caller-runs)。|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#io-thread-pool-task-executor-caller-runs)具有`CALLER_RUNS`策略的线程池任务执行器
+#### 具有`CALLER_RUNS`策略的线程池任务执行器
当使用带有`CallerRunsPolicy`(`CALLER_RUNS`使用``命名空间时)的固定线程池并且队列容量很小时,应该记住一些重要的考虑因素。
@@ -875,11 +875,11 @@ private CompositeExecutor compositeExecutor() {
```
-### [](#ssl-tls)SSL/TLS 支持
+### SSL/TLS 支持
支持安全套接字层/传输层安全。当使用蔚来时,JDK5+`SSLEngine`特性用于在建立连接后处理握手。当不使用蔚来时,使用标准`SSLSocketFactory`和`SSLServerSocketFactory`对象来创建连接。提供了许多策略接口,以允许进行重要的定制。这些接口的默认实现提供了开始安全通信的最简单方法。
-#### [](#ip-ssl-tls-getting-started)入门
+#### 入门
无论是否使用蔚来,都需要在连接工厂上配置`ssl-context-support`属性。此属性引用了一个 \定义,该定义描述了所需密钥存储的位置和密码。
@@ -926,7 +926,7 @@ SSL/TLS 对等点需要两个密钥存储区:
从版本 4.3.6 开始,当你使用蔚来时,你可以在连接工厂上指定`ssl-handshake-timeout`(以秒为单位)。在等待数据时,在 SSL 握手过程中使用此超时(默认为 30 秒)。如果超过了超时,进程将停止,套接字将关闭。
-#### [](#tcp-ssl-host-verification)主机验证
+#### 主机验证
从版本 5.0.8 开始,你可以配置是否启用主机验证。从版本 5.1 开始,它是默认启用的;禁用它的机制取决于你是否使用蔚来。
@@ -956,11 +956,11 @@ connectionFactory.setTcpSocketSupport(new DefaultTcpSocketSupport(false));
同样,构造函数参数禁用主机验证。
-### [](#tcp-advanced-techniques)先进技术
+### 先进技术
本节介绍了一些高级技术,你可能会发现这些技术在某些情况下会有所帮助。
-#### [](#strategy-interfaces)策略接口
+#### 策略接口
在许多情况下,前面描述的配置是支持 TCP/IP 上的安全通信所需的全部。 Spring 然而,集成提供了许多策略接口,以允许自定义和修改套接字工厂和套接字:
@@ -974,7 +974,7 @@ connectionFactory.setTcpSocketSupport(new DefaultTcpSocketSupport(false));
* `TcpNioConnectionSupport`
-##### [](#the-tcpsslcontextsupport-strategy-interface)the`TcpSSLContextSupport`策略界面
+##### the`TcpSSLContextSupport`策略界面
下面的清单显示了`TcpSSLContextSupport`策略接口:
@@ -988,7 +988,7 @@ public interface TcpSSLContextSupport {
`TcpSSLContextSupport`接口的实现负责创建`SSLContext`对象。该框架提供的实现方式是`DefaultTcpSSLContextSupport`,[前面描述的](#ip-ssl-tls-getting-started)。如果你需要不同的行为,实现这个接口,并向连接工厂提供对你的类实现的 Bean 的引用。
-##### [](#the-tcpsocketfactorysupport-strategy-interface)的`TcpSocketFactorySupport`策略界面
+##### 的`TcpSocketFactorySupport`策略界面
下面的清单显示了`TcpSocketFactorySupport`策略接口的定义:
@@ -1007,7 +1007,7 @@ public interface TcpSocketFactorySupport {
| |只有当`using-nio`是`false`时,此接口才适用。
蔚来不使用套接字工厂。|
|---|---------------------------------------------------------------------------------------------|
-##### [](#the-tcpsocketsupport-strategy-interface)的`TcpSocketSupport`策略界面
+##### 的`TcpSocketSupport`策略界面
下面的清单显示了`TcpSocketSupport`策略接口的定义:
@@ -1025,7 +1025,7 @@ public interface TcpSocketSupport {
要提供你自己的`TcpSocketFactorySupport`或`TcpSocketSupport`的实现,通过分别设置`socket-factory-support`和`socket-support`属性,向连接工厂提供对自定义类型的 bean 的引用。
-##### [](#the-tcpnetconnectionsupport-strategy-interface)的`TcpNetConnectionSupport`策略界面
+##### 的`TcpNetConnectionSupport`策略界面
下面的清单显示了`TcpNetConnectionSupport`策略接口的定义:
@@ -1070,7 +1070,7 @@ public class CompositeDeserializer implements Deserializer {
}
```
-##### [](#the-tcpnioconnectionsupport-strategy-interface)该`TcpNioConnectionSupport`策略接口
+##### 该`TcpNioConnectionSupport`策略接口
下面的清单显示了`TcpNioConnectionSupport`策略接口的定义:
@@ -1087,7 +1087,7 @@ public interface TcpNioConnectionSupport {
调用这个接口来创建`TcpNioConnection`对象(或来自子类的对象)。 Spring 集成提供了两种实现方式:`DefaultTcpNioSSLConnectionSupport`和`DefaultTcpNioConnectionSupport`。使用哪一种取决于是否使用 SSL。一个常见的用例是子类`DefaultTcpNioSSLConnectionSupport`并覆盖`postProcessSSLEngine`。参见[SSL 客户端身份验证示例](#ssl-client-authentication-example)。与`DefaultTcpNetConnectionSupport`一样,这些实现也支持后推。
-#### [](#ssl-client-authentication-example)示例:启用 SSL 客户机身份验证
+#### 示例:启用 SSL 客户机身份验证
要在使用 SSL 时启用客户端证书身份验证,该技术取决于是否使用蔚来。当你不蔚来时,请提供一个自定义`TcpSocketSupport`实现来对服务器套接字进行后处理:
@@ -1129,7 +1129,7 @@ public TcpNioServerConnectionFactory server() {
(当你使用 XML 配置时,从版本 4.3.7 开始,通过设置`nio-connection-support`属性来提供对 Bean 的引用)。
-### [](#ip-endpoint-reference)IP 配置属性
+### IP 配置属性
下表描述了可以设置以配置 IP 连接的属性:
@@ -1251,7 +1251,7 @@ public TcpNioServerConnectionFactory server() {
| `async` | |在发送后释放发送线程;回复(或错误)将在接收线程上发送。|
|`unsolicited``MessageChannel`| |向其发送未经请求的消息和延迟回复的通道。|
-### [](#ip-msg-headers)IP 消息头
+### IP 消息头
IP 消息头
@@ -1276,7 +1276,7 @@ IP 消息头
在定制 Mapper 属性或子类时,将 Mapper 声明为 Bean,并使用`mapper`属性向连接工厂提供一个实例。
-### [](#ip-annotation)基于注释的配置
+### 基于注释的配置
下面示例存储库中的示例显示了使用注释而不是 XML 时可用的一些配置选项:
@@ -1361,7 +1361,7 @@ public static class Config {
|**7**|客户端连接工厂。|
|**8**|服务器端连接工厂。|
-### [](#ip-dsl)对 TCP 组件使用 Java DSL
+### 对 TCP 组件使用 Java DSL
对 TCP 组件的 DSL 支持包括适配器和网关的规范,带有工厂方法的`Tcp`类来创建连接工厂 bean,以及带有工厂方法的`TcpCodecs`类来创建序列化器和反序列化器。有关更多信息,请参考他们的 Javadocs。
diff --git a/docs/spring-integration/jdbc.md b/docs/spring-integration/jdbc.md
index 0748b0406b5e9deb936616a8a428ec8b8a61a5fa..b1ed8fc5123c1bcd340a1efd9fd67d166f658929 100644
--- a/docs/spring-integration/jdbc.md
+++ b/docs/spring-integration/jdbc.md
@@ -1,6 +1,6 @@
# JDBC 支持
-## [](#jdbc)JDBC 支持
+## JDBC 支持
Spring 集成提供了用于通过使用数据库查询来接收和发送消息的通道适配器。通过这些适配器, Spring 集成不仅支持普通的 JDBC SQL 查询,还支持存储过程和存储函数调用。
@@ -38,7 +38,7 @@ compile "org.springframework.integration:spring-integration-jdbc:5.5.9"
Spring 集成 JDBC 模块还提供了[JDBC 消息存储](#jdbc-message-store)。
-### [](#jdbc-inbound-channel-adapter)入站通道适配器
+### 入站通道适配器
入站通道适配器的主要功能是执行 SQL`SELECT`查询,并将结果集转换为消息。消息负载是整个结果集(表示为`List`),列表中项的类型取决于行映射策略。默认策略是泛型映射器,它为查询结果中的每一行返回`Map`。你可以通过添加对`RowMapper`实例的引用来改变这一点(有关行映射的更多详细信息,请参见[Spring JDBC](https://docs.spring.io/spring/docs/current/spring-framework-reference/html/jdbc.html)文档)。
@@ -113,7 +113,7 @@ Spring 集成 JDBC 模块还提供了[JDBC 消息存储](#jdbc-message-store)。
| |使用`createParameterSourceNoCache`工厂方法。
否则,参数源将缓存求值的结果。
还请注意,由于缓存是禁用的,如果相同的参数名多次出现在 SELECT 查询中,则会对每次出现的结果进行重新求值。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#jdbc-polling-transactions)轮询和事务
+#### 轮询和事务
入站适配器接受一个常规的 Spring 集成 Poller 作为一个子元素。因此,可以控制轮询的频率(除其他用途外)。用于 JDBC 使用的 Poller 的一个重要特性是在事务中包装 poll 操作的选项,如下例所示:
@@ -131,7 +131,7 @@ Spring 集成 JDBC 模块还提供了[JDBC 消息存储](#jdbc-message-store)。
在前面的示例中,数据库每 1000 毫秒(或每秒一次)进行一次轮询,并且 Update 和 SELECT 查询都在同一个事务中执行。未显示事务管理器配置。然而,只要它知道数据源,轮询就是事务性的。一个常见的用例是,下游通道是直接通道(默认),这样,在相同的线程中调用端点,从而调用相同的事务。这样,如果它们中的任何一个失败了,事务就会回滚,输入数据就会恢复到原来的状态。
-#### [](#jdbc-max-rows-versus-max-messages-per-poll)`max-rows`vs`max-messages-per-poll`
+#### `max-rows`vs`max-messages-per-poll`
JDBC 入站通道适配器定义了一个名为`max-rows`的属性。在指定适配器的 Poller 时,还可以定义一个名为`max-messages-per-poll`的属性。虽然这两个属性看起来很相似,但它们的含义却大不相同。
@@ -146,7 +146,7 @@ JDBC 入站通道适配器定义了一个名为`max-rows`的属性。在指定
| |建议通过特定于供应商的查询选项使用结果集限制,例如 MySQL或 SQL Server或 甲骨文 的。有关更多信息,请参见特定供应商的文档。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#jdbc-outbound-channel-adapter)出站通道适配器
+### 出站通道适配器
出站通道适配器是入站的反面:它的作用是处理消息并使用它执行 SQL 查询。默认情况下,消息有效负载和消息头可作为查询的输入参数,如下例所示:
@@ -166,7 +166,7 @@ JDBC 入站通道适配器定义了一个名为`max-rows`的属性。在指定
如果输入通道是直接通道,则出站适配器将在相同的线程中运行其查询,因此,与消息的发送者运行相同的事务(如果有的话)。
-#### [](#passing-parameters-by-using-spel-expressions)使用 spel 表达式传递参数
+#### 使用 spel 表达式传递参数
大多数 JDBC 通道适配器的一个常见需求是将参数作为 SQL 查询或存储过程或函数的一部分进行传递。如前所述,这些参数在默认情况下是 Bean 属性表达式,而不是 SPEL 表达式。但是,如果需要将 SPEL 表达式作为参数传递,则必须显式地注入`SqlParameterSourceFactory`。
@@ -192,7 +192,7 @@ JDBC 入站通道适配器定义了一个名为`max-rows`的属性。在指定
有关更多信息,请参见[定义参数源](#sp-defining-parameter-sources)。
-#### [](#using-the-preparedstatement-callback)使用`PreparedStatement`回调
+#### 使用`PreparedStatement`回调
有时,`SqlParameterSourceFactory`的灵活性和松耦合并不能满足我们对目标`PreparedStatement`的需求,或者我们需要做一些低级别的 JDBC 工作。 Spring JDBC 模块提供 API 来配置执行环境(例如`ConnectionCallback`或`PreparedStatementCreator`)和操作参数值(例如`SqlParameterSource`)。它甚至可以访问用于低级操作的 API,例如`StatementCallback`。
@@ -222,11 +222,11 @@ public MessageHandler jdbcMessageHandler(DataSource dataSource) {
从 XML 配置的角度来看,`prepared-statement-setter`属性在``组件上可用。它允许你指定`MessagePreparedStatementSetter` Bean 引用。
-#### [](#batch-update)批量更新
+#### 批量更新
从版本 5.1 开始,如果请求消息的有效负载是`Iterable`实例,则`JdbcOperations.batchUpdate()`执行`JdbcOperations.batchUpdate()`。`Iterable`的每个元素都被包装到`Message`,并带有来自请求消息的标题。在基于常规`SqlParameterSourceFactory`的配置的情况下,这些消息用于为上述`JdbcOperations.batchUpdate()`函数中使用的参数构建`SqlParameterSource[]`。当应用`MessagePreparedStatementSetter`配置时,将使用`BatchPreparedStatementSetter`变量对每个项的这些消息进行迭代,并针对它们调用所提供的`MessagePreparedStatementSetter`。选择`keysGenerated`模式时,不支持批处理更新。
-### [](#jdbc-outbound-gateway)出站网关
+### 出站网关
出站网关类似于出站适配器和入站适配器的组合:它的作用是处理消息,并使用它执行 SQL 查询,然后通过将结果发送到应答通道来进行响应。默认情况下,消息有效负载和消息头可作为查询的输入参数,如下例所示:
@@ -277,7 +277,7 @@ public MessageHandler jdbcMessageHandler(DataSource dataSource) {
有关`MessagePreparedStatementSetter`的更多信息,请参见[出站通道适配器](#jdbc-outbound-channel-adapter)。
-### [](#jdbc-message-store)JDBC 消息存储
+### JDBC 消息存储
Spring 集成提供了两个 JDBC 特定的消息存储实现。`JdbcMessageStore`适合用于聚合器和索赔检查模式。`JdbcChannelMessageStore`实现为消息通道提供了更有针对性和可伸缩的实现。
@@ -289,13 +289,13 @@ Spring 集成提供了两个 JDBC 特定的消息存储实现。`JdbcMessageStor
| |当使用`甲骨文ChannelMessageStoreQueryProvider`时,将添加优先通道索引**必须**,因为它包含在查询中的一个提示中。|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#initializing-the-database)初始化数据库
+#### 初始化数据库
在开始使用 JDBC 消息存储组件之前,你应该为目标数据库提供适当的对象。
Spring 集成附带一些示例脚本,这些脚本可用于初始化数据库。在`spring-integration-jdbc`JAR 文件中,你可以在`org.springframework.integration.jdbc`包中找到脚本。它为一系列公共数据库平台提供了一个示例 CREATE 和一个示例 DROP 脚本。使用这些脚本的一种常见方法是在[Spring JDBC data source initializer](https://docs.spring.io/spring/docs/current/spring-framework-reference/html/jdbc.html#jdbc-intializing-datasource)中引用它们。请注意,这些脚本是作为示例以及所需的表和列名的规范提供的。你可能会发现需要为生产使用而增强它们(例如,通过添加索引声明)。
-#### [](#jdbc-message-store-generic)通用 JDBC 消息存储
+#### 通用 JDBC 消息存储
JDBC 模块提供了由数据库支持的 Spring 集成`MessageStore`(在 ClaimCheck 模式中很重要)和`MessageGroupStore`(在有状态模式中很重要,例如聚合器)的实现。这两个接口都是由`JdbcMessageStore`实现的,并且支持在 XML 中配置存储实例,如下例所示:
@@ -314,11 +314,11 @@ JDBC 模块提供了由数据库支持的 Spring 集成`MessageStore`(在 Clai
在前面的示例中,我们指定了一个`LobHandler`,用于将消息作为大型对象处理(对于 甲骨文 来说,这通常是必需的),并为存储生成的查询中的表名指定了一个前缀。表名前缀默认为`INT_`。
-#### [](#jdbc-message-store-channels)后台消息通道
+#### 后台消息通道
如果你打算用 JDBC 支持消息通道,我们建议使用`JdbcChannelMessageStore`实现。它只与消息通道一起工作。
-##### [](#supported-databases)支持的数据库
+##### 支持的数据库
`JdbcChannelMessageStore`使用特定于数据库的 SQL 查询来从数据库检索消息。因此,你必须在`JdbcChannelMessageStore`上设置`ChannelMessageStoreQueryProvider`属性。这个`channelMessageStoreQueryProvider`为你指定的特定数据库提供 SQL 查询。 Spring 集成为以下关系数据库提供了支持:
@@ -344,7 +344,7 @@ JDBC 模块提供了由数据库支持的 Spring 集成`MessageStore`(在 Clai
4.0 版本在表中添加了`MESSAGE_SEQUENCE`列,以确保即使消息存储在相同的毫秒内也能进行先进先出排队。
-##### [](#custom-message-insertion)自定义消息插入
+##### 自定义消息插入
从版本 5.0 开始,通过重载`ChannelMessageStorePreparedStatementSetter`类,可以为`JdbcChannelMessageStore`中的消息插入提供自定义实现。你可以使用它来设置不同的列,或者改变表结构或序列化策略。例如,你可以将它的结构存储为 JSON 字符串,而不是默认的序列化`byte[]`。
@@ -367,14 +367,14 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
| |通常,我们不建议使用关系数据库进行排队。
相反,如果可能的话,可以考虑使用 JMS-或 AMQP 支持的通道代替。
有关更多参考,请参见以下参考资料:
。
*[作为队列反模式的数据库](https://mikehadlow.blogspot.com/2012/04/database-as-queue-anti-pattern.html)。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#concurrent-polling)并发轮询
+##### 并发轮询
在轮询消息通道时,你可以选择将关联的`Poller`配置为`TaskExecutor`引用。
| |不过,请记住,如果你使用 JDBC 支持的消息通道,并且你计划轮询该通道,并因此轮询多线程的消息存储,那么你应该确保使用支持[多版本并发控制](https://en.wikipedia.org/wiki/Multiversion_concurrency_control)的关系数据库。,否则,
,锁定可能是一个问题,并且在使用多个线程时,性能可能不会像预期的那样实现。
例如,阿帕奇德比 在这方面是有问题的。
为了实现更好的 JDBC 队列吞吐量,并避免在不同线程可能从队列轮询相同的`Message`时出现问题,使用不支持 MVCC 的数据库时,将**重要的**的`usingIdCache`属性设置为`true`。
下面的示例演示了如何这样做:
```
class="o.s.i.jdbc.store.channel.PostgresChannelMessageStoreQueryProvider"/>
queue-capacity="10" rejection-policy="CALLER_RUNS" />
max-messages-per-poll="1" task-executor="pool">
isolation="READ_COMMITTED" transaction-manager="transactionManager" />
```|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#priority-channel)优先通道
+##### 优先通道
从版本 4.0 开始,`JdbcChannelMessageStore`实现了`PriorityCapableChannelMessageStore`,并提供了`priorityEnabled`选项,让它用作`message-store`实例的引用。为此,`INT_CHANNEL_MESSAGE`表有一个`MESSAGE_PRIORITY`列来存储`PRIORITY`消息头的值。此外,一个新的`MESSAGE_SEQUENCE`列使我们能够实现一种健壮的先进先出轮询机制,即使多个消息以相同的优先级存储在相同的毫秒中。用`order by MESSAGE_PRIORITY DESC NULLS LAST, CREATED_DATE, MESSAGE_SEQUENCE`对数据库中的消息进行轮询(选中)。
@@ -400,11 +400,11 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
```
-#### [](#partitioning-a-message-store)对消息存储进行分区
+#### 对消息存储进行分区
通常使用`JdbcMessageStore`作为同一应用程序中的一组应用程序或节点的全局存储。为了提供一些防止名称冲突的保护,并控制数据库元数据配置,消息存储允许以两种方式对表进行分区。一种方法是使用单独的表名,通过更改前缀(as[前面描述的](#jdbc-message-store-generic))。另一种方法是为单个表中的数据分区指定`region`名称。第二种方法的一个重要用例是当`MessageStore`管理支持 Spring 集成消息通道的持久性队列时。持久通道的消息数据在通道名称的存储中进行键控。因此,如果通道名称不是全局唯一的,则通道可以接收不适合它们的数据。为了避免这种危险,你可以使用消息存储`region`将具有相同逻辑名称的不同物理通道的数据分开。
-### [](#stored-procedures)存储过程
+### 存储过程
在某些情况下,仅仅支持 JDBC 是不够的。也许你需要处理遗留的关系数据库模式,或者你有复杂的数据处理需求,但是,最终,你必须使用[存储过程](https://en.wikipedia.org/wiki/Stored_procedure)或存储函数。 Spring 自集成 2.1 以来,我们提供了三个组件来执行存储过程或存储函数:
@@ -414,7 +414,7 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
* 存储过程出站网关
-#### [](#sp-supported-databases)支持的数据库
+#### 支持的数据库
为了启用对存储过程和存储函数的调用,存储过程组件使用[`org.springframework.jdbc.core.simple.SimpleJdbcCall`](https://DOCS. Spring.io/ Spring/DOCS/current/javadoc-api/org/springframework/jdbc/core/simplejdbccall.html)类。因此,完全支持以下数据库来执行存储过程:
@@ -445,11 +445,11 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
| |即使你的特定数据库可能没有得到完全支持,但只要你的 RDBMS 支持存储过程或存储函数,你仍然可以非常成功地使用存储过程 Spring 集成组件,事实上,
,提供的一些集成测试使用[H2 数据库](https://www.h2database.com/)。
尽管如此,彻底测试这些使用场景是非常重要的。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#sp-configuration)配置
+#### 配置
存储过程组件提供了完整的 XML 命名空间支持,并且配置这些组件与前面讨论的通用 JDBC 组件类似。
-#### [](#sp-common-config-params)公共配置属性
+#### 公共配置属性
所有存储过程组件共享某些配置参数:
@@ -490,7 +490,7 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
但是,如果传递了过程参数,则此属性(默认情况下)计算为`false`。`ProcedureParameter`将提供 SPEL 表达式。因此,具有对整个`Message`的访问是非常有益的。该属性设置在底层`StoredProcExecutor`上。可选的。
-#### [](#sp-common-config-subelements)公共配置子元素
+#### 公共配置子元素
存储过程组件共享一组公共的子元素,你可以使用这些子元素定义参数并将参数传递给存储过程或存储函数。以下要素是可用的:
@@ -547,7 +547,7 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
* `poller`:如果这个端点是`PollingConsumer`,则允许你配置消息 poller。可选的。
-#### [](#sp-defining-parameter-sources)定义参数源
+#### 定义参数源
参数源控制检索 Spring 集成消息属性并将其映射到相关的存储过程输入参数的技术。
@@ -570,7 +570,7 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
如果你需要更多地控制参数的检索方式,可以考虑使用`sql-parameter-source-factory`属性来传入`SqlParameterSourceFactory`的自定义实现。
-#### [](#stored-procedure-inbound-channel-adapter)存储过程入站通道适配器
+#### 存储过程入站通道适配器
下面的清单调用了对存储过程入站通道适配器很重要的属性:
@@ -600,7 +600,7 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
|**2**|如果将此属性设置为`true`,那么存储过程调用的所有结果,如果没有相应的`SqlOutParameter`声明,都将被忽略,
例如,存储过程可以返回更新计数值,即使你的存储过程只声明了一个结果参数。
确切的行为取决于数据库实现。
该值设置在底层`JdbcTemplate`上。
值默认为`true`。
可选的。|
|**3**|指示是否应包括此过程的返回值。
自 Spring 积分 3.0 起。
可选。|
-#### [](#stored-procedure-outbound-channel-adapter)存储过程出站通道适配器
+#### 存储过程出站通道适配器
下面的清单调用了对存储过程出站通道适配器很重要的属性:
@@ -625,7 +625,7 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
|-----|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|**2**|指定当此端点作为订阅服务器连接到某个通道时的调用顺序。
当该通道使用`failover`调度策略时,这一点尤其相关。
当该端点本身是具有队列的通道的轮询消费者时,它没有任何作用。
可选的。|
-#### [](#stored-procedure-outbound-gateway)存储过程出站网关
+#### 存储过程出站网关
下面的清单调用了对存储过程出站通道适配器很重要的属性:
@@ -660,7 +660,7 @@ public class JsonPreparedStatementSetter extends ChannelMessageStorePreparedStat
|**4**|指示是否应包含此过程的返回值。
可选的。|
|**5**|如果`skip-undeclared-results`属性被设置为`true`,那么来自存储过程调用的所有没有相应的`SqlOutParameter`声明的结果都将被忽略,
例如,存储过程可能返回一个更新计数值,即使你的存储过程只声明了一个结果参数。
确切的行为取决于数据库。
该值设置在底层`JdbcTemplate`上。
值默认为`true`。
可选的。|
-#### [](#sp-examples)示例
+#### 示例
本节包含两个调用[阿帕奇德比](https://db.apache.org/derby/)存储过程的示例。第一个过程调用返回`ResultSet`的存储过程。通过使用`RowMapper`,数据被转换成域对象,然后该域对象成为 Spring 集成消息有效负载。
@@ -731,7 +731,7 @@ PARAMETER STYLE JAVA LANGUAGE JAVA EXTERNAL NAME \
```
-### [](#jdbc-lock-registry)JDBC 锁定注册表
+### JDBC 锁定注册表
4.3 版引入了`JdbcLockRegistry`。某些组件(例如,聚合器和重排序程序)使用从`LockRegistry`实例获得的锁来确保一次只有一个线程操作组。`DefaultLockRegistry`在单个组件中执行此功能。现在,你可以在这些组件上配置一个外部锁注册中心。当与共享的`MessageGroupStore`一起使用时,你可以使用`JdbcLockRegistry`来跨多个应用程序实例提供此功能,使得一次只有一个实例可以操作组。
@@ -762,7 +762,7 @@ CREATE TABLE INT_LOCK (
使用 5.5.6 版本的字符串,`JdbcLockRegistry`支持通过`JdbcLockRegistry.setCacheCapacity()`自动清理`JdbcLockRegistry.locks`中的 JDBClock 的缓存。有关更多信息,请参见其 Javadocs。
-### [](#jdbc-metadata-store)JDBC 元数据存储
+### JDBC 元数据存储
5.0 版本引入了 JDBC`MetadataStore`(参见[元数据存储](./meta-data-store.html#metadata-store))实现。你可以使用`JdbcMetadataStore`在应用程序重启期间维护元数据状态。此`MetadataStore`实现可与以下适配器一起使用:
diff --git a/docs/spring-integration/jms.md b/docs/spring-integration/jms.md
index 9d493eefaf95d8c500a38476662476d088398c7c..e86c6493e7b5db81206baf29d11fd2a609b0fe0a 100644
--- a/docs/spring-integration/jms.md
+++ b/docs/spring-integration/jms.md
@@ -1,6 +1,6 @@
# JMS 支持
-## [](#jms)JMS 支持
+## JMS 支持
Spring 集成提供了用于接收和发送 JMS 消息的通道适配器。
@@ -32,7 +32,7 @@ Spring 尽管 JMS 通道适配器旨在用于单向消息传递(仅发送或
在 Spring Integration2.2 之前,如果有必要,将为每个请求或回复创建(并删除)一个`TemporaryQueue`。从 Spring Integration2.2 开始,你可以将出站网关配置为使用`MessageListener`容器来接收回复,而不是直接使用新的(或缓存的)`Consumer`来接收每个请求的回复。在这样配置且未提供明确的应答目的地时,每个网关使用一个`TemporaryQueue`,而不是每个请求使用一个。
-### [](#jms-inbound-channel-adapter)入站通道适配器
+### 入站通道适配器
入站通道适配器需要对单个`JmsTemplate`实例的引用,或者对`ConnectionFactory`和`Destination`的引用(你可以提供一个“destinationName”来代替“destination”引用)。下面的示例定义了一个具有`Destination`引用的入站通道适配器:
@@ -99,7 +99,7 @@ Jms.inboundAdapter(connectionFactory)
.configureJmsTemplate(template -> template.receiveTimeout(-1))
```
-#### [](#jms-ib-transactions)事务
+#### 事务
从版本 4.0 开始,入站通道适配器支持`session-transacted`属性。在较早的版本中,你必须插入一个`JmsTemplate`,并将`sessionTransacted`设置为`true`。(适配器确实允许你将`acknowledge`属性设置为`transacted`,但这是不正确的,并且不工作)。
@@ -107,7 +107,7 @@ Jms.inboundAdapter(connectionFactory)
如果你希望整个流是事务性的(例如,如果有一个下游出站通道适配器),则必须使用`transactional`poller 和`JmsTransactionManager`。或者,考虑使用`jms-message-driven-channel-adapter`并将`acknowledge`设置为`transacted`(默认值)。
-### [](#jms-message-driven-channel-adapter)消息驱动通道适配器
+### 消息驱动通道适配器
`message-driven-channel-adapter`要求引用 Spring `MessageListener`容器的实例(`AbstractMessageListenerContainer`的任意子类),或者同时引用`ConnectionFactory`和`Destination`(可以提供一个“destinationName”来代替“destination”引用)。下面的示例用`Destination`引用定义了消息驱动的通道适配器:
@@ -191,11 +191,11 @@ XML
从版本 5.1 开始,当端点在应用程序保持运行时停止时,底层侦听器容器将被关闭,从而关闭其共享连接和消费者。以前,连接和消费者保持开放。要恢复到以前的行为,请将`JmsMessageDrivenEndpoint`上的`shutdownContainerOnStop`设置为`false`。
-#### [](#jms-md-conversion-errors)入站转换错误
+#### 入站转换错误
从版本 4.2 开始,“错误通道”也用于转换错误。在此之前,如果 JMS``或``由于转换错误而无法发送消息,则会将异常抛回容器。如果容器被配置为使用事务,则消息将被回滚并反复重新交付。转换过程发生在消息构造之前和期间,以便不会将此类错误发送到“错误通道”。现在,这样的转换异常会导致`ErrorMessage`被发送到“错误通道”,但`payload`除外。如果你希望事务回滚并定义了“错误通道”,那么“错误通道”上的集成流必须重新抛出异常(或其他异常)。如果错误流没有抛出异常,则提交事务并删除消息。如果没有定义“错误通道”,则异常将像以前一样被抛回容器。
-### [](#jms-outbound-channel-adapter)出站通道适配器
+### 出站通道适配器
`JmsSendingMessageHandler`实现了`MessageHandler`接口,并且能够将 Spring 集成`Messages`转换为 JMS 消息,然后发送到 JMS 目的地。它需要一个`jmsTemplate`引用,或者同时需要`jmsConnectionFactory`和`destination`引用(`destinationName`可以用来代替`destination`)。与入站通道适配器一样,配置此适配器的最简单方法是使用名称空间支持。以下配置生成一个适配器,该适配器接收来自`exampleChannel`的 Spring 集成消息,将这些消息转换为 JMS 消息,并将它们发送到 Bean 名称为`outQueue`的 JMS 目标引用:
@@ -258,11 +258,11 @@ XML
time-to-live-expression="headers.jms_expiration - T(System).currentTimeMillis()"/>
```
-#### [](#jms-ob-transactions)事务
+#### 事务
从版本 4.0 开始,出站通道适配器支持`session-transacted`属性。在较早的版本中,你必须插入一个`JmsTemplate`,并将`sessionTransacted`设置为`true`。现在,该属性在内置的默认值`JmsTemplate`上设置属性。如果存在事务(可能来自上游`message-driven-channel-adapter`),则在同一事务中执行发送操作。否则,将启动一个新的事务。
-### [](#jms-inbound-gateway)入站网关
+### 入站网关
Spring Integration 的消息驱动 JMS Inbound-Gateway 委托给`MessageListener`容器,支持动态调整并发消费者,还可以处理回复。入站网关需要引用`ConnectionFactory`和请求`Destination`(或“requestDestationName”)。下面的示例定义了一个 JMS,该 JMS 从 Bean ID 引用的 JMS 队列接收,并发送到名为的 Spring 集成通道:
@@ -298,7 +298,7 @@ Spring Integration 的消息驱动 JMS Inbound-Gateway 委托给`MessageListener
从版本 5.1 开始,当端点在应用程序保持运行时停止时,底层侦听器容器将被关闭,从而关闭其共享连接和消费者。以前,连接和消费者保持开放。要恢复到以前的行为,请将`JmsInboundGateway`上的`shutdownContainerOnStop`设置为`false`。
-### [](#jms-outbound-gateway)出站网关
+### 出站网关
出站网关从 Spring 集成消息创建 JMS 消息,并将它们发送到“请求-目的地”。然后,它通过使用选择器从你配置的“reply-destination”接收 JMS 回复消息,或者,如果没有提供“reply-destination”,则通过创建 JMS`TemporaryQueue`实例来处理 JMS 回复消息。
@@ -316,7 +316,7 @@ Spring Integration 的消息驱动 JMS Inbound-Gateway 委托给`MessageListener
“出站网关”有效负载提取属性与“入站网关”的有效负载提取属性是反相关的(参见[先前的讨论](#jms-message-driven-channel-adapter))。这意味着“extract-request-payload”属性值应用于正在转换为 JMS 消息的 Spring 集成消息,该消息将作为请求发送。“extract-reply-payload”属性值应用于作为答复接收的 JMS 消息,然后将其转换为 Spring 集成消息,随后将其发送到“replacy-channel”,如前面的配置示例所示。
-#### [](#jms-outbound-gateway-reply-listener)使用``
+#### 使用``
Spring Integration2.2 引入了一种用于处理答复的替代技术。如果你在网关中添加一个``子元素,而不是为每个回复创建一个使用者,那么将使用一个`MessageListener`容器来接收回复并将其交给请求线程。这提供了许多性能优势,并缓解了[早些时候的警告](#jms-outbound-gateway-memory-caution)中描述的缓存消费者内存利用问题。
@@ -340,13 +340,13 @@ Spring Integration2.2 引入了一种用于处理答复的替代技术。如果
侦听器非常轻量级,我们预计,在大多数情况下,你只需要一个消费者。但是,你可以添加诸如`concurrent-consumers`、`max-concurrent-consumers`等属性。有关受支持的属性的完整列表,请参见模式,以及[Spring JMS documentation](https://docs.spring.io/spring/docs/current/spring-framework-reference/html/jms.html)的含义。
-#### [](#idle-reply-listeners)空闲回复侦听器
+#### 空闲回复侦听器
从版本 4.2 开始,你可以根据需要启动应答侦听器(并在空闲时间之后停止它),而不是在网关的生命周期中运行。如果你在应用程序上下文中有许多网关,而这些网关大部分都是空闲的,那么这可能是有用的。其中一种情况是上下文中使用 Spring 集成和 JMS 进行分区分发的许多(非活动的)分区[Spring Batch](https://spring.io/projects/spring-batch)作业。如果所有的应答侦听器都是活动的,那么 JMS 代理为每个网关都有一个活动的消费者。通过启用空闲超时,每个使用者仅在相应的批处理作业运行时存在(并在其完成后的很短时间内存在)。
见`idle-reply-listener-timeout`in[属性引用](#jms-og-attributes)。
-#### [](#gateway-reply-correlation)网关回复相关性
+#### 网关回复相关性
本节描述了用于响应相关性的机制(确保发起网关仅接收对其请求的响应),具体取决于网关的配置方式。有关此处讨论的属性的完整描述,请参见[属性引用](#jms-og-attributes)。
@@ -429,7 +429,7 @@ Spring Integration2.2 引入了一种用于处理答复的替代技术。如果
回复侦听器不允许使用用户提供的相关 ID。网关不使用此配置初始化。
-#### [](#jms-async-gateway)异步网关
+#### 异步网关
从版本 4.3 开始,在配置出站网关时,你现在可以指定`async="true"`(或者在 Java 中是`setAsync(true)`)。
@@ -437,7 +437,7 @@ Spring Integration2.2 引入了一种用于处理答复的替代技术。如果
`async`需要``(或者在使用 Java 配置时`setUseReplyContainer(true)`)。它还需要指定`correlationKey`(通常`JMSCorrelationID`)。如果不满足上述任一条件,`async`将被忽略。
-#### [](#jms-og-attributes)属性引用
+#### 属性引用
下面的清单显示了`outbound-gateway`的所有可用属性:
@@ -503,7 +503,7 @@ Spring Integration2.2 引入了一种用于处理答复的替代技术。如果
|**26**|见[异步网关](#jms-async-gateway)。|
|**27**|当包含此元素时,将通过异步`MessageListenerContainer`接收答复,而不是为每个答复创建一个消费者。
在许多情况下,这可以更有效。|
-### [](#jms-header-mapping)映射消息头到和来自 JMS 消息
+### 映射消息头到和来自 JMS 消息
JMS 消息可以包含元信息,如 JMS API 头和简单属性。你可以使用`JmsHeaderMapper`将这些消息映射到 Spring 集成消息头。JMS API 头被传递给适当的 setter 方法(例如`setJMSReplyTo`),而其他头则被复制到 JMS 消息的一般属性中。JMS 出站网关使用`JmsHeaderMapper`的默认实现来引导,它将映射标准的 JMS API 头以及原语或`String`消息头。还可以通过使用入站和出站网关的`header-mapper`属性提供自定义的头映射器。
@@ -530,7 +530,7 @@ public DefaultJmsHeaderMapper jmsHeaderMapper() {
这些 JMS 属性分别映射到`JmsHeaders.DELIVERY_MODE`和`JmsHeaders.EXPIRATION` Spring 消息头。
-### [](#jms-conversion-and-marshalling)消息转换、编组和解组
+### 消息转换、编组和解组
如果需要转换消息,所有 JMS 适配器和网关都允许你通过设置`message-converter`属性来提供`MessageConverter`。要做到这一点,请提供在相同的应用程序上下文中可用的`MessageConverter`实例的 Bean 名称。另外,为了提供与 Marshaller 和 Unmarshaller 接口的某种一致性, Spring 提供了`MarshallingMessageConverter`,你可以使用自己的自定义 Marshaller 和 Unmarshaller 对其进行配置。下面的示例展示了如何做到这一点。
@@ -553,7 +553,7 @@ public DefaultJmsHeaderMapper jmsHeaderMapper() {
| |当你提供自己的`MessageConverter`实例时,它仍然被包装在`HeaderMappingMessageConverter`中。
这意味着“extract-request-payload”和“extract-reply-payload”属性可能会影响传递给转换器的实际对象。
`HeaderMappingMessageConverter`本身委托给目标`MessageConverter`,同时还将 Spring 集成`MessageHeaders`映射到 JMS 消息属性并再次返回。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#jms-channel)JMS 支持的消息通道
+### JMS 支持的消息通道
前面介绍的通道适配器和网关都是为与其他外部系统集成的应用程序设计的。入站选项假设其他系统正在向 JMS 目的地发送 JMS 消息,出站选项假设其他系统正在从该目的地接收消息。 Spring 集成应用程序可以是也可以不是另一种系统。当然,当发送 Spring 集成消息实例作为 JMS 消息本身的主体时(将’extract-payload’值设置为`false`),假定另一个系统是基于 Spring 集成的。然而,这绝不是一项要求。这种灵活性是使用基于消息的集成选项并抽象“通道”(在 JMS 的情况下是目标)的好处之一。
@@ -591,7 +591,7 @@ public DefaultJmsHeaderMapper jmsHeaderMapper() {
对于``,对于持久订阅,将`durable`属性设置为`true`,对于共享订阅,将`subscription-shared`属性设置为`subscription-shared`(需要一个 JMS2.0 代理,并且自版本 4.2 以来一直可用)。使用`subscription`来命名订阅。
-### [](#jms-selectors)使用 JMS 消息选择器
+### 使用 JMS 消息选择器
使用 JMS 消息选择器,你可以基于 JMS 头和 JMS 属性过滤[JMS 消息](https://docs.oracle.com/javaee/6/api/javax/jms/Message.html)。例如,如果希望侦听其自定义 JMS 头属性`myHeaderProperty`等于`something`的消息,则可以指定以下表达式:
@@ -614,7 +614,7 @@ myHeaderProperty = 'something'
| |不能使用 JMS 消息选择器引用消息主体的值。|
|---|------------------------------------------------------------------------|
-### [](#jms-samples)JMS 样本
+### JMS 样本
要对这些 JMS 适配器进行实验,请查看 Spring Integration Samples Git 存储库中的 JMS 示例,网址为[https://github.com/spring-projects/spring-integration-samples/tree/master/basic/jms](https://github.com/SpringSource/spring-integration-samples/tree/main/basic/jms)。
diff --git a/docs/spring-integration/jmx.md b/docs/spring-integration/jmx.md
index 2f6e7fe81d54356b7497f1693874972e79a1135a..43c3577b515e16188da6246c3f1ab78bb6126870 100644
--- a/docs/spring-integration/jmx.md
+++ b/docs/spring-integration/jmx.md
@@ -1,6 +1,6 @@
# JMX 支持
-### [](#jmx)JMX 支持
+### JMX 支持
Spring 集成提供了用于接收和发布 JMX 通知的通道适配器。
@@ -24,7 +24,7 @@ compile "org.springframework.integration:spring-integration-jmx:5.5.9"
入站通道适配器允许轮询 JMX MBean 属性值,出站通道适配器允许调用 JMX MBean 操作。
-#### [](#jmx-notification-listening-channel-adapter)通知-监听通道适配器
+#### 通知-监听通道适配器
通知监听通道适配器需要一个 JMX,用于发布此侦听器应注册到的通知的 MBean。一个非常简单的配置可能类似于以下内容:
@@ -53,7 +53,7 @@ compile "org.springframework.integration:spring-integration-jmx:5.5.9"
| |仅对于这个组件,`object-name`属性可以包含一个对象名模式(例如,
“org.something:type=mytype,name=\*”)。,在这种情况下,适配器接收来自所有具有匹配该模式的对象名的 MBean 的通知。,此外,
,`object-name`属性可以包含对``对象名称模式的 SPEL 引用,如下例所示:
```
channel="manyNotificationsChannel"
object-name="#{patterns}"/>
org.foo:type=Foo,name=*
org.foo:type=Bar,name=*
```
启用调试级别日志时,将记录定位的 MBean 的名称。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#jmx-notification-publishing-channel-adapter)通知-发布通道适配器
+#### 通知-发布通道适配器
通知发布通道适配器相对简单。它在配置中只需要一个 JMX 对象名,如下例所示:
@@ -80,7 +80,7 @@ JMX 通知还具有`type`,并且应该是以点分隔的`String`。有两种
default-notification-type="some.default.type"/>
```
-#### [](#jmx-attribute-polling-channel-adapter)属性-轮询通道适配器
+#### 属性-轮询通道适配器
当你需要定期检查通过 MBean 作为托管属性提供的某些值时,属性轮询通道适配器非常有用。可以以与 Spring 集成中的任何其他轮询适配器相同的方式配置 Poller(或者可以依赖默认的 Poller)。需要`object-name`和`attribute-name`。还需要一个 mBeanServer 引用。但是,默认情况下,它会自动检查名为`mbeanServer`的 Bean,与通知侦听通道适配器[前面描述的](#jmx-notification-listening-channel-adapter)相同。下面的示例展示了如何使用 XML 配置属性轮询通道适配器:
@@ -93,7 +93,7 @@ JMX 通知还具有`type`,并且应该是以点分隔的`String`。有两种
```
-#### [](#tree-polling-channel-adapter)树轮询通道适配器
+#### 树轮询通道适配器
树轮询通道适配器查询 JMX MBean 树,并发送一条带有有效负载的消息,该负载是与查询匹配的对象的图形。默认情况下,MBean 映射到原语和简单对象,例如`Map`、`List`和数组。这样做允许简单地转换到(例如)JSON。还需要一个 mBeanServer 引用。但是,默认情况下,它会自动检查名为`mbeanServer`的 Bean,与通知监听通道适配器[前面描述的](#jmx-notification-listening-channel-adapter)相同。下面的示例展示了如何使用 XML 配置树轮询通道适配器:
@@ -109,7 +109,7 @@ JMX 通知还具有`type`,并且应该是以点分隔的`String`。有两种
Spring 集成提供了两个标准过滤器。`NamedFieldsMBeanAttributeFilter`允许你指定要包含的属性列表。`NotNamedFieldsMBeanAttributeFilter`允许你指定要排除的属性列表。你还可以实现自己的过滤器。
-#### [](#jmx-operation-invoking-channel-adapter)操作调用通道适配器
+#### 操作调用通道适配器
操作调用通道适配器支持对 MBean 公开的任何托管操作的消息驱动调用。每个调用都需要调用操作名和目标 MBean 的对象名。这两个都必须由适配器配置显式提供,或者分别通过`JmxHeaders.OBJECT_NAME`和`JmxHeaders.OPERATION_NAME`消息头提供:
@@ -125,7 +125,7 @@ Spring 集成提供了两个标准过滤器。`NamedFieldsMBeanAttributeFilter`
如果你希望公开一个通道,以便由不需要包含头的消息调用单个公共操作,那么最后一个选项效果很好。
-#### [](#jmx-operation-invoking-outbound-gateway)操作调用出站网关
+#### 操作调用出站网关
Spring 与操作调用通道适配器类似,集成还提供了一个操作调用出站网关,当需要返回值时,可以在处理非 void 操作时使用该网关。返回值作为消息有效负载发送到网关指定的`reply-channel`。下面的示例展示了如何使用 XML 配置操作调用出站网关:
@@ -138,7 +138,7 @@ Spring 与操作调用通道适配器类似,集成还提供了一个操作调
如果不提供`reply-channel`属性,则将回复消息发送到由`IntegrationMessageHeaderAccessor.REPLY_CHANNEL`标头标识的通道。该消息头通常由消息流的入口点自动创建,例如任何网关组件。但是,如果消息流是通过手动创建 Spring 集成消息并将其直接发送到通道来启动的,则必须显式地指定消息头,或者使用`reply-channel`属性。
-#### [](#jmx-mbean-exporter)MBean 出口商
+#### MBean 出口商
Spring 当`IntegrationMBeanExporter`被配置时,集成组件本身可以作为 MBean 公开。要创建`IntegrationMBeanExporter`的实例,定义 Bean 并提供对`MBeanServer`的引用和域名(如果需要)。可以省略这个域,在这种情况下,默认域是`org.springframework.integration`。下面的示例展示了如何声明`IntegrationMBeanExporter`实例和关联的`MBeanServer`实例:
@@ -171,7 +171,7 @@ public class ContextConfiguration {
如果需要提供更多选项或具有几个`IntegrationMBeanExporter`bean(例如用于不同的 MBean 服务器或避免与标准 Spring `MBeanExporter`冲突——例如通过`@EnableMBeanExport`),则可以将`IntegrationMBeanExporter`配置为通用 Bean。
-##### [](#jmx-mbean-features)MBean 对象名
+##### MBean 对象名
应用程序中的所有`MessageChannel`、`MessageHandler`和`MessageSource`实例都由 MBean Exporter 包装,以提供管理和监视功能。下表列出了为每个组件类型生成的 JMX 对象名:
@@ -214,7 +214,7 @@ public class Namer implements ObjectNamingStrategy {
从版本 5.1 开始;任何 Bean 名称(由对象名称中的`name`键表示),如果它们包含 Java 标识符(或句号`.`)中不允许的任何字符,都将被引用。
-##### [](#jmx-42-improvements)JMX 改进
+##### JMX 改进
版本 4.2 引入了一些重要的改进,代表了对框架中的 JMX 支持的一次相当大的改革。这些结果导致了 JMX 统计数据收集的性能的显著改善,并对其进行了更多的控制。然而,在一些特定的(不常见的)情况下,它对用户代码有一些影响。下文详细介绍了这些变化,必要时请谨慎从事。
@@ -235,7 +235,7 @@ MBean Exporter Bean 名称模式
`IntegrationMBeanExporter`不再实现`SmartLifecycle`。这意味着`start()`和`stop()`操作不再可用于注册和取消注册 MBean。MBean 现在在上下文初始化期间注册,在上下文被销毁时取消注册。
-##### [](#jmx-mbean-shutdown)有序关停托管运行
+##### 有序关停托管运行
MBean Exporter 允许一个 JMX 操作以有序的方式关闭应用程序。它是在停止 JVM 之前使用的。下面的示例展示了如何使用它:
diff --git a/docs/spring-integration/jpa.md b/docs/spring-integration/jpa.md
index e7d1e31a4eaa2b769907306dbb89bd21353a87e1..1926bfddef4c431008cfd7a6465d7605a7a507b7 100644
--- a/docs/spring-integration/jpa.md
+++ b/docs/spring-integration/jpa.md
@@ -1,6 +1,6 @@
# JPA 支持
-## [](#jpa) JPA 支持
+## JPA 支持
Spring 集成的 JPA(Java 持久性 API)模块提供了用于使用 JPA 执行各种数据库操作的组件。
@@ -48,7 +48,7 @@ JPA 入站通道适配器允许你使用 JPA 从数据库中轮询和检索(`s
* 更新出站网关
-### [](#functionality)功能
+### 功能
所有 JPA 组件通过使用以下之一来执行其各自的 JPA 操作:
@@ -62,7 +62,7 @@ JPA 入站通道适配器允许你使用 JPA 从数据库中轮询和检索(`s
下面的小节将更详细地描述这些组件中的每一个。
-### [](#jpa-supported-persistence-providers)支持的持久性提供程序
+### 支持的持久性提供程序
Spring 集成 JPA 支持已经针对以下持久性提供者进行了测试:
@@ -72,7 +72,7 @@ Spring 集成 JPA 支持已经针对以下持久性提供者进行了测试:
在使用持久性提供程序时,你应该确保该提供程序与 JPA 2.1 兼容。
-### [](#jpa-java-implementation)Java 实现
+### Java 实现
所提供的每个组件都使用`o.s.i.jpa.core.JpaExecutor`类,其反过来使用`o.s.i.jpa.core.JPAOperations`接口的实现。`JpaOperations`操作方式类似于典型的数据访问对象,并提供了诸如查找、持久化、ExecuteUpdate 等方法。对于大多数用例,默认实现(`o.s.i.jpa.core.DefaultJpaOperations`)应该足够了。但是,如果需要自定义行为,则可以指定自己的实现。
@@ -106,11 +106,11 @@ public MessageHandler retrievingJpaGateway() {
}
```
-### [](#jpa-namespace-support)名称空间支持
+### 名称空间支持
在使用 XML 名称空间支持时,底层解析器类将为你实例化相关的 Java 类。因此,你通常不需要处理 JPA 适配器的内部工作。本节记录了 Spring Integration 提供的 XML 命名空间支持,并向你展示了如何使用 XML 命名空间支持来配置 JPA 组件。
-#### [](#jpa-namespace-support-common-attributes)常见的 XML 名称空间配置属性
+#### 常见的 XML 名称空间配置属性
某些配置参数由所有 JPA 组件共享:
@@ -166,7 +166,7 @@ public MessageHandler retrievingJpaGateway() {
指一个已命名的查询。命名查询可以在原生 SQL 或 JPAQL 中定义,但是底层的 JPA 持久性提供程序在内部处理这种区别。
-#### [](#jpa-parameters)提供 JPA 查询参数
+#### 提供 JPA 查询参数
要提供参数,可以使用`parameter`XML 元素。它有一种机制,允许你为基于 Java 持久性查询语言或本机 SQL 查询的查询提供参数。你还可以为命名查询提供参数。
@@ -195,7 +195,7 @@ public MessageHandler retrievingJpaGateway() {
```
-#### [](#jpa-transactions)事务处理
+#### 事务处理
所有 JPA 操作(例如`INSERT`、`UPDATE`和`DELETE`)都需要一个事务在执行时处于活动状态。对于入站通道适配器,你不需要做任何特别的事情。它的工作方式与我们配置事务管理器的方式类似,它使用与其他入站通道适配器一起使用的 Poller。下面的 XML 示例配置了一个事务管理器,该事务管理器使用带入站通道适配器的 Poller:
@@ -235,7 +235,7 @@ public MessageHandler retrievingJpaGateway() {
| |与 Spring Integration 的命名空间中定义的 Poller 的`transactional`元素不同,用于出站网关或适配器的`transactional`元素是在 JPA 命名空间中定义的。|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#jpa-inbound-channel-adapter)入站通道适配器
+### 入站通道适配器
入站通道适配器用于使用 JPA QL 在数据库上执行 SELECT 查询并返回结果。消息有效负载是单个实体或`List`的实体。以下 XML 配置`inbound-channel-adapter`:
@@ -266,7 +266,7 @@ public MessageHandler retrievingJpaGateway() {
|**8**|如果要删除执行查询后收到的行,请将该值设置为`true`。
你必须确保组件作为事务的一部分进行操作。
否则,你可能会遇到异常,例如:`java.lang.IllegalArgumentException: Removing a detached instance …`|
|**9**|如果你想在删除接收到的实体后立即刷新持久性上下文,并且不想依赖`EntityManager`的`flushMode`,则将该值设置为`true`。
值默认为`false`。|
-#### [](#jpaInboundChannelAdapterParameters)配置参数引用
+#### 配置参数引用
下面的清单显示了可以为`inbound-channel-adapter`设置的所有值:
@@ -307,7 +307,7 @@ public MessageHandler retrievingJpaGateway() {
|**13**|一个`o.s.i.jpa.support.parametersource.ParameterSource`的实现,用于解析查询中的参数的值。
如果`entity-class`属性有一个值,则忽略。
可选。|
|**14**|发送消息到通道时等待的最长时间(以毫秒为单位)。
可选。|
-#### [](#configuring-with-java-configuration)使用 Java 配置进行配置
+#### 使用 Java 配置进行配置
Spring 以下引导应用程序展示了如何使用 Java 配置入站适配器的示例:
@@ -348,7 +348,7 @@ public class JpaJavaApplication {
}
```
-#### [](#configuring-with-the-java-dsl)使用 Java DSL 进行配置
+#### 使用 Java DSL 进行配置
Spring 以下引导应用程序展示了如何使用 Java DSL 配置入站适配器的示例:
@@ -381,11 +381,11 @@ public class JpaJavaApplication {
}
```
-### [](#jpa-outbound-channel-adapter)出站通道适配器
+### 出站通道适配器
JPA 出站通道适配器允许你通过请求通道接受消息。有效负载可以用作要持久化的实体,也可以与 JPQL 查询的参数表达式中的头一起使用。下面的部分介绍了执行这些操作的可能方法。
-#### [](#jpa-outbound-channel-adapter-entity-class)使用实体类
+#### 使用实体类
以下 XML 将出站通道适配器配置为将一个实体持久化到数据库:
@@ -410,7 +410,7 @@ JPA 出站通道适配器允许你通过请求通道接受消息。有效负载
| |从版本 5.5.4 开始,`JpaOutboundGateway`的`JpaExecutor`配置为`PersistMode.DELETE`的`JpaExecutor`可以接受`Iterable`有效负载,为提供的实体执行批删除持久操作。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#jpa-using-jpaql)使用 JPA 查询语言( JPA ql)
+#### 使用 JPA 查询语言( JPA ql)
[上一节](#jpa-outbound-channel-adapter-entity-class)演示了如何通过使用实体执行`PERSIST`操作。本节展示了如何使用带有 JPA QL 的出站通道适配器。
@@ -448,7 +448,7 @@ JPA 出站通道适配器允许你通过请求通道接受消息。有效负载
| |尽管指定`select`对 JPA QL 有效,但这样做没有意义。
出站通道适配器不返回任何结果。
如果你想选择一些值,请考虑使用出站网关。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#jpa-using-native-queries)使用本机查询
+#### 使用本机查询
本节描述如何使用本机查询来使用 JPA 出站通道适配器执行操作。使用本机查询与使用 JPA QL 类似,只是查询是本机数据库查询。通过使用本机查询,我们失去了数据库供应商的独立性,这是我们使用 JPA QL 获得的。
@@ -473,7 +473,7 @@ JPA 出站通道适配器允许你通过请求通道接受消息。有效负载
请注意,其他属性(例如`channel`和`entity-manager`)和`parameter`元素具有与 JPA QL 相同的语义。
-#### [](#using-named-queries)使用命名查询
+#### 使用命名查询
使用命名查询类似于使用[JPA QL](#jpa-using-jpaql)或[本机查询](#jpa-using-native-queries),只是我们指定了命名查询而不是查询。首先,我们介绍如何定义 JPA 命名查询。然后,我们将介绍如何声明出站通道适配器来处理命名查询。如果我们有一个名为`Student`的实体,我们可以使用`Student`类上的注释来定义两个命名的查询:`selectStudent`和`updateStudent`。下面的示例展示了如何做到这一点:
@@ -518,7 +518,7 @@ public class Student {
|**1**|当适配器通过通道接收消息时,我们希望它执行的已命名查询。|
|-----|------------------------------------------------------------------------------------------------|
-#### [](#jpaOutboundChannelAdapterParameters)配置参数引用
+#### 配置参数引用
下面的清单显示了可以在出站通道适配器上设置的所有属性:
@@ -567,7 +567,7 @@ public class Student {
|**17**|定义事务管理属性和对要由 JPA 适配器使用的事务管理器的引用。
可选的。|
|**18**|一个或多个`parameter`属性——用于查询中使用的每个参数。
求值或表达式以计算参数的值。
可选。|
-#### [](#configuring-with-java-configuration-2)使用 Java 配置进行配置
+#### 使用 Java 配置进行配置
Spring 下面的引导应用程序展示了如何使用 Java 配置出站适配器的示例:
@@ -614,7 +614,7 @@ public class JpaJavaApplication {
}
```
-#### [](#configuring-with-the-java-dsl-2)使用 Java DSL 进行配置
+#### 使用 Java DSL 进行配置
Spring 以下引导应用程序展示了如何使用 Java DSL 配置出站适配器的示例:
@@ -644,7 +644,7 @@ public class JpaJavaApplication {
}
```
-### [](#jpa-outbound-gateways)出站网关
+### 出站网关
JPA 入站通道适配器允许对数据库进行轮询以检索一个或多个 JPA 实体。因此,检索到的数据被用来启动 Spring 集成流,该集成流将检索到的数据用作消息负载。
@@ -683,7 +683,7 @@ JPA 入站通道适配器允许对数据库进行轮询以检索一个或多个
有关配置示例,请参见[JPA Outbound Gateway Samples](#outboundGatewaySamples)。
-#### [](#jpa-outbound-gateway-common-parameters)常见配置参数
+#### 常见配置参数
JPA 出站网关始终具有对 Spring 集成`Message`的访问作为输入。因此,以下参数是可用的:
@@ -695,7 +695,7 @@ JPA 出站网关始终具有对 Spring 集成`Message`的访问作为输入。
如果设置为`true`,则`Message`的有效负载将用作参数的源。如果设置为`false`,则整个`Message`可以作为参数的源。如果没有 JPA 参数被传入,则此属性默认为`true`。这意味着,如果使用默认的`BeanPropertyParameterSourceFactory`,则有效负载的 Bean 属性被用作 JPA 查询参数值的源。但是,如果将 JPA 参数传入,则默认情况下,此属性的值为`false`。原因是 JPA 参数允许你提供 SPEL 表达式。因此,具有对整个`Message`的访问是非常有益的,包括头。可选的。
-#### [](#jpa-updating-outbound-gateway)更新出站网关
+#### 更新出站网关
下面的清单显示了可以在更新-出站-网关上设置的所有属性,并描述了关键属性:
@@ -732,7 +732,7 @@ JPA 出站网关始终具有对 Spring 集成`Message`的访问作为输入。
其余的属性将在本章前面描述。见[配置参数参考](#jpaInboundChannelAdapterParameters)和[配置参数参考](#jpaOutboundChannelAdapterParameters)。
-#### [](#configuring-with-java-configuration-3)使用 Java 配置进行配置
+#### 使用 Java 配置进行配置
Spring 以下引导应用程序展示了如何使用 Java 配置出站适配器的示例:
@@ -772,7 +772,7 @@ public class JpaJavaApplication {
}
```
-#### [](#configuring-with-the-java-dsl-3)使用 Java DSL 进行配置
+#### 使用 Java DSL 进行配置
Spring 以下引导应用程序展示了如何使用 Java DSL 配置出站适配器的示例:
@@ -801,7 +801,7 @@ public class JpaJavaApplication {
}
```
-#### [](#jpa-retrieving-outbound-gateway)检索出站网关
+#### 检索出站网关
下面的示例展示了你可以在检索出站网关上设置的所有属性,并描述了关键属性:
@@ -847,7 +847,7 @@ public class JpaJavaApplication {
其余的属性将在本章前面描述。见[配置参数参考](#jpaInboundChannelAdapterParameters)和[配置参数参考](#jpaOutboundChannelAdapterParameters)。
-#### [](#configuring-with-java-configuration-4)使用 Java 配置进行配置
+#### 使用 Java 配置进行配置
Spring 下面的引导应用程序展示了如何使用 Java 配置出站适配器的示例:
@@ -886,7 +886,7 @@ public class JpaJavaApplication {
}
```
-#### [](#configuring-with-the-java-dsl-4)使用 Java DSL 进行配置
+#### 使用 Java DSL 进行配置
Spring 以下引导应用程序展示了如何使用 Java DSL 配置出站适配器的示例:
@@ -920,11 +920,11 @@ public class JpaJavaApplication {
| |当你选择在检索时删除实体,并且你已检索到一组实体时,默认情况下,实体是在每个实体的基础上删除的。
这可能会导致性能问题。
或者,你可以将属性`deleteInBatch`设置为`true`,从而执行批删除。但是,
,这样做的限制是不支持级联删除。,
JSR317:Java 持久性 2.0 在第 4.10 章中指出,“批量更新和删除操作”,即:
“删除操作仅适用于指定类及其子类的实体。
它不会级联到相关实体。”
有关更多信息,请参见[JSR317:Java 持久性 2.0](https://jcp.org/en/jsr/detail?id=317)|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#outboundGatewaySamples) JPA 出站网关样本
+#### JPA 出站网关样本
本节包含使用更新出站网关和检索出站网关的各种示例:
-##### [](#update-by-using-an-entity-class)使用实体类进行更新
+##### 使用实体类进行更新
在下面的示例中,通过使用`org.springframework.integration.jpa.test.entity.Student`实体类作为 JPA 定义参数来持久化更新出站网关:
@@ -939,7 +939,7 @@ public class JpaJavaApplication {
|-----|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|**2**|这就是网关与出站适配器不同的地方。
这是接收 JPA 操作的回复的通道,
但是,如果你对接收到的回复不感兴趣,并且只想执行操作,使用 JPA `outbound-channel-adapter`是适当的选择。
在本例中,我们使用一个实体类,其答复是作为 JPA 操作的结果而创建或合并的实体对象。|
-##### [](#update-using-jpql)使用 jpql 进行更新
+##### 使用 jpql 进行更新
下面的示例使用 Java 持久性查询语言更新实体,该语言要求使用更新出站网关:
@@ -958,7 +958,7 @@ public class JpaJavaApplication {
当发送带有`String`有效负载的消息时,该消息还包含一个名为`rollNumber`的头,该头具有`long`值,具有指定滚动号的学生的姓氏将更新为消息有效负载中的值。当使用更新网关时,返回值始终是整数值,该整数值表示受 JPA QL 的执行影响的记录的数量。
-##### [](#retrieving-an-entity-using-jpql)使用 jpql 检索实体
+##### 使用 jpql 检索实体
下面的示例使用一个检索出站网关和 JPQL 从数据库中检索(选择)一个或多个实体:
@@ -972,7 +972,7 @@ public class JpaJavaApplication {
```
-##### [](#retrieving-an-entity-by-using-id-expression)使用`id-expression`检索实体
+##### 使用`id-expression`检索实体
下面的示例使用带有`id-expression`的检索出站网关从数据库中检索(查找)一个且只有一个实体:`primaryKey`是`id-expression`求值的结果。`entityClass`是一类消息`payload`。
@@ -984,7 +984,7 @@ public class JpaJavaApplication {
entity-manager="em"/>
```
-##### [](#update-using-a-named-query)使用命名查询进行更新
+##### 使用命名查询进行更新
使用命名查询基本上与直接使用 JPQL 查询相同。不同之处在于使用了`named-query`属性,如下例所示:
diff --git a/docs/spring-integration/kafka.md b/docs/spring-integration/kafka.md
index ede554289fb07068101bd042bd21c7bf7224d558..3c711703561720b0984c0e5a281b906e0c27ad33 100644
--- a/docs/spring-integration/kafka.md
+++ b/docs/spring-integration/kafka.md
@@ -1,8 +1,8 @@
# Apache Kafka 支持
-## [](#kafka)Apache Kafka 支持
+## Apache Kafka 支持
-### [](#overview)概述
+### 概述
Spring Apache Kafka 的集成基于[Spring for Apache Kafka project](https://projects.spring.io/spring-kafka/)。
@@ -38,7 +38,7 @@ compile "org.springframework.integration:spring-integration-kafka:5.5.9"
* [Apache Kafka 主题支持的频道](#kafka-channels)
-### [](#kafka-outbound)出站通道适配器
+### 出站通道适配器
出站通道适配器用于将消息从 Spring 集成通道发布到 Apache Kafka 主题。通道在应用程序上下文中定义,然后连接到将消息发送到 Apache Kafka 的应用程序中。发送方应用程序可以通过使用 Spring 集成消息发布到 Apache Kafka,这些消息由出站通道适配器在内部转换为 Kafka 记录,如下所示:
@@ -80,7 +80,7 @@ topic-expression="headers['topic'] != null ? headers['topic'] : 'myTopic'"
`KafkaProducerMessageHandler.sendTimeoutExpression`默认值已从 10 秒更改为`delivery.timeout.ms`Kafka Producer 属性`+ 5000`,以便将超时后的实际 Kafka 错误传播到应用程序,而不是由此框架生成的超时。为了保持一致性,对此进行了更改,因为你可能会遇到意外的行为( Spring 可能会超时发送,而实际上最终是成功的)。重要提示:默认情况下,超时时间为 120 秒,因此你可能希望减少超时时间,以获得更多的及时故障。
-#### [](#java-configuration)Java 配置
+#### Java 配置
下面的示例展示了如何使用 Java 为 Apache Kafka 配置出站通道适配器:
@@ -111,7 +111,7 @@ public ProducerFactory producerFactory() {
}
```
-#### [](#java-dsl-configuration)Java DSL 配置
+#### Java DSL 配置
下面的示例展示了如何使用 Spring 集成 Java DSL 为 Apache Kafka 配置出站通道适配器:
@@ -156,7 +156,7 @@ private KafkaProducerMessageHandlerSpec kafkaMessageHandler(
}
```
-#### [](#xml-configuration)XML 配置
+#### XML 配置
下面的示例展示了如何使用 XML 配置 Kafka 出站通道适配器:
@@ -188,7 +188,7 @@ private KafkaProducerMessageHandlerSpec kafkaMessageHandler(
```
-### [](#kafka-inbound)消息驱动通道适配器
+### 消息驱动通道适配器
`KafkaMessageDrivenChannelAdapter`(``)使用`spring-kafka``KafkaMessageListenerContainer`或`ConcurrentListenerContainer`。
@@ -203,7 +203,7 @@ private KafkaProducerMessageHandlerSpec kafkaMessageHandler(
在构建`ErrorMessage`(用于`error-channel`或`recovery-callback`)时,可以通过设置`error-message-strategy`属性来定制错误消息。默认情况下,将使用`RawRecordHeaderErrorMessageStrategy`,以提供对转换后的消息以及原始`ConsumerRecord`的访问。
-#### [](#java-configuration-2)Java 配置
+#### Java 配置
下面的示例展示了如何使用 Java 配置消息驱动的通道适配器:
@@ -233,7 +233,7 @@ public ConsumerFactory consumerFactory() {
}
```
-#### [](#java-dsl-configuration-2)Java DSL 配置
+#### Java DSL 配置
下面的示例展示了如何使用 Spring 集成 Java DSL 配置消息驱动通道适配器:
@@ -277,7 +277,7 @@ public IntegrationFlow topic2ListenerFromKafkaFlow() {
注意,在这种情况下,适配器被赋予`id`(`topic2Adapter`)。容器以`topic2Adapter.container`的名称注册在应用程序上下文中。如果适配器没有`id`属性,则容器的 Bean 名称是容器的完全限定类名称加上`#n`,其中`n`对每个容器递增。
-#### [](#xml-configuration-2)XML 配置
+#### XML 配置
下面的示例展示了如何使用 XML 配置消息驱动的通道适配器:
@@ -315,11 +315,11 @@ public IntegrationFlow topic2ListenerFromKafkaFlow() {
```
-### [](#kafka-inbound-pollable)入站通道适配器
+### 入站通道适配器
`KafkaMessageSource`提供了一个可匹配的通道适配器实现。
-#### [](#java-configuration-3)Java 配置
+#### Java 配置
```
@InboundChannelAdapter(channel = "fromKafka", poller = @Poller(fixedDelay = "5000"))
@@ -341,7 +341,7 @@ public KafkaMessageSource source(ConsumerFactory
此适配器发出的消息包含一个标题`kafka_remainingRecords`,其中包含上一个轮询中剩余的记录的计数。
-#### [](#java-dsl-configuration-3)Java DSL 配置
+#### Java DSL 配置
```
@Bean
@@ -353,7 +353,7 @@ public IntegrationFlow flow(ConsumerFactory cf) {
}
```
-#### [](#xml-configuration-3)XML 配置
+#### XML 配置
```
cf) {
```
-### [](#kafka-outbound-gateway)出站网关
+### 出站网关
出站网关用于请求/回复操作。它与大多数 Spring 集成网关的不同之处在于,发送线程不会在网关中阻塞,而应答将在应答侦听器容器线程上进行处理。如果你的代码调用同步[消息传递网关](https://docs.spring.io/spring-integration/reference/html/messaging-endpoints-chapter.html#gateway)后面的网关,则用户线程将在此阻塞,直到收到答复(或者发生超时)。
@@ -382,7 +382,7 @@ public IntegrationFlow flow(ConsumerFactory cf) {
`KafkaProducerMessageHandler``sendTimeoutExpression`默认值是`delivery.timeout.ms`Kafka Producer 属性`+ 5000`,这样超时后的实际 Kafka 错误将传播到应用程序,而不是由该框架生成的超时。为了保持一致性,对此进行了更改,因为你可能会遇到意外的行为( Spring 可能会超时发送,而实际上最终是成功的)。重要提示:默认情况下,超时时间为 120 秒,因此你可能希望减少超时时间,以获得更多的及时故障。
-#### [](#java-configuration-4)Java 配置
+#### Java 配置
下面的示例展示了如何使用 Java 配置网关:
@@ -407,7 +407,7 @@ public KafkaProducerMessageHandler outGateway(
还可以指定`KafkaHeaders.REPLY_PARTITION`头,以确定用于答复的特定分区。同样,这是根据模板的回复容器的订阅进行验证的。
-#### [](#java-dsl-configuration-4)Java DSL 配置
+#### Java DSL 配置
下面的示例展示了如何使用 Java DSL 配置出站网关:
@@ -436,7 +436,7 @@ public IntegrationFlow outboundGateFlow() {
}
```
-#### [](#xml-configuration-4)XML 配置
+#### XML 配置
```
```
-### [](#kafka-inbound-gateway)入站网关
+### 入站网关
入站网关用于请求/回复操作。
@@ -512,7 +512,7 @@ public IntegrationFlow serverGateway() {
还可以使用用于`@KafkaListener`注释的容器工厂为其他目的创建`ConcurrentMessageListenerContainer`实例。有关示例,请参见[the Spring for Apache Kafka documentation](https://docs.spring.io/spring-kafka/docs/current/reference/html/)和[消息驱动通道适配器](#kafka-inbound)。
-#### [](#xml-configuration-5)XML 配置
+#### XML 配置
```
template,
}
```
-#### [](#java-configuration-5)Java 配置
+#### Java 配置
```
/**
@@ -632,7 +632,7 @@ PollableKafkaChannel pollable(KafkaTemplate template,
}
```
-#### [](#xml-configuration-6)XML 配置
+#### XML 配置
```
template,
group-id="pubSubGroup" container-factory="containerFactory" />
```
-### [](#message-conversion)消息转换
+### 消息转换
a`StringJsonMessageConverter`。有关更多信息,请参见[the Spring for Apache Kafka documentation](https://docs.spring.io/spring-kafka/docs/current/reference/html/)。
@@ -682,7 +682,7 @@ public KafkaMessageDrivenChannelAdapter
}
```
-### [](#kafka-tombstones)空有效载荷和日志压缩“墓碑”记录
+### 空有效载荷和日志压缩“墓碑”记录
Spring 消息传递`Message>`对象不能具有`null`有效负载。当你使用 Apache Kafka 的端点时,`null`有效载荷(也称为 Tombstone 记录)由类型为`KafkaNull`的有效载荷表示。有关更多信息,请参见[the Spring for Apache Kafka documentation](https://docs.spring.io/spring-kafka/docs/current/reference/html/)。
@@ -697,7 +697,7 @@ public void in(@Header(KafkaHeaders.RECEIVED_MESSAGE_KEY) String key,
}
```
-### [](#streams-integration)从`KStream`调用 Spring 集成流
+### 从`KStream`调用 Spring 集成流
你可以使用`MessagingTransformer`从`KStream`调用集成流:
@@ -736,7 +736,7 @@ public IntegrationFlow flow() {
当一个集成流从一个接口开始时,所创建的代理具有该流的名称 Bean,并附加了“.gateway”,因此如果需要,这个 Bean 名称可以使用 a`@Qualifier`。
-### [](#read-process-write)读/处理/写场景的性能注意事项
+### 读/处理/写场景的性能注意事项
许多应用程序使用一个主题,执行一些处理并写入另一个主题。在大多数情况下,如果写入失败,应用程序将希望抛出一个异常,以便可以重试传入的请求并/或将其发送到一个死信主题。该功能由底层消息侦听器容器以及适当配置的错误处理程序支持。然而,为了支持这一点,我们需要阻塞侦听器线程,直到写操作成功(或失败),以便可以将任何异常抛到容器中。当使用单个记录时,可以通过在出站适配器上设置`sync`属性来实现。然而,当使用批处理时,使用`sync`会导致显著的性能下降,因为应用程序将在发送下一条消息之前等待每次发送的结果。你还可以执行多个发送,然后等待这些发送的结果。这是通过向消息处理程序添加`futuresChannel`来实现的。要启用该功能,请将`KafkaIntegrationHeaders.FUTURE_TOKEN`添加到出站消息中;然后可以使用此功能将`Future`关联到特定的已发送消息。下面是一个如何使用此功能的示例:
diff --git a/docs/spring-integration/kotlin-dsl.md b/docs/spring-integration/kotlin-dsl.md
index b2bf6577891366fe0bf973b451e6a078d3465686..f02ff8832327e4cf3631ade59900f54504f89765 100644
--- a/docs/spring-integration/kotlin-dsl.md
+++ b/docs/spring-integration/kotlin-dsl.md
@@ -1,6 +1,6 @@
# Kotlin DSL
-## [](#kotlin-dsl) Kotlin dsl
+## Kotlin dsl
Kotlin DSL 是[Java DSL](./dsl.html#java-dsl)的包装器和扩展,其目的是使 Spring 上的集成开发尽可能平滑和简单,并与现有的 Java API 和 Kotlin 语言特定的结构具有互操作性。
diff --git a/docs/spring-integration/mail.md b/docs/spring-integration/mail.md
index e60245a031488d7684ade0bd2d3371427a195870..d0ceaf9596c2ef431688fd0fc1aedd2968d04a4a 100644
--- a/docs/spring-integration/mail.md
+++ b/docs/spring-integration/mail.md
@@ -1,6 +1,6 @@
# 邮件支持
-## [](#mail)邮件支持
+## 邮件支持
本节描述如何在 Spring 集成中处理邮件消息。
@@ -24,7 +24,7 @@ compile "org.springframework.integration:spring-integration-mail:5.5.9"
`javax.mail:javax.mail-api`必须通过特定于供应商的实现来包含。
-### [](#mail-outbound)邮件发送通道适配器
+### 邮件发送通道适配器
Spring 集成提供了对带有`MailSendingMessageHandler`的出站电子邮件的支持。它将委托给 Spring 的`爪哇MailSender`的一个配置实例,如下例所示:
@@ -50,7 +50,7 @@ Spring 集成提供了对带有`MailSendingMessageHandler`的出站电子邮件
| |`MailHeaders`还可以重写相应的`MailMessage`值。
例如,如果`MailMessage.to`被设置为’[[电子邮件保护]](/cdn-cgi/l/email-protection#d0a4b8b8b9beb7e190a4b8b9beb7a3feb3bfbbd)’并提供了`MailHeaders.TO`消息头,则优先处理并重写`MailMessage`中的对应值。|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#mail-inbound)邮件接收通道适配器
+### 邮件接收通道适配器
Spring 集成还提供了对带有`MailReceivingMessageSource`的入站电子邮件的支持。它将委托给 Spring 集成自己的`MailReceiver`接口的已配置实例。有两种实现方式:`Pop3MailReceiver`和`ImapMailReceiver`。实例化这两种方法中任何一种的最简单方法是将邮件存储的“URI”传递给接收者的构造函数,如下例所示:
@@ -90,7 +90,7 @@ if (closeableResource != null) {
从版本 5.4 开始,现在可以返回`MimeMessage`,不需要任何转换或急切的内容加载。该功能是通过以下选项组合启用的:不提供`headerMapper`,`simpleContent`属性是`false`,`autoCloseFolder`属性是`false`。`MimeMessage`作为产生的 Spring 消息的有效负载而存在。在这种情况下,唯一填充的头是上面提到的`IntegrationMessageHeaderAccessor.CLOSEABLE_RESOURCE`,用于在`MimeMessage`的处理完成时必须关闭的文件夹。
-### [](#mail-mapping)入站邮件消息映射
+### 入站邮件消息映射
默认情况下,入站适配器产生的消息的有效负载是 RAW`MimeMessage`。你可以使用该对象查询标题和内容。从版本 4.3 开始,你可以提供`HeaderMapper`来将标题映射到`MessageHeaders`。 Spring 为方便起见,集成为此目的提供了`DefaultMailHeaderMapper`。它映射了以下标题:
@@ -164,7 +164,7 @@ XML
从版本 5.4 开始,当没有`headerMapper`被提供时,`autoCloseFolder`是`false`而`simpleContent`是`false`,则在产生的 Spring 消息的有效负载中以原样返回`MimeMessage`。通过这种方式,`MimeMessage`的内容在引用时按需加载,稍后在流程中加载。上面提到的所有转换仍然有效。
-### [](#mail-namespace)邮件命名空间支持
+### 邮件命名空间支持
Spring 集成为与邮件相关的配置提供了一个命名空间。要使用它,请配置以下架构位置:
@@ -302,7 +302,7 @@ public interface SearchTermStrategy {
| |重要提示:IMAP Peek
从版本 4.1.1 开始,IMAP 邮件接收器使用`mail.imap.peek`或`mail.imaps.peek`JavaMail 属性,如果指定的话。
以前,接收器忽略了该属性,并且总是设置`PEEK`标志。
现在,如果你显式地将此属性设置为`false`,无论`shouldMarkMessagesRead`的设置如何,消息 ISE 都标记为`\Seen`。
如果未指定,则保留先前的行为(PEEK 为`true`)。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#imap-idle-and-lost-connections)IMAP`idle`和丢失连接
+#### IMAP`idle`和丢失连接
当使用 IMAP`idle`通道适配器时,与服务器的连接可能会丢失(例如,由于网络故障),并且由于 JavaMail 文档明确指出,实际的 IMAP API 是实验性的,理解 API 中的差异以及在配置 IMAP`idle`适配器时如何处理它们是很重要的。目前, Spring 集成邮件适配器已经用 JavaMail1.4.1 和 JavaMail1.4.3 进行了测试。根据使用的是哪一个,你必须特别注意在自动重新连接时需要设置的一些 JavaMail 属性。
@@ -327,7 +327,7 @@ public interface SearchTermStrategy {
| |从 3.0 版本开始,当出现异常时,IMAP`idle`适配器会发出应用程序事件(特别是`ImapIdleExceptionEvent`实例)。
这允许应用程序检测并对这些异常执行。
你可以通过使用``或任何`ApplicationListener`配置为接收`ImapIdleExceptionEvent`或其超类之一来获得事件。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#imap-seen)不支持`\Recent`时标记 IMAP 消息
+### 不支持`\Recent`时标记 IMAP 消息
如果`shouldMarkMessagesAsRead`为真,则 IMAP 适配器设置`\Seen`标志。
@@ -337,7 +337,7 @@ public interface SearchTermStrategy {
从版本 4.2.2 开始,你可以通过在`MailReceiver`上使用`setUserFlag`来设置用户标志的名称。这样做可以让多个接收者使用不同的标志(只要邮件服务器支持用户标志)。当使用名称空间配置适配器时,`user-flag`属性可用。
-### [](#mail-filtering)邮件过滤
+### 邮件过滤
通常,你可能会遇到过滤收到的消息的要求(例如,你希望只读取`Subject`行中具有“ Spring 集成”的电子邮件)。你可以通过将入站邮件适配器与基于表达式的`Filter`连接起来来实现这一点。尽管它会起作用,但这种方法也有缺点。由于在通过入站邮件适配器之后将对消息进行过滤,因此所有此类消息将被标记为已读(`SEEN`)或未读(取决于`should-mark-messages-as-read`属性的值)。然而,在现实中,只有当消息通过筛选条件时,将消息标记为`SEEN`才更有用。这类似于在浏览预览窗格中的所有邮件时查看电子邮件客户端,但仅标记实际打开并读为`SEEN`的邮件。
@@ -360,7 +360,7 @@ Spring Integration2.0.4 在`inbound-channel-adapter`和`imap-idle-channel-adapte
另一个合理的问题是,在下一个轮询或空闲事件中会发生什么,或者在重新启动这样的适配器时会发生什么。是否有重复的按摩需要过滤?换句话说,如果在上一次检索中,有五条新消息,只有一条通过了过滤器,那么其他四条会发生什么情况?在下一次投票时,他们会再次通过过滤逻辑还是空闲?毕竟,它们没有被标记为`SEEN`。答案是否定的。由于电子邮件服务器设置并由 Spring 集成邮件搜索过滤器使用的另一个标志(`RECENT`),它们不会受到重复处理。文件夹实现将此标志设置为表示此邮件是此文件夹新建的。也就是说,它是从上次打开这个文件夹开始到达的。换句话说,虽然我们的适配器可能会偷看电子邮件,但它也让电子邮件服务器知道此类电子邮件已被触摸,因此电子邮件服务器应将其标记为`RECENT`。
-### [](#mail-tx-sync)事务同步
+### 事务同步
入站适配器的事务同步允许你在事务提交或回滚之后执行不同的操作。你可以通过为轮询的``的 poller 或``添加``元素来启用事务同步。即使不涉及“实际”事务,也可以通过使用带有``元素的`PseudoTransactionManager`来启用此功能。有关更多信息,请参见[事务同步](./transactions.html#transaction-synchronization)。
@@ -418,7 +418,7 @@ public class Mover {
| |要使消息在事务结束后仍可用于操作,*应该-删除-消息*必须设置为“false”。|
|---|------------------------------------------------------------------------------------------------------------------------------|
-### [](#mail-java-dsl-configuration)使用 Java DSL 配置通道适配器
+### 使用 Java DSL 配置通道适配器
为了在 Java DSL 中配置邮件组件,框架提供了一个`o.s.i.mail.dsl.Mail`工厂,它可以这样使用:
diff --git a/docs/spring-integration/message-publishing.md b/docs/spring-integration/message-publishing.md
index c2fb477e36ae64746be45459a2b583c2c94bde19..062372be8f0d5142c91df7bb9dab4ec7346d7fb2 100644
--- a/docs/spring-integration/message-publishing.md
+++ b/docs/spring-integration/message-publishing.md
@@ -1,14 +1,14 @@
# 消息发布
-## [](#message-publishing)消息发布
+## 消息发布
(面向方面的编程) AOP 消息发布特性允许你构造和发送消息,作为方法调用的副产品。例如,假设你有一个组件,并且每当该组件的状态发生变化时,你都希望得到一条消息的通知。发送此类通知的最简单方法是将消息发送到专用通道,但是如何将更改对象状态的方法调用连接到消息发送过程,以及通知消息应该如何进行结构化? AOP 消息发布特性使用配置驱动的方法处理这些职责。
-### [](#message-publishing-config)消息发布配置
+### 消息发布配置
Spring 集成提供了两种方法:XML 配置和注释驱动配置。
-#### [](#publisher-annotation)注释驱动的配置,使用`@Publisher`注释
+#### 注释驱动的配置,使用`@Publisher`注释
注释驱动的方法允许你使用`@Publisher`注释对任何方法进行注释,以指定“通道”属性。从版本 5.1 开始,要打开这个功能,你必须在某些`@Configuration`类上使用`@EnablePublisher`注释。有关更多信息,请参见[configuration and`@EnableIntegration`]。消息由方法调用的返回值构造,并发送到由“channel”属性指定的通道。为了进一步管理消息结构,还可以使用`@Payload`和`@Header`注释的组合。
@@ -148,7 +148,7 @@ static class BankingOperationsImpl implements BankingOperations {
}
```
-#### 使用``元素的基于 XML 的方法[](#aop-based-interceptor)
+#### 使用``元素的基于 XML 的方法
基于 XML 的方法允许你配置与基于名称空间的`MessagePublishingInterceptor`配置相同的基于 AOP 的消息发布功能。它当然比注释驱动的方法有一些好处,因为它允许你使用 AOP 切入点表达式,因此可能同时拦截多个方法,或者拦截和发布你没有源代码的方法。
@@ -207,7 +207,7 @@ static class BankingOperationsImpl implements BankingOperations {
前面的示例将匹配切入点表达式的每个方法的返回值映射到一个有效负载,并将其发送到`default-channel`。如果没有指定`defaultChannel`(前面的示例没有这样做),则消息将被发送到全局`nullChannel`(相当于`/dev/null`)。
-##### [](#asynchronous-publishing)异步发布
+##### 异步发布
发布与组件的执行发生在同一个线程中。因此,默认情况下,它是同步的。这意味着整个消息流必须等到发布者的消息流完成。然而,开发人员通常想要完全相反的结果:使用这个消息发布特性来启动异步流。例如,你可能托管一个接收远程请求的服务(HTTP、WS 等)。你可能希望在内部将此请求发送到一个可能需要一段时间的流程中。然而,你也可能希望立即回复用户。因此,与将处理的入站请求发送到输出通道(传统的方式)不同,你可以使用“输出通道”或“replyChannel”头向调用者发送一个简单的类似于确认的答复,同时使用消息发布者功能来启动一个复杂的流。
@@ -245,7 +245,7 @@ public String echo(Object complexPayload) {
处理这种情况的另一种方法是使用线接。见[Wire Tap](./channel.html#channel-wiretap)。
-#### [](#scheduled-producer)基于调度触发器生成和发布消息
+#### 基于调度触发器生成和发布消息
在前面的部分中,我们研究了消息发布特性,该特性将消息作为方法调用的副产品进行构造和发布。但是,在这些情况下,你仍然需要负责调用该方法。 Spring Integration2.0 在“inbound-channel-adapter”元素上添加了对调度消息生成器和发布器的支持,该支持带有新的`expression`属性。你可以基于几个触发器进行调度,其中任何一个都可以在“poller”元素上进行配置。目前,我们支持`cron`、`fixed-rate`、`fixed-delay`以及由你实现并由’trigger’属性值引用的任何自定义触发器。
diff --git a/docs/spring-integration/message-routing.md b/docs/spring-integration/message-routing.md
index 20c415205dc679cf8d94ed9e6eeef1e594ec4c80..fdd49e73de44cb8706fa8078c50bade87c623bc7 100644
--- a/docs/spring-integration/message-routing.md
+++ b/docs/spring-integration/message-routing.md
@@ -1,10 +1,10 @@
# 消息路由
-## [](#messaging-routing-chapter)消息路由
+## 消息路由
本章介绍了使用 Spring 集成路由消息的细节。
-### [](#router)路由器
+### 路由器
本节介绍路由器的工作方式。它包括以下主题:
@@ -20,7 +20,7 @@
* [动态路由器](#dynamic-routers)
-#### [](#router-overview)概述
+#### 概述
路由器是许多消息传递体系结构中的关键元素。它们消耗来自消息通道的消息,并根据一组条件将每个消耗的消息转发到一个或多个不同的消息通道。
@@ -85,11 +85,11 @@ Spring 集成提供了以下路由器:
| |在 Spring Integration2.1 中,路由器参数已经在所有路由器实现中得到了更多的标准化。因此,一些小的更改可能会破坏较旧的 Spring 基于 Integration 的应用程序。,自 Spring Integration2.1 以来,将`ignore-channel-name-resolution-failures`属性删除,以利于将其行为与`resolution-required`属性合并,
此外,`resolution-required`属性现在默认为`true`,
在进行这些更改之前,`resolution-required`属性默认为`false`,当没有解析通道且没有设置`default-output-channel`时,导致消息被静默删除。
新行为需要至少一个解析通道,并且默认情况下,如果没有确定通道(或者发送尝试未成功),则抛出`MessageDeliveryException`。
如果你确实希望静默地删除消息,则可以设置`default-output-channel="nullChannel"`。|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#router-common-parameters)常见路由器参数
+#### 常见路由器参数
本节描述所有路由器参数的公共参数(在本章前面的两个表中勾选了它们的所有方框的参数)。
-##### [](#router-common-parameters-all)链条的内部和外部
+##### 链条的内部和外部
以下参数对链内和链外的所有路由器都有效。
@@ -126,7 +126,7 @@ Spring 集成提供了以下路由器:
`timeout`属性指定向目标消息通道发送消息时等待的最大时间(以毫秒为单位)。默认情况下,发送操作会无限期地阻塞。
-##### [](#router-common-parameters-top)顶层(在链外)
+##### 顶层(在链外)
以下参数仅对链外的所有顶级路由器有效。
@@ -146,11 +146,11 @@ Spring 集成提供了以下路由器:
此属性定义了当此端点作为订阅服务器连接到信道时调用的顺序。当该通道使用故障转移调度策略时,这一点尤其重要。当这个端点本身是具有队列的通道的轮询消费者时,它没有任何作用。
-#### [](#router-implementations)路由器实现
+#### 路由器实现
由于基于内容的路由通常需要一些特定于领域的逻辑,因此大多数用例都需要 Spring 集成的选项,可以通过使用 XML 名称空间支持或注释来将任务委托给 POJO。这两个问题都将在后面讨论。然而,我们首先介绍了几个满足常见需求的实现。
-##### [](#router-implementations-payloadtyperouter)`PayloadTypeRouter`
+##### `PayloadTypeRouter`
a`PayloadTypeRouter`将消息发送到由有效负载类型映射定义的通道,如下例所示:
@@ -223,7 +223,7 @@ public IntegrationFlow routerFlow2() {
}
```
-##### [](#router-implementations-headervaluerouter)`HeaderValueRouter`
+##### `HeaderValueRouter`
a`HeaderValueRouter`基于单独的头部值映射向通道发送消息。当创建`HeaderValueRouter`时,将使用要计算的标头的名称对其进行初始化。页眉的值可以是以下两点中的一点:
@@ -306,7 +306,7 @@ public IntegrationFlow routerFlow2() {
| |自 Spring Integration2.1 以来,解析通道的行为更加明确。例如,如果省略
属性,则路由器无法解析至少一个有效通道,并且通过将`resolution-required`设置为`false`,可以忽略任何通道名称解析失败,然后抛出一个`MessageDeliveryException`。
基本上,默认情况下,路由器必须能够将消息成功路由到至少一个通道。
如果你真的想要删除消息,还必须将`default-output-channel`设置为`nullChannel`。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#router-implementations-recipientlistrouter)`RecipientListRouter`
+##### `RecipientListRouter`
`RecipientListRouter`将接收到的每个消息发送到静态定义的消息通道列表。下面的示例创建了`RecipientListRouter`:
@@ -383,7 +383,7 @@ public IntegrationFlow routerFlow() {
在前面的配置中,对由`selector-expression`属性标识的 SPEL 表达式进行求值,以确定该收件人是否应包括在给定输入消息的收件人列表中。表达式的求值结果必须是布尔值。如果未定义此属性,则通道始终位于收件人列表中。
-##### [](#recipient-list-router-management)`RecipientListRouterManagement`
+##### `RecipientListRouterManagement`
从版本 4.1 开始,`RecipientListRouter`提供了几个操作来在运行时动态地操作收件人。这些管理操作由`RecipientListRouterManagement`通过`@ManagedResource`注释表示。可以通过使用[控制总线](./control-bus.html#control-bus)以及使用 JMX 来获得它们,如下例所示:
@@ -405,11 +405,11 @@ messagingTemplate.convertAndSend(controlBus, "@'simpleRouter.handler'.addRecipie
由于``的运行时管理操作,从一开始就可以在没有任何``的情况下对其进行配置。在这种情况下,当消息没有匹配的收件人时,`RecipientListRouter`的行为是相同的。如果`defaultOutputChannel`被配置,消息将被发送到那里。否则将抛出`MessageDeliveryException`。
-##### [](#router-implementations-xpath-router)XPath 路由器
+##### XPath 路由器
XPath 路由器是 XML 模块的一部分。见[使用 XPath 路由 XML 消息](./xml.html#xml-xpath-routing)。
-##### [](#router-implementations-exception-router)路由和错误处理
+##### 路由和错误处理
Spring 集成还提供了一种特殊的基于类型的路由器,称为`ErrorMessageExceptionTypeRouter`,用于路由错误消息(定义为其`payload`是`Throwable`实例的消息)。`ErrorMessageExceptionTypeRouter`类似于`PayloadTypeRouter`。事实上,它们几乎完全相同。唯一的区别是,虽然`PayloadTypeRouter`导航有效负载实例的实例层次结构(例如,`payload.getClass().getSuperclass()`)以找到最特定的类型和通道映射,但`ErrorMessageExceptionTypeRouter`导航“异常原因”的层次结构(例如,`payload.getCause()`)以找到最特定的`Throwable`类型或通道映射,并使用`mappingClass.isInstance(cause)`将`cause`匹配到类或任何超类。
@@ -434,11 +434,11 @@ Spring 集成还提供了一种特殊的基于类型的路由器,称为`ErrorM
```
-#### [](#router-namespace)配置通用路由器
+#### 配置通用路由器
Spring 集成提供了一种通用的路由器。你可以将其用于通用路由(与 Spring Integration 提供的其他路由器相反,每个路由器都具有某种形式的专门化)。
-##### [](#configuring-a-content-based-router-with-xml)使用 XML 配置基于内容的路由器
+##### 使用 XML 配置基于内容的路由器
`router`元素提供了一种将路由器连接到输入通道的方法,并且还接受可选的`default-output-channel`属性。`ref`属性引用了自定义路由器实现的 Bean 名称(它必须扩展`AbstractMessageRouter`)。下面的示例展示了三种通用路由器:
@@ -526,7 +526,7 @@ public IntegrationFlow routerFlow() {
}
```
-#### [](#router-spel)路由器与 Spring 表达式语言
+#### 路由器与 Spring 表达式语言
有时,路由逻辑可能很简单,为它编写一个单独的类并将其配置为 Bean 可能看起来有些过头。在 Spring Integration2.0 中,我们提供了一种替代方案,允许你使用 SPEL 来实现以前需要自定义 POJO 路由器的简单计算。
@@ -591,7 +591,7 @@ SPEL 用于配置路由器的另一个优点是,表达式可以返回`Collecti
* [收藏选择](https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#expressions-collection-selection)
-##### [](#router-annotation)配置带有注释的路由器
+##### 配置带有注释的路由器
当使用`@Router`注释一个方法时,该方法可以返回`MessageChannel`或`String`类型。在后一种情况下,端点解析通道名,就像解析默认输出通道一样。此外,该方法可以返回单个值,也可以返回集合。如果返回了集合,则将回复消息发送到多个通道。总而言之,以下方法签名都是有效的:
@@ -621,7 +621,7 @@ public List route(@Header("orderStatus") OrderStatus status)
有关路由器配置的更多信息,请参见 Java DSL 章节中的[消息路由器](./dsl.html#java-dsl-routers)。
-#### [](#dynamic-routers)动态路由器
+#### 动态路由器
Spring 集成为常见的基于内容的路由用例提供了相当多的不同的路由器配置,以及将定制路由器实现为 POJO 的选项。例如,`PayloadTypeRouter`提供了一种简单的方式来配置路由器,该路由器基于传入消息的有效负载类型来计算信道,而`HeaderValueRouter`通过评估特定消息头的值来配置路由器来计算信道,从而提供了相同的便利。也有基于表达式的路由器,其中信道是基于对表达式的求值来确定的。所有这些类型的路由器都表现出一些动态特性。
@@ -700,7 +700,7 @@ Spring 集成为常见的基于内容的路由用例提供了相当多的不同
| |返回到通道键,因为通道名是灵活和方便的,
但是,如果你不信任消息创建者,恶意参与者(了解系统)可能会创建一条消息,并将其路由到一个意外的通道。,例如,因此,你可能希望禁用此功能(将`channelKeyFallback`属性设置为`false`),并在需要时更改映射。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#dynamic-routers-control-bus)使用控制总线管理路由器映射
+##### 使用控制总线管理路由器映射
Spring 管理路由器映射的一种方法是通过[控制总线](https://www.enterpriseintegrationpatterns.com/ControlBus.html)模式,该模式公开了一个控制通道,你可以向其发送控制消息以管理和监视集成组件,包括路由器。
@@ -725,14 +725,14 @@ Spring 管理路由器映射的一种方法是通过[控制总线](https://www.e
请注意,每个映射都用一个换行符分隔(`\n`)。对于映射的编程更改,出于类型安全考虑,我们建议你使用`setChannelMappings`方法。`replaceChannelMappings`忽略不是`String`对象的键或值。
-##### [](#dynamic-routers-jmx)使用 JMX 管理路由器映射
+##### 使用 JMX 管理路由器映射
你还可以使用 Spring 的 JMX 支持来公开一个路由器实例,然后使用你最喜欢的 JMX 客户机(例如,JConsole)来管理那些用于更改路由器配置的操作(方法)。
| |有关 Spring Integration 的 JMX 支持的更多信息,请参见[JMX 支持](./jmx.html#jmx)。|
|---|-----------------------------------------------------------------------------------------------|
-##### [](#routing-slip)路由条
+##### 路由条
Spring 从版本 4.1 开始,集成提供了[布线滑移](https://www.enterpriseintegrationpatterns.com/RoutingTable.html)Enterprise 集成模式的实现。它被实现为`routingSlip`消息头,当没有为端点指定`outputChannel`时,它用于在`AbstractMessageProducingHandler`实例中确定下一个通道。这种模式在复杂、动态的情况下很有用,因为很难配置多个路由器来确定消息流。当消息到达没有`output-channel`的端点时,将查询`routingSlip`以确定将消息发送到的下一个通道。当路由滑移耗尽时,恢复正常的`replyChannel`处理。
@@ -802,7 +802,7 @@ public HeaderEnricher headerEnricher() {
* 当`routingSlipIndex`超过路由单`path`列表的大小时,算法将移动到标准`replyChannel`报头的默认行为。
-#### [](#process-manager)Process Manager Enterprise 集成模式
+#### Process Manager Enterprise 集成模式
Enterprise 集成模式包括[过程管理器](https://www.enterpriseintegrationpatterns.com/ProcessManager.html)模式。现在,你可以通过使用封装在路由条中的`RoutingSlipRouteStrategy`中的自定义流程管理器逻辑轻松地实现此模式。除了 Bean 名称之外,`RoutingSlipRouteStrategy`还可以返回任何`MessageChannel`对象,并且不要求该`MessageChannel`实例在应用程序上下文中是 Bean。这样,当无法预测应该使用哪个信道时,我们可以提供强大的动态路由逻辑。可以在`RoutingSlipRouteStrategy`中创建`MessageChannel`并返回。对于这样的情况,`FixedSubscriberChannel`与`MessageHandler`相关联的实现是一个很好的组合。例如,你可以路由到[反应流](https://projectreactor.io/docs/core/release/reference/#getting-started),如下例所示:
@@ -825,7 +825,7 @@ public RoutingSlipRouteStrategy routeStrategy() {
}
```
-### [](#filter)过滤器
+### 过滤器
消息筛选器用于根据某些条件(例如消息头值或消息内容本身)来决定是否应该传递`Message`。因此,消息过滤器类似于路由器,但对于从过滤器的输入通道接收的每个消息,相同的消息可能会也可能不会发送到过滤器的输出通道。与路由器不同,它不会决定将消息发送到哪个消息通道,而只会决定是否发送消息。
@@ -850,7 +850,7 @@ MessageFilter filter = new MessageFilter(someSelector);
结合名称空间和 SPEL,你可以用很少的 Java 代码配置强大的过滤器。
-#### [](#filter-xml)使用 XML 配置过滤器
+#### 使用 XML 配置过滤器
可以使用``元素来创建消息选择端点。除了`input-channel`和`output-channel`属性外,它还需要一个`ref`属性。`ref`可以指向`MessageSelector`实现,如下例所示:
@@ -940,7 +940,7 @@ filterPatterns.example=payload > 100
| |所有这些使用`expression`作为属性或子元素的示例也可以应用于 Transformer、Router、Splitter、Service-Activator 和 Header-Enrich 元素中,
给定组件类型的语义和角色将影响对评估结果的解释,与方法调用的返回值将被解释的方式相同。
例如,表达式可以返回将被路由器组件视为消息通道名的字符串。
但是,在 Spring 集成范围内的所有核心 EIP 组件中,根据作为根对象的消息计算表达式并解析 Bean 名称(如果前缀为’@’)的底层功能是一致的。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#filter-annotations)配置带有注释的过滤器
+#### 配置带有注释的过滤器
下面的示例展示了如何通过使用注释来配置过滤器:
@@ -963,11 +963,11 @@ XML 元素提供的所有配置选项也可用于`@Filter`注释。
另见[使用注释为端点提供建议](./handler-advice.html#advising-with-annotations)。
-### [](#splitter)splitter
+### splitter
拆分器是一个组件,其作用是将消息划分为多个部分,并将生成的消息发送给要独立处理的部分。通常情况下,他们是包括聚合器的管道中的上游生产者。
-#### [](#programming-model)编程模型
+#### 编程模型
用于执行拆分的 API 由一个基类组成,`AbstractMessageSplitter`。它是一个`MessageHandler`实现,它封装了拆分器常见的功能,例如在生成的消息上填充适当的消息头(`CORRELATION_ID`、`SEQUENCE_SIZE`和`SEQUENCE_NUMBER`)。这种填充可以跟踪消息及其处理结果(在典型的场景中,这些头被复制到由各种转换端点产生的消息)。然后可以使用这些值,例如,由[组合消息处理器](https://www.enterpriseintegrationpatterns.com/DistributionAggregate.html)使用。
@@ -992,7 +992,7 @@ public abstract class AbstractMessageSplitter
在 Spring 集成中,任何 POJO 都可以实现分割算法,前提是它定义了一个接受单个参数并具有返回值的方法。在这种情况下,方法的返回值被解释为如前所述。输入参数可以是`Message`,也可以是简单的 POJO。在后一种情况下,拆分器接收传入消息的有效负载。我们推荐这种方法,因为它将代码与 Spring Integration API 分离,并且通常更容易测试。
-##### [](#iterators)迭代器
+##### 迭代器
从版本 4.1 开始,`AbstractMessageSplitter`支持`Iterator`类型来分割`value`。注意,在`Iterator`(或`Iterable`)的情况下,我们无法访问底层项的数量,并且`SEQUENCE_SIZE`头被设置为`0`。这意味着``的`SequenceSizeReleaseStrategy`的默认`SequenceSizeReleaseStrategy`将不工作,并且来自`splitter`的`CORRELATION_ID`的组将不会被释放;它将保持为`incomplete`。在这种情况下,你应该使用适当的自定义`ReleaseStrategy`,或者将`send-partial-result-on-expiry`与`group-timeout`或`MessageGroupStoreReaper`一起使用。
@@ -1000,7 +1000,7 @@ public abstract class AbstractMessageSplitter
`Iterator`对象可以避免在拆分前在内存中构建整个集合的需要。例如,当底层项使用迭代或流从某些外部系统(例如数据库或 FTP`MGET`)填充时。
-##### [](#split-stream-and-flux)流和通量
+##### 流和通量
从版本 5.0 开始,`AbstractMessageSplitter`支持用于分割`value`的 Java`Stream`和反应流`Publisher`类型。在这种情况下,目标`Iterator`是建立在它们的迭代功能之上的。
@@ -1008,7 +1008,7 @@ public abstract class AbstractMessageSplitter
从版本 5.2 开始,Splitter 支持一个`discardChannel`选项,用于发送那些请求消息,对于这些请求消息,Split 函数返回了一个空的容器(集合、数组、流、`Flux`等)。在这种情况下,没有要迭代的项用于发送到`outputChannel`。将`null`分割结果保留为流指示器的结束。
-#### [](#configuring-a-splitter-with-xml)使用 XML 配置拆分器
+#### 使用 XML 配置拆分器
可以通过 XML 将拆分器配置如下:
@@ -1050,7 +1050,7 @@ public abstract class AbstractMessageSplitter
| |如果`ref`属性引用扩展`AbstractMessageProducingHandler`的 Bean(例如框架本身提供的分割器),则通过将输出通道直接注入处理程序来优化配置。,在这种情况下,
,每个`ref`必须是一个单独的 Bean 实例(或`prototype`-作用域 Bean),或者使用内部``配置类型。
但是,只有当你在 Splitter XML 定义中没有提供任何特定于 Splitter 的属性时,此优化才会应用。
如果你无意中从多个 bean 引用了相同的消息处理程序,则会出现配置异常。|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#configuring-a-splitter-with-annotations)配置带有注释的拆分器
+#### 配置带有注释的拆分器
`@Splitter`注释适用于期望`Message`类型或消息有效负载类型的方法,并且方法的返回值应该是任何类型的`Collection`。如果返回的值不是实际的`Message`对象,则将每个项包装在`Message`中,作为`Message`的有效负载。每个结果`Message`都被发送到用于定义`@Splitter`的端点的指定输出通道。
@@ -1065,13 +1065,13 @@ List extractItems(Order order) {
另见[使用注释为端点提供建议](./handler-advice.html#advising-with-annotations),[Splitters](./dsl.html#java-dsl-splitters)和[文件拆分器](./file.html#file-splitter)。
-### [](#aggregator)聚合器
+### 聚合器
聚合器基本上是拆分器的镜像,是一种消息处理程序,它接收多个消息并将它们合并为一个消息。实际上,聚合器通常是包含拆分器的管道中的下游消费者。
从技术上讲,聚合器比拆分器更复杂,因为它是有状态的。它必须保存要聚合的消息,并确定何时可以聚合完整的消息组。为了做到这一点,它需要`MessageStore`。
-#### [](#aggregator-functionality)功能
+#### 功能
聚合器通过关联和存储一组相关消息来组合一组相关消息,直到该组被认为是完整的。此时,聚合器通过处理整个组创建一个消息,并将聚合的消息作为输出发送。
@@ -1081,7 +1081,7 @@ List extractItems(Order order) {
要确定准备好处理一组消息的时间点,请参考`ReleaseStrategy`。当序列中包含的所有消息都存在时,聚合器的默认发布策略将基于`IntegrationMessageHeaderAccessor.SEQUENCE_SIZE`头发布一个组。你可以通过提供对自定义`ReleaseStrategy`实现的引用来覆盖此默认策略。
-#### [](#aggregator-api)编程模型
+#### 编程模型
聚合 API 由多个类组成:
@@ -1091,7 +1091,7 @@ List extractItems(Order order) {
* `CorrelationStrategy`接口及其默认实现:`HeaderAttributeCorrelationStrategy`
-##### [](#aggregatingmessagehandler)`AggregatingMessageHandler`
+##### `AggregatingMessageHandler`
`AggregatingMessageHandler`(`AbstractCorrelatingMessageHandler`的子类)是`MessageHandler`实现,封装了聚合器(和其他相关用例)的公共功能,如下所示:
@@ -1174,7 +1174,7 @@ public AbstractCorrelatingMessageHandler(MessageGroupProcessor processor, Messag
这使得聚合器作为消息屏障工作,在此过程中,到达的消息将被保存,直到发布策略触发,并且将组作为单个消息的序列发布。
-##### [](#releasestrategy)`ReleaseStrategy`
+##### `ReleaseStrategy`
`ReleaseStrategy`接口定义如下:
@@ -1231,7 +1231,7 @@ Spring 集成为`ReleaseStrategy`提供了一种实现方式:`SimpleSequenceSi
如果你要聚合大的群组,你不需要释放部分群组,也不需要检测/拒绝重复的序列,考虑使用`SimpleSequenceSizeReleaseStrategy`代替,它对这些用例来说效率要高得多,并且是自*版本 5.0*未指定部分分组发布时的默认设置。
-##### [](#aggregating-large-groups)聚合大型群组
+##### 聚合大型群组
4.3 版本将`SimpleMessageGroup`中的消息的默认`Collection`更改为`HashSet`(以前是`BlockingQueue`)。当从大的组中删除单个消息(需要 O(n)线性扫描)时,这是昂贵的。尽管散列集通常可以更快地删除,但对于大消息来说,它可能会很昂贵,因为散列集必须在插入和删除两个部分上计算。如果你的消息散列成本很高,请考虑使用其他类型的集合。正如[使用`MessageGroupFactory`](./message-store.html#message-group-factory)中所讨论的,提供了一个`SimpleMessageGroupFactory`,以便你可以选择最适合你的需要的`Collection`。你还可以提供你自己的工厂实现来创建一些其他`Collection>`。
@@ -1255,7 +1255,7 @@ Spring 集成为`ReleaseStrategy`提供了一种实现方式:`SimpleSequenceSi
| |如果过滤器端点涉及聚合器的上游流,序列大小发布策略(固定的或基于`sequenceSize`报头)不会达到其目的,因为来自序列的一些消息可能会被过滤器丢弃,
在这种情况下,建议选择另一种`ReleaseStrategy`,或者使用从丢弃子流发送的补偿消息,在其内容中携带一些信息,以便在自定义的完整组函数中跳过。
有关更多信息,请参见[Filter](./filter.html#filter)。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#correlation-strategy)相关策略
+##### 相关策略
`CorrelationStrategy`接口定义如下:
@@ -1273,11 +1273,11 @@ public interface CorrelationStrategy {
Spring 集成为`CorrelationStrategy`提供了一种实现方式:`HeaderAttributeCorrelationStrategy`。此实现返回一个消息头的值(其名称由构造函数参数指定)作为相关键。默认情况下,相关策略是一个`HeaderAttributeCorrelationStrategy`,它返回`CORRELATION_ID`header 属性的值。如果你有一个自定义的头名称,那么你可以在`HeaderAttributeCorrelationStrategy`的实例上配置它,并将其作为聚合器的相关策略的参考。
-##### [](#lock-registry)锁定注册表
+##### 锁定注册表
对组的更改是线程安全的。因此,当你并发地为相同的相关 ID 发送消息时,聚合器中只会处理其中的一个消息,从而使其有效地成为**每个消息组的单线程**。a`LockRegistry`用于获得解析的相关 ID 的锁。默认情况下(内存中)使用`DefaultLockRegistry`。要在使用共享`MessageGroupStore`的服务器上同步更新,必须配置共享锁注册中心。
-##### [](#aggregator-deadlocks)避免死锁
+##### 避免死锁
如上所述,当消息组发生突变(添加或释放消息)时,将保持锁定。
@@ -1311,11 +1311,11 @@ Found one Java-level deadlock:
| |如果由于某种原因,单个聚合器的输出最终被路由回相同的聚合器,也可能导致此问题。
当然,上面的第一个解决方案在这种情况下不适用。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#aggregator-java-dsl)在 Java DSL 中配置聚合器
+#### 在 Java DSL 中配置聚合器
有关如何在 Java DSL 中配置聚合器,请参见[聚合器和重排序器](./dsl.html#java-dsl-aggregators)。
-##### [](#aggregator-xml)使用 XML 配置聚合器
+##### 使用 XML 配置聚合器
Spring 集成支持通过``元素配置带有 XML 的聚合器。下面的示例展示了聚合器的示例:
@@ -1464,7 +1464,7 @@ public class PojoCorrelationStrategy {
| |只要这样做是有意义的,释放策略方法、相关策略方法和聚合器方法就可以合并为一个 Bean。
(实际上,它们中的所有或任意两个都可以合并。)|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-###### [](#aggregator-spel)聚合器和 Spring 表达式语言
+###### 聚合器和 Spring 表达式语言
Spring Integration2.0 以来,你可以使用[SpEL](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#expressions)处理各种策略(相关、发布和聚合),如果这样的发布策略背后的逻辑相对简单,我们推荐使用这种策略。假设你有一个设计用于接收对象数组的遗留组件。我们知道,默认的发布策略在`List`中组装了所有聚合的消息。现在我们有两个问题。首先,我们需要从列表中提取单个消息。其次,我们需要提取每个消息的有效负载并组装对象数组。下面的示例解决了这两个问题:
@@ -1509,7 +1509,7 @@ release-strategy-expression="!messages.?[payload==5].empty"
在前面的示例中,SPEL 求值上下文的根对象是`MessageGroup`本身,并且你正在声明,一旦在这个组中出现有效负载`5`的消息,就应该释放该组。
-###### [](#agg-and-group-to)聚合器和组超时
+###### 聚合器和组超时
从版本 4.0 开始,引入了两个新的互斥属性:`group-timeout`和`group-timeout-expression`。见[使用 XML 配置聚合器](#aggregator-xml)。在某些情况下,如果`ReleaseStrategy`在当前消息到达时未释放,则可能需要在超时后发出聚合器结果(或丢弃该组)。为此,`groupTimeout`选项允许强制完成调度`MessageGroup`,如下例所示:
@@ -1532,7 +1532,7 @@ release-strategy-expression="!messages.?[payload==5].empty"
group-timeout-expression="size() ge 2 ? new java.util.Date(timestamp + 200) : null"
```
-##### [](#aggregator-annotations)配置带有注释的聚合器
+##### 配置带有注释的聚合器
下面的示例展示了一个配置了注释的聚合器:
@@ -1587,7 +1587,7 @@ public MessageHandler aggregator(MessageGroupStore jdbcMessageGroupStore) {
| |从版本 4.2 开始,`AggregatorFactoryBean`可用于简化`AggregatingMessageHandler`的 Java 配置。|
|---|---------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#reaper)在聚合器中管理状态:`MessageGroupStore`
+#### 在聚合器中管理状态:`MessageGroupStore`
聚合器(以及 Spring Integration 中的一些其他模式)是一种有状态的模式,该模式要求基于一组在一段时间内到达的消息做出决策,所有这些消息都具有相同的相关键。在有状态模式(例如`ReleaseStrategy`)中,接口的设计是由以下原则驱动的:组件(无论是由框架还是由用户定义的)应该能够保持无状态。所有状态都由`MessageGroup`承载,其管理被委托给`MessageGroupStore`。`MessageGroupStore`接口定义如下:
@@ -1667,7 +1667,7 @@ Spring 为方便用户,集成以`MessageGroupStoreReaper`的形式为消息过
| |当共享的`MessageStore`用于不同的相关端点时,必须配置适当的`CorrelationStrategy`以确保组 ID 的唯一性。
否则,当一个相关端点从其他端点释放或过期消息时,可能会发生意外行为。
具有相同相关键的消息存储在相同的消息组中。
某些`MessageStore`实现允许使用相同的物理资源,通过对数据进行分区。例如,
,`JdbcMessageStore`具有`region`属性,而`MongoDbMessageStore`具有`collectionName`属性。`MessageGroup`
有关`MessageStore`接口及其实现的更多信息,请参见[消息存储](./message-store.html#message-store)。|
|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#flux-aggregator)通量聚合器
+#### 通量聚合器
在版本 5.2 中,引入了`FluxAggregatorMessageHandler`组件。它是基于项目反应器`Flux.groupBy()`和`Flux.window()`的运营商。传入消息被发送到由该组件的构造函数中的`Flux.create()`发起的`FluxSink`中。如果不提供`outputChannel`或者它不是`ReactiveStreamsSubscribableChannel`的实例,则订阅主`Flux`是从`Lifecycle.start()`实现完成的。否则它将被推迟到由`ReactiveStreamsSubscribableChannel`实现所完成的订阅。消息由`Flux.groupBy()`分组,使用用于组键的`CorrelationStrategy`。默认情况下,查询消息的`IntegrationMessageHeaderAccessor.CORRELATION_ID`头。
@@ -1717,11 +1717,11 @@ Flux> window =
另见[文件聚合器](./file.html#file-aggregator)。
-### [](#resequencer)重序器
+### 重序器
重测序器与聚合器相关,但具有不同的目的。当聚合器合并消息时,重排序程序在不更改消息的情况下传递消息。
-#### [](#resequencer-functionality)功能
+#### 功能
重序器的工作方式与聚合器类似,它使用`CORRELATION_ID`将消息分组存储。不同之处在于,重排序程序不会以任何方式处理消息。相反,它以`SEQUENCE_NUMBER`标头值的顺序释放它们。
@@ -1730,7 +1730,7 @@ Flux> window =
| |重序器的目的是对具有较小间隙的相对较短的消息序列进行重新排序。
如果你有大量具有许多间隙的不相交序列,那么你可能会遇到性能问题。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#configuring-a-resequencer)配置重排序程序
+#### 配置重排序程序
有关在 Java DSL 中配置重排序程序,请参见[聚合器和重排序器](./dsl.html#java-dsl-aggregators)。
@@ -1794,7 +1794,7 @@ Flux> window =
| |由于在 爪哇 类中没有针对重序列器实现的自定义行为,因此没有对它的注释支持。|
|---|----------------------------------------------------------------------------------------------------------------------------|
-### [](#chain)消息处理程序链
+### 消息处理程序链
`MessageHandlerChain`是`MessageHandler`的一种实现,它可以被配置为单个消息端点,同时实际上将其委托给一系列其他处理程序,例如过滤器、转换器、拆分器等。当多个处理程序需要以固定的线性级数连接时,这可能会导致更简单的配置。例如,在提供变压器之前提供其他组件是相当常见的。类似地,当你在链中的其他组件之前提供一个过滤器时,实质上创建了[选择性消费者](https://www.enterpriseintegrationpatterns.com/MessageSelector.html)。在这两种情况下,链只需要一个`input-channel`和一个`output-channel`,从而无需为每个单独的组件定义通道。
@@ -1813,7 +1813,7 @@ Flux> window =
在大多数情况下,你不需要自己实现`MessageHandler`。下一节将重点介绍对 Chain 元素的命名空间支持。 Spring 大多数集成端点,例如服务激活器和转换器,适合在`MessageHandlerChain`内使用。
-#### [](#chain-namespace)配置链
+#### 配置链
``元素提供了一个`input-channel`属性。如果链中的最后一个元素能够生成回复消息(可选的),那么它还支持`output-channel`属性。然后,子元素是过滤器、变压器、分离器和服务激活器。最后一个元素也可以是路由器或出站通道适配器。下面的示例展示了一个链定义:
@@ -1845,7 +1845,7 @@ Flux> window =
| |不允许的属性和元素
某些属性,例如`order`和`input-channel`不允许在链内使用的组件上指定。
对于 poller 子元素也是如此。
对于 Spring 集成核心组件,
,但是,对于非核心组件或你自己的定制组件,这些约束是由 XML 名称空间解析器强制执行的,不是通过 XML 模式。
这些 XML 名称空间解析器约束是在 Spring Integration2.2 中添加的。
如果尝试使用不允许的属性和元素,XML 名称空间解析器将抛出`BeanDefinitionParsingException`。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#using-the-id-attribute)使用’id’属性
+#### 使用’id’属性
从 Spring Integration3.0 开始,如果给一个 chain 元素一个`id`属性,则该元素的 Bean 名称是链的`id`和元素本身的`id`的组合。没有`id`属性的元素不被注册为 bean,但是每个元素都被赋予了一个`componentName`,其中包含了链`id`。考虑以下示例:
@@ -1873,7 +1873,7 @@ Flux> window =
| |在``元素上提供显式的`id`属性是有用的,以简化日志中的子组件的标识,并提供从`BeanFactory`等对它们的访问。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#chain-gateway)从链内调用链子
+#### 从链内调用链子
有时,你需要从一个链中对另一个链进行嵌套调用,然后返回并继续在原来的链中执行。要实现这一点,你可以通过包含一个 \元素来使用消息传递网关,如下例所示:
@@ -1910,7 +1910,7 @@ Flux> window =
在前面的示例中,`nested-chain-a`是在`main-chain`处理结束时由在那里配置的’gateway’元素调用的。而在`nested-chain-a`中,对`nested-chain-b`的调用是在 header 充实之后进行的。然后流返回以在`nested-chain-b`中完成执行。最后,该流返回`main-chain`。当在链中定义``元素的嵌套版本时,它不需要`service-interface`属性。相反,它以当前状态接收消息,并将其放置在`request-channel`属性中定义的通道上。当由该网关发起的下游流完成时,一个`Message`被返回到网关,并继续其在当前链中的行程。
-### [](#scatter-gather)分散收集
+### 分散收集
从版本 4.1 开始, Spring 集成提供了[分散收集](https://www.enterpriseintegrationpatterns.com/BroadcastAggregate.html)Enterprise 集成模式的实现。它是一个复合端点,其目标是向收件人发送消息并汇总结果。正如[*Enterprise 整合模式 *](https://www.enterpriseintegrationpatterns.com/)中所指出的,它是“最佳报价”等场景的组件,在这种情况下,我们需要从几个供应商那里请求信息,并决定哪个供应商为我们提供所请求的项目的最佳术语。
@@ -1918,15 +1918,15 @@ Flux> window =
`ScatterGatherHandler`是一个请求-回复端点,它结合了`PublishSubscribeChannel`(或`RecipientListRouter`)和`AggregatingMessageHandler`。请求消息被发送到`scatter`通道,而`ScatterGatherHandler`等待聚合器发送给`outputChannel`的回复。
-#### [](#scatter-gather-functionality)功能
+#### 功能
`Scatter-Gather`模式提出了两种情况:“拍卖”和“分销”。在这两种情况下,`aggregation`函数是相同的,并且提供了`AggregatingMessageHandler`的所有可用选项。(实际上,`ScatterGatherHandler`只需要一个`AggregatingMessageHandler`作为构造函数参数。)有关更多信息,请参见[Aggregator](./aggregator.html#aggregator)。
-##### [](#auction)拍卖
+##### 拍卖
拍卖`Scatter-Gather`变体对请求消息使用“发布-订阅”逻辑,其中“分散”通道是带有`PublishSubscribeChannel`的`apply-sequence="true"`。然而,这个通道可以是任何`MessageChannel`实现(就像`request-channel`中的`ContentEnricher`—参见[内容更丰富](./content-enrichment.html#content-enricher)中的`request-channel`一样)。但是,在这种情况下,你应该为`aggregation`函数创建自己的自定义`correlationStrategy`。
-##### [](#distribution)分布
+##### 分布
该发行版`Scatter-Gather`变体基于`RecipientListRouter`(参见[`RecipientListRouter`](./router.html#router-implementations-reciscuentlistrouter)),具有`RecipientListRouter`的所有可用选项。这是第二个`ScatterGatherHandler`构造函数参数。如果你希望仅依赖`correlationStrategy`的`recipient-list-router`和`aggregator`的默认`correlationStrategy`,则应该指定`apply-sequence="true"`。否则,你应该为`aggregator`提供一个自定义`correlationStrategy`。与`PublishSubscribeChannel`变体(拍卖变体)不同,具有`recipient-list-router``selector`选项可以基于消息过滤目标供应商。使用`apply-sequence="true"`,将提供默认的`sequenceSize`,并且`aggregator`可以正确地释放该组。分配选项与拍卖选项是互斥的。
@@ -1934,7 +1934,7 @@ Flux> window =
默认情况下,所有供应商都应该将其结果发送到`replyChannel`头(通常通过省略最终端点的`output-channel`)。但是,还提供了`gatherChannel`选项,允许供应商将其答复发送到该聚合通道。
-#### [](#scatter-gather-namespace)配置分散收集端点
+#### 配置分散收集端点
下面的示例显示了`Scatter-Gather` Bean 定义的 Java 配置:
@@ -2004,7 +2004,7 @@ public MessageHandler scatterGatherDistribution() {
|**12**|将``选项.
选项.
与`scatter-channel`属性互斥。|
|**13**|需要``选项。
选项。|
-#### [](#scatter-gather-error-handling)错误处理
+#### 错误处理
由于 Scatter-Gather 是一个多请求-应答组件,错误处理有一些额外的复杂性。在某些情况下,如果`ReleaseStrategy`允许进程以比请求更少的回复来完成任务,那么最好只捕获并忽略下游异常。在其他情况下,当发生错误时,应该考虑从子流返回“补偿消息”之类的内容。
@@ -2046,7 +2046,7 @@ public Message> processAsyncScatterError(MessagingException payload) {
| |在将分散的结果发送给收集者之前,`ScatterGatherHandler`将恢复请求消息头,如果有的话,包括回复和错误通道,
这样,来自`AggregatingMessageHandler`的错误将传播给调用者,即使在分散的接收者子流中应用了异步关闭。
要成功地进行操作,必须将`gatherResultChannel`,`originalReplyChannel`和`originalErrorChannel`标题从分散的接收者子流中传输回答复。,在这种情况下,
是合理的,必须为`gatherTimeout`配置有限的`ScatterGatherHandler`。
否则,默认情况下,将永远阻止它等待收集者的回复。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-### [](#barrier)螺纹屏障
+### 螺纹屏障
有时,我们需要挂起消息流线程,直到发生其他异步事件。例如,考虑一个向 RabbitMQ 发布消息的 HTTP 请求。在 RabbitMQ 代理发出消息已被接收的确认消息之前,我们可能不希望回复用户。
diff --git a/docs/spring-integration/message-transformation.md b/docs/spring-integration/message-transformation.md
index 7f26a19c513e7c330e53fc9a69e6fce819e3f329..2bd740684046055fbb98f4c286269e0ab72e6cd8 100644
--- a/docs/spring-integration/message-transformation.md
+++ b/docs/spring-integration/message-transformation.md
@@ -1,8 +1,8 @@
# 消息转换
-## [](#messaging-transformation-chapter)消息转换
+## 消息转换
-### [](#transformer)转换器
+### 转换器
消息转换器在实现消息生产者和消息消费者之间的松耦合方面发挥着非常重要的作用。你可以在这些组件之间添加转换器,而不是要求每个产生消息的组件都知道下一个使用者期望的类型。通用的转换器,例如将`String`转换为 XML 文档的转换器,也是高度可重用的。
@@ -11,7 +11,7 @@
| |为了最大限度地提高灵活性, Spring 不需要基于 XML 的消息有效负载。
不过,如果这确实是你的应用程序的正确选择,那么该框架确实为处理基于 XML 的有效负载提供了一些方便的转换器。
有关这些转换器的更多信息,请参见[XML 支持-处理 XML 有效负载](./xml.html#xml)。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#transformer-namespace)使用 XML 配置转换器
+#### 使用 XML 配置转换器
``元素用于创建消息转换端点。除了`input-channel`和`output-channel`属性外,它还需要一个`ref`属性。`ref`可以指向单个方法上包含`@Transformer`注释的对象(参见[用注解配置转换器](#transformer-annotation)),也可以与`method`属性中提供的显式方法名值结合。
@@ -40,7 +40,7 @@
在 Spring Integration2.0 中,消息转换器的转换方法不再能够返回`null`。返回`null`将导致一个异常,因为消息转换器应该始终被期望将每个源消息转换为有效的目标消息。换句话说,消息转换器不应该被用作消息过滤器,因为它有一个专用的``选项。但是,如果你确实需要这种类型的行为(其中组件可能会返回`null`,这不应被视为错误),则可以使用服务激活器。其`requires-reply`值默认为`false`,但可以设置为`true`,以便为`null`抛出异常返回值,就像转换器一样。
-#### [](#transformers-and-spring-expression-language-spel)转换器与 Spring 表达式语言
+#### 转换器与 Spring 表达式语言
与路由器、聚合器和其他组件一样,在 Spring Integration2.0 中,只要转换逻辑相对简单,转换器也可以从[SPEL 支持](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#expressions)中受益。下面的示例展示了如何使用 SPEL 表达式:
@@ -52,11 +52,11 @@
前面的示例在不编写自定义转换器的情况下转换有效负载。我们的有效负载(假定为`String`)是上层的,与当前的时间戳连接在一起,并应用了一些格式。
-#### [](#common-transformers)通用转换器
+#### 通用转换器
Spring 集成提供了一些转换器实现方式。
-##### [](#object-to-string-transformer)对象到字符串转换器
+##### 对象到字符串转换器
因为使用`toString()`表示`Object`是相当常见的, Spring 集成提供了一个`ObjectToStringTransformer`,其输出是带有字符串`payload`的`Message`。这个`String`是在入站消息的有效负载上调用`toString()`操作的结果。下面的示例展示了如何声明对象到字符串转换器的实例:
@@ -84,7 +84,7 @@ Spring 集成提供了一些转换器实现方式。
| |当反序列化来自不受信任的源的数据时,你应该考虑添加一个`allow-list`的包和类模式。
默认情况下,所有类都是反序列化的。|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#object-to-map-and-map-to-object-transformers)`Object`-to-`Map`和`Map`-to-`Object`转换器
+##### `Object`-to-`Map`和`Map`-to-`Object`转换器
Spring 集成还提供了`Object`-to-`Map`和`Map`-to-`Object`转换器,它们使用 JSON 序列化和反序列化对象图。对象层次结构被内省到最原始的类型(`String`,`int`,等等)。这种类型的路径是用 SPEL 描述的,它在转换的`Map`中成为`key`。原语类型成为值。
@@ -186,7 +186,7 @@ Spring 集成为映射到对象提供了名称空间支持,如下例所示:
从版本 5.0 开始,你可以为`ObjectToMapTransformer`提供自定义的`JsonObjectMapper`——当你需要为空集合的日期或空集合(以及其他用途)提供特殊格式时。有关`JsonObjectMapper`实现的更多信息,请参见[JSON 转换器](#json-transformers)。
-##### [](#stream-transformer)流转换器
+##### 流转换器
`StreamTransformer`将`InputStream`有效载荷转换为`byte[]`(如果提供了`charset`,则转换为<`String`)。
@@ -215,7 +215,7 @@ public StreamTransformer streamToString() {
}
```
-##### [](#json-transformers)JSON 转换器
+##### JSON 转换器
Spring 集成提供了对象到 JSON 和 JSON 到对象转换器。以下两个示例展示了如何用 XML 声明它们:
@@ -298,7 +298,7 @@ Spring 除了 JSON Transformers 之外,Integration 还提供了一个用于表
从版本 5.2.6 开始,`JsonToObjectTransformer`可以提供一个`valueTypeExpression`来解析一个`ResolvableType`,以便在运行时根据请求消息从 JSON 转换有效负载。默认情况下,它在请求消息中查询`JsonHeaders`。如果这个表达式返回`null`或`ResolvableType`building 抛出一个`ClassNotFoundException`,则转换器返回到所提供的`targetType`。这个逻辑以表达式的形式存在,因为`JsonHeaders`可能没有真正的类值,而是一些类型 ID,这些类型 ID 必须根据某些外部注册中心映射到目标类。
-##### [](#Avro-transformers)Apache AVROTransformers
+##### Apache AVROTransformers
版本 5.2 增加了简单的转换器,以转换到/从 Apache AVRO。
@@ -308,7 +308,7 @@ Spring 除了 JSON Transformers 之外,Integration 还提供了一个用于表
`SimpleToAvroTransformer`也有一个`setTypeExpression`方法。这允许生产者和消费者分离,在这种情况下,发送者可以将头设置为表示类型的某个令牌,然后消费者将该令牌映射到类型。
-#### [](#transformer-annotation)配置带有注释的转换器
+#### 配置带有注释的转换器
你可以将`@Transformer`注释添加到需要`Message`类型或消息有效负载类型的方法中。返回值的处理方式与前面(在描述``元素的一节中)描述的完全相同。下面的示例展示了如何使用`@Transformer`注释将`String`转换为`Order`:
@@ -330,7 +330,7 @@ Order generateOrder(String productId, @Header("customerName") String customer) {
另见[使用注释为端点提供建议](./handler-advice.html#advising-with-annotations)。
-#### [](#header-filter)页眉过滤器
+#### 页眉过滤器
有时,你的转换用例可能很简单,只需删除几个标题即可。对于这样的用例, Spring Integration 提供了一个头过滤器,它允许你指定应该从输出消息中删除的某些头名称(例如,出于安全原因删除头,或者仅暂时需要的值)。基本上,header 过滤器与 header enricher 相反。后者在[页眉 Enricher](./content-enrichment.html#header-enricher)中讨论。下面的示例定义了一个头过滤器:
@@ -341,11 +341,11 @@ Order generateOrder(String productId, @Header("customerName") String customer) {
正如你所看到的,头过滤器的配置非常简单。它是一个典型的端点,具有输入和输出通道以及`header-names`属性。该属性接受需要删除的标头的名称(如果有多个标头,则用逗号分隔)。因此,在前面的示例中,出站消息中不存在名为“lastname”和“state”的头。
-#### [](#codec-based-transformers)基于编解码器的转换器
+#### 基于编解码器的转换器
见[Codec](./codec.html#codec)。
-### [](#content-enricher)内容更丰富
+### 内容更丰富
有时,你可能需要使用比目标系统提供的更多信息来增强请求。[数据收集器](https://www.enterpriseintegrationpatterns.com/DataEnricher.html)模式描述了各种场景以及允许你满足此类需求的组件。
@@ -367,7 +367,7 @@ Spring Integration`Core`模块包括两个增强器:
有关表达式支持的更多信息,请参见[Spring Expression Language (SpEL)](./spel.html#spel)。
-#### [](#header-enricher)页眉 Enricher
+#### 页眉 Enricher
如果只需要向消息添加头,而头不是由消息内容动态确定的,那么引用 Transformer 的自定义实现可能会导致过度使用。出于这个原因, Spring 集成为 Header Enricher 模式提供了支持。它是通过``元素公开的。下面的示例展示了如何使用它:
@@ -395,7 +395,7 @@ Header Enricher 还提供了有用的子元素来设置众所周知的头名称
从版本 4.1 开始,Header Enricher 提供了一个`routing-slip`子元素。有关更多信息,请参见[布线滑移](./router.html#routing-slip)。
-##### [](#pojo-support)POJO 支持
+##### POJO 支持
通常,头文件的值不能静态地定义,而必须根据消息中的某些内容动态地确定。这就是为什么 Header Enricher 允许你通过使用`ref`和`method`属性来指定 Bean 引用的原因。指定的方法计算标头值。考虑以下配置和具有修改`String`的方法的 Bean:
@@ -436,7 +436,7 @@ public class MyBean {
```
-##### [](#spel-support)spel 支持
+##### spel 支持
在 Spring Integration2.0 中,我们引入了[Spring Expression Language (SpEL)](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#expressions)的便利,以帮助配置许多不同的组件。标题 Enricher 就是其中之一。再看看前面显示的 POJO 示例。你可以看到,确定标头值的计算逻辑非常简单。一个自然的问题是:“有没有更简单的方法来实现这一点?”这就是 SPEL 展现其真正力量的地方。考虑以下示例:
@@ -448,7 +448,7 @@ public class MyBean {
通过在这种简单的情况下使用 SPEL,你不再需要提供一个单独的类并在应用程序上下文中对其进行配置。你所需要做的就是将`expression`属性配置为一个有效的 SPEL 表达式。“payload”和“headers”变量绑定到 SPEL 评估上下文,从而使你能够完全访问传入的消息。
-##### [](#configuring-a-header-enricher-with-java-configuration)使用 Java 配置来配置标题 Enricher
+##### 使用 Java 配置来配置标题 Enricher
下面的两个示例展示了如何使用 Java 配置来增强报头:
@@ -478,7 +478,7 @@ public HeaderEnricher enrichHeaders() {
第一个示例添加了一个文字头。第二个示例添加了两个头,一个文字头和一个基于 SPEL 表达式的头。
-##### [](#configuring-a-header-enricher-with-the-java-dsl)使用 Java DSL 配置 header Enricher
+##### 使用 Java DSL 配置 header Enricher
下面的示例展示了 Header Enricher 的 Java DSL 配置:
@@ -493,7 +493,7 @@ public IntegrationFlow enrichHeadersInFlow() {
}
```
-##### [](#header-channel-registry)报头通道注册表
+##### 报头通道注册表
从 Spring Integration3.0 开始,一个新的子元素``可用。它没有任何属性。这个新的子元素将现有的`replyChannel`和`errorChannel`头(当它们是`MessageChannel`时)转换为`String`,并将通道存储在注册表中,以便以后在需要发送回复或处理错误时进行解析。这对于可能丢失消息头的情况很有用——例如,将消息序列化到消息存储中或通过 JMS 传输消息时。如果标题不存在,或者它不是`MessageChannel`,则不进行任何更改。
@@ -533,7 +533,7 @@ public IntegrationFlow enrichHeadersInFlow() {
在第一种情况下,每个头通道映射的可用时间为两分钟。在第二种情况下,在消息头中指定了生存时间,如果没有消息头,则使用 Elvis 操作符使用两分钟。
-#### [](#payload-enricher)有效载荷 Enricher
+#### 有效载荷 Enricher
在某些情况下,正如前面所讨论的,header enricher 可能是不够的,并且有效负载本身可能需要用额外的信息来丰富。例如,进入 Spring 集成消息传递系统的订单消息必须基于提供的客户编号查找订单的客户,然后用该信息丰富原始有效负载。
@@ -552,7 +552,7 @@ Spring 集成 2.1 引入了有效负载 Enricher。有效负载 Enricher 定义
| |增强器是转换器的一种变体。
在许多情况下,你可以使用有效负载 Enricher 或通用 Transformer 实现来向消息有效负载添加额外的数据。
你应该熟悉 Spring Integration 提供的所有具有转换能力的组件,并仔细选择语义上最适合你的业务用例的实现。|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#payload-enricher-configuration)配置
+##### 配置
下面的示例显示了有效负载 Enricher 的所有可用配置选项:
@@ -590,7 +590,7 @@ Spring 集成 2.1 引入了有效负载 Enricher。有效负载 Enricher 定义
|**12**|每个`property`子元素都提供了一个属性的名称(通过强制`name`属性)。
该属性应该可以在目标有效负载实例上设置。
正好是`value`或`expression`属性中的一个属性也必须提供——前一个属性对于要设置的文字值和要计算的 SPEL 表达式的文字值。
计算上下文的根对象是从这个 Enricher 启动的流返回的消息——输入消息如果没有请求通道或应用程序上下文(使用`@.`spel 语法)。
从版本 4.0 开始,当指定`value`属性时,还可以指定可选的`type`属性。
当目标是类型化的 setter 方法时,框架会适当地强制该值(只要存在`PropertyEditor`)来处理转换。
但是,如果目标负载是`Map`,则该条目将填充该值而不进行转换。
例如,`type`属性允许你这样做,将包含数字的`String`转换为目标有效载荷中的`Integer`值。
从版本 4.1 开始,你还可以指定一个可选的`null-result-expression`属性。
当`enricher`返回 null 时,将对其进行求值,并返回求值的输出。|
|**13**|每个`header`子元素都提供了消息头的名称(通过强制`name`属性)。
正好是`value`或`expression`属性中的一个,也必须提供前者以设置文本值计算上下文的根对象是从这个 Enricher 发起的流返回的消息——输入消息如果没有请求通道或应用程序上下文(使用’@\.\’spel 语法)。
请注意,与``类似,``元素的`header`元素具有`type`和`overwrite`属性。但是,与
属性不同的是,默认情况下,`overwrite`属性是`true`,以与``元素的``子元素保持一致。
从版本 4.1 开始,你还可以指定一个可选的`null-result-expression`属性。
当`enricher`返回 null 时,将对其进行求值,并返回评估的输出。|
-##### [](#payload-enricher-examples)示例
+##### 示例
本节包含在各种情况下使用有效负载 Enricher 的几个示例。
@@ -612,7 +612,7 @@ Spring 集成 2.1 引入了有效负载 Enricher。有效负载 Enricher 定义
通过隐式设置`reply-channel`,返回一个`User`对象,并通过使用`property`子元素,从应答中提取属性并用于丰富原始有效负载。
-##### [](#how-do-i-pass-only-a-subset-of-data-to-the-request-channel)如何仅将数据的子集传递给请求通道?
+##### 如何仅将数据的子集传递给请求通道?
当使用`request-payload-expression`属性时,可以将有效负载的单个属性而不是完整消息传递到请求通道。在下面的示例中,用户名属性被传递到请求通道:
@@ -628,7 +628,7 @@ Spring 集成 2.1 引入了有效负载 Enricher。有效负载 Enricher 定义
请记住,尽管只传递了用户名,但发送到请求通道的结果消息包含完整的`MessageHeaders`集。
-###### [](#how-can-i-enrich-payloads-that-consist-of-collection-data)如何充实由收集数据组成的有效载荷?
+###### 如何充实由收集数据组成的有效载荷?
在下面的示例中,传入的不是`User`对象,而是`Map`对象:
@@ -643,7 +643,7 @@ Spring 集成 2.1 引入了有效负载 Enricher。有效负载 Enricher 定义
`Map`包含`username`Map 键下的用户名。只有`username`被传递到请求通道。该回复包含一个完整的`User`对象,该对象最终被添加到`Map`键下的`user`中。
-##### [](#how-can-i-enrich-payloads-with-static-information-without-using-a-request-channel)在不使用请求通道的情况下,如何使用静态信息丰富有效负载?
+##### 在不使用请求通道的情况下,如何使用静态信息丰富有效负载?
下面的示例根本不使用请求通道,而只使用静态值来丰富消息的有效负载:
@@ -659,7 +659,7 @@ Spring 集成 2.1 引入了有效负载 Enricher。有效负载 Enricher 定义
请注意,“static”一词在这里的用法并不严谨。你仍然可以使用 SPEL 表达式来设置这些值。
-### [](#claim-check)索赔检查
+### 索赔检查
在前面的部分中,我们介绍了几个内容更丰富的组件,它们可以帮助你处理消息丢失一段数据的情况。我们还讨论了内容过滤,它允许你从消息中删除数据项。然而,有时我们希望暂时隐藏数据。例如,在分布式系统中,我们可能会接收到具有非常大的有效负载的消息。一些间歇性的消息处理步骤可能不需要访问此有效负载,而一些可能只需要访问某些标头,因此通过每个处理步骤携带较大的消息有效负载可能会导致性能下降,可能会产生安全风险,并可能使调试更加困难。
@@ -673,7 +673,7 @@ Spring 集成提供了两种类型的索赔检查转换器:
可以使用方便的基于名称空间的机制来配置它们。
-#### [](#claim-check-in)进件索赔检查转换器
+#### 进件索赔检查转换器
传入的索赔检查转换器通过将传入的消息存储在其`message-store`属性标识的消息存储区中来转换该消息。以下示例定义了传入的索赔检查转换器:
@@ -712,7 +712,7 @@ Spring 集成提供了两种类型的索赔检查转换器:
|**7**|指定向输出通道发送回复消息时等待的最长时间(以毫秒为单位)。
默认为`-1`—无限期地阻塞。
此属性在`Chain`元素内不可用。
可选。|
|**8**|定义一个 poller。
这个元素在`Chain`元素中是不可用的。
可选的。|
-#### [](#claim-check-out)出口索赔检查转换器
+#### 出口索赔检查转换器
一个传出的索赔检查转换器允许你将具有索赔检查有效负载的消息转换为具有原始内容作为其有效负载的消息。
@@ -751,7 +751,7 @@ Spring 集成提供了两种类型的索赔检查转换器:
|**8**|指定在向输出通道发送回复消息时等待的最长时间(以毫秒为单位)。
它默认为`-1`—无限期地阻塞。
该属性在`Chain`元素内不可用。
可选。|
|**9**|定义一个 poller。
这个元素在`Chain`元素中是不可用的。
可选的。|
-#### [](#claim-once)索赔一次
+#### 索赔一次
有时,一条特定的消息必须只声明一次。作为一个类比,考虑处理飞机行李的过程。你在出发时托运行李,到达时认领。一旦行李被认领了,在没有先托运的情况下,就不能再认领了。为了适应这种情况,我们在`claim-check-out`Transformer 上引入了`remove-message`布尔属性。默认情况下,此属性设置为`false`。但是,如果设置为`true`,则从`MessageStore`中删除已声明的消息,因此不能再次声明该消息。
@@ -765,7 +765,7 @@ Spring 集成提供了两种类型的索赔检查转换器:
remove-message="true"/>
```
-#### [](#a-word-on-message-store)消息存储中的一个单词
+#### 消息存储中的一个单词
尽管我们很少关心索赔检查的细节(只要它们有效),但你应该知道 Spring 集成中实际索赔检查(指针)的当前实现使用 UUID 来确保唯一性。
@@ -775,7 +775,7 @@ Spring 集成提供了两种类型的索赔检查转换器:
* `JdbcMessageStore`:在 JDBC 上使用关系数据库的实现
-### [](#codec)编解码器
+### 编解码器
Spring 集成的 4.2 版本引入了`Codec`抽象。编解码器对`byte[]`之间的对象进行编码和解码。它们为 Java 序列化提供了一种替代方案。一个优点是,通常,对象不需要实现`Serializable`。我们提供了一个使用[Kryo](https://github.com/EsotericSoftware/kryo)进行序列化的实现,但是你可以提供你自己的实现,以便在以下任何组件中使用:
@@ -785,25 +785,25 @@ Spring 集成的 4.2 版本引入了`Codec`抽象。编解码器对`byte[]`之
* `CodecMessageConverter`
-#### [](#encodingpayloadtransformer)`EncodingPayloadTransformer`
+#### `EncodingPayloadTransformer`
该转换器通过使用编解码器将有效负载编码为`byte[]`。它不影响消息头。
有关更多信息,请参见[Javadoc](https://docs.spring.io/spring-integration/api/org/springframework/integration/transformer/EncodingPayloadTransformer.html)。
-#### [](#decodingtransformer)`DecodingTransformer`
+#### `DecodingTransformer`
该转换器利用编解码器对`byte[]`进行解码。它需要配置一个`Class`来对对象进行解码(或者一个解析为`Class`的表达式)。如果生成的对象是`Message>`,则不保留入站标头。
有关更多信息,请参见[Javadoc](https://docs.spring.io/spring-integration/api/org/springframework/integration/transformer/DecodingTransformer.html)。
-#### [](#codecmessageconverter)`CodecMessageConverter`
+#### `CodecMessageConverter`
某些端点(例如 TCP 和 Redis)没有消息头的概念。它们支持使用`MessageConverter`,并且`CodecMessageConverter`可用于将消息转换为或从`byte[]`进行传输。
有关更多信息,请参见[Javadoc](https://docs.spring.io/spring-integration/api/org/springframework/integration/codec/CodecMessageConverter.html)。
-#### [](#kryo)克里奥
+#### 克里奥
目前,这是`Codec`的唯一实现,并且它提供了两种`Codec`:
@@ -821,7 +821,7 @@ Spring 集成的 4.2 版本引入了`Codec`抽象。编解码器对`byte[]`之
通过使用`FileKryoRegistrar`对`PojoCodec`进行初始化,第一个可以与`PojoCodec`一起使用。第二个和第三个与`MessageCodec`一起使用,后者是用`MessageKryoRegistrar`初始化的。
-##### [](#customizing-kryo)定制 Kryo
+##### 定制 Kryo
默认情况下,Kryo 将未知的 Java 类型委托给它的`FieldSerializer`。Kryo 还为每个基元类型注册默认的序列化器,以及`String`、`Collection`和`Map`。`FieldSerializer`使用反射来导航对象图。一种更有效的方法是实现一个自定义序列化器,它了解对象的结构,并可以直接序列化选定的原语字段。下面的示例展示了这样的序列化器:
@@ -847,11 +847,11 @@ public class AddressSerializer extends Serializer {
| |在注册自定义序列化器时,你需要一个注册 ID,
注册 ID 是任意的,
但是,在我们的情况下,必须显式地定义 ID,因为分布式应用程序中的每个 Kryo 实例必须使用相同的 ID。,
Kryo 建议使用小的正整数,并保留一些 ID(值 \<10), Spring 集成目前默认使用 40,41,和 42(对于前面提到的文件和消息头序列化器)。
我们建议你从 60 开始,以允许在框架中进行扩展。
你可以通过配置前面提到的注册商来覆盖这些框架默认设置。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-###### [](#using-a-custom-kryo-serializer)使用自定义 Kryo 序列化器
+###### 使用自定义 Kryo 序列化器
如果你需要定制序列化,请参阅[Kryo](https://github.com/EsotericSoftware/kryo)文档,因为你需要使用本机 API 来进行定制。例如,参见[`MessageCodec`](https://github.com/ Spring-projects/ Spring-integration/blob/main/ Spring-integration-core/SRC/main/java/org/springframework/integration/codec/kryo/messagecodec.java)的实现。
-###### [](#implementing-kryoserializable)实现 kryoserializable
+###### 实现 kryoserializable
如果具有对域对象源代码的写访问权限,则可以实现`KryoSerializable`所描述的[here](https://github.com/EsotericSoftware/kryo#kryoserializable)。在这种情况下,类本身提供序列化方法,不需要进一步的配置。然而,基准测试表明,这并不像显式注册自定义序列化器那样有效。下面的示例展示了一个自定义的 Kryo 序列化器:
@@ -877,7 +877,7 @@ public class Address implements KryoSerializable {
你也可以使用此技术来包装 Kryo 以外的序列化库。
-###### [](#using-the-defaultserializer-annotation)使用`@DefaultSerializer`注释
+###### 使用`@DefaultSerializer`注释
Kryo 还提供了`@DefaultSerializer`注释,如[here](https://github.com/EsotericSoftware/kryo#default-serializers)所述。
diff --git a/docs/spring-integration/message.md b/docs/spring-integration/message.md
index 20c81be61b571463924900c82692898689376af9..7ba3b79fb6d9e9909ac90c5862988ad94371a56b 100644
--- a/docs/spring-integration/message.md
+++ b/docs/spring-integration/message.md
@@ -1,10 +1,10 @@
# 信息
-### [](#message)消息
+### 消息
Spring Integration`Message`是一个通用的数据容器。任何对象都可以作为有效负载提供,并且每个`Message`实例都包括包含用户可扩展属性的头作为键-值对。
-#### [](#message-interface)`Message`接口
+#### `Message`接口
下面的清单显示了`Message`接口的定义:
@@ -20,7 +20,7 @@ public interface Message {
`Message`接口是 API 的核心部分。通过将数据封装在通用包装器中,消息传递系统可以在不了解数据类型的情况下传递数据。随着应用程序逐渐支持新类型,或者当类型本身被修改或扩展时,消息传递系统不会受到影响。另一方面,当消息传递系统中的某些组件确实需要访问关于`Message`的信息时,这样的元数据通常可以存储到并从消息头中的元数据检索。
-#### [](#message-headers)消息头
+#### 消息头
正如 Spring 集成允许任何`Object`被用作`Message`的有效负载一样,它也支持任何`Object`类型作为头值。实际上,`MessageHeaders`类实现了`java.util.Map_ interface`,如下面的类定义所示:
@@ -54,7 +54,7 @@ Long timestamp = message.getHeaders().getTimestamp();
许多入站和出站适配器实现还提供或期望某些标头,并且你可以配置其他用户定义的标头。这些标头的常量可以在存在这样的标头的模块中找到——例如`AmqpHeaders`,`JmsHeaders`,等等。
-##### [](#message-header-accessor)`MessageHeaderAccessor` API
+##### `MessageHeaderAccessor` API
从 Spring Framework4.0 和 Spring Integration4.0 开始,核心消息抽象已移至`spring-messaging`模块,并引入了`MessageHeaderAccessor`API,以在消息实现上提供额外的抽象。现在,在`IntegrationMessageHeaderAccessor`类中声明了所有(核心) Spring 特定于集成的消息头常量。下表描述了预定义的消息头:
@@ -86,7 +86,7 @@ Object correlationId = accessor.getCorrelationId();
|```
IntegrationMessageHeaderAccessor.
SEQUENCE_DETAILS
```| ```
java.util.
List>
``` |当需要嵌套相关性时(例如,`splitter→…→splitter→…→aggregator→…→aggregator`)使用的相关数据堆栈。|
| ```
IntegrationMessageHeaderAccessor.
ROUTING_SLIP
``` |```
java.util.
Map, Integer>
```|见[布线滑移](./router.html#routing-slip)。|
-##### [](#message-id-generation)消息 ID 生成
+##### 消息 ID 生成
当一条消息在应用程序中转换时,每当它发生突变(例如,通过转换器)时,都会分配一个新的消息 ID。消息 ID 是`UUID`。从 Spring Integration3.0 开始,用于 IS Generation 的默认策略比以前的`java.util.UUID.randomUUID()`实现更有效。它使用基于安全随机种子的简单随机数,而不是每次创建一个安全随机数。
@@ -97,7 +97,7 @@ Object correlationId = accessor.getCorrelationId();
除了默认的策略之外,还提供了两个额外的`IdGenerators`。`org.springframework.util.JdkIdGenerator`使用了以前的`UUID.randomUUID()`机制。当不真正需要 UUID 并且简单的递增值就足够了时,可以使用`o.s.i.support.IdGenerators.SimpleIncrementingIdGenerator`。
-##### [](#read-only-headers)只读标题
+##### 只读标题
`MessageHeaders.ID`和`MessageHeaders.TIMESTAMP`是只读标头,不能重写。
@@ -107,7 +107,7 @@ Object correlationId = accessor.getCorrelationId();
从版本 5.0 开始,[消息传递网关](./gateway.html#gateway),[页眉 Enricher ](./content-enrichment.html#header-enricher),[内容更丰富](./content-enrichment.html#payload-enricher)和[头过滤器](./transformer.html#header-filter)不允许你配置`MessageHeaders.ID`和`MessageHeaders.TIMESTAMP`使用`DefaultMessageBuilderFactory`时的头名称,并抛出`BeanInitializationException`。
-##### [](#header-propagation)报头传播
+##### 报头传播
当消息产生端点(例如[服务激活器](./service-activator.html#service-activator))处理(和修改)消息时,通常将入站头传播到出站消息。一个例外是[变压器](./transformer.html#transformer),当完整的消息返回到框架时。在这种情况下,用户代码负责整个出站消息。当转换器只返回有效负载时,入站报头将被传播。此外,只有在出站消息中不存在头文件的情况下,才会对其进行传播,从而允许你根据需要更改头文件的值。
@@ -120,7 +120,7 @@ Object correlationId = accessor.getCorrelationId();
| |头传播抑制不适用于那些不修改消息的端点,例如[bridges](./bridge.html#bridge)和[routers](./router.html#router)。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#message-implementations)消息实现
+#### 消息实现
`Message`接口的基本实现是`GenericMessage`,它提供了两个构造函数,如以下清单所示:
@@ -142,7 +142,7 @@ Throwable t = message.getPayload();
注意,这个实现利用了`GenericMessage`基类是参数化的这一事实。因此,如两个示例中所示,在检索`Message`有效载荷`Object`时,无需强制转换。
-#### [](#message-builder)the`MessageBuilder`助手类
+#### the`MessageBuilder`助手类
你可能注意到`Message`接口为其有效负载和标题定义了检索方法,但没有提供 setter。其原因是`Message`在其初始创建后不能进行修改。因此,当`Message`实例被发送到多个消费者(例如,通过发布-订阅通道)时,如果其中一个消费者需要发送具有不同有效负载类型的答复,它必须创建一个新的`Message`。因此,其他消费者不受这些变化的影响。请记住,多个消费者可能会访问相同的有效负载实例或标头值,而这样的实例本身是否不可变是一个留给你的决定。换句话说,`Message`实例的契约类似于不可修改的`Collection`实例的契约,`MessageHeaders`映射进一步证明了这一点。即使`MessageHeaders`类实现了`java.util.Map`,在`put`实例上调用`put`操作(或“remove”或“clear”)的任何尝试都会导致`UnsupportedOperationException`实例。
diff --git a/docs/spring-integration/messaging-endpoints.md b/docs/spring-integration/messaging-endpoints.md
index d16c7cc901ade6c9f9e41f3fbcfb2efd3ae2ed86..310b0ca22e62aaaa101d2f7244df90bcc0310e4c 100644
--- a/docs/spring-integration/messaging-endpoints.md
+++ b/docs/spring-integration/messaging-endpoints.md
@@ -1,8 +1,8 @@
# 消息传递端点
-## [](#messaging-endpoints-chapter)消息传递端点
+## 消息传递端点
-### [](#endpoint)消息端点
+### 消息端点
本章的第一部分介绍了一些背景理论,并揭示了驱动 Spring 集成的各种消息传递组件的底层 API。如果你想真正了解幕后的情况,这些信息可能会很有帮助。但是,如果你想要启动并运行各种元素的基于名称空间的简化配置,现在可以跳过[端点命名空间支持](#endpoint-namespace)。
@@ -10,7 +10,7 @@
在这两种情况中,事件驱动的消费者要简单得多。不需要管理和调度单独的 Poller 线程,它们本质上是具有回调方法的侦听器。当连接到 Spring 集成的可订阅消息通道之一时,这个简单的选项非常有效。然而,当连接到一个缓冲的、可匹配的消息通道时,一些组件必须调度和管理轮询线程。 Spring 集成提供了两种不同的端点实现,以适应这两种类型的消费者。因此,消费者本身只需要实现回调接口。当需要轮询时,端点充当使用者实例的容器。其好处类似于使用容器来托管消息驱动的 bean,但是,由于这些使用者是在`ApplicationContext`中运行的 Spring 管理对象,因此它更类似于 Spring 自己的`MessageListener`容器。
-#### [](#endpoint-handler)消息处理程序
+#### 消息处理程序
Spring 集成的`MessageHandler`接口由框架内的许多组件实现。换句话说,这不是公共 API 的一部分,并且你通常不会直接实现`MessageHandler`。然而,消息使用者使用它来实际处理所使用的消息,因此了解此策略接口确实有助于理解使用者的整体角色。接口定义如下:
@@ -24,7 +24,7 @@ public interface MessageHandler {
尽管它很简单,但是这个接口为下面几章中涉及的大多数组件(路由器、转换器、分发器、聚合器、服务激活器和其他组件)提供了基础。这些组件各自对它们处理的消息执行非常不同的功能,但是实际接收消息的要求是相同的,并且轮询和事件驱动行为之间的选择也是相同的。 Spring 集成提供了两个端点实现,它们承载这些基于回调的处理程序,并让它们连接到消息通道。
-#### [](#endpoint-eventdrivenconsumer)事件驱动的消费者
+#### 事件驱动的消费者
因为它是两个中比较简单的,所以我们首先讨论事件驱动的消费者端点。你可能还记得`SubscribableChannel`接口提供了一个`subscribe()`方法,并且该方法接受一个`MessageHandler`参数(如[`SubscribableChannel`](./channel.html#channel-interfaces-subscribablechannel)所示)。下面的清单显示了`subscribe`方法的定义:
@@ -40,7 +40,7 @@ SubscribableChannel channel = context.getBean("subscribableChannel", Subscribabl
EventDrivenConsumer consumer = new EventDrivenConsumer(channel, exampleHandler);
```
-#### [](#endpoint-pollingconsumer)轮询消费者
+#### 轮询消费者
Spring 集成还提供了一个`PollingConsumer`,并且可以以相同的方式进行实例化,只是通道必须实现`PollableChannel`,如下例所示:
@@ -108,7 +108,7 @@ consumer.setTaskExecutor(taskExecutor);
| |许多`MessageHandler`实现都可以生成回复消息。
如前所述,与接收消息相比,发送消息是微不足道的。
然而,何时以及发送多少回复消息取决于处理程序类型。例如,
,聚合器等待大量消息到达,并且通常被配置为拆分器的下游使用者,拆分器可以为其处理的每条消息生成多个答复。
当使用名称空间配置时,你不需要严格地了解所有细节。,但是,
,仍然值得知道的是,这些组件中的几个共享一个公共基类,即`AbstractReplyProducingMessageHandler`,并且它提供了一个`setOutputChannel(..)`方法。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#endpoint-namespace)端点命名空间支持
+#### 端点命名空间支持
在本参考手册中,你可以找到端点元素的特定配置示例,例如路由器、转换器、服务激活器等等。其中大多数支持`input-channel`属性,许多支持`output-channel`属性。在被解析之后,这些端点元素产生`PollingConsumer`或`EventDrivenConsumer`的实例,这取决于所引用的`input-channel`的类型:`PollableChannel`或`SubscribableChannel`,分别。当通道是可匹配的时,轮询行为基于端点元素的`poller`子元素及其属性。
@@ -148,7 +148,7 @@ consumer.setTaskExecutor(taskExecutor);
|**13**|允许指定额外的 AOP 建议来处理额外的横切问题。
有关更多信息,请参见[事务支持](#transaction-support)。
可选。|
|**14**|可以使 poller 成为事务性的。
有关更多信息,请参见[AOP Advice chains](#aop-advice-chains)。
可选。|
-##### [](#examples)示例
+##### 示例
具有 1 秒间隔的简单的基于间隔的 Poller 可以配置如下:
@@ -189,7 +189,7 @@ consumer.setTaskExecutor(taskExecutor);
| |`ref`属性仅在内部 poller 定义上允许。
在顶级 poller 上定义此属性会导致在初始化应用程序上下文期间引发配置异常。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-###### [](#global-default-poller)全局默认 Poller
+###### 全局默认 Poller
为了进一步简化配置,你可以定义一个全局默认 Poller。XML DSL 中的单个顶级 Poller 组件可能将`default`属性设置为`true`。对于 爪哇 配置,在这种情况下必须声明带有`PollerMetadata.DEFAULT_POLLER`名称的`PollerMetadata` Bean。在这种情况下,任何具有`PollableChannel`作为其输入通道的端点,都是在相同的`ApplicationContext`中定义的,并且没有显式配置`poller`的端点使用该默认值。下面的示例展示了这样的 Poller 和使用它的 Transformer:
@@ -266,7 +266,7 @@ XML
output-channel="output"/>
```
-###### [](#transaction-support)事务支持
+###### 事务支持
Spring 集成还为 Pollers 提供事务支持,以便每个接收和转发操作可以作为工作的原子单元来执行。要为 Poller 配置事务,请添加``子元素。下面的示例显示了可用的属性:
@@ -282,7 +282,7 @@ Spring 集成还为 Pollers 提供事务支持,以便每个接收和转发操
有关更多信息,请参见[Poller 事务支持](./transactions.html#transaction-poller)。
-##### [](#aop-advice-chains) AOP 建议链
+##### AOP 建议链
由于 Spring 事务支持依赖于用`TransactionInterceptor`( AOP 通知)处理由 Poller 发起的消息流的事务行为的代理机制,因此有时必须提供额外的建议来处理与 Poller 相关的其他交叉行为。为此,`poller`定义了一个`advice-chain`元素,该元素允许你在实现`MethodInterceptor`接口的类中添加更多的建议。下面的示例展示了如何为`poller`定义`advice-chain`:
@@ -304,7 +304,7 @@ Spring 集成还为 Pollers 提供事务支持,以便每个接收和转发操
| |当使用建议链时,不能指定``子元素。
相反,声明一个`` Bean 并将其添加到``中。
有关完整的配置详细信息,请参见[Poller 事务支持](./transactions.html#transaction-poller)。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-###### [](#taskexecutor-support)TaskExecutor 支持
+###### TaskExecutor 支持
轮询线程可以由 Spring 的`TaskExecutor`抽象的任何实例执行。这使端点或一组端点能够并发。截至 Spring 3.0,核心 Spring 框架有一个`task`名称空间,其``元素支持创建一个简单的线程池执行器。该元素接受用于公共并发设置的属性,例如池大小和队列容量。配置线程池执行器可以使端点在负载下的执行方式发生很大的变化。这些设置可用于每个端点,因为端点的性能是需要考虑的主要因素之一(另一个主要因素是端点订阅的通道上的预期卷)。要为配置了 XML 名称空间支持的轮询端点启用并发,请在其``元素上提供`task-executor`引用,然后提供一个或多个属性,如以下示例所示:
@@ -331,7 +331,7 @@ Spring 集成还为 Pollers 提供事务支持,以便每个接收和转发操
使用这种方法不会带来太多的开销,因为在内部,它只不过是一个定时等待线程,它所需的 CPU 资源使用量几乎不像(例如)颠簸的无限 while 循环那样多。
-#### [](#polling-consumer-change-polling-rate)在运行时更改轮询速率
+#### 在运行时更改轮询速率
当配置带有`fixed-delay`或`fixed-rate`属性的 Poller 时,默认实现使用`PeriodicTrigger`实例。`PeriodicTrigger`是核心 Spring 框架的一部分。它只接受作为构造函数参数的时间间隔。因此,它不能在运行时进行更改。
@@ -344,7 +344,7 @@ Spring 集成还为 Pollers 提供事务支持,以便每个接收和转发操
| |不过,需要注意的是,由于触发器方法是`nextExecutionTime()`,因此基于现有配置,对动态触发器的任何更改直到下一次轮询才生效。
在当前配置的下一次执行时间之前,不可能强制触发。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#payload-type-conversion)有效载荷类型转换
+#### 有效载荷类型转换
在整个参考手册中,你还可以看到各种端点的特定配置和实现示例,这些端点接受消息或任何任意的`Object`作为输入参数。在`Object`的情况下,这样的参数被映射到消息有效负载或有效负载或报头的一部分(当使用 Spring 表达式语言时)。然而,端点方法的输入参数的类型有时与有效负载或其部分的类型不匹配。在这个场景中,我们需要执行类型转换。 Spring 集成提供了一种方便的方式来注册类型转换器(通过使用 Spring )在其自身实例内的名为的转换服务 Bean。 Bean 是在通过使用 Spring 集成基础设施定义第一转换器时自动创建的。要注册转换器,可以实现`org.springframework.core.convert.converter.Converter`、`org.springframework.core.convert.converter.GenericConverter`或`org.springframework.core.convert.converter.ConverterFactory`。
@@ -405,7 +405,7 @@ public class ContextConfiguration {
| |在配置应用程序上下文时, Spring 框架允许你添加`conversionService` Bean(参见[配置转换服务](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#core-convert-Spring-config)章)。
当需要时,该服务用于在 Bean 创建和配置期间执行适当的转换,相比之下,
,`integrationConversionService`用于运行时转换。
这些用途是完全不同的。
转换器是用于连接 Bean 构造函数参数和属性时使用的转换器,如果在运行时用于 Spring 针对数据类型通道、有效负载类型转换器中的消息的集成表达式计算,则可能会产生意想不到的结果,以此类推。
但是,如果你确实希望使用 Spring `conversionService`作为 Spring 集成`integrationConversionService`,则可以在应用程序上下文中配置一个别名,如以下示例所示:
在这种情况下,
由`conversionService`提供的转换器可用于 Spring 集成运行时转换。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#content-type-conversion)内容类型转换
+#### 内容类型转换
从版本 5.0 开始,默认情况下,方法调用机制基于`org.springframework.messaging.handler.invocation.InvocableHandlerMethod`基础架构。它的`HandlerMethodArgumentResolver`实现(例如`PayloadArgumentResolver`和`MessageMethodArgumentResolver`)可以使用`MessageConverter`抽象来将传入的`payload`转换为目标方法参数类型。该转换可以基于`contentType`消息头。为此, Spring Integration 提供了`ConfigurableCompositeMessageConverter`,它将委托给要调用的已注册转换器的列表,直到其中一个转换器返回非空结果。默认情况下,此转换器提供(以严格的顺序):
@@ -434,7 +434,7 @@ public ConfigurableCompositeMessageConverter compositeMessageConverter() {
| |当使用 SPEL 方法调用时,基于`MessageConverter`(包括`contentType`header)的转换是不可用的。
在这种情况下,只有在[有效载荷类型转换](#payload-type-conversion)中提到的常规类到类的转换是可用的。|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#async-polling)异步轮询
+#### 异步轮询
如果希望轮询是异步的,则 Poller 可以选择指定一个`task-executor`属性,该属性指向任何`TaskExecutor` Bean 的现有实例( Spring 3.0 通过`task`命名空间提供了一个方便的命名空间配置)。但是,在使用`TaskExecutor`配置 Poller 时,你必须了解某些事情。
@@ -460,7 +460,7 @@ public ConfigurableCompositeMessageConverter compositeMessageConverter() {
处理此问题的方法之一是设置任务执行器的`queue-capacity`属性。即使是 0 也是一个合理的值。你还可以通过设置任务执行器的`rejection-policy`属性(例如,设置为`DISCARD`)来指定如何处理不能排队的消息来管理它。换句话说,在配置`TaskExecutor`时,你必须了解某些细节。有关此主题的更多详细信息,请参见 Spring 参考手册中的[“任务执行和调度”](https://docs.spring.io/spring/docs/current/spring-framework-reference/integration.html#scheduling)。
-#### [](#endpoint-inner)端点内部 bean
+#### 端点内部 bean
许多端点是复合 bean。这包括所有的消费者和所有的入站通道适配器。消费者(民意测验或事件驱动)委托给`MessageHandler`。经过轮询的适配器通过委托给`MessageSource`来获取消息。 Bean 通常情况下,获得对委托的引用是有用的,可能用于在运行时更改配置或进行测试。这些 bean 可以从具有众所周知的名称的`ApplicationContext`中获得。`MessageHandler`实例使用与`someConsumer.handler`相似的 Bean ID 在应用程序上下文中注册,(其中’Consumer’是端点的`id`属性的值),`MessageSource`实例使用与`somePolledAdapter.source`相似的 Bean ID 注册,其中“somepolledapter”是适配器的 ID。
@@ -475,7 +475,7 @@ public ConfigurableCompositeMessageConverter compositeMessageConverter() {
Bean 被视为与任何内部 Bean 声明的一样,并且不与应用上下文注册。如果你希望以某种其他方式访问此 Bean,请在顶层用`id`声明它,并使用`ref`属性。有关更多信息,请参见[Spring Documentation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-inner-beans)。
-### [](#endpoint-roles)端点角色
+### 端点角色
从版本 4.2 开始,可以将端点分配给角色。角色让端点作为一个组开始和停止。这在使用领导选举时特别有用,在这种情况下,可以分别在授予或撤销领导时启动或停止一组端点。为此,框架在应用程序上下文中以`IntegrationContextUtils.INTEGRATION_LIFECYCLE_ROLE_CONTROLLER`的名称注册了`SmartLifecycleRoleController` Bean。每当需要控制生命周期时,这 Bean 可以被注入或`@Autowired`:
@@ -562,7 +562,7 @@ public Map getEndpointsRunningStatus(String role) (4)
|**3**|如果角色中的端点都没有运行,则返回`true`。|
|**4**|返回`component name : running status`的映射。
组件名称通常是 Bean 名称。|
-### [](#leadership-event-handling)领导力事件处理
+### 领导力事件处理
端点组可以根据分别授予或撤销的领导才能来启动和停止。这在群集场景中很有用,在群集场景中,共享资源必须仅由单个实例使用。这方面的一个例子是一个文件入站通道适配器,它正在轮询一个共享目录。(见[读取文件](./file.html#file-reading))。
@@ -595,11 +595,11 @@ public LockRegistryLeaderInitiator leaderInitiator(LockRegistry locks) {
有关领导选举和使用 ZooKeeper 的活动的更多信息,请参见[动物园管理员领导事件处理](./zookeeper.html#zk-leadership)。
-### [](#gateway)消息传递网关
+### 消息传递网关
网关隐藏了 Spring 集成提供的消息传递 API。它让应用程序的业务逻辑不了解 Spring Integration API。通过使用通用网关,你的代码只与一个简单的接口交互。
-#### [](#gateway-proxy)输入`GatewayProxyFactoryBean`
+#### 输入`GatewayProxyFactoryBean`
如前所述,不依赖 Spring 集成 API(包括 Gateway 类)将是很好的。出于这个原因, Spring 集成提供了`GatewayProxyFactoryBean`,它为任何接口生成代理,并在内部调用下面所示的网关方法。通过使用依赖注入,你可以将接口公开给你的业务方法。
@@ -615,7 +615,7 @@ public interface Cafe {
}
```
-#### [](#gateway-namespace)网关 XML 命名空间支持
+#### 网关 XML 命名空间支持
还提供了名称空间支持。它允许你将接口配置为服务,如下例所示:
@@ -633,7 +633,7 @@ public interface Cafe {
对于单个方法,可以重写默认值。见[带有注释和 XML 的网关配置](#gateway-configuration-annotations)。
-#### [](#gateway-default-reply-channel)设置默认回复通道
+#### 设置默认回复通道
通常,你不需要指定`default-reply-channel`,因为网关会自动创建一个临时的匿名回复通道,在该通道中监听回复。然而,有些情况下可能会提示你定义`default-reply-channel`(或者`reply-channel`具有适配器网关,例如 HTTP、JMS 和其他)。
@@ -652,7 +652,7 @@ public interface Cafe {
| |从版本 5.4 开始,当网关方法返回类型是`void`时,如果没有明确提供这样的头,则框架将`replyChannel`头填充为`nullChannel` Bean 引用。
这允许丢弃来自下游流的任何可能的答复,从而满足单向网关契约。|
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#gateway-configuration-annotations)带注释和 XML 的网关配置
+#### 带注释和 XML 的网关配置
考虑下面的示例,该示例通过添加`@Gateway`注释,扩展了前面的`Cafe`接口示例:
@@ -710,7 +710,7 @@ public interface FileWriter {
| |如果在 XML 中指定了无参数网关,并且接口方法同时具有`@Payload`和`@Gateway`注释(在`payloadExpression`元素中带有`payload-expression`或`payload-expression`元素),则`@Payload`值将被忽略。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#expressions-and-global-headers)表达式和“全局”头
+##### 表达式和“全局”头
``元素支持`expression`作为`value`的替代项。计算 SPEL 表达式以确定标头的值。从版本 5.2 开始,计算上下文的`#root`对象是带有`getMethod()`和`getArgs()`访问器的`MethodArgsHolder`对象。
@@ -727,7 +727,7 @@ public interface FileWriter {
网关现在还支持`default-payload-expression`,它适用于所有方法(除非重写)。
-#### [](#gateway-mapping)将方法参数映射到消息
+#### 将方法参数映射到消息
使用上一节中的配置技术,可以控制如何将方法参数映射到消息元素(有效负载和标题)。当不使用显式配置时,将使用某些约定来执行映射。在某些情况下,这些约定不能确定哪个参数是有效负载,哪个参数应该映射到头。考虑以下示例:
@@ -743,7 +743,7 @@ public String send2(Map thing1, Map thing2);
或者(每当约定失效时),你可以承担将方法调用映射到消息的全部责任。为此,实现`MethodArgsMessageMapper`,并通过使用`mapper`属性将其提供给``。映射器映射了`MethodArgsHolder`,这是一个简单的类,它包装`java.reflect.Method`实例和包含参数的`Object[]`实例。当提供自定义映射器时,在网关上不允许`default-payload-expression`属性和``元素。类似地,`payload-expression`属性和``元素在任何``元素上都是不允许的。
-##### [](#mapping-method-arguments)映射方法参数
+##### 映射方法参数
以下示例展示了如何将方法参数映射到消息,并展示了无效配置的一些示例:
@@ -801,7 +801,7 @@ public interface MyGateway {
```
-#### [](#messaging-gateway-annotation)`@MessagingGateway`注解
+#### `@MessagingGateway`注解
从版本 4.0 开始,网关服务接口可以用`@MessagingGateway`注释来标记,而不需要定义用于配置的``XML 元素。下面的两个示例比较了配置相同网关的两种方法:
@@ -842,7 +842,7 @@ public interface TestGateway {
| |如果没有 XML 配置,则在至少一个`@Configuration`类上需要`@EnableIntegration`注释。
参见[configuration and`@EnableIntegration`](./overview.html#configuration-enable-integration)以获取更多信息。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#gateway-calling-no-argument-methods)调用无参数方法
+#### 调用无参数方法
在没有任何参数的网关接口上调用方法时,默认的行为是从`PollableChannel`接收`Message`。
@@ -887,11 +887,11 @@ public interface Cafe {
如果一个方法没有参数,也没有返回值,但确实包含有效负载表达式,那么它将被视为只发送操作。
-#### [](#gateway-calling-default-methods)调用`default`方法
+#### 调用`default`方法
网关代理的接口也可以有`default`方法,并且从版本 5.3 开始,该框架将`DefaultMethodInvokingMethodInterceptor`注入到代理中,以便使用`default`方法而不是代理方法来调用`java.lang.invoke.MethodHandle`方法。来自 JDK 的接口,例如`java.util.function.Function`,仍然可以用于网关代理,但是它们的`default`方法不能被调用,因为内部的 Java 安全原因导致针对 JDK 类的`MethodHandles.Lookup`实例化。这些方法还可以使用显式的`@Gateway`方法上的注释,或`proxyDefaultMethods`上的注释或`proxyDefaultMethods`上的注释或`@MessagingGateway`上的注释或``XML 组件来代理(失去它们的实现逻辑,同时,恢复以前的网关代理行为)。
-#### [](#gateway-error-handling)错误处理
+#### 错误处理
网关调用可能会导致错误。默认情况下,下游发生的任何错误都会在网关的方法调用中“按原样”重新抛出。例如,考虑以下简单的流程:
@@ -953,7 +953,7 @@ public interface RequestReplyExchanger {
| |如果下游流返回一个`ErrorMessage`,则其`payload`(a`Throwable`)被视为一个常规的下游错误。
如果配置了一个`error-channel`,则将其发送到错误流。
否则,有效负载将被抛给网关的调用者。,如果`error-channel`上的错误流返回`ErrorMessage`,它的有效负载被抛给调用者。
这同样适用于任何具有`Throwable`有效负载的消息。
当你需要将`Exception`直接传播给调用者时,这在异步情况下很有用。,
这样做,你可以返回一个`Exception`(作为来自某个服务的`reply`),也可以抛出它,
通常情况下,即使使用异步流,框架负责将下游流引发的异常传播回网关。
[TCP 客户机-服务器多路复用](https://github.com/spring-projects/spring-integration-samples/tree/main/intermediate/tcp-client-server-multiplex)示例演示了这两种技术都可以将异常返回给调用者。
它通过使用`aggregator`和`group-timeout`(参见[聚合器和组超时](./aggregator.html#agg-and-group-to))以及在 discard 流上的`MessagingTimeoutException`答复来模拟套接字 IO 错误到等待线程。|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#gateway-timeouts)网关超时
+#### 网关超时
网关有两个超时属性:`requestTimeout`和`replyTimeout`。请求超时仅在通道可以阻塞(例如,有界`QueueChannel`已满)的情况下才适用。`replyTimeout`值是网关等待回复或返回`null`的时间。它默认值为无穷大。
@@ -979,7 +979,7 @@ String lateReply(String payload, long requestTimeout, long replyTimeout);
```
-#### [](#async-gateway)异步网关
+#### 异步网关
作为一种模式,消息传递网关提供了一种很好的方式来隐藏特定于消息传递的代码,同时仍然公开消息传递系统的全部功能。由于[前面描述的](#gateway-proxy),`GatewayProxyFactoryBean`提供了一种方便的方式,可以通过服务接口公开代理,从而使你能够基于 POJO 访问消息传递系统(基于你自己的域中的对象、原语/字符串或其他对象)。但是,当网关通过返回值的简单 POJO 方法公开时,这意味着对于每个请求消息(在调用方法时生成),必须有一个答复消息(在方法返回时生成)。由于消息传递系统是自然异步的,因此你可能不能总是保证“对于每个请求,总是会有一个答复”的契约。 Spring Integration2.0 引入了对异步网关的支持,它提供了一种方便的方式来初始化流,当你可能不知道是否需要回复或回复需要多长时间才能到达时。
@@ -1014,7 +1014,7 @@ int finalResult = result.get(1000, TimeUnit.SECONDS);
有关更详细的示例,请参见 Spring 集成示例中的[异步网关](https://github.com/spring-projects/spring-integration-samples/tree/main/intermediate/async-gateway)示例。
-##### [](#listenablefuture)`ListenableFuture`
+##### `ListenableFuture`
从版本 4.1 开始,异步网关方法还可以返回`ListenableFuture`(在 Spring Framework4.0 中引入)。这些返回类型允许你提供回调,在结果可用(或发生异常)时调用该回调。当网关检测到此返回类型并且[任务执行者](#gateway-asynctaskexecutor)是`AsyncListenableTaskExecutor`时,将调用执行器的`submitListenable()`方法。下面的示例展示了如何使用`ListenableFuture`:
@@ -1034,7 +1034,7 @@ result.addCallback(new ListenableFutureCallback() {
});
```
-##### [](#gateway-asynctaskexecutor)`AsyncTaskExecutor`
+##### `AsyncTaskExecutor`
默认情况下,`GatewayProxyFactoryBean`在为返回类型为`Future`的任何网关方法提交内部`AsyncInvocationTask`实例时使用`org.springframework.core.task.SimpleAsyncTaskExecutor`。但是,``元素的配置中的`async-executor`属性允许你提供对 Spring 应用程序上下文中可用的`java.util.concurrent.Executor`的任何实现的引用。
@@ -1072,7 +1072,7 @@ public interface NoExecGateway {
| |如果返回类型是特定的具体`Future`实现或配置的执行器不支持的其他子接口,则流在调用方的线程上运行,流必须在应答消息有效负载中返回所需的类型。|
|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#gw-completable-future)`CompletableFuture`
+##### `CompletableFuture`
从版本 4.2 开始,网关方法现在可以返回`CompletableFuture>`。返回此类型时有两种操作模式:
@@ -1080,7 +1080,7 @@ public interface NoExecGateway {
* 当异步执行器显式地设置为`null`并且返回类型是`CompletableFuture`或者返回类型是`CompletableFuture`的子类时,将在调用者的线程上调用该流。在这种情况下,预计下游流将返回适当类型的`CompletableFuture`。
-###### [](#usage-scenarios)使用场景
+###### 使用场景
在下面的场景中,调用者线程立即返回一个`CompletableFuture`,当下游流回应到网关(使用`Invoice`对象)时,这个过程就完成了。
@@ -1128,7 +1128,7 @@ CompletableFuture result = process("foo")
String out = result.get(10, TimeUnit.SECONDS);
```
-##### [](#reactor-mono)反应堆`Mono`
+##### 反应堆`Mono`
从版本 5.0 开始,`GatewayProxyFactoryBean`允许使用带有网关接口方法的[项目反应堆](https://projectreactor.io/),使用[`Mono`](https://github.com/reactor/reactor-core)返回类型。内部`AsyncInvocationTask`包装在`Mono.fromCallable()`中。
@@ -1172,11 +1172,11 @@ mono.subscribe(invoice -> handleInvoice(invoice));
调用线程继续,当流完成时调用`handleInvoice()`。
-##### [](#downstream-flows-returning-an-asynchronous-type)下游流返回异步类型
+##### 下游流返回异步类型
正如上面的`ListenableFuture`小节中提到的,如果你希望某些下游组件返回带有异步负载的消息(`Future`,`Mono`,以及其他),则必须显式地将异步执行器设置为`null`(或者在使用 XML 配置时`""`)。然后在调用者线程上调用该流,然后可以检索结果。
-##### [](#void-return-type)`void`返回类型
+##### `void`返回类型
与前面提到的返回类型不同,当方法返回类型是`void`时,框架不能隐式地确定你希望下游流异步运行,而调用者线程立即返回。在这种情况下,你必须用`@Async`注释接口方法,如下例所示:
@@ -1193,13 +1193,13 @@ public interface MyGateway {
与`Future>`返回类型不同,如果流引发了某些异常,则无法通知调用方,除非某些自定义`TaskExecutor`(例如`ErrorHandlingTaskExecutor`)与`@Async`注释相关联。
-#### [](#gateway-no-response)未收到响应时的网关行为
+#### 未收到响应时的网关行为
由于[早些时候解释过](#gateway-proxy),网关提供了一种通过 POJO 方法调用与消息传递系统进行交互的便捷方式。但是,通常期望总是返回(即使有异常)的典型方法调用可能并不总是将一对一映射到消息交换(例如,回复消息可能不会到达——相当于方法不返回)。
本节的其余部分涵盖了各种场景,以及如何使网关的行为更具可预测性。可以对某些属性进行配置,以使同步网关行为更可预测,但其中一些属性可能并不总是如你所期望的那样工作。其中一个是`reply-timeout`(在方法级别或`default-reply-timeout`在网关级别)。我们检查`reply-timeout`属性,以查看它如何能够和不能在各种场景中影响同步网关的行为。我们研究了单线程场景(下游的所有组件都通过直接通道连接)和多线程场景(例如,在下游的某个地方,你可能有一个打破单线程边界的 pollable 或 executor 通道)。
-##### [](#long-running-process-downstream)长期运行的流程下游
+##### 长期运行的流程下游
单线程同步网关
@@ -1209,7 +1209,7 @@ public interface MyGateway {
如果多线程消息流中的下游组件仍在运行(可能是由于无限循环或服务速度较慢),那么设置`reply-timeout`会产生一种效果,即允许网关方法调用在超时后返回,因为`GatewayProxyFactoryBean`在回复通道上轮询,等待消息,直到超时结束。但是,如果在产生实际的回复之前已经达到超时,则可能导致网关方法返回“null”。你应该理解,在网关方法调用返回之后,回复消息(如果产生)将被发送到一个回复通道,因此你必须意识到这一点,并在设计流程时将其考虑在内。
-##### [](#downstream-component-returns-null)下游组件返回’null’
+##### 下游组件返回’null’
同步网关——单线程
@@ -1219,7 +1219,7 @@ public interface MyGateway {
行为与前一例相同。
-##### [](#downstream-component-return-signature-is-void-while-gateway-method-signature-is-non-void)下游组件返回签名为“void”,而网关方法签名为非 void
+##### 下游组件返回签名为“void”,而网关方法签名为非 void
同步网关——单线程
@@ -1229,7 +1229,7 @@ public interface MyGateway {
行为与前一例相同。
-##### [](#downstream-component-results-in-runtime-exception)下游组件导致运行时异常
+##### 下游组件导致运行时异常
同步网关——单线程
@@ -1250,11 +1250,11 @@ public interface MyGateway {
有关通过`IntegrationFlows`定义网关的选项,请参见 Java DSL 章节中的[`IntegrationFlow`as gateway](./dsl.html#integration-flow-as-gateway)。
-### [](#service-activator)服务激活器
+### 服务激活器
服务激活器是用于将任何 Spring 管理的对象连接到输入通道的端点类型,以便它可以扮演服务的角色。如果服务产生输出,它也可以连接到一个输出通道。或者,输出产生服务可以位于处理管道或消息流的末端,在这种情况下,可以使用入站消息的`replyChannel`头。如果没有定义输出通道,这是默认的行为。与这里描述的大多数配置选项一样,相同的行为实际上也适用于大多数其他组件。
-#### [](#service-activator-namespace)配置服务激活器
+#### 配置服务激活器
要创建服务激活器,请使用带有“input-channel”和“ref”属性的“service-activator”元素,如下例所示:
@@ -1332,7 +1332,7 @@ public class MyBean {
| |如果`ref`属性引用扩展`AbstractMessageProducingHandler`的 Bean(例如框架本身提供的处理程序),则通过将输出通道直接注入处理程序来优化配置。,在这种情况下,
,每个`ref`必须是单独的 Bean 实例(或`prototype`-作用域 Bean)或使用内部的``配置类型。
如果无意中从多个 bean 引用了相同的消息处理程序,则会出现配置异常。|
|---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-##### [](#service-activators-and-the-spring-expression-language-spel)服务激活器和 Spring 表达式语言
+##### 服务激活器和 Spring 表达式语言
Spring 集成 2.0 以来,服务激活器还可以受益于[SpEL](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#expressions)。
@@ -1355,23 +1355,23 @@ Spring 集成 2.0 以来,服务激活器还可以受益于[SpEL](https://docs.
有关配置服务激活器的更多信息,请参见 Java DSL 章节中的[服务激活器和`.handle()`方法](./dsl.html#java-dsl-handle)。
-#### [](#async-service-activator)异步服务激活器
+#### 异步服务激活器
服务激活器由调用线程调用。如果输入通道是`SubscribableChannel`或`PollableChannel`的 poller 线程,则这是一个上游线程。如果服务返回一个`ListenableFuture>`,那么默认的操作是将其作为消息的有效负载发送到输出(或回复)通道。从版本 4.3 开始,你现在可以将`async`属性设置为`true`(在使用 Java 配置时使用`Object`)。如果当`async`属性被设置为`true`时,服务返回一个`ListenableFuture>`,则调用线程将立即被释放,并在完成将来的线程(从你的服务中)上发送答复消息。这对于使用`PollableChannel`的长时间运行的服务特别有利,因为 Poller 线程被释放以在框架内执行其他服务。
如果服务使用`Exception`完成 future,则发生正常的错误处理。如果存在`ErrorMessage`消息头,则将其发送到`errorChannel`消息头。否则,将把`ErrorMessage`发送到默认的`errorChannel`(如果可用)。
-#### [](#service-activator-return-type)服务激活器和方法返回类型
+#### 服务激活器和方法返回类型
服务方法可以返回成为回复消息有效负载的任何类型。在这种情况下,将创建一个新的`Message>`对象,并复制来自请求消息的所有标题。当交互是基于 POJO 方法调用时,对于大多数 Spring 集成`MessageHandler`实现,这以相同的方式工作。
也可以从该方法返回一个完整的`Message>`对象。但是请记住,与[变形金刚](./transformer.html#transformer)不同的是,对于服务激活器,如果返回的消息中不存在标题,则将通过从请求消息中复制标题来修改此消息。因此,如果你的方法参数是`Message>`,并且你在服务方法中复制了一些(但不是全部)现有的头,那么它们将在回复消息中重新出现。从回复消息中删除头不是服务激活器的责任,并且,遵循松耦合原则,最好在集成流中添加`HeaderFilter`。或者,可以使用 Transformer 代替服务激活器,但是,在这种情况下,当返回完整的`Message>`时,该方法完全负责消息,包括复制请求消息头(如果需要)。你必须确保重要的框架标题(例如`replyChannel`,`errorChannel`)如果存在,就必须保留。
-### [](#delayer)延迟器
+### 延迟器
延迟器是一个简单的端点,它允许消息流延迟一定的时间间隔。当消息延迟时,原始发件人不会阻塞。相反,延迟消息被调度为一个`org.springframework.scheduling.TaskScheduler`的实例,以便在延迟通过后将其发送到输出通道。这种方法即使对于相当长的延迟也是可伸缩的,因为它不会导致大量的发件人线程被阻塞。相反,在典型的情况下,线程池用于实际执行消息的释放。本节包含几个配置延迟器的示例。
-#### [](#delayer-namespace)配置延迟器
+#### 配置延迟器
``元素用于延迟两个消息通道之间的消息流。与其他端点一样,你可以提供“输入通道”和“输出通道”属性,但延迟器也具有“默认延迟”和“表达式”属性(以及“表达式”元素),它们决定每条消息应该延迟的毫秒数。以下示例将所有消息延迟 3 秒钟:
@@ -1461,7 +1461,7 @@ XML
| |`ThreadPoolTaskScheduler`具有一个属性`Map`,该属性可以与`org.springframework.util.ErrorHandler`的一些实现一起注入。
该处理程序允许从发送延迟消息的调度任务的线程处理`Exception`,默认情况下,它使用`org.springframework.scheduling.support.TaskUtils$LoggingErrorHandler`,你可以在日志中看到堆栈跟踪,
你可能需要考虑使用`org.springframework.integration.channel.MessagePublishingErrorHandler`,它将`ErrorMessage`发送到`error-channel`,要么从失败消息的消息头,要么进入默认的`error-channel`。
此错误处理是在事务回滚(如果存在)后执行的。
参见[发布失败](#delayer-release-failures)。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#delayer-message-store)延迟器和消息存储
+#### 延迟器和消息存储
`DelayHandler`将延迟消息保存到提供的`MessageStore`中的消息组中。(“groupid”基于``元素所需的“id”属性。)在`DelayHandler`将消息发送到`output-channel`之前,调度任务将从`MessageStore`中删除一条延迟消息。如果提供的`MessageStore`是持久性的(例如`JdbcMessageStore`),则提供了在应用程序关闭时不丢失消息的能力。在应用程序启动之后,`ErrorMessage`从其消息组中的[表达式评估建议](#expression-advice)中读取消息,并根据消息的原始到达时间(如果延迟是数值的话)重新安排它们的延迟。对于延迟报头为`Date`的消息,在重新调度时使用`Date`。如果延迟消息在`TaskScheduler`中的停留时间超过其“延迟”,则在启动后立即发送该消息。
@@ -1495,13 +1495,13 @@ controlBusChannel.send(delayerReschedulingMessage);
从版本 5.3.7 开始,如果将消息存储到`MessageStore`时事务处于活动状态,则在`TransactionSynchronization.afterCommit()`回调中调度发布任务。这对于防止竞争情况是必要的,在这种情况下,调度的发布可以在事务提交之前运行,并且找不到消息。在这种情况下,消息将在延迟之后发布,或者在事务提交之后发布,以较晚者为准。
-#### [](#delayer-release-failures)发行失败
+#### 发行失败
从版本 5.0.8 开始,DeLayer 上有两个新属性:
* `maxAttempts`(默认 5)
-* [](#delayer-release-failures)(默认 1 秒)
+* (默认 1 秒)
当消息被释放时,如果下游流失败,将在`retryDelay`之后尝试释放。如果达到`maxAttempts`,则该消息将被丢弃(除非该发布是事务性的,在这种情况下,该消息将保留在存储区中,但将不再计划发布,直到重新启动应用程序,或者调用`reschedulePersistedMessages()`方法,如上所述)。
@@ -1509,7 +1509,7 @@ controlBusChannel.send(delayerReschedulingMessage);
如果错误流使用错误消息并正常退出,则不会采取进一步的操作;如果发布是事务性的,则事务将提交,消息将从存储中删除。如果错误流抛出一个异常,则释放将被重试到`maxAttempts`,正如上面讨论的那样。
-### [](#scripting)脚本支持
+### 脚本支持
Spring Integration2.1 增加了对[面向 Java 规范的 JSR223 脚本](https://www.jcp.org/en/jsr/detail?id=223)的支持,在 Java 版本 6 中引入。它允许你使用以任何受支持的语言(包括 Ruby、JRuby、Groovy 和 Kotlin)编写的脚本来为各种集成组件提供逻辑,类似于 Spring 表达式语言在 Spring 集成中的使用方式。有关 JSR223 的更多信息,请参见[文件](https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/prog_guide/api.html)。
@@ -1576,7 +1576,7 @@ runtime 'org.jetbrains.kotlin:kotlin-scripting-compiler-embeddable'
| |如果你计划使用 Groovy 作为脚本语言,我们建议你使用[Spring-Integration’s Groovy Support](./groovy.html#groovy),因为它提供了 Groovy 特有的其他功能。
但是,这一部分也是相关的。|
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-#### [](#scripting-config)脚本配置
+#### 脚本配置
根据集成需求的复杂性,脚本可以作为 XML 配置中的 CDATA 内联提供,也可以作为对包含该脚本的 Spring 资源的引用提供。 Spring 为了启用脚本支持,集成定义了一个`headers`,它将消息有效负载绑定到一个名为`payload`的变量,并将消息头绑定到一个`headers`变量,这两个变量都可以在脚本执行上下文中访问。你所需要做的就是编写一个使用这些变量的脚本。以下两个示例展示了创建筛选器的示例配置:
@@ -1669,7 +1669,7 @@ XML
| |无法重新加载内联脚本。|
|---|-----------------------------------|
-##### [](#scripting-script-variable-bindings)脚本变量绑定
+##### 脚本变量绑定
需要变量绑定来使脚本能够引用外部提供给脚本执行上下文的变量。默认情况下,`headers`和`headers`用作绑定变量。可以使用``元素(或`ScriptSpec.variables()`选项)将其他变量绑定到脚本,如下例所示:
@@ -1747,7 +1747,7 @@ XML
| |不能同时提供`script-variable-generator`属性和``元素。
它们是互斥的。|
|---|-------------------------------------------------------------------------------------------------------------------------------|
-### [](#groovy)Groovy 支持
+### Groovy 支持
在 Spring Integration2.0 中,我们添加了 Groovy 支持,允许你使用 Groovy 脚本语言为各种集成组件提供逻辑——类似于 Spring Expression 语言在路由、转换和其他集成问题中所支持的方式。有关 Groovy 的更多信息,请参见 Groovy 文档,你可以在[项目网站](https://groovy-lang.org/)上找到该文档。
@@ -1769,7 +1769,7 @@ Gradle
compile "org.springframework.integration:spring-integration-groovy:5.5.9"
```
-#### [](#groovy-config)Groovy 配置
+#### Groovy 配置
在 Spring Integration2.1 中,Groovy 支持的配置名称空间是 Spring Integration 的脚本支持的扩展,并共享[脚本支持](./scripting.html#scripting)部分中详细描述的核心配置和行为。尽管 Groovy 脚本很好地得到了通用脚本支持,但 Groovy 支持提供了`Groovy`配置名称空间,它由 Spring 框架的`org.springframework.scripting.groovy.GroovyScriptFactory`和相关组件支持,为使用 Groovy 提供了扩展功能。下面的清单显示了两个示例配置:
@@ -1789,7 +1789,7 @@ compile "org.springframework.integration:spring-integration-groovy:5.5.9"
正如前面的示例所示,该配置看起来与常规脚本支持配置相同。唯一的区别是使用 Groovy 命名空间,如`int-groovy`命名空间前缀所示。还要注意,`