dependencies - 使用不同的启动级别来管理 OSGi 包之间的依赖关系是否合理？

Question

我的团队正在尝试开发一个基于 OSGi 的新系统，现在我们有 50 多个 bundle 并且还在增加。问题是， bundle 之间存在依赖关系。例如，当bundle A启动时，它将向OSGi注册一个服务，而当bundle B启动时，它将使用该服务。因此，我需要在 bundle B 之前启动 bundle A。为了实现这一点，我将 bundle A 的启动级别设置为小于 bundle B。

我们尝试使用 ServiceTracker 来避免设置启动级别，但是随着服务数量的增长，管理和理解整个系统变得困难。

但是，我在网上找到了这篇文章:OSGi and Start Levels .我不确定里面有两句话:

• Start order within the start level is indeterminate!
• On the whole, when working with start levels, never depend on start order. Think about start levels as a management issue, not a development time issue.

这是否意味着启动级别不会决定启动顺序？那我应该什么时候使用呢？

使用不同的启动级别来管理 OSGi 包之间的依赖关系是否合理？

可以将所有的bundle做成一个动态模块(使用ServiceTracker来跟踪它使用的所有服务)，但是这需要更多的时间和需要高级开发人员，并且系统变得难以调试。

Answer 1

我的回答与 Bertrand 类似:您应该考虑为您的解决方案使用更高级别的基于组件的抽象:SCR、iPOJO、Blueprint 等。

使用启动级别来控制依赖关系有点像在 Java 中使用线程优先级来修复竞争条件。当然，你可能会在一段时间内让事情顺利进行，但你会在这个过程中发疯——无论如何你最终都会失败。

开始级别很有用。典型示例是，如果您需要在启动基于 OSGi 的 GUI 应用程序时显示启动屏幕，方法是将其代码放在一个包中。如果没有起始关卡，就无法确保启动画面最终会在应有的时候显示，但是使用起始关卡就变得微不足道了。

也就是说，我已经使用启动级别来解决在第三方包(例如 Spring)中发现的依赖排序错误，尽管这不涉及服务排序，而是关于查找资源的假设(使用 Spring，一个用于 Spring Integration 自定义的 XSD命名空间)。