无法找到服务,因为 OSGi 捆绑包未激活

发布于 2024-08-17 02:11:35 字数 528 浏览 13 评论 0原文

我在发现某些未激活的 OSGi 捆绑包提供的服务时遇到问题。让我描述一下情况:

  • Bundle A 定义接口 X
  • Bundle B、C 和 D 提供实现接口 X 的服务
    • 这些bundle的服务是通过Spring DM注册的,因此它们仅在bundle被激活并且Spring DM初始化bundle中定义的应用程序上下文时创建
  • A被激活,并在某个时刻向服务注册中心请求服务。接口 X。它没有找到任何东西,因为包 B、C 和 D 尚未进入 ACTIVE 状态(它们只是 RESOLVED)。

我似乎无法启动捆绑包 B、C 或 D,因此无法注册它们的服务。通过将它们添加到 config.ini 来强制它们启动并不是一种选择,因为应用程序中可以安装任意数量的包(通过类似 Eclipse p2 的更新机制)来实现 该应用

程序是一个基于 Eclipse 3.5 的 RCP 应用程序,使用 Spring 2.5.6 和 Spring DM 1.2.1。

如何强制激活这些捆绑包?

I'm having a problem discovering services that are provided by some OSGi bundles that are not being activated. Let me describe the situation:

  • Bundle A defines interface X
  • Bundles B, C, and D provide services that implement interface X
    • These bundles' services are registered via Spring DM, so they are only created when the bundle is activated and Spring DM initialized the application context defined in the bundle
  • Bundle A is activated and at some point asks the service registry for services for interface X. It doesn't find any, because bundles B, C, and D haven't been moved into the ACTIVE state (they are only RESOLVED).

I cannot seem to get bundles B, C, or D to start, and therefore register their services. Forcing them to start by adding them to the config.ini is not an option, because there can be any number of bundles that are installed in the application (via an Eclipse p2-like update mechanism) that implement interface X.

The application is an Eclipse 3.5-based RCP app, using Spring 2.5.6 and Spring DM 1.2.1.

How do I force these bundles to be activated?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

半枫 2024-08-24 02:11:35

你真正遇到的是依赖层次结构问题,你提出的黑客解决方案实际上只是解决根本问题的创可贴。

您真正应该考虑的是系统的架构,实际上您拥有的是循环依赖(回复:原始帖子评论中的讨论)。你(不管喜欢与否)A 需要 B 和 C 的服务(并且在某种意义上依赖于)。同时,B 和 C 直接依赖于 A,因此,在 A 到来之前无法启动向上。

在最好的情况下,您可以在 B 和 C 中编写代码来侦听 A 的存在,但这充其量掩盖了(正如我提到的)根本问题。你真正应该考虑的是将 A 分成两个包,我们称它们为 A1 和 A2。

A1应该提供B和C需要(依赖)的接口。 A2 应该有 B 和 C 所依赖的服务的侦听器。启动时,如果 B 和 C 是必需的服务,则 A1 必须运行,但 A2 可能稍后启动,并且一切都应该正常。

What you really have is a dependency hierarchy problem, your proposed hacky solution is really just a band-aid over the underlying issue.

What you should really consider is the architecture of your system, as effectively what you have is a circular dependency (re: discussion in comments your original post). You have (like it or not) A requires services from (and in some sense depends on) B and C. Meanwhile, B and C directly depend on A, and as such, cannot start until A comes up.

In the best case, you can write code in B and C to listen for the existence of A, but this at best masks (as I mentioned) the underlying issue. What you should really consider is splitting A into two bundles, let's call them A1 and A2.

A1 should provide the interface which B and C require (depend on). A2 should have listeners for the services B and C depend on. At startup, if B and C are required services, A1 must be run, but A2 may start any time later, and everything should work.

你的心境我的脸 2024-08-24 02:11:35

我想我已经找到了这个问题的解决方案,尽管感觉有点hackish。

我遇到了此帖子,其中 Adrian Colyer 暗示外部当捆绑包安装到框架中时,“捆绑包观察程序”可能负责激活捆绑包。

因此,我的解决方案是:

  • 将自定义标头添加到捆绑包 B、C 和 D 各自的清单中,例如“MyApp-AutoStart: true”
  • 创建一个捆绑包侦听器,该侦听器在捆绑包移至“已解析”状态时做出响应,并查找标头
  • 如果标头的值为“true”,则捆绑包侦听器调用 bundle.start()

使用此方法,可以启动我想要启动的捆绑包,而无需使用 config .ini,它们可以随意来去,但它们的服务在查询时可用。

I think I've found the solution to this problem, though it feels a bit hackish.

I ran across this thread where Adrian Colyer implied that an external "bundle watcher" could be responsible for activating bundles when they are installed into the framework.

So, my solution was to:

  • Add a custom header to bundle B, C, and D's respective manifests, e.g., "MyApp-AutoStart: true"
  • Create a bundle listener that responds when a bundle is moved into the RESOLVED state, and looks for the header
  • If the header's value is "true," the bundle listener calls bundle.start()

Using this method, the bundles I want to be started are started without having to resort to using config.ini, and they can come and go as they please, but their services are available when queried.

日裸衫吸 2024-08-24 02:11:35

另请查看 felix fileinstall,它会监视捆绑包的目录并自动安装和启动它们。当删除文件时,捆绑包也会停止并卸载。

Also have a look at felix fileinstall, which watches a directory for bundles and automatically installs and starts them. When a file is deleted, the bundle is stopped and uninstalled as well.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文