应用错误收集

我正在设计一个应用程序，其功能需要在不同的上下文中相同。请参考下图：


                     +----+         +----+       +----+
                     |B1  +--->-----+B2  +-->----+B3  |
                     |ctx1|  use    |ctx1|  use  |ctx1|
                     +----+ service +----+service+----+



     +-------+       +----+         +----+       +----+
     |Context|       |B1  +--->-----+B2  +-->----+B3  |
     |Manager|       |ctx2|  use    |ctx2|  use  |ctx2|
     |       |       +----+ service +----+service+----+
     |       |         :              :            :
     +-------+         :              :            :

                     +----+         +----+       +----+
                     |B1  +--->-----+B2  +-->----+B3  |
                     |ctxN|  use    |ctxN|  use  |ctxN|
                     +----+ service +----+service+----+

有4个捆绑包：

上下文管理器
的 B1
的 B2
的 B3

上下文管理器是负责知道新上下文何时可用并实例化新版本 B1 ， B2 的捆绑包>和 B3 。 B2 和 B3 提供的服务在上下文中完全相同，只是我想在服务上添加一个属性来区分它在哪个上下文运行（ctx1 vs ctxN for例）。现在这是我想要实现的理论，我想我可以通过Declarative Services轻松实现它，实际上我做了 B1 * B2 *和 B3 是 ComponentFactory ，方法是在组件标题中指定component.factory属性，然后设置 B1 以引用 B2提供的服务，我也设置 B2 来引用 B3 提供的服务。这些是我面临的挑战：

上下文管理器第一次了解 B3 提供的 ComponentFactory 服务，只要 B1 和 B2 尚未满足，他们没有在服务注册表中注册 ComponentFactory 服务。只要是这种情况， B1 和 B2 就不会为第一个上下文实例化。
B1 和 B2 创建后，从其他上下文获取任意服务，我想将reference.target参数设置为仅从同一上下文中选择服务但似乎没有任何方法可以声明这样做，似乎从同一个上下文中选择服务的唯一方法是通过设置基数 0..n 的引用并提供一个基于当前上下文选择的“bind”方法，这意味着每个组件都必须复制相同的选择逻辑，而我认为可以由上下文管理器提供调用newInstance时实际上如果在调用 ComponentFactory.newtInstance（props）; 我可以提供像.target =（context = mycontext）这样的属性那么这可以实现，但我不知道所有的引用组件实际上正在使用。

此时我正在考虑实际上避免使用声明式服务并让每个上下文包扩展我将提供的基类，它基本上实现类似于org.apache.felicy.dependencymanager的依赖性跟踪，但是这样每个上下文组件的开发人员不必担心知道代码所在的上下文。但是我讨厌恢复这个解决方案，我觉得我只是复制逻辑可能已经存在于OSGi规范中，所以我的问题是：

创建可在OSGi中的每个上下文基础上运行的bundle的最佳方法是什么，这样bundle可以以声明方式描述依赖，而不必明确提及它们所在的上下文跑？

OSGi中的每个上下文服务

2 个答案: