我的团队正在尝试开发一个基于OSGi的新系统，现在我们有超过50个捆绑计数。问题是，捆绑之间存在依赖关系。例如，当捆绑A启动时，它将向OSGi注册服务，而当捆绑B启动时，它将使用该服务。因此，我需要捆绑A启动早于捆绑B.为了实现这一点，我将捆绑A的起始级别设置为小于捆绑B.
我们尝试使用ServiceTracker来避免设置启动级别，但是当服务计数增长时，很难管理和理解整个系统。
但是，我在互联网上发现了这篇文章：OSGi and Start Levels。我不确定中有两句话：
- 开始级别内的开始顺序是不确定的！
- 总的来说，在使用启动级别时，永远不要依赖启动顺序。将启动级别视为管理问题，而不是开发时间问题。
是否意味着启动级别不会决定启动顺序？那我什么时候应该使用它？
使用不同的Start Levels来管理OSGi包之间的依赖关系是否合理？
可以将所有捆绑包作为动态模块（使用ServiceTracker跟踪它使用的所有服务），但是需要更多时间并且需要高级开发人员，并且系统变得难以调试。
答案 0 :(得分：9)
我的答案与Bertrand类似：您应该考虑为您的解决方案使用更高级别的基于组件的抽象：SCR，iPOJO，Blueprint等。
使用启动级别来控制依赖关系有点像在Java中使用线程优先级来修复竞争条件。当然，你可能会让事情变得有效，有一段时间，但你会在这个过程中疯狂 - 而且你最终会失败。
启动级别 非常有用。规范示例是，如果您需要在启动基于OSGi的GUI应用程序时显示启动屏幕，方法是将其代码放在一个包中。如果没有启动级别，则无法确保启动屏幕最终会显示，但是使用启动级别会变得微不足道。
那就是说，我已经使用了启动级别来解决在第三方软件包中发现的依赖性排序错误（例如，Spring），尽管这不涉及服务排序，但是关于查找资源的假设（使用Spring，XSD用于Spring Integration自定义命名空间）。
答案 1 :(得分：7)
使用启动级别来管理服务之间的依赖关系是一个坏主意 - 服务组件运行时（SCR）是一种更好的管理方式，如果正确完成将处理所有依赖项，启动顺序，重新启动组件时他们所需的服务重新启动等等。
如果您正在使用Maven，Apache Felix SCR插件（http://felix.apache.org/site/scr-annotations.html）可以使用少量Java注释轻松创建SCR管理的服务。 Apache Sling的代码（http://sling.apache.org）充满了使用它的例子。
答案 2 :(得分：1)
关于启动级别/依赖性问题的一个很好的总结，它解释了为什么必须避免在具有启动级别的bundle之间定义依赖关系。