Camel in OSGi Container: Apply InterceptStrategy to all camel contexts(OSGi 容器中的骆驼:将拦截策略应用于所有骆驼上下文)
问题描述
我有几个包(A、B 和 C)部署到一个 OSGi 容器,每个包都包含一个 CamelContext
和一些路由.我有另一个带有 CamelContext
的包(M),带有一个路由(用于收集监控数据)和一个 InterceptStrategy
bean.我希望 M 中的 InterceptStrategy
bean 自动应用于容器中的所有其他 CamelContext
(即 A、B 和 C 中的那些),而无需修改其他捆绑包.
I have several bundles (A, B, and C) deployed to an OSGi container, each containing a CamelContext
and some routes. I have another bundle (M) with a CamelContext
with a route (for collecting monitoring data) and a InterceptStrategy
bean. I would like the InterceptStrategy
bean from M to automatically apply to all of the other CamelContext
s in the container (i.e., those in A, B, and C), without having to modify the other bundles.
最终,目标是将每个 CamelContext
中的数据窃听到 M 中的路由中,而无需对 A、B 或 C 进行任何更改以显式路由 Exchange代码>.这种方法或类似方法是否可行?
Ultimately, the goal is to wiretap data from each CamelContext
into the route in M, without having to make any changes to A, B, or C to explicitly route the Exchange
. Is this approach or a similar approach doable?
所有的 CamelContext
都是使用 Spring XML 配置的.
All of the CamelContext
s are configured using Spring XML.
更新:附加上下文
捆绑包 A、B 和 C 包含负责处理数据的核心产品.Bundle M 包含一个可选的监控工具,旨在测量流经 A、B 和 C 的数据的某些参数.目前,添加可选工具需要更改 A、B 和 C 中的路由以添加额外的 Processor
用监控数据丰富 Exchange
并在
Bundles A, B, and C contain the core product responsible for processing data. Bundle M contains an optional monitoring tool, designed to measure certain parameters of the data flowing through A, B, and C. Currently, adding on the optional tool requires changing the routes in A, B, and C to add additional Processor
s to enrich the Exchange
with the monitoring data and to read the monitoring data prior to <to />
endpoints.
我们的目标是能够将 Bundle M 放入一个已经验证过的具有 A、B 和 C 的系统中;并让它自动应用于现有路由,而无需修改现有和工作包的配置.可以对 A、B 和 C 进行修改以支持这一点,只要这些更改不会导致 A、B 和 C 依赖于 M 运行(即 ABC 必须仍然在没有 M 的情况下运行).
The goal is to be able to drop in Bundle M into a already verified-as-working system with A, B, and C; and have it automatically apply to the existing routes without having to modify the configuration for the existing-and-working bundles. It is acceptable to make modifications to A, B, and C to support this, as long as the changes do not cause A, B, and C to rely on M to run (i.e., ABC must still run without M).
如果有比使用拦截器更好的方法来做到这一点,我愿意接受.主要目标是:
If there is a better means to do this than using interceptors, I am open to that. The primary goals are:
- 保持 A、B 和 C 与 M 分离(尤其是在开发过程中)
- 确保尽可能轻松地将 M 与 A、B 和 C 集成
- 无需手动更改 A、B 或 C 即可集成 M
推荐答案
我认为使用 InterceptorStrategy
是不可能的,因为它期望它在同一个骆驼上下文中运行.我知道跨多个上下文工作的唯一方法是使用 VM 端点(显然仅限于同一个 JVM),但是在这种情况下,您可能会更好地使用 JMS、JMX 或类似的东西.
I dont think this is possible using InterceptorStrategy
since that expects it is running in the same camel context. The only ways I am aware of working across multiple contexts is using the VM endpoint (which is obviously limited to the same JVM), however in this case you would probably be better utilising JMS, JMX or something similar.
JMS
为 A, B & 中的每个骆驼上下文创建一个
InterceptorStrategy
将消息发布到 M
intercept().bean(transformForMonitoring).to("jms:queue:monitoring");
from("whatever:endpoint")
.process(myProcessor)
.to("target:endpoint");
如果您不想要 JMS 的开销,您也可以在 intercept()
上使用 vm
组件,但是这会将您的监控组件限制为单个 JVM.
You could also use the vm
component on the intercept()
if you dont want the overhead of JMS, however this limits your monitoring component to a single JVM.
JMX
这有点复杂,但基本思想是告诉骆驼上下文为 A, B & 发布 MBean.C
This is a bit more complicated, but the basic idea is to tell the camel context to publish MBeans for A, B & C
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<jmxAgent id="agent" mbeanObjectDomainName="your.domain.name"/>
...
</camelContext>
然后让 M
连接到 JVM MBean 服务器并使用类似 NotificationListener 对交易所做出反应.
and then have M
connect to the JVM MBean Server and utilise something like NotificationListener to react to the Exchanges.
这篇关于OSGi 容器中的骆驼:将拦截策略应用于所有骆驼上下文的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:OSGi 容器中的骆驼:将拦截策略应用于所有骆驼上下文
基础教程推荐
- 如何使用 Java 创建 X509 证书? 2022-01-01
- Java:带有char数组的println给出乱码 2022-01-01
- 降序排序:Java Map 2022-01-01
- FirebaseListAdapter 不推送聊天应用程序的单个项目 - Firebase-Ui 3.1 2022-01-01
- “未找到匹配项"使用 matcher 的 group 方法时 2022-01-01
- Java Keytool 导入证书后出错,"keytool error: java.io.FileNotFoundException &拒绝访问" 2022-01-01
- 设置 bean 时出现 Nullpointerexception 2022-01-01
- 在 Libgdx 中处理屏幕的正确方法 2022-01-01
- 无法使用修饰符“public final"访问 java.util.Ha 2022-01-01
- 减少 JVM 暂停时间 >1 秒使用 UseConcMarkSweepGC 2022-01-01