抢先一步
VMware 提供培训和认证,以加速您的进步。
了解更多尊敬的 Spring 社区:
我们很高兴地宣布 Spring Integration 4.1 Release Candidate 已发布。 请使用 Milestone Repository 与 Maven 或 Gradle,或下载 distribution archive,进行试用。
此版本包含许多新功能和改进,以及一些错误修复。 GA 版本计划于 11 月初发布。
首先,感谢所有为 4.1 Milestone 1 提供反馈并提交报告(错误或新功能)的人员。 特别感谢那些通过 Pull Requests 提供贡献的人。 以下是自里程碑版本以来的主要更改摘要
Web Sockets 支持
此功能在 4.1 Milestone 1 中引入,但已解决了一些问题,并且我们现在提供了一些示例,以更好地了解如何在 Spring Integration 应用程序中使用 Web Sockets:Basic 和 STOMP Chat。
JDK8 Optional<?> 一致处理
如果您正在使用 Java 8,您将能够使用 Optional<?>
容器作为服务方法参数。 例如
public void optionals(@Payload("@myConvert.conv(payload)") Optional<Bar> payload,
@Header(value="foo") Optional<String> header)
在这种情况下,如果 @myConvert.conv(payload)
返回 null
,则 payload
变量将包含一个 Optional.empty()
。 对于 header
变量也是如此 - 如果请求 Message<?>
中没有 foo
标头。 这可以用作 @Header
注释中 required
属性的替代方法。
Routing Slip 模式
现在支持 Routing Slip 模式。 我们引入了 RoutingSlipRouteStrategy
,它提供基于请求 Message<?>
和 reply object
的动态运行时路由,而不是简单的 static list of channel names
。 也支持 SpEL
<header-enricher input-channel="input" output-channel="process">
<routing-slip value="channel1; request.headers[myRoutingSlipChannel];
routingSlipRoutingStrategy;"/>
</header-enricher>
当配置多个路由器来确定消息流变得困难时,此模式在复杂的动态情况下非常有用。 通过此增强功能,当消息到达没有 output-channel
的端点时,将查询路由滑块以确定消息将发送到的下一个通道。 当路由滑块耗尽时,正常的 replyChannel
处理将恢复。
Idempotent Receiver 模式
在此版本中,我们已将 Idempotent Receiver 实现为一流的功能。 以前,用户必须通过在 <filter/>
中使用自定义 MessageSelector
来实现此模式。 该框架现在支持此功能作为 Advice
组件,该组件可以应用于任何消耗端点
<idempotent-receiver endpoint="endpoint1, foo*"
metadata-store="store"
discard-channel="duplicates"
key-expression="payload.invoiceNumber"/>
这将创建一个 AOP IdempotentReceiverInterceptor
,该拦截器应用于 MessageHandler#handleMessage
在其中 id
与提供的 endpoint
模式之一匹配的端点内。
如果省略了 discard-channel
,则重复的消息仍然发送到消息处理程序,但它将包含一个 duplicateMessage
标头,允许用户代码采取进一步的操作。
对于 JavaConfig,提供了 @IdempotentReceiver
注释,但是也必须配置 IdempotentReceiverInterceptor
@Bean
@Bean
public IdempotentReceiverInterceptor idempotentReceiverInterceptor() {
return new IdempotentReceiverInterceptor(new MetadataStoreSelector(m ->
m.getPayload().toString()));
}
@Bean
@ServiceActivator(inputChannel = "input", outputChannel = "output")
@IdempotentReceiver("idempotentReceiverInterceptor")
public MessageHandler myService() {
....
}
有关更多信息,请阅读 IdempotentReceiverInterceptor
JavaDocs。
Scatter-Gather 模式
现在提供了 Scatter-Gather 企业集成模式
<!--Auction scenario-->
<scatter-gather input-channel="inputAuction" output-channel="output"
scatter-channel="auctionChannel">
<gatherer release-strategy-expression="^[payload gt 5] != null or size() == 3"/>
</scatter-gather>
<!--Distribution scenario-->
<scatter-gather input-channel="inputDistribution" output-channel="output"
gather-channel="gatherChannel">
<scatterer apply-sequence="true">
<recipient channel="distribution1Channel"/>
<recipient channel="distribution2Channel"/>
<recipient channel="distribution3Channel"/>
</scatterer>
<gatherer release-strategy-expression="^[payload gt 5] != null or size() == 3"/>
</scatter-gather>
它是一个复合端点,它结合了 publish-subscribe
逻辑和 aggregation
函数。 当然,它以前可以使用现有的 publish-subscribe-channel
或 recipient-list-router
以及 aggregator
组件实现为集成流,但是此新功能为诸如 best quote
之类的场景提供了更清晰的实现。
Redis 队列网关
基于 Redis List
的一对 request-reply
(入站和出站)网关组件已添加到 Redis
模块中
<int-redis:queue-outbound-gateway request-channel="sendChannel" queue="foo"/>
<int-redis:queue-inbound-gateway request-channel="requestChannel" queue="foo"/>
Reactor 的 PersistentQueue
已更改 QueueChannel
以允许注入任何 Queue<?>
实现。 这样做是为了允许在 [Reactor](http://reactor.github.io/reactor/)项目中使用 Chronicle-Queue 实现
@Bean QueueChannel queueChannel() {
return new QueueChannel(new PersistentQueueSpec<Message<?>>()
.codec(new JavaSerializationCodec<>())
.basePath("/usr/queuePath")
.get());
}
跳过轮询
使用轮询端点时,有时需要“跳过”轮询,可能是因为某些下游条件可能导致失败,或者说,任务执行程序池没有可用的线程。 此版本添加了 PollSkipAdvice
,可以将其插入轮询器的 advice 链中,跳过逻辑基于用户提供的代码。
注意
结论
有关此版本的更多信息,请参见发行说明,有关更多信息,请参见项目页面。有关4.1版本中“新增功能”的完整列表,请参见参考文档。从早期版本升级的用户应查阅各种迁移指南。
与往常一样,我们非常欢迎贡献。