|
该版本仍在开发中,尚未被视为稳定。对于最新的稳定版本,请使用 Spring Integration 7.0.0! |
注释支持
除了支持XML命名空间配置消息端点外,你还可以使用注释。
首先,Spring 集成提供了类级@MessageEndpoint作为一种刻板印象注释,意味着它本身也用斯普林的注释@Component注释,因此在Spring的组件扫描中自动被识别为豆子定义。
更重要的是各种方法级注释。 它们表明注释方法能够处理消息。 以下示例展示了类级和方法级注释:
@MessageEndpoint
public class FooService {
@ServiceActivator
public void processMessage(Message message) {
...
}
}
该方法“处理”消息的具体含义取决于具体的注释。 Spring 集成中可用的注释包括:
-
@Aggregator(参见聚合器) -
@Filter(参见过滤器) -
@Router(参见路由器) -
@ServiceActivator(参见服务激活器) -
@Splitter(参见Splitter) -
@Transformer(参见变形金刚) -
@InboundChannelAdapter(参见通道适配器) -
@BridgeFrom(参见用 Java 配置配置桥接器) -
@BridgeTo(参见用 Java 配置配置桥接器) -
@MessagingGateway(参见消息网关) -
@IntegrationComponentScan(参见配置和@EnableIntegration)
如果你结合使用XML配置和注释,那@MessageEndpoint不需要注释。
如果你想从裁判a的属性<服务激活器/>元素,你只能提供方法级注释。
在这种情况下,即使没有方法级属性,注释也能防止歧义<服务激活器/>元素。 |
在大多数情况下,带注释的处理程序方法不应要求消息类型作为其参数。
相反,方法参数类型可以匹配消息的有效载荷类型,如下示例所示:
public class ThingService {
@ServiceActivator
public void bar(Thing thing) {
...
}
}
当方法参数应从消息头另一种选择是使用参数级@Header注解。
一般来说,带有 Spring Integration 注释的方法可以接受消息本身、消息有效载荷,或一个头部值(其中@Header)作为参数。
事实上,该方法可以接受组合,如下示例所示:
public class ThingService {
@ServiceActivator
public void otherThing(String payload, @Header("x") int valueX, @Header("y") int valueY) {
...
}
}
你也可以使用@Headers注释以提供所有消息头部作为地图,如下示例所示:
public class ThingService {
@ServiceActivator
public void otherThing(String payload, @Headers Map<String, Object> headerMap) {
...
}
}
注释的值也可以是 SpEL 表达式(例如,someHeader.toUpperCase()),当你希望在注入前作头部值时非常有用。
它还提供一个可选的必填属性,指定属性值是否必须在头部中可用。
该项的默认值必填财产是true. |
对于其中若干注释,当消息处理方法返回非空值时,端点尝试发送回复。
这在两个配置选项(命名空间和注释)中都是一致的,因为如果有的话,会使用该端点的输出通道,并且REPLY_CHANNEL消息头值作为备用。
| 端点上的输出通道与回复通道消息头的组合使得流水线方法成为可能,即多个组件拥有一个输出通道,最终组件允许返回消息转发到回复通道(如原始请求消息中指定)。 换句话说,最终组件依赖于原始发送方提供的信息,因此可以动态支持任意数量的客户端。 这是退货地址模式的一个例子。 |
除了这里展示的例子外,这些注释还支持输入通道和输出通道以下示例展示了性质:
@Service
public class ThingService {
@ServiceActivator(inputChannel="input", outputChannel="output")
public void otherThing(String payload, @Headers Map<String, Object> headerMap) {
...
}
}
这些注释的处理会生成与相应XML组件相同的豆子——摘要终点实例和消息处理器实例(或消息源为入站通道适配器实例)。
看注释@Bean方法.
豆子名称由以下模式生成:[组件名称]。[方法名称]。[去大写AnnotationClassShortName].
在前面的例子中,豆子的名字是thingService.otherThing.serviceActivator对于摘要终点以及同名加上一个额外的。处理器 (。源) 后缀消息处理器 (消息源) 豆子。
这样的名称可以通过以下方式进行定制@EndpointId注释与这些消息注释并行。
这消息处理器实例(消息源实例)也可以通过消息历史记录被追踪。
从4.0版本开始,所有消息注释都提供SmartLifecycle选项(自动启动和阶段)以便允许对应用上下文初始化进行端点生命周期控制。
他们默认是true和0分别。
改变端点的状态(例如:开始()或停止()),你可以通过使用豆子工厂(或自接线)并调用这些方法。
或者,你也可以向控制总线(参见控制总线)
为此,你应该使用豆名前面提到的。
|
在解析上述注释后自动创建的通道(当未配置特定通道豆)及其对应的消费者端点,在上下文初始化接近尾声时被声明为豆子。
这些豆子可以在其他服务中自动接线,但必须标注
|
从6.0版本开始,所有消息注释都是@Repeatable现在,可以在同一服务方法上声明多个相同类型的节点,目的是创建与重复这些注释数量相同的端点:
@Transformer(inputChannel = "inputChannel1", outputChannel = "outputChannel1")
@Transformer(inputChannel = "inputChannel2", outputChannel = "outputChannel2")
public String transform(String input) {
return input.toUpperCase();
}
使用@Poller注解
在 Spring 集成 4.0 之前,消息注释要求输入通道可以引用订阅频道.
为Pollable频道实例,一个<in:bridge/>配置 元素<in:poller/>使复合端点为民调消费者.
4.0 版本引入了@Poller注释以允许配置轮询者属性直接出现在消息注释上,如下示例所示:
public class AnnotationService {
@Transformer(inputChannel = "input", outputChannel = "output",
poller = @Poller(maxMessagesPerPoll = "${poller.maxMessagesPerPoll}", fixedDelay = "${poller.fixedDelay}"))
public String handle(String payload) {
...
}
}
这@Poller注释仅提供简单Poller元数据选项。
你可以配置@Poller注释的属性(maxMessagesPerPoll,fixedDelay,固定利率和克朗)带有属性占位符。
此外,从5.1版本开始,收到超时选项为民调消费者也提供了S。
如果需要提供更多轮询选项(例如,交易,咨询链,错误处理以及其他),你应该配置Poller元数据作为一种通用豆,并使用其豆名作为@Poller的值属性。
在这种情况下,不允许其他属性(它们必须在Poller元数据豆)。
注意,如果输入通道是Pollable频道不@Poller是配置好的,是默认的Poller元数据如果在应用上下文中存在,则被使用。
通过使用@Configuration注释,使用类似以下示例的代码:
@Bean(name = PollerMetadata.DEFAULT_POLLER)
public PollerMetadata defaultPoller() {
PollerMetadata pollerMetadata = new PollerMetadata();
pollerMetadata.setTrigger(new PeriodicTrigger(10));
return pollerMetadata;
}
以下示例展示了如何使用默认轮询器:
public class AnnotationService {
@Transformer(inputChannel = "aPollableChannel", outputChannel = "output")
public String handle(String payload) {
...
}
}
以下示例展示了如何使用命名轮询器:
@Bean
public PollerMetadata myPoller() {
PollerMetadata pollerMetadata = new PollerMetadata();
pollerMetadata.setTrigger(new PeriodicTrigger(1000));
return pollerMetadata;
}
以下示例展示了使用默认轮询器的端点:
public class AnnotationService {
@Transformer(inputChannel = "aPollableChannel", outputChannel = "output"
poller = @Poller("myPoller"))
public String handle(String payload) {
...
}
}
从4.3.3版本开始,@Poller注释具有errorChannel属性以便更易配置底层消息发布错误处理.
该属性起到相同的作用错误信道在<poller>XML组件。
更多信息请参见端点命名空间支持。
这poller()消息注释上的属性与响应式()属性。
更多信息请见下一节。
用@Reactive注解
这ReactiveStreamsConsumer自5.0版本以来就已存在,但仅在端点的输入通道为流信息频道(或者任何org.reactivestreams.出版商实现)。
从5.3版本开始,当目标消息处理程序是响应式消息处理器与输入通道类型无关。
这@Reactive子注释(类似上述)@Poller)自5.5版本起,已为所有消息注释引入。
它接受可选的功能<?超级Flux<Message<?>>,?扩展出版商<信息<?>>>BEAN 引用,且独立于输入通道类型和消息处理程序,将目标端点转换为ReactiveStreamsConsumer实例。
该函数来自Flux.transform()运算符以应用一些自定义(publishOn(),doOnNext(),log(),重试()等等)在输入通道的无功流源上。
以下示例演示了如何独立于最终订阅者和生产者将发布线程从输入通道切换到直达频道:
@Bean
public Function<Flux<?>, Flux<?>> publishOnCustomizer() {
return flux -> flux.publishOn(Schedulers.parallel());
}
@ServiceActivator(inputChannel = "directChannel", reactive = @Reactive("publishOnCustomizer"))
public void handleReactive(String payload) {
...
}
这响应式()消息注释上的属性与poller()属性。
看使用@Poller注解以及反应式流支持以获取更多信息。
使用@InboundChannelAdapter注解
4.0 版本引入了@InboundChannelAdapter方法级注释。
它产生SourcePollingChannelAdapter基于MethodInvokingMessageSource对于注释法。
该注释是<int:入站通道适配器>XML 组件和具有相同的限制:方法不能有参数,返回类型也不能是无效.
它有两个特点:值(要求消息频道豆名)和轮询者(可选@Poller注释,如前所述)。
如果你需要提供一些消息头,使用留言<?>返回类型并使用消息构建器以建造留言<?>.
使用消息构建器你可以配置消息头.
以下示例展示了如何使用@InboundChannelAdapter注解:
@InboundChannelAdapter("counterChannel")
public Integer count() {
return this.counter.incrementAndGet();
}
@InboundChannelAdapter(value = "fooChannel", poller = @Poller(fixed-rate = "5000"))
public String foo() {
return "foo";
}
4.3 版本引入了渠道别名值注释属性,以提供更好的源代码可读性。
还有,目标消息频道豆子在SourcePollingChannelAdapter由所提供名称(由输出频道名称选项)在第一页接收()呼叫,而不是在初始化阶段。
它允许“晚绑定”逻辑:目标消息频道从消费者角度看,BEAN 的创建和注册时间稍晚于@InboundChannelAdapter解析阶段。
第一个例子要求默认轮询器在应用上下文的其他地方被声明。
使用@MessagingGateway注解
使用@IntegrationComponentScan注解
标准的Spring框架@ComponentScan注释不会扫描接口以识别刻板印象@Component附注。
为了克服这一限制,允许@MessagingGateway(参见@MessagingGateway注解),我们引入了@IntegrationComponentScan机制。
该注释必须加上@Configuration注释并可定制以定义其扫描选项,
如basePackages和basePackageClasses.
在这种情况下,所有发现的接口都标注为@MessagingGateway被解析并注册为GatewayProxyFactoryBean实例。
所有其他基于类的组件都由标准解析@ComponentScan.