我想配置一个看起来像这样的过程:
Method Call -> Dynamic Proxy Gateway -> Channel -> Service Activator -> Method Call
^---------- Transformer <- Channel <- [return value]
实际上,我想以某种方式访问 Spring Integration 创建的隐藏通道,并将返回的消息有效负载转换为不同的消息类型。
一个简单的解决方案可能起初似乎是在网关上配置默认回复通道,问题是我正在使用 OSGi 在捆绑包之间共享通道。Service Activator 由捆绑“B”提供,并为传入请求提供共享通道(它充当数据提供者服务)。捆绑“A”需要一些数据,因此它需要它,但需要另一种格式的结果。请注意,如果 Bundle “B” 能够使用 Bundle “A” 指定的默认回复通道,则 Bundle “A” 必须共享它。这一切都很好,但是我在 OSGi 中有一个循环依赖,什么都不会开始。
似乎这里的另一种解决方案是在服务激活器上定义一个输出通道,但这会遇到一个稍微不同的问题。假设我从 Bundle “B” 共享输出通道,我已经缓解了循环依赖问题,但现在任何时候有人从 Bundle “A” 请求某些东西,回复都会发送给连接到输出通道的每个人——这也是不可取的.
[编辑:我的意思是,如果“B”为其服务激活器共享输入和输出通道,那么绑定到“B”输出通道的任何人都将收到任何人对“B”输入的请求的结果通道——并且期望的行为是回复是针对请求者的。
我应该注意,这里的转换器仅在 Bundle A 的上下文中才有意义。Bundle B 提供了一项服务(对于所有意图和目的,我无法控制)。特定于 Bundle A 需求的转换应驻留在 Bundle A 中。]
所以,我认为我真正需要的是能够在回复动态代理网关时配置转换器,但尽我所能在 Spring Integration 手册中找不到这样的设备。与往常一样,我们将不胜感激。
--
编辑2:我在这里尝试了另外两种策略:
使用引用 Bundle B 中的 OSGi 共享通道的服务激活器
结果是返回的元素是一个 GenericMessageType——它可以被转换。GenericMessageType 实际上是服务激活器必须指向的“发送”方法的布尔结果,而不是回复消息。所以这个方法行不通。
使用 header-enricher 设置REPLY_CHANNEL并将回复通道作为参考而不是值传递。
这种技术不起作用,当设置了网关的默认回复通道(并且必须设置默认回复通道)时,REPLY_CHANNEL 标头元素似乎被忽略了。