我想配置一个类似于：
的流程Method Call -> Dynamic Proxy Gateway -> Channel -> Service Activator -> Method Call
^---------- Transformer <- Channel <- [return value]
实际上，我想以某种方式访问隐藏的通道Spring Integration创建并将返回消息有效负载转换为不同的消息类型。
一个简单的解决方案可能首先似乎是在网关上配置默认回复通道，问题是我在使用OSGi在bundle之间共享通道。 Service Activator由Bundle“B”提供，为传入请求提供共享通道（它充当数据提供者服务）。捆绑“A”需要一些数据，因此它会请求它，但需要以替代格式生成结果。请注意，如果Bundle“B”能够使用Bundle“A”指定的default-reply-channel，则Bundle“A”必须共享它。这一切都很公平，但后来我在OSGi中有一个循环依赖，什么都不会开始。
这里的另一个解决方案似乎是在Service Activator上定义一个输出通道，但这会遇到一个稍微不同的问题。假设我从Bundle“B”共享输出通道，我已经减轻了循环依赖性问题，但是现在每当有人从Bundle“A”请求某些东西时，回复都会发送给连接到输出通道的每个人 - 这也是不可取的
[编辑：我的意思是，如果“B”共享其服务激活器的输入和输出通道，则任何绑定到“B”输出通道的人都将收到结果任何人对“B”的输入频道的请求 - 并且所希望的行为是答复是针对请求者的。
我应该注意，这里的变换器仅在Bundle A的上下文中才有意义.Bundle B提供了一种服务（对于所有意图和目的，我无法控制）。特定于Bundle A需求的转换应该存在于Bundle A中。]
所以，我认为我真正需要的是能够在对动态代理网关的回复中配置转换器，但尝试我可能在Spring Integration手册中找不到这样的设备。一如既往，非常感谢帮助。
-
编辑2 ：我在这里尝试了另外两种策略：
使用引用Bundle B的OSGi共享通道的服务激活器
结果是返回的元素是GenericMessageType - 它可以转换。 GenericMessageType实际上是服务激活器必须指向的“发送”方法的布尔结果，而不是回复消息。所以这个方法不工作。
使用标题扩充器设置REPLY_CHANNEL并将回复频道作为参考而不是值传递。
此技术不工作，当设置网关的默认回复通道时，REPLY_CHANNEL标头元素似乎被忽略（并且default-reply-channel 必须被设定）。
答案 0 :(得分：1)
理论上，这里的真正答案是使用链条。
Bundle A的配置类似于
<si:gateway id="gw" default-request-channel="xyz" />
<si:channel id="xyz" />
<si:chain input-channel="xyz" />
<si:service-activator />
<si:transformer />
</si:chain>
对于Bundle B的注意事项，配置保持不变，只有一个通道可以通过OSGi共享，以便Bundle A或任何三级捆绑包访问。
服务激活器有两个选项：
Bundle A中的代理网关将注入一些输入通道“xyz”，最终隐含的返回通道将根据需要包含转换后的内容。
此解决方案与SingleShot提出的解决方案几乎相同，但是在这里我们阻止通过OSGi共享实际服务，维护捆绑边界。
答案 1 :(得分：0)
我对你的问题描述感到有点困惑。我理解循环依赖方面和变换器方面，但我不太确定“答复是附在A上的所有人”。
听起来你可能想要为B提供两个服务激活器。你现有的B服务激活器会留下来，大多数客户都会使用它。另一个将进入A，并且只使用A中定义的通道。这将阻止A到B的请求导致A之外的组件接收到响应。
这应该可以使转换问题更容易。变形金刚从一个频道接收消息，对其进行转换，然后将其放在另一个频道上。只需在A中添加一个就可以了。
所以在A中你会有这些组件，只能用于A：
在B中你可以使用，任何人都可以使用：
A取决于B，但B不依赖于A.
这会起作用吗？