Spring集成代理网关上的入站变压器

我想配置一个看起来像:

Method Call -> Dynamic Proxy Gateway -> Channel -> Service Activator -> Method Call
             ^---------- Transformer <- Channel <-             [return value]

实际上,我想以某种方式访问隐藏的通道Spring集成创建并将返回消息有效负载转换为不同的消息类型。

一个简单的解决方案可能首先是在网关上配置一个默认的回复通道,问题是我使用OSGi在包之间共享这个通道。服务激活器由bundle“b”提供,并为传入请求提供共享通道(它充当数据提供程序服务)。捆绑“a”需要一些数据,因此它请求它,但需要一个备用格式的结果。注意,如果bundle“b”能够使用bundle“a”指定的默认回复通道,那么bundle“a”必须共享它。这是公平的,很好,但是我在OSGi中有一个循环依赖,什么都不会开始。

这里的另一个解决方案似乎是在服务激活器上定义一个输出通道,但这有一个稍微不同的问题。假设我共享bundle“b”的输出通道,我已经减轻了循环依赖性问题,但是现在每当有人请求bundle“a”的某些内容时,回复就会转到连接到输出通道的每个人身上——这也是不可取的。

[ 编辑 :这里我的意思是,如果“b”为其服务激活器共享一个输入和一个输出通道,那么任何绑定到“b”的输出通道的人都将收到任何人对“b”的输入通道的请求的结果——并且所需的行为是,答复是针对请求者的。

我需要注意的是,这里的变压器只在包A的上下文中才有意义。包B提供服务(对于所有的意图和目的,我都无法控制)。针对A包需求的转换应位于A包中。]

所以,我认为我真正需要的是能够在对动态代理网关的响应上配置一个转换器,但是尽我所能在Spring集成手册中找不到这样的设备。一如既往,我们将非常感谢您的帮助。

——

编辑2 :我在这里尝试了另外两种策略:

1. 使用引用bundle b中的OSGi共享通道的服务激活器

   结果是返回的元素是一个GenericMessageType——它可以进行转换。GenericMessageType实际上是服务激活器必须指向的“send”方法的布尔结果,而不是回复消息。所以这个方法可以 不 工作。

2. 使用标题丰富器设置 REPLY_CHANNEL 并将应答通道作为引用而不是值传递。

   这项技术确实 不 工作时,设置网关的默认答复通道(和默认答复通道)时,似乎忽略了reply_channel header元素 必须 被设置)。