我的团队正在尝试开发一个基于OSGi的新系统,现在我们有超过50个捆绑计数.问题是,捆绑包之间存在依赖关系.例如,当捆绑A启动时,它将向OSGi注册服务,而当捆绑B启动时,它将使用该服务.因此,我需要比捆绑B更早地捆绑A启动.为了实现这一点,我将捆绑A的起始级别设置为小于捆绑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.
这是否意味着启动级别不会决定启动顺序？那我什么时候应该用它？
使用不同的Start Levels来管理OSGi包之间的依赖关系是否合理？
可以使所有捆绑包成为动态模块(使用ServiceTracker跟踪它使用的所有服务),但是需要更多时间并且需要高级开发人员,并且系统变得难以调试.
我的答案与Bertrand类似：您应该考虑为您的解决方案使用更高级别的基于组件的抽象：SCR,iPOJO,Blueprint等.
原文链接：https://www.f2er.com/javaschema/281555.html使用启动级别来控制依赖关系有点像在Java中使用线程优先级来修复竞争条件.当然,你可能会让事情变得有效,有一段时间,但你会在这个过程中疯狂 – 而且你最终会失败.
开始等级很有用.规范示例是,如果您需要在启动基于OSGi的GUI应用程序时显示启动屏幕,方法是将其代码放在一个包中.如果没有启动级别,则无法确保启动屏幕最终会显示,但是使用启动级别会变得微不足道.
也就是说,我已经使用了起始级别来解决第三方软件包中发现的依赖性排序错误(例如,Spring),尽管这不涉及服务排序,而是涉及查找资源的假设(使用Spring,一个用于Spring Integration自定义的XSD)命名空间).
