From cf2182f4dfd3e97c27a15b356ca044075c8817f0 Mon Sep 17 00:00:00 2001 From: ZhangKai Date: Mon, 7 Mar 2022 16:55:50 +0800 Subject: [PATCH] #21 spring-integration cn header hfef remove --- docs/spring-integration/amqp.md | 54 +- docs/spring-integration/configuration.md | 34 +- docs/spring-integration/core.md | 100 +-- docs/spring-integration/dsl.md | 50 +- docs/spring-integration/endpoint-summary.md | 2 +- docs/spring-integration/error-handling.md | 2 +- docs/spring-integration/event.md | 6 +- docs/spring-integration/feed.md | 10 +- docs/spring-integration/file.md | 60 +- docs/spring-integration/ftp.md | 78 +- docs/spring-integration/gemfire.md | 14 +- docs/spring-integration/history.md | 842 +++++++++--------- docs/spring-integration/http.md | 48 +- docs/spring-integration/ip.md | 90 +- docs/spring-integration/jdbc.md | 60 +- docs/spring-integration/jms.md | 38 +- docs/spring-integration/jmx.md | 22 +- docs/spring-integration/jpa.md | 68 +- docs/spring-integration/kafka.md | 56 +- docs/spring-integration/kotlin-dsl.md | 2 +- docs/spring-integration/mail.md | 20 +- docs/spring-integration/message-publishing.md | 12 +- docs/spring-integration/message-routing.md | 122 +-- .../message-transformation.md | 80 +- docs/spring-integration/message.md | 18 +- .../spring-integration/messaging-endpoints.md | 168 ++-- docs/spring-integration/mongodb.md | 26 +- docs/spring-integration/mqtt.md | 22 +- docs/spring-integration/overview.md | 46 +- docs/spring-integration/preface.md | 10 +- docs/spring-integration/r2dbc.md | 6 +- docs/spring-integration/reactive-streams.md | 24 +- docs/spring-integration/redis.md | 44 +- docs/spring-integration/resource.md | 4 +- docs/spring-integration/resources.md | 2 +- docs/spring-integration/rmi.md | 10 +- docs/spring-integration/rsocket.md | 14 +- docs/spring-integration/samples.md | 26 +- docs/spring-integration/security.md | 6 +- docs/spring-integration/sftp.md | 78 +- docs/spring-integration/spel.md | 10 +- docs/spring-integration/stomp.md | 20 +- docs/spring-integration/stream.md | 8 +- docs/spring-integration/syslog.md | 6 +- docs/spring-integration/system-management.md | 44 +- docs/spring-integration/testing.md | 24 +- docs/spring-integration/transactions.md | 14 +- docs/spring-integration/web-sockets.md | 22 +- docs/spring-integration/webflux.md | 12 +- docs/spring-integration/whats-new.md | 28 +- docs/spring-integration/ws.md | 18 +- docs/spring-integration/xml.md | 56 +- docs/spring-integration/xmpp.md | 22 +- docs/spring-integration/zeromq.md | 12 +- docs/spring-integration/zookeeper.md | 8 +- 55 files changed, 1339 insertions(+), 1339 deletions(-) diff --git a/docs/spring-integration/amqp.md b/docs/spring-integration/amqp.md index e905c16..6c1a400 100644 --- a/docs/spring-integration/amqp.md +++ b/docs/spring-integration/amqp.md @@ -1,6 +1,6 @@ # AMQP 支持 -## [](#amqp)AMQP 支持 +## AMQP 支持 Spring 集成提供了用于通过使用高级消息队列协议接收和发送消息的通道适配器。 @@ -42,7 +42,7 @@ Spring 鉴于所提供的 AMQP 通道适配器仅用于单向消息传递（发 小贴士：你应该熟悉[reference documentation of the Spring AMQP project](https://docs.spring.io/spring-amqp/reference/html/)。它提供了关于 Spring 与 AMQP 的集成的更深入的信息，特别是与 RabbitMQ 的集成。 -### [](#amqp-inbound-channel-adapter)入站通道适配器 +### 入站通道适配器 下面的清单显示了 AMQP 入站通道适配器的可能配置选项： @@ -167,7 +167,7 @@ XML 从版本 5.5 开始，`AmqpInboundChannelAdapter`可以配置`org.springframework.amqp.rabbit.retry.MessageRecoverer`策略，当内部调用重试操作时，该策略在`RecoveryCallback`中使用。有关更多信息，请参见`setMessageRecoverer()`爪哇docs。 -#### [](#amqp-debatching)批处理消息 +#### 批处理消息 有关批处理消息的更多信息，请参见[the Spring AMQP Documentation](https://docs.spring.io/spring-amqp/docs/current/reference/html/#template-batching)。 @@ -180,9 +180,9 @@ XML | |当重试操作需要恢复时，必须在批处理中使用`org.springframework.amqp.rabbit.retry.MessageBatchRecoverer`。| |---|-------------------------------------------------------------------------------------------------------------------------------------------| -### [](#polled-inbound-channel-adapter)已调查的入站通道适配器 +### 已调查的入站通道适配器 -#### [](#overview)概述 +#### 概述 版本 5.0.1 引入了一个轮询通道适配器，允许你按需获取单个消息——例如，使用`MessageSourcePollingTemplate`或 Poller。有关更多信息，请参见[延迟确认可收集消息源](./polling-consumer.html#deferred-acks-message-source)。 @@ -221,13 +221,13 @@ XML This adapter currently does not have XML configuration support. ``` -#### [](#amqp-polled-debatching)批处理消息 +#### 批处理消息 见[批处理消息](#amqp-debatching)。 对于轮询的适配器，不存在侦听器容器，批处理的消息总是会被删除（如果`BatchingStrategy`支持这样做的话）。 -### [](#amqp-inbound-gateway)入站网关 +### 入站网关 入站网关支持入站通道适配器上的所有属性（除了“通道”被“请求通道”代替），以及一些附加属性。下面的清单显示了可用的属性： @@ -313,11 +313,11 @@ XML 从版本 5.5 开始，`AmqpInboundChannelAdapter`可以配置`org.springframework.amqp.rabbit.retry.MessageRecoverer`策略，当内部调用重试操作时，该策略在`RecoveryCallback`中使用。有关更多信息，请参见`setMessageRecoverer()`Javadocs。 -#### [](#amqp-gateway-debatching)批处理消息 +#### 批处理消息 见[批处理消息](#amqp-debatching)。 -### [](#amqp-inbound-ack)入站端点确认模式 +### 入站端点确认模式 默认情况下，入站端点使用`AUTO`确认模式，这意味着当下游集成流完成（或者通过使用`QueueChannel`或`ExecutorChannel`将消息传递给另一个线程）时，容器会自动确认消息。将模式设置为`NONE`将配置消费者，使得完全不使用确认（代理在消息发送后立即自动确认消息）。将模式设置为`MANUAL`，可以让用户代码在处理过程中的另一个点确认消息。为了支持这一点，在此模式下，端点在`amqp_channel`和`amqp_deliveryTag`标题中分别提供`Channel`和`deliveryTag`。 @@ -348,11 +348,11 @@ public Object handle(@Payload String payload, @Header(AmqpHeaders.CHANNEL) Chann } ``` -### [](#amqp-outbound-endpoints)出站端点 +### 出站端点 以下出站端点有许多类似的配置选项。从版本 5.2 开始，添加了`confirm-timeout`。通常，当启用了 Publisher Confirms 时，代理将快速返回一个 ACK（或 NACK），该 ACK 将被发送到相应的通道。如果在接收到确认之前关闭了通道，则 Spring AMQP 框架将合成 NACK。“丢失”ACK 永远不会发生，但是，如果你设置了此属性，则端点将定期检查它们，并在时间过去而未收到确认的情况下合成 NACK。 -### [](#amqp-outbound-channel-adapter)出站通道适配器 +### 出站通道适配器 下面的示例显示了 AMQP 出站通道适配器的可用属性： @@ -436,7 +436,7 @@ XML | |return-channel

使用`return-channel`需要一个`RabbitTemplate`，其`mandatory`属性设置为`true`，而`CachingConnectionFactory`属性设置为`true`。
当使用带有返回的多个出站端点时，每个端点都需要一个单独的`RabbitTemplate`。| |---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -### [](#amqp-outbound-gateway)出站网关 +### 出站网关 下面的清单显示了 AMQP 出站网关的可能属性： @@ -536,7 +536,7 @@ XML 请注意，出站适配器和出站网关配置之间的唯一区别是`expectReply`属性的设置。 -### [](#amqp-async-outbound-gateway)异步出站网关 +### 异步出站网关 在上一节中讨论的网关是同步的，因为发送线程被挂起，直到收到答复（或发生超时）。 Spring 集成版本 4.3 增加了一个异步网关，它使用 Spring AMQP 中的`AsyncRabbitTemplate`。当发送消息时，线程在发送操作完成后立即返回，当收到消息时，响应将在模板的侦听器容器线程上发送。当在 Poller 线程上调用网关时，这可能是有用的。该线程已被释放，并可用于框架中的其他任务。 @@ -649,7 +649,7 @@ XML | |RabbitTemplate

当你使用确认和返回时，我们建议将连接到`RabbitTemplate`的`AsyncRabbitTemplate`中的
专用。否则，可能会遇到意想不到的副作用。| |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -### [](#alternative-confirms-returns)发布者确认和返回的替代机制 +### 发布者确认和返回的替代机制 当连接工厂被配置为 Publisher 确认和返回时，上面的小节讨论了用于异步接收确认和返回的消息通道的配置。从版本 5.4 开始，有一个额外的机制，通常更容易使用。 @@ -674,11 +674,11 @@ catch { ... } 为了提高性能，你可能希望发送多条消息，然后等待确认，而不是一次发送一条消息。返回的消息是转换后的原始消息；你可以使用所需的任何附加数据进行子类`CorrelationData`。 -### [](#amqp-conversion-inbound)入站消息转换 +### 入站消息转换 到达通道适配器或网关的入站消息将使用消息转换器转换为`spring-messaging``Message`有效负载。默认情况下，使用`SimpleMessageConverter`，它处理 Java 序列化和文本。默认情况下，标头使用`DefaultHeaderMapper.inboundMapper()`进行映射。如果发生了转换错误，并且没有定义错误通道，那么异常将被抛到容器中，并由侦听器容器的错误处理程序处理。默认的错误处理程序将转换错误视为致命错误，并且消息将被拒绝（如果队列是这样配置的，则将其路由到死信交换）。如果定义了错误通道，则`ErrorMessage`有效负载是一个`ListenerExecutionFailedException`，带有属性`failedMessage`（无法转换的 Spring AMQP 消息）和`cause`。如果容器`AcknowledgeMode`是`AUTO`（默认值），并且错误流在不抛出异常的情况下消耗错误，则将确认原始消息。如果错误流抛出一个异常，那么异常类型将与容器的错误处理程序一起，决定是否重新请求消息。如果容器配置为`AcknowledgeMode.MANUAL`，则有效负载是带有附加属性`channel`和`deliveryTag`的`ManualAckListenerExecutionFailedException`。这使得错误流能够为消息调用`basicAck`或`basicNack`（或`basicReject`）来控制其配置。 -### [](#content-type-conversion-outbound)出站消息转换 +### 出站消息转换 Spring AMQP1.4 引入了`ContentTypeDelegatingMessageConverter`，其中实际的转换器是基于传入的内容类型选择消息属性的。这可以由入站端点使用。 @@ -716,17 +716,17 @@ Spring AMQP1.4 引入了`ContentTypeDelegatingMessageConverter`，其中实际 | |从版本 5.0 开始，添加到出站消息的`MessageProperties`的标题永远不会被映射的标题覆盖（默认情况下）。
以前，只有当消息转换器是`ContentTypeDelegatingMessageConverter`（在这种情况下，头是首先映射的，以便可以选择适当的转换器）。，对于其他转换器，例如`SimpleMessageConverter`，映射的标头覆盖了转换器添加的任何标头。
当出站消息有一些剩余的`contentType`标头（可能来自入站通道适配器）时，这会导致问题。并且正确的出站`contentType`被错误地覆盖。
解决方法是在将消息发送到出站端点之前使用头部过滤器删除头部。

但是，在某些情况下，需要使用以前的行为—例如，当`String`包含 JSON 的有效负载时，`SimpleMessageConverter`不知道内容，并将`contentType`消息属性设置为`text/plain`，但你的应用程序想要重写通过将发送到出站端点的消息的`contentType`头设置为`application/json`。
`ObjectToJsonTransformer`确实做到了这（默认情况下）。

现在在出站通道适配器和网关上（以及在 AMQP 支持的通道上）有一个名为`headersMappedLast`的属性。
将其设置为`true`，以恢复覆盖转换器添加的属性的行为。

从 5.1.9 版本开始，类似的`replyHeadersMappedLast`是为`AmqpInboundGateway`提供的，当我们生成一个答复并想要覆盖由转换器填充的标题时。
有关更多信息，请参见其 Javadocs。| |---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -### [](#amqp-user-id)出站用户 ID +### 出站用户 ID Spring AMQP 版本 1.6 引入了一种机制，以允许用于出站消息的默认用户 ID 的规范。始终可以设置`AmqpHeaders.USER_ID`标头，它现在优先于默认值。这对消息接收者可能很有用。对于入站消息，如果消息发布者设置了属性，则该属性在`AmqpHeaders.RECEIVED_USER_ID`标头中可用。注意 RabbitMQ[验证用户 ID 是连接的实际用户 ID，或者该连接允许模拟](https://www.rabbitmq.com/validated-user-id.html)。 要为出站消息配置默认的用户 ID，请在`RabbitTemplate`上对其进行配置，并将出站适配器或网关配置为使用该模板。类似地，要在回复中设置用户 ID 属性，请在入站网关中插入一个适当配置的模板。有关更多信息，请参见[Spring AMQP documentation](https://docs.spring.io/spring-amqp/reference/html/_reference.html#template-user-id)。 -### [](#amqp-delay)延迟消息交换 +### 延迟消息交换 Spring AMQP 支持[RabbitMQ 延迟消息交换插件](https://docs.spring.io/spring-amqp/reference/html/#delayed-message-exchange)。对于入站消息，`x-delay`标头映射到`AmqpHeaders.RECEIVED_DELAY`标头。设置`AMQPHeaders.DELAY`报头会在出站消息中设置相应的`x-delay`报头。你还可以在出站端点上指定`delay`和`delayExpression`属性（当使用 XML 配置时，`delay-expression`）。这些属性优先于`AmqpHeaders.DELAY`标头。 -### [](#amqp-channels)AMQP 支持的消息通道 +### AMQP 支持的消息通道 有两个消息通道实现可用。一种是点对点，另一种是发布订阅。这两个通道都为底层`AmqpTemplate`和`SimpleMessageListenerContainer`提供了广泛的配置属性（如本章前面所示的通道适配器和网关）。然而，我们在这里展示的示例具有最小的配置。探索 XML 模式以查看可用的属性。 @@ -760,7 +760,7 @@ Spring AMQP 支持[RabbitMQ 延迟消息交换插件](https://docs.spring.io/spr | |从版本 5.0 开始，poller 通道现在为指定的`receiveTimeout`阻塞 poller 线程（默认值为 1 秒）。
以前，与其他`PollableChannel`实现不同，如果没有可用的消息，线程将立即返回到调度程序，与接收超时无关。
拦截比使用`basicGet()`检索消息（没有超时）要贵一些，因为必须创建一个使用者来接收每个消息。
要恢复以前的行为，请将 poller 的`receiveTimeout`设置为 0。| |---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -#### [](#configuring-with-java-configuration)使用 Java 配置进行配置 +#### 使用 Java 配置进行配置 下面的示例展示了如何使用 Java 配置来配置通道： @@ -793,7 +793,7 @@ public AmqpChannelFactoryBean pubSub(ConnectionFactory connectionFactory) { } ``` -#### [](#configuring-with-the-java-dsl)使用 Java DSL 进行配置 +#### 使用 Java DSL 进行配置 下面的示例展示了如何使用 Java DSL 配置通道： @@ -829,9 +829,9 @@ public IntegrationFlow pubSubInFlow(ConnectionFactory connectionFactory) { } ``` -### [](#amqp-message-headers)AMQP 消息头 +### AMQP 消息头 -#### [](#overview-2)概述 +#### 概述 Spring 集成 AMQP 适配器自动映射所有 AMQP 属性和标头。（这是从 4.3-以前，只有标准标题被映射的变化）。默认情况下，这些属性通过使用[`DefaultAmqpHeaderMapper`]（https://DOCS. Spring.io/ Spring-integration/api/org/springframework/integration/amqp/support/defaultamqpheadermapper.html）来复制到 Spring Integration`MessageHeaders`。 @@ -919,7 +919,7 @@ AMQP[`MessageProperties`]（https://DOCS. Spring.io/ Spring-amqp/api/org/springf | |从版本 5.1 开始，`DefaultAmqpHeaderMapper`将分别回到映射`MessageHeaders.ID`和`MessageHeaders.TIMESTAMP`到`MessageProperties.messageId`和`MessageProperties.timestamp`，如果出站消息上不存在相应的`amqp_messageId`或`amqp_timestamp`标头。
入站属性将像以前一样映射到`amqp_*`标头。
当消息消费者使用有状态重试时，填充`messageId`属性是有用的。| |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -#### [](#amqp-content-type)标题`contentType` +#### 标题`contentType` 与其他头不同，`AmqpHeaders.CONTENT_TYPE`不带`amqp_`前缀；这允许在不同的技术之间透明地传递 ContentType 头。例如，发送到 RabbitMQ 队列的入站 HTTP 消息。 @@ -927,7 +927,7 @@ AMQP[`MessageProperties`]（https://DOCS. Spring.io/ Spring-amqp/api/org/springf 在版本 5.1 之前，这个头也被映射为`MessageProperties.headers`映射中的一个条目；这是不正确的，而且，该值可能是错误的，因为底层的 Spring AMQP 消息转换器可能已经更改了内容类型。这样的更改将反映在第一类`content_type`属性中，但不会反映在 RabbitMQ 头文件映射中。入站映射忽略了 headers 映射值。`contentType`不再映射到 headers 映射中的条目。 -### [](#amqp-strict-ordering)严格的消息排序 +### 严格的消息排序 本节描述了入站和出站消息的消息排序。 @@ -935,7 +935,7 @@ AMQP[`MessageProperties`]（https://DOCS. Spring.io/ Spring-amqp/api/org/springf 如果需要对入站消息进行严格排序，则必须将入站侦听器容器的`prefetchCount`属性配置为`1`。这是因为，如果一条消息失败并被重新传递，它将在已有的预取消息之后到达。自 Spring AMQP 版本 2.0 以来，`prefetchCount`默认为`250`，以提高性能。严格的订货要求是以性能下降为代价的。 -#### [](#outbound)出站 +#### 出站 考虑以下集成流程： @@ -971,7 +971,7 @@ public IntegrationFlow flow(RabbitTemplate template) { | |在下游流中不能有线程切换（`QueueChannel`，`ExecutorChannel`，以及其他）。| |---|--------------------------------------------------------------------------------------------------------| -### [](#amqp-samples)AMQP 样本 +### AMQP 样本 要对 AMQP 适配器进行实验，请查看 Spring Integration Samples Git Repository 中可用的示例，网址为[https://github.com/SpringSource/spring-integration-samples](https://github.com/spring-projects/spring-integration-samples) diff --git a/docs/spring-integration/configuration.md b/docs/spring-integration/configuration.md index 320856c..d5fe7c6 100644 --- a/docs/spring-integration/configuration.md +++ b/docs/spring-integration/configuration.md @@ -1,10 +1,10 @@ # 配置 -## [](#configuration)配置 +## 配置 Spring 集成提供了许多配置选项。你选择哪一种选择取决于你的特殊需求，以及你更喜欢工作的级别。与 Spring 框架一般一样，你可以混合和匹配各种技术以适应手头的问题。例如，你可以为大多数配置选择基于 XSD 的名称空间，并将其与使用注释进行配置的几个对象结合在一起。两者尽可能地提供一致的命名。由 XSD 模式定义的 XML 元素与注释的名称匹配，并且这些 XML 元素的属性与注释属性的名称匹配。你也可以直接使用 API，但是我们希望大多数开发人员选择一个更高级别的选项，或者基于名称空间的配置和注释驱动的配置的组合。 -### [](#configuration-namespace)名称空间支持 +### 名称空间支持 你可以使用 XML 元素配置 Spring 集成组件，这些 XML 元素直接映射到 Enterprise 集成的术语和概念。在许多情况下，元素名与[*Enterprise 整合模式 *](https://www.enterpriseintegrationpatterns.com/)书中的元素名匹配。 @@ -70,7 +70,7 @@ Spring 集成提供了许多其他名称空间。实际上，每个提供名称 本参考手册在相应章节中提供了各种元素的具体示例。在这里，需要认识的主要问题是每个名称空间 URI 和模式位置的命名的一致性。 -### [](#namespace-taskscheduler)配置任务调度程序 +### 配置任务调度程序 在 Spring 集成中，`ApplicationContext`扮演着消息总线的中心角色，你只需要考虑几个配置选项。首先，你可能想要控制中心`TaskScheduler`实例。你可以通过提供一个名为`taskScheduler`的 Bean 来实现此目的。这也被定义为一个常数，如下所示： @@ -96,7 +96,7 @@ IntegrationContextUtils.TASK_SCHEDULER_BEAN_NAME 有关更多信息，请参见[错误处理](./error-handling.html#error-handling)。 -### [](#global-properties)全局属性 +### 全局属性 可以通过在 Classpath 上提供一个属性文件来覆盖某些全局框架属性。 @@ -141,7 +141,7 @@ spring.integration.readOnly.headers= spring.integration.messagingTemplate.throwExceptionOnLateReply=true ``` -### [](#annotations)注释支持 +### 注释支持 除了对配置消息端点的 XML 命名空间的支持外，还可以使用注释。首先， Spring 集成提供了类级`@MessageEndpoint`作为原型注释，这意味着它本身用 Spring 的`@Component`注释，因此通过 Spring 的组件扫描自动识别为 Bean 定义。 @@ -253,7 +253,7 @@ public class ThingService { | |在解析所提及的注释（当没有配置特定的通道 Bean 时）之后自动创建的通道和相应的消费者端点，在上下文初始化的末尾附近被声明为 bean。
这些 bean**CAN**在其他服务中被自动连线，但它们必须用`@Lazy`注释标记，因为这些定义通常在正常的自动布线处理过程中还不可用。

```
@Autowired
@Lazy
@Qualifier("someChannel")
MessageChannel someChannel;
...

@Bean
Thing1 dependsOnSPCA(@Qualifier("someInboundAdapter") @Lazy SourcePollingChannelAdapter someInboundAdapter) {
...
}
```| |---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -#### [](#configuration-using-poller-annotation)使用`@Poller`注释 +#### 使用`@Poller`注释 Spring Integration4.0 之前，消息传递注释要求`inputChannel`是对`SubscribableChannel`的引用。对于`PollableChannel`实例，需要一个``元素来配置``并使复合端点为`PollingConsumer`。版本 4.0 引入了`@Poller`注释，以允许直接在消息传递注释上配置`poller`属性，如下例所示： @@ -319,7 +319,7 @@ public class AnnotationService { 消息传递注释上的`poller()`属性与`reactive()`属性是互斥的。有关更多信息，请参见下一节。 -#### [](#configuration-using-reactive-annotation)使用`@Reactive`注释 +#### 使用`@Reactive`注释 `ReactiveStreamsConsumer`自版本 5.0 以来一直存在，但它仅在端点的输入通道是`FluxMessageChannel`（或任何`org.reactivestreams.Publisher`实现）时才应用。从版本 5.3 开始，当目标消息处理程序是独立于输入通道类型的`ReactiveMessageHandler`时，框架也会创建它的实例。对于从版本 5.5 开始的所有消息传递注释，都引入了`@Reactive`子注释（类似于上面提到的`@Poller`）。它接受一个可选的`Function>, ? extends Publisher>>` Bean 引用，并且独立于输入通道类型和消息处理程序，将目标端点转换为`ReactiveStreamsConsumer`实例。该函数使用来自`Flux.transform()`操作符的一些自定义（`publishOn()`，`doOnNext()`，`log()`，`retry()`等）在来自输入通道的反应流上应用。 @@ -339,7 +339,7 @@ public void handleReactive(String payload) { 消息传递注释上的`reactive()`属性与`poller()`属性是互斥的。有关更多信息，请参见[使用`@Poller`注释]（#configuration-using-poller-annotation）和[反应流支持](./reactive-streams.html#reactive-streams)。 -#### [](#using-the-inboundchanneladapter-annotation)使用`@InboundChannelAdapter`注释 +#### 使用`@InboundChannelAdapter`注释 版本 4.0 引入了`@InboundChannelAdapter`方法级注释。它为带注释的方法基于`MethodInvokingMessageSource`生成`SourcePollingChannelAdapter`集成组件。该注释类似于``XML 组件，并且具有相同的限制：该方法不能具有参数，并且返回类型不能是`void`。它有两个属性：`value`（要求的`MessageChannel` Bean name）和`poller`（可选的`@Poller`注释，如[前面描述的](#configuration-using-poller-annotation)）。如果需要提供一些`MessageHeaders`，使用`Message`返回类型并使用`MessageBuilder`来构建`Message`。使用`MessageBuilder`可以配置`MessageHeaders`。下面的示例展示了如何使用`@InboundChannelAdapter`注释： @@ -363,11 +363,11 @@ public String foo() { 参见[`@MessagingGateway`注释]（./gateway.html#messaging-gateway-annotation）。 -#### [](#using-the-integrationcomponentscan-annotation)使用`@IntegrationComponentScan`注释 +#### 使用`@IntegrationComponentScan`注释 标准的 Spring 框架`@ComponentScan`注释不扫描接口中的原型`@Component`注释。为了克服这个限制并允许`@MessagingGateway`的配置（参见[`@MessagingGateway`注释]（./gateway.html#messaging-gateway-annotation）），我们引入了`@IntegrationComponentScan`机制。此注释必须与`@Configuration`注释一起放置，并进行自定义以定义其扫描选项，例如`basePackages`和`basePackageClasses`。在这种情况下，所有发现的带有`@MessagingGateway`注释的接口都被解析并注册为`GatewayProxyFactoryBean`实例。所有其他基于类的组件都由标准`@ComponentScan`解析。 -### [](#meta-annotations)消息传递元注释 +### 消息传递元注释 从版本 4.0 开始，所有消息传递注释都可以配置为元注释，并且所有用户定义的消息传递注释都可以定义相同的属性来覆盖其默认值。此外，元注释可以按层次进行配置，如下例所示： @@ -399,7 +399,7 @@ public Object service(Object payload) { 分层配置元注释使用户可以为各种属性设置默认值，并使 Framework Java 依赖与用户注释隔离，从而避免在用户类中使用它们。如果框架找到了一个具有框架元注释的用户注释的方法，则将其视为直接使用框架注释对该方法进行了注释。 -#### [](#annotations_on_beans)方法上的注释 +#### 方法上的注释 从版本 4.0 开始，你可以在`@Configuration`类中的`@Bean`方法定义上配置消息注释，以基于 bean 而不是方法生成消息端点。当`@Bean`定义是“开箱即用”`MessageHandler`实例（`AggregatingMessageHandler`，`DefaultMessageSplitter`，以及其他），`Transformer`实例（`JsonToObjectTransformer`，`ClaimCheckOutTransformer`，以及其他），以及`MessageSource`实例（`FileReadingMessageSource`，`RedisStoreMessageSource`，以及其他）时，它是有用的。下面的示例展示了如何使用带有`@Bean`注释的消息传递注释： @@ -477,7 +477,7 @@ public class MyFlowConfiguration { | |使用 Java 配置，你可以在`@Bean`方法级别上使用任何`@Conditional`（例如，`@Profile`）的定义来跳过 Bean 注册的某些条件原因。
下面的示例展示了如何这样做：

```
@Bean
@ServiceActivator(inputChannel = "skippedChannel")
@Profile("thing")
public MessageHandler skipped() {
return System.out::println;
}
```连同现有的容器逻辑一起，消息传递端点 Bean（基于`@ServiceActivator`注释）也未注册。| |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -#### [](#creating-a-bridge-with-annotations)创建带有注释的桥 +#### 创建带有注释的桥 从版本 4.0 开始，Java Configuration 提供`@BridgeFrom`和`@BridgeTo``@Bean`方法注释，以便在`MessageChannel`类中标记`MessageChannel`bean。这些确实是为了完整性而存在的，提供了一种方便的机制来声明`BridgeHandler`及其消息端点配置： @@ -506,15 +506,15 @@ public MessageChannel bridgeToInput() { 你也可以将这些注释用作元注释。 -#### [](#advising-annotated-endpoints)通知带注释的端点 +#### 通知带注释的端点 见[使用注释为端点提供建议](./handler-advice.html#advising-with-annotations)。 -### [](#message-mapping-rules)消息映射规则和约定 +### 消息映射规则和约定 Spring 集成实现了一种灵活的功能，通过依赖一些默认规则和定义某些约定，在不提供额外配置的情况下将消息映射到方法及其参数。以下各节中的示例阐明了这些规则。 -#### [](#sample-scenarios)示例场景 +#### 示例场景 下面的示例显示了一个未注释的参数（对象或原语），它不是具有非空返回类型的`Map`或`Properties`对象： @@ -580,7 +580,7 @@ public void soSomething(); 这个示例与前面的示例相同，但不产生输出。 -#### [](#annotation-based-mapping)基于注释的映射 +#### 基于注释的映射 基于注释的映射是将消息映射到方法的最安全、最不模糊的方法。下面的示例展示了如何显式地将方法映射到标头： @@ -614,7 +614,7 @@ public String soSomething(@Headers Map m, @Header("something") Map f, @Header("s 这个示例将特别有问题，因为它的两个参数是`Map`实例。然而，使用基于注释的映射，可以很容易地避免歧义。在这个示例中，第一个参数映射到所有消息头，而第二个和第三个参数映射到名为“Something”和“Somethothing”的消息头的值。有效载荷没有被映射到任何参数。 -#### [](#complex-scenarios)复杂情景 +#### 复杂情景 下面的示例使用了多个参数： diff --git a/docs/spring-integration/core.md b/docs/spring-integration/core.md index ec8cdba..da6fb22 100644 --- a/docs/spring-integration/core.md +++ b/docs/spring-integration/core.md @@ -1,12 +1,12 @@ # 核心消息传递 -## [](#messaging-channels-section)消息传递通道 +## 消息传递通道 -### [](#channel)消息通道 +### 消息通道 虽然`Message`在封装数据方面发挥着关键作用，但将消息生产者与消息消费者分离开来的是`MessageChannel`。 -#### [](#channel-interfaces)MessageChannel 接口 +#### MessageChannel 接口 Spring 集成的顶级`MessageChannel`接口定义如下： @@ -21,7 +21,7 @@ public interface MessageChannel { 发送消息时，如果消息发送成功，则返回值为`true`。如果发送调用超时或被中断，它将返回`false`。 -##### [](#channel-interfaces-pollablechannel)`PollableChannel` +##### `PollableChannel` 由于消息通道可能会或可能不会缓冲消息（如[Spring Integration Overview](./overview.html#overview)中所讨论的），因此两个子接口定义了缓冲和非缓冲通道行为。下面的清单显示了`PollableChannel`接口的定义： @@ -37,7 +37,7 @@ public interface PollableChannel extends MessageChannel { 与发送方法一样，当接收到消息时，在超时或中断的情况下，返回值为 null。 -##### [](#channel-interfaces-subscribablechannel)`SubscribableChannel` +##### `SubscribableChannel` `SubscribableChannel`基本接口是通过将消息直接发送到其订阅的`MessageHandler`实例的通道来实现的。因此，它们不提供用于轮询的接收方法。相反，他们定义了管理这些订阅者的方法。下面的清单显示了`SubscribableChannel`接口的定义： @@ -51,11 +51,11 @@ public interface SubscribableChannel extends MessageChannel { } ``` -#### [](#channel-implementations)消息通道实现 +#### 消息通道实现 Spring 集成提供了几种不同的消息通道实现方式。下面几节简要介绍每一种方法。 -##### [](#channel-implementations-publishsubscribechannel)`PublishSubscribeChannel` +##### `PublishSubscribeChannel` `PublishSubscribeChannel`实现将发送给它的任何`Message`广播给其所有订阅的处理程序。这通常用于发送事件消息，其主要作用是通知（与文档消息相反，文档消息通常由单个处理程序处理）。请注意，`PublishSubscribeChannel`仅用于发送。由于它在调用`send(Message)`方法时直接向订阅者广播，因此消费者无法轮询消息（它没有实现`PollableChannel`，因此没有`receive()`方法）。相反，任何订阅服务器本身必须是`MessageHandler`，并且依次调用订阅服务器的`handleMessage(Message)`方法。 @@ -64,7 +64,7 @@ Spring 集成提供了几种不同的消息通道实现方式。下面几节简 | |如果使用`TaskExecutor`，则仅使用存在正确数量的订阅服务器来进行此确定，因为消息的实际处理是异步执行的。| |---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -##### [](#channel-implementations-queuechannel)`QueueChannel` +##### `QueueChannel` `QueueChannel`实现封装了一个队列。与`PublishSubscribeChannel`不同，`QueueChannel`具有点对点语义。换句话说，即使该通道有多个消费者，其中只有一个应该接收到发送到该通道的任何`Message`。它提供了一个默认的无参数构造函数（提供了一个基本上是无界的`Integer.MAX_VALUE`的容量），以及一个接受队列容量的构造函数，如下面的清单所示： @@ -74,11 +74,11 @@ public QueueChannel(int capacity) 未达到容量限制的通道将消息存储在其内部队列中，并且`send(Message)`方法立即返回，即使没有接收者准备好处理该消息。如果队列已达到容量，发送方将阻塞该队列，直到该队列中有可用的空间为止。或者，如果使用具有附加超时参数的 send 方法，则队列将阻塞，直到可用的房间或超时周期（以先发生的为准）过去为止。类似地，如果队列上有消息可用，则`receive()`调用将立即返回，但是，如果队列是空的，则接收调用可能会阻塞，直到消息可用或超时（如果提供了超时）为止。在这两种情况下，都可以通过传递 0 的超时值来强制立即返回，而不管队列的状态如何。但是，请注意，这将无限期地调用`send()`和`receive()`参数块的版本。 -##### [](#channel-implementations-prioritychannel)`PriorityChannel` +##### `PriorityChannel` 虽然`QueueChannel`强制执行先进先出排序，但`PriorityChannel`是一种替代实现，它允许基于优先级在通道内对消息进行排序。默认情况下，优先级由每个消息中的`priority`头决定。但是，对于自定义优先级确定逻辑，可以向`Comparator>`构造函数提供类型`PriorityChannel`的比较器。 -##### [](#channel-implementations-rendezvouschannel)`RendezvousChannel` +##### `RendezvousChannel` `RendezvousChannel`启用了一个“直接切换”场景，其中，发送方会阻塞，直到另一方调用该通道的`receive()`方法。另一方屏蔽，直到发送方发送消息。在内部，这种实现与`QueueChannel`非常相似，只是它使用了`SynchronousQueue`（`BlockingQueue`的零容量实现）。这在发送方和接收方在不同线程中操作的情况下很好地工作，但是在队列中异步丢弃消息是不合适的。换句话说，对于`RendezvousChannel`，发送者知道某些接收者已经接受了该消息，而对于`QueueChannel`，该消息将被存储到内部队列中，并且可能永远不会被接收。 @@ -87,7 +87,7 @@ public QueueChannel(int capacity) `RendezvousChannel`对于实现请求-回复操作也很有用。发送方可以创建`RendezvousChannel`的临时匿名实例，然后在构建`Message`时将其设置为“replychannel”头。在发送`Message`之后，发送者可以立即调用`receive`（可选地提供超时值），以便在等待答复`Message`时阻塞。这与 Spring 集成的许多请求-应答组件内部使用的实现非常相似。 -##### [](#channel-implementations-directchannel)`DirectChannel` +##### `DirectChannel` `DirectChannel`具有点对点语义，但在其他方面比前面描述的任何基于队列的通道实现更类似于`PublishSubscribeChannel`。它实现了`SubscribableChannel`接口，而不是`PollableChannel`接口，因此它直接将消息分派给订阅服务器。然而，作为点对点信道，它与`PublishSubscribeChannel`的不同之处在于，它将每个`Message`发送到一个订阅的`MessageHandler`。 @@ -121,20 +121,20 @@ a`FixedSubscriberChannel`是一个`SubscribableChannel`只支持一个不能取 从版本 5.2 开始，当`failover`为真时，当前处理程序的失败以及失败的消息将分别记录在`debug`或`info`（如果已分别配置）下。 -##### [](#executor-channel)`ExecutorChannel` +##### `ExecutorChannel` `ExecutorChannel`是一个点对点通道，支持与`DirectChannel`相同的 Dispatcher 配置（负载平衡策略和`failover`布尔属性）。这两种调度通道类型之间的主要区别是，`ExecutorChannel`委托给`TaskExecutor`的一个实例来执行调度。这意味着发送方法通常不会阻塞，但也意味着处理程序调用可能不会发生在发送方的线程中。因此，它不支持跨越发送者和接收处理程序的事务。 | |例如，当使用带有抑制客户机的拒绝策略（例如`ThreadPoolExecutor.CallerRunsPolicy`）的`TaskExecutor`时，发送方有时会阻塞.，在线程池达到最大容量且执行者的工作队列已满的任何时候，发送者的线程都可以执行该方法。
由于这种情况只会以不可预测的方式发生，因此不应依赖它进行事务。| |---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -##### [](#flux-message-channel)`FluxMessageChannel` +##### `FluxMessageChannel` `FluxMessageChannel`是`org.reactivestreams.Publisher`实现的`org.reactivestreams.Publisher`，用于将消息发送到内部`reactor.core.publisher.Flux`，以供下游的响应订阅者按需消费。该通道实现既不是`SubscribableChannel`，也不是`PollableChannel`，因此只有`org.reactivestreams.Subscriber`实例可以用于从该通道消耗具有背压特性的反应流。另一方面，`FluxMessageChannel`实现了`ReactiveStreamsSubscribableChannel`及其`subscribeTo(Publisher>)`契约，允许接收来自反应源发布者的事件，将反应流连接到集成流。为了在整个集成流程中实现完全无反应的行为，必须在流程中的所有端点之间放置这样的通道。 有关与反应流的交互的更多信息，请参见[反应流支持](./reactive-streams.html#reactive-streams)。 -##### [](#channel-implementations-threadlocalchannel)作用域信道 +##### 作用域信道 Spring Integration1.0 提供了`ThreadLocalChannel`的实现，但自 2.0 起该实现已被移除。现在，处理相同需求的更一般的方法是将`scope`属性添加到通道中。属性的值可以是上下文中可用的作用域的名称。例如，在 Web 环境中，某些作用域是可用的，任何自定义作用域实现都可以在上下文中注册。下面的示例显示了应用于通道的线程本地作用域，包括作用域本身的注册： @@ -156,7 +156,7 @@ Spring Integration1.0 提供了`ThreadLocalChannel`的实现，但自 2.0 起该 现在，由于任何通道都可以被作用域定义，所以除了线程本地之外，你还可以定义自己的作用域。 -#### [](#channel-interceptors)信道拦截器 +#### 信道拦截器 消息传递体系结构的优势之一是能够提供公共行为，并以非侵入性的方式捕获有关通过系统的消息的有意义的信息。由于`Message`实例被发送到`MessageChannel`实例并从`MessageChannel`实例接收，这些通道提供了截获发送和接收操作的机会。下面的清单中显示了`ChannelInterceptor`策略接口，它为每个操作提供了方法： @@ -204,7 +204,7 @@ Spring 集成还提供了[Wire Tap](https://www.enterpriseintegrationpatterns.co | |从版本 5.2 开始， Spring 消息传递模块中的`ChannelInterceptorAware`被弃用，而支持`InterceptableChannel`，它现在对其进行了扩展，以实现向后兼容。| |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -#### [](#channel-template)`MessagingTemplate` +#### `MessagingTemplate` Spring 当引入端点及其各种配置选项时，集成为消息传递组件提供了一个基础，该组件允许从消息传递系统非侵入性地调用你的应用程序代码。但是，有时需要从应用程序代码中调用消息传递系统。 Spring 在实现这样的用例时，为了方便起见，集成提供了一个`MessagingTemplate`，它支持跨消息通道的各种操作，包括请求和应答场景。例如，可以发送请求并等待答复，如下所示： @@ -230,7 +230,7 @@ public Message receive(final PollableChannel channel) { ... | |在[Enter the`GatewayProxyFactoryBean`]（./gateway.html#gateway-proxy）中描述了一种侵入性较小的方法，它允许你调用带有有效负载或头值的简单接口，而不是`Message`实例。| |---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -#### [](#channel-configuration)配置消息通道 +#### 配置消息通道 要创建消息通道实例，可以使用``元素表示 XML，也可以使用`DirectChannel`实例表示 爪哇 配置，如下所示： @@ -270,7 +270,7 @@ XML 你可以替代地提供各种``子元素来创建任何可对应信道类型（如[消息通道实现](#channel-implementations)中所描述的）。下面的部分展示了每种通道类型的示例。 -##### [](#channel-configuration-directchannel)`DirectChannel`配置 +##### `DirectChannel`配置 如前所述，`DirectChannel`是默认类型。下面的清单显示了谁来定义一个： @@ -319,7 +319,7 @@ XML ``` -##### [](#channel-datatype-channel)数据类型通道配置 +##### 数据类型通道配置 有时，使用者只能处理特定类型的有效负载，这迫使你确保输入消息的有效负载类型。首先想到的可能是使用消息过滤器。然而，消息过滤器所能做的就是过滤掉不符合使用者需求的消息。另一种方法是使用基于内容的路由器，将具有不兼容数据类型的消息路由到特定的转换器，以强制转换和转换到所需的数据类型。这可能行得通，但要实现同样的事情，一种更简单的方法是应用[数据类型通道](https://www.enterpriseintegrationpatterns.com/DatatypeChannel.html)模式。对于每个特定的有效负载数据类型，可以使用单独的数据类型通道。 @@ -420,7 +420,7 @@ XML 或者，你可以声明一个 ID 为`datatypeChannelMessageConverter`的``类型的`MessageConverter`，并且该转换器被所有具有`datatype`的通道使用。 -##### [](#channel-configuration-queuechannel)`QueueChannel`配置 +##### `QueueChannel`配置 要创建`QueueChannel`，请使用``子元素。你可以按以下方式指定频道的容量： @@ -444,7 +444,7 @@ XML | |如果你没有为这个``子元素上的“capacity”属性提供一个值，则生成的队列是无界的。
为了避免内存耗尽等问题，我们强烈建议你为有界队列设置一个显式的值。| |---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -###### [](#persistent-queuechannel-configuration)持久`QueueChannel`配置 +###### 持久`QueueChannel`配置 由于`QueueChannel`提供了缓冲消息的功能，但在默认情况下仅在内存中进行缓冲，因此它还引入了一种可能性，即在系统故障的情况下，消息可能会丢失。为了减轻这种风险，`QueueChannel`策略接口的持久实现可以支持`MessageGroupStore`策略。有关`MessageGroupStore`和`MessageStore`的更多详细信息，请参见[消息存储](./message-store.html#message-store)。 @@ -536,7 +536,7 @@ public PollableChannel distributedQueue() { } ``` -##### [](#channel-configuration-pubsubchannel)`PublishSubscribeChannel`配置 +##### `PublishSubscribeChannel`配置 要创建`PublishSubscribeChannel`，请使用 \元素。当使用这个元素时，你还可以指定用于发布消息的`task-executor`（如果没有指定消息，它将在发送方的线程中发布），如下所示： @@ -585,7 +585,7 @@ XML 从版本 5.4.3 开始，`PublishSubscribeChannel`还可以配置其`requireSubscribers`选项的`requireSubscribers`，以指示此通道在没有订阅服务器时不会静默忽略消息。当没有订阅者时，将抛出带有`MessageDispatchingException`消息的`Dispatcher has no subscribers`消息，并将此选项设置为`true`。 -##### [](#channel-configuration-executorchannel)`ExecutorChannel` +##### `ExecutorChannel` 要创建`ExecutorChannel`，请添加带有`task-executor`属性的``子元素。该属性的值可以引用上下文中的任何`TaskExecutor`。例如，这样做可以配置线程池，用于将消息分配给订阅的处理程序。如前所述，这样做会破坏发送方和接收方之间的单线程执行上下文，从而处理程序的调用不会共享任何活动事务上下文（即，处理程序可能抛出`Exception`，但`send`调用已成功返回）。下面的示例展示了如何使用`dispatcher`元素并在`task-executor`属性中指定一个执行器： @@ -609,7 +609,7 @@ XML | |`load-balancer`和`failover`选项在 \子元素上也是可用的，如前面在[`DirectChannel`配置]（#channel-configuration-directchannel）中所述。
同样的默认值也适用，因此，
，通道具有循环负载平衡策略，启用了故障转移，除非为其中一个或两个属性提供了显式配置，如以下示例所示：

```



```| |---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -##### [](#channel-configuration-prioritychannel)`PriorityChannel`配置 +##### `PriorityChannel`配置 要创建`PriorityChannel`，请使用``子元素，如下例所示： @@ -654,7 +654,7 @@ XML 自版本 4.0 以来，`priority-channel`子元素支持`message-store`选项（在这种情况下不允许`comparator`和`capacity`）。消息存储必须是`PriorityCapableChannelMessageStore`。`PriorityCapableChannelMessageStore`的实现方式目前提供给`Redis`、`JDBC`和`MongoDB`。有关更多信息，请参见[`QueueChannel`Configuration]和[消息存储](./message-store.html#message-store)。你可以在[支持消息通道](./jdbc.html#jdbc-message-store-channels)中找到示例配置。 -##### [](#channel-configuration-rendezvouschannel)`RendezvousChannel`配置 +##### `RendezvousChannel`配置 当 queue 子元素是``时，将创建`RendezvousChannel`。它没有为前面描述的那些提供任何额外的配置选项，并且它的队列不接受任何容量值，因为它是一个零容量直接切换队列。下面的示例展示了如何声明`RendezvousChannel`: @@ -675,7 +675,7 @@ XML ``` -##### [](#channel-configuration-threadlocalchannel)作用域信道配置 +##### 作用域信道配置 任何通道都可以配置`scope`属性，如下例所示： @@ -683,7 +683,7 @@ XML ``` -##### [](#channel-configuration-interceptors)信道拦截器配置 +##### 信道拦截器配置 消息通道也可以具有拦截器，如[信道拦截器](#channel-interceptors)中所述。可以将``子元素添加到``（或更具体的元素类型）中。你可以提供`ref`属性来引用实现`ChannelInterceptor`接口的任何 Spring 托管对象，如下例所示： @@ -697,7 +697,7 @@ XML 通常，我们建议在单独的位置定义拦截器实现，因为它们通常提供可以跨多个通道重用的公共行为。 -##### [](#global-channel-configuration-interceptors)全局信道拦截器配置 +##### 全局信道拦截器配置 通道拦截器为每个通道应用横切行为提供了一种简洁的方法。如果应该在多个信道上应用相同的行为，那么为每个信道配置相同的拦截器集合将不是最有效的方法。 Spring 为了避免重复配置，同时也使拦截器能够应用于多个信道，集成提供了全局拦截器。考虑以下两个例子： @@ -733,7 +733,7 @@ Order 属性允许你在给定信道上有多个拦截器时管理此拦截器 | |注意，`order`和`pattern`属性都是可选的。
`order`的默认值将为 0，而`pattern`的默认值为’\*’（以匹配所有通道）。| |---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -##### [](#channel-wiretap)丝锥 +##### 丝锥 正如前面提到的， Spring 集成提供了一种简单的线分接拦截器。你可以在``元素内的任何通道上配置线控分接。这样做对于调试特别有用，并且可以与 Spring Integration 的日志通道适配器结合使用，如下所示： @@ -786,11 +786,11 @@ public IntegrationFlow loggingFlow() { } ``` -##### [](#conditional-wiretap)条件式电线分接 +##### 条件式电线分接 通过使用`selector`或`selector-expression`属性，可以使电线分接成为有条件的。`selector`引用了`MessageSelector` Bean，这可以在运行时确定消息是否应该转到 TAP 通道。类似地，`selector-expression`是一个执行相同目的的布尔 SPEL 表达式：如果表达式的计算结果为`true`，则消息将被发送到 TAP 通道。 -##### [](#channel-global-wiretap)全局线接接头配置 +##### 全局线接接头配置 作为[全局信道拦截器配置](#global-channel-configuration-interceptors)的特殊情况，可以配置全局线接。为此，配置一个顶级`wire-tap`元素。现在，除了正常的`wire-tap`名称空间支持外，`pattern`和`order`属性也得到了支持，并且它们的工作方式与`channel-interceptor`完全相同。下面的示例展示了如何配置全局线接： @@ -813,7 +813,7 @@ XML | |全局线接提供了一种方便的方式，可以在不修改现有通道配置的情况下，在外部配置单通道线接。
要这样做，请将`pattern`属性设置为目标通道名。
例如，你可以使用此技术来配置测试用例，以验证通道上的消息。| |---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -#### [](#channel-special-channels)特殊频道 +#### 特殊频道 默认情况下，在应用程序上下文中定义了两个特殊通道：`errorChannel`和`nullChannel`。“nullchannel”（`NullChannel`的实例）的作用类似于`/dev/null`，记录在`DEBUG`级别发送到它的任何消息并立即返回。对`org.reactivestreams.Publisher`发送的消息的有效负载应用了特殊处理：它在此信道中被立即订阅，以启动反应流处理，尽管数据被丢弃。从反应流处理中抛出的错误（参见`Subscriber.onError(Throwable)`）将记录在警告级别下，以进行可能的调查。如果需要对这样的错误做任何事情，则`[ReactiveRequestHandlerAdvice](./handler-advice.html#reactive-advice)`具有`Mono.doOnError()`自定义的消息处理程序可以应用于产生`Mono`的消息处理程序，对此`nullChannel`进行回复。当你遇到不关心的通道解析错误时，你可以将受影响组件的`output-channel`属性设置为“nullchannel”（名称“nullchannel”在应用程序上下文中保留）。 @@ -821,11 +821,11 @@ XML 有关消息通道和拦截器的更多信息，请参见 Java DSL 章节中的[消息通道](./dsl.html#java-dsl-channels)。 -### [](#polling-consumer)poller +### poller 本节描述了 Spring 集成中轮询的工作方式。 -#### [](#polling-consumer-2)轮询消费者 +#### 轮询消费者 当消息端点（通道适配器）连接到通道并进行实例化时，它们会产生以下实例之一： @@ -839,7 +839,7 @@ XML 在许多消息传递场景中，它们代表了一个关键的交叉问题。在 Spring 集成中，轮询消费者是基于具有相同名称的模式，这在 Gregor Hohpe 和 Bobby Woolf 的书*Enterprise 整合模式*中进行了描述。你可以在[Book 的网站](https://www.enterpriseintegrationpatterns.com/PollingConsumer.html)上找到模式的描述。 -#### [](#pollable-message-source)可选消息源 +#### 可选消息源 Spring 集成提供了轮询消费者模式的第二种变化。当使用入站通道适配器时，这些适配器通常用`SourcePollingChannelAdapter`包装。例如，当从远程 FTP 服务器位置检索消息时，[FTP 入站通道适配器](./ftp.html#ftp-inbound)中描述的适配器配置了一个 poller，以定期检索消息。因此，当组件配置为 Poller 时，生成的实例属于以下类型之一： @@ -860,7 +860,7 @@ Spring 集成提供了轮询消费者模式的第二种变化。当使用入站 本章仅对轮询消费者以及他们如何适应消息通道（参见[消息通道](./channel.html#channel)）和通道适配器（参见[通道适配器](./channel-adapter.html#channel-adapter)）的概念进行了高级概述。有关一般消息传递端点和特别是轮询消费者的更多信息，请参见[消息端点](./endpoint.html#endpoint)。 -#### [](#deferred-acks-message-source)延迟确认可收集消息源 +#### 延迟确认可收集消息源 从版本 5.0.1 开始，某些模块提供`MessageSource`实现，支持延迟确认，直到下游流完成（或将消息传递给另一个线程）。这目前仅限于`AmqpMessageSource`和`KafkaMessageSource`。 @@ -927,15 +927,15 @@ template.poll(h -> { 在这两种情况下（`SourcePollingChannelAdapter`和`MessageSourcePollingTemplate`），都可以通过在回调中调用`noAutoAck()`来禁用 auto ack/nack。如果你将消息传递给另一个线程并希望稍后确认，那么你可能会这样做。并不是所有的实现都支持这一点（例如，Apache Kafka 不支持这一点，因为偏移提交必须在同一个线程上执行）。 -#### 消息源的[](#conditional-pollers)条件 Pollers +#### 消息源的条件 Pollers 本节介绍如何使用条件 Pollers。 -##### [](#background)背景 +##### 背景 `Advice`对象，在 poller 上的`advice-chain`中，为整个轮询任务（消息检索和处理）提供建议。这些“周围建议”方法无法访问投票的任何上下文——只有投票本身。这对于需求很好，比如执行事务任务或由于某些外部条件而跳过轮询，正如前面讨论的那样。如果我们希望根据轮询的`receive`部分的结果采取某些操作，或者如果我们希望根据条件调整 Poller，该怎么办？在这些情况下， Spring 集成提供了“智能”轮询。 -##### [](#smart-polling)“智能”民调 +##### “智能”民调 5.3 版引入了`ReceiveMessageAdvice`接口。（在`MessageSourceMutator`中，`AbstractMessageSourceAdvice`已被弃用，而支持`default`方法。）在`advice-chain`中实现此接口的任何`Advice`对象仅应用于接收操作-`MessageSource.receive()`和`PollableChannel.receive(timeout)`。因此，它们只能应用于`SourcePollingChannelAdapter`或`PollingConsumer`。这样的类实现了以下方法： @@ -949,14 +949,14 @@ template.poll(h -> { | |建议链排序

你应该了解在初始化期间如何处理建议链，`Advice`不实现`ReceiveMessageAdvice`的对象将应用于整个轮询过程，并且所有这些对象都将首先被调用，在任何`ReceiveMessageAdvice`.
之前，`ReceiveMessageAdvice`对象是按照围绕源`receive()`方法的顺序被调用的。
如果你有，例如，`Advice`对象`a, b, c, d`，其中`b`和`d`是，则这些对象也按照以下顺序应用：`a, c, b, d`。如果源已经是`Proxy`，则在任何现有的`Advice`对象之后调用`ReceiveMessageAdvice`。
如果你希望更改顺序，则必须自己连接代理。| |---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -##### [](#simpleactiveidlereceivemessageadvice)`SimpleActiveIdleReceiveMessageAdvice` +##### `SimpleActiveIdleReceiveMessageAdvice` （以前的`SimpleActiveIdleMessageSourceAdvice`仅用于`MessageSource`已不推荐。）此建议是`ReceiveMessageAdvice`的一个简单实现。当与`DynamicPeriodicTrigger`结合使用时，它会调整轮询频率，这取决于上一次轮询是否导致了消息。Poller 还必须具有对相同`DynamicPeriodicTrigger`的引用。 | |重要提示：异步切换

`SimpleActiveIdleReceiveMessageAdvice`基于`receive()`结果修改触发器。
只有在 poller 线程上调用通知时，此操作才有效。
它不工作如果 poller 有`task-executor`.
来使用此建议，其中你希望在轮询结果之后使用异步操作，请稍后进行异步切换，也许可以使用`ExecutorChannel`。| |---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -##### [](#compoundtriggeradvice)`CompoundTriggerAdvice` +##### `CompoundTriggerAdvice` 此建议允许根据投票是否返回消息来选择两个触发器中的一个。考虑一个使用`CronTrigger`的 poller。`CronTrigger`实例是不可变的，因此一旦构造它们，就不能对它们进行更改。考虑一个用例，我们希望使用 CRON 表达式每小时触发一次轮询，但是如果没有收到消息，则每分钟轮询一次，并且在检索到消息时，恢复为使用 CRON 表达式。 @@ -995,15 +995,15 @@ Poller 还必须具有对相同`CompoundTrigger`的引用。 | |重要提示：异步切换

`CompoundTriggerAdvice`基于`receive()`结果修改触发器。
只有在 poller 线程上调用通知时，此操作才有效。
它不工作如果 poller 有`task-executor`。
使用此建议，其中你希望在轮询结果之后使用异步操作，请稍后进行异步切换，也许可以使用`ExecutorChannel`。| |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -##### [](#messagesource-only-advices)MessageSource-仅限建议 +##### MessageSource-仅限建议 有些建议可能只适用于`MessageSource.receive()`，而对于`PollableChannel`则没有意义。为此，仍然存在`MessageSourceMutator`接口（`ReceiveMessageAdvice`的扩展）。对于`default`方法，它完全替换了已经废弃的`AbstractMessageSourceAdvice`方法，并且应该在只期望`MessageSource`代理的实现中使用。有关更多信息，请参见[入站通道适配器：轮询多个服务器和目录](./ftp.html#ftp-rotating-server-advice)。 -### [](#channel-adapter)通道适配器 +### 通道适配器 通道适配器是一个消息端点，它允许将单个发送方或接收方连接到消息通道。 Spring 集成提供了许多适配器以支持各种传输，例如 JMS、文件、HTTP、Web 服务、邮件等。本参考指南的下几章将讨论每个适配器。然而，这一章的重点是简单但灵活的方法-调用通道适配器支持。这里既有入站适配器，也有出站适配器，每个适配器都可以配置为使用核心名称空间中提供的 XML 元素。这些提供了一种扩展 Spring 集成的简单方法，只要你有一个可以作为源或目标调用的方法。 -#### [](#channel-adapter-namespace-inbound)配置入站通道适配器 +#### 配置入站通道适配器 一个`inbound-channel-adapter`元素（在 Java 配置中是`SourcePollingChannelAdapter`）可以在 Spring 管理的对象上调用任何方法，并在将方法的输出转换为`Message`之后，将一个非空返回值发送到`MessageChannel`。当适配器的订阅被激活时，Poller 尝试从源接收消息。根据提供的配置，用`TaskScheduler`调度 Poller。要为单个通道适配器配置轮询间隔或 CRON 表达式，可以提供具有调度属性之一的“poller”元素，例如“fixed-rate”或“CRON”。下面的示例定义了两个`inbound-channel-adapter`实例： @@ -1075,7 +1075,7 @@ XML | |重要：poller 配置

所有`inbound-channel-adapter`类型都支持`SourcePollingChannelAdapter`，这意味着它们包含一个 poller 配置，该配置轮询`MessageSource`（以调用产生该值的自定义方法）这将成为基于 poller 中指定的配置的`Message`有效负载）。
下面的示例显示了两个 poller 的配置：


在第一个配置中，轮询任务每轮询一次被调用，并且在每个任务（轮询）期间，根据`max-messages-per-poll`属性值调用该方法（该方法将产生消息）一次，
在第二个配置中，轮询任务将在每个轮询中调用 10 次，或者直到它返回’null’为止，因此，在每次轮询以一秒的间隔进行时，每次轮询可能会产生 10 条消息。
但是，如果配置看起来像以下示例，会发生什么情况：

```

```
请注意，没有`max-messages-per-poll`指定。
，我们将在后面介绍，在`PollingConsumer`（例如，`service-activator`，`filter`，`router`，以及其他）中，相同的 poller 配置将对`-1`的`max-messages-per-poll`具有默认值，这意味着“不停地执行轮询任务，除非轮询方法返回 null（可能是因为`QueueChannel`中没有更多的消息）”，然后睡眠一秒。，

但是，在`SourcePollingChannelAdapter`中，有点不同。
`max-messages-per-poll`的默认值是`1`，除非你显式地将其设置为负值（例如`-1`）。
这可以确保 poller 可以对生命周期事件（例如开始和停止）做出反应，并防止它可能在无限循环中旋转如果`MessageSource`的自定义方法的实现可能永远不会返回 null，并且碰巧是不可中断的。

但是，如果你确信你的方法可以返回 null，并且你需要对每个轮询中可用的尽可能多的源进行轮询，你应该显式地将`max-messages-per-poll`设置为负值，如下例所示：

```

```
从版本 5.5 开始，
的`0`值具有特殊的含义-完全跳过`MessageSource.receive()`调用，这可能被认为是对此入站通道适配器的暂停，直到`maxMessagesPerPoll`在稍后的时间被更改为非零值，例如通过控制总线。

还请参见[全局默认 Poller](./endpoint.html#global-default-poller)以获取更多信息。| |---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -#### [](#channel-adapter-namespace-outbound)配置出站通道适配器 +#### 配置出站通道适配器 一个`outbound-channel-adapter`元素（用于 Java 配置的`@ServiceActivator`）也可以将`MessageChannel`连接到任何 POJO 使用者方法，该方法应该使用发送到该通道的消息的有效负载来调用。下面的示例展示了如何定义出站通道适配器： @@ -1158,7 +1158,7 @@ XML 可以在没有`channel`引用的情况下创建任何通道适配器，在这种情况下，它会隐式地创建`DirectChannel`的实例。创建的通道名称与``或``元素的`id`属性匹配。因此，如果不提供`channel`，则需要`id`。 -#### [](#channel-adapter-expressions-and-scripts)通道适配器表达式和脚本 +#### 通道适配器表达式和脚本 与许多其他 Spring 集成组件一样，``和``也提供了对 SPEL 表达式求值的支持。要使用 SPEL，在“expression”属性中提供表达式字符串，而不是提供用于 Bean 上的方法调用的“ref”和“method”属性。当计算一个表达式时，它遵循与方法调用相同的契约，其中：当计算结果为非空值时，``的表达式会生成消息，而``的表达式必须等同于无效返回方法调用。 @@ -1176,7 +1176,7 @@ XML | |``（`SourcePollingChannelAdapter`）是一个端点，它通过周期性地触发轮询某个底层`MessageSource`来启动消息流，
，因为在轮询时，没有消息对象，表达式和脚本无法访问根`Message`，因此，在大多数其他消息传递 SPEL 表达式中没有可用的有效负载或 headers 属性。
该脚本可以生成并返回一个完整的`Message`对象，该对象带有 headers 和 payload，或者只有一个 payload，它由框架添加到带有基本 headers 的消息中。| |---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -### [](#bridge)消息传递桥 +### 消息传递桥 消息传递桥是连接两个消息通道或通道适配器的相对简单的端点。例如，你可能希望将`PollableChannel`连接到`SubscribableChannel`，以便订阅端点不必担心任何轮询配置。相反，消息传递桥接会提供轮询配置。 @@ -1184,7 +1184,7 @@ XML 消息传递桥的另一个有效用途是连接两个不同的系统。在这样的场景中， Spring 集成的作用仅限于在这些系统之间建立连接，并在必要时管理 Poller。在两个系统之间至少要有一个转换器，以便在它们的格式之间进行转换，这可能是更常见的做法。在这种情况下，这些通道可以作为变压器端点的“输入通道”和“输出通道”提供。如果不需要数据格式转换，那么消息传递桥接可能就足够了。 -#### [](#bridge-namespace)使用 XML 配置桥 +#### 使用 XML 配置桥 可以使用``元素在两个消息通道或通道适配器之间创建消息传递桥梁。要做到这一点，请提供`input-channel`和`output-channel`属性，如下例所示： @@ -1215,7 +1215,7 @@ XML | |如果在桥上没有定义“输出通道”，则使用由入站消息提供的应答通道（如果可用）。
如果输出和应答通道都不可用，则抛出异常。| |---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -#### [](#bridge-annot)使用 Java 配置配置桥 +#### 使用 Java 配置配置桥 下面的示例展示了如何使用`@BridgeFrom`注释在 Java 中配置桥： @@ -1260,7 +1260,7 @@ public BridgeHandler bridge() { } ``` -#### [](#bridge-dsl)使用 Java DSL 配置桥 +#### 使用 Java DSL 配置桥 你可以使用 Java Domain Specific Language 来配置桥，如下例所示： diff --git a/docs/spring-integration/dsl.md b/docs/spring-integration/dsl.md index bcc5c3d..e9481b7 100644 --- a/docs/spring-integration/dsl.md +++ b/docs/spring-integration/dsl.md @@ -1,6 +1,6 @@ # Java DSL -## [](#java-dsl)Java DSL +## Java DSL Spring 集成 Java 配置和 DSL 提供了一组方便的构建器和 Fluent API，允许你配置 Spring 来自 Spring `@Configuration`类的集成消息流。 @@ -43,7 +43,7 @@ public class MyConfiguration { 前面的配置示例的结果是，它在`ApplicationContext`启动后创建 Spring 集成端点和消息通道。Java 配置既可以用来替换 XML 配置，也可以用来增强 XML 配置。你不需要替换所有现有的 XML 配置来使用 Java 配置。 -### [](#java-dsl-basics)DSL 基础知识 +### DSL 基础知识 `org.springframework.integration.dsl`包包含前面提到的`IntegrationFlowBuilder`API 和许多`IntegrationComponentSpec`实现，它们也是构建器，并提供 Fluent API 来配置具体的端点。`IntegrationFlowBuilder`基础架构为基于消息的应用程序（例如通道、端点、poller 和通道拦截器）提供了常见的[Enterprise 整合模式](https://www.enterpriseintegrationpatterns.com/)。 @@ -97,7 +97,7 @@ public IntegrationFlow myFlow() { | |Bean 定义重写

该 Java DSL 可以为在流定义中在线定义的对象注册 bean，并且可以重用现有的、注入的 bean。
在为在线对象定义的名称与现有的 Bean 定义相同的情况下，抛出一个`BeanDefinitionOverrideException`，表示这样的配置是错误的。
但是，当你处理`prototype`bean 时，没有办法从集成流处理器中检测到现有的 Bean 定义，因为每次我们从`BeanFactory`调用`prototype` Bean 时，都会得到一个新的实例。
这样，在`IntegrationFlow`中就会使用所提供的实例。正如没有任何 Bean 注册和任何可能的检查现有的`prototype` Bean 定义。
但是`BeanFactory.initializeBean()`是为这个对象调用的，如果它有一个显式的`id`并且 Bean 这个名称的定义在`prototype`范围内。| |---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -### [](#java-dsl-channels)消息通道 +### 消息通道 除了带有 EIP 方法的`IntegrationFlowBuilder`之外，Java DSL 还提供了一个 Fluent API 来配置`MessageChannel`实例。为此，提供了`MessageChannels`建设者工厂。下面的示例展示了如何使用它： @@ -180,7 +180,7 @@ Could not register object [queueChannel] under bean name 'queueChannel': 要使其工作，你需要为该通道声明`@Bean`，并从不同的`IntegrationFlow`实例中使用其 Bean 方法。 -### [](#java-dsl-pollers)调查者 +### 调查者 Spring 集成还提供了一个 Fluent API，它允许你为`PollerMetadata`实现配置`AbstractPollingEndpoint`。你可以使用`Pollers`Builder 工厂来配置公共 Bean 定义或从`IntegrationFlowBuilder`EIP 方法创建的定义，如下例所示： @@ -197,7 +197,7 @@ public PollerSpec poller() { | |如果使用 DSL 构造`PollerSpec`作为`@Bean`，请不要调用 Bean 定义中的`get()`方法。
`PollerSpec`是一个`FactoryBean`，它从规范中生成`PollerMetadata`对象并初始化其所有属性。| |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -### [](#java-dsl-reactive)the`reactive()`端点 +### `端点 从版本 5.5 开始，`ConsumerEndpointSpec`提供了一个`reactive()`配置属性，并带有一个可选的定制程序`Function>, ? extends Publisher>>`。此选项将目标端点配置为`ReactiveStreamsConsumer`实例，独立于输入通道类型，该类型通过`IntegrationReactiveUtils.messageChannelToFlux()`转换为`Flux`。所提供的函数是使用来自`Flux.transform()`的操作符来自定义（`publishOn()`、`log()`、`doOnNext()`等）来自输入通道的反应流的源。 @@ -216,7 +216,7 @@ public IntegrationFlow reactiveEndpointFlow() { 有关更多信息，请参见[反应流支持](./reactive-streams.html#reactive-streams)。 -### [](#java-dsl-endpoints)DSL 和端点配置 +### DSL 和端点配置 所有`IntegrationFlowBuilder`EIP 方法都有一个变体，该变体应用 lambda 参数为`AbstractEndpoint`实例提供选项：`SmartLifecycle`、`PollerMetadata`、`request-handler-advice-chain`和其他实例。每个参数都有通用参数，因此它允许你在上下文中配置一个端点，甚至它的`MessageHandler`，如下例所示： @@ -254,7 +254,7 @@ public IntegrationFlow clientTcpFlow() { 即它们不是合并的，在这种情况下只使用`testAdvice()` Bean。 -### [](#java-dsl-transformers)变形金刚 +### 变形金刚 DSL API 提供了一个方便的、fluent`Transformers`工厂，可用作`.transform()`EIP 方法中的内联目标对象定义。下面的示例展示了如何使用它： @@ -274,7 +274,7 @@ public IntegrationFlow transformFlow() { 另请参见[lambdas 和`Message`参数]。 -### [](#java-dsl-inbound-adapters)入站通道适配器 +### 入站通道适配器 通常，消息流从入站通道适配器开始（例如``）。适配器配置为``，并要求`MessageSource`定期生成消息。Java DSL 也允许从`MessageSource`开始`IntegrationFlow`。为此，`IntegrationFlows`Builder 工厂提供了一个重载的`IntegrationFlows.from(MessageSource messageSource)`方法。你可以将`MessageSource`配置为 Bean，并将其作为该方法的参数。`IntegrationFlows.from()`的第二个参数是一个`Consumer`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 5821371..9281c0d 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 d508372..c18b467 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 0c2ab73..cc77271 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 19f0528..8ec04ef 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 9a6cb28..fa753d1 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 44508c0..229767b 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 0930ea7..d53d6e0 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 b773409..5039453 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>)`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)现在支持`