我是用下面的IntegrationFlow形式,在那里我被一个标头值借助过滤我的话题邮件工作:路由在Spring集成DSL
IntegrationFlows.from (
Jms.messageDrivenChannelAdapter ( Jms.container(factory, connection)
.messageSelector("X-HEADER = 'X_VALUE'")
.get()
)
.get()
)
.handle(XMessageHandler)
.get();
..或任何
IntegrationFlows.from (
Jms.messageDrivenChannelAdapter ( Jms.container(factory, connection)
.get()
)
.get()
)
.filter(Message.class, filterByHeaderPropertySelector(X_HEADER, X_VALUE)
.handle(XMessageHandler)
.get();
但现在,一种新型的流量预计的加入了话题,所以鉴别头有一个新值Y.因此,一个新的过滤器filter(Message.class, filterByHeaderPropertySelector(Y_HEADER, Y_VALUE)
与目标YMessageHandler
。
我的问题是我怎么能重复使用的影响降到最低的基础设施。这将是使用路由过滤器的理想选择,但route
操作似乎没有以相同方式内联。也许有一种更简单/明显的方式?
另外,我要重复的每个消息选择的适配器?将消息选择器放在容器设置中或作为集成流程的一部分进行操作之间有何区别。有没有性能问题,或者集成构建器是否巧妙地优化了它?我的意思是,将选择器放在流中并不会避免解析消息等,而在容器的定义上它只是从一开始就对其进行过滤。解决这个问题的最佳方法是什么?
由于这就是我需要的信息! – Whimusical
等等,事情是我需要在我的客户端上处理所有类型的消息。所以,只要路由它们,我不介意收到所有消息。在那种情况下,使用容器方法有什么好处吗?我想我应该去路由器。无论如何,直接与路由器上的处理程序一起工作,而不是创建渠道? – Whimusical
你需要容器以任何方式从代理获取消息。但是如果你不关心他们的类型,你不应该在那里使用选择器。性能会更好。所有其余的逻辑应该在路由器和所有下游分支流程中实施 –