我是用下面的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
你需要容器以任何方式從代理獲取消息。但是如果你不關心他們的類型,你不應該在那裏使用選擇器。性能會更好。所有其餘的邏輯應該在路由器和所有下游分支流程中實施 –