2

在看到 Robert Dunne 的OSGi Dependencies: Heaven and Hell之后,我对以下内容特别感兴趣:

如果您使用的解析器不知道ACTIVE包依赖关系,那么您必须自己管理所有这些。使用 Nimble,您只需询问您需要什么,其余的交给解析器。这加快了开发生命周期并避免了多余的杂乱脚本。

正如理查德所说,使用 obr 可以解决解析时间依赖关系。但是,我认为如果不扫描包的源,很难解决活动时依赖(活动包的依赖自动)。

例如,如果一个 bundle A 使用了一个在 bundle B 上注册的服务 usingBundleContext.register方法,那么,当激活 bundle A 时,我们怎么知道我们必须激活 bundle B 的事实呢?

4

1 回答 1

2

整个方法背后的假设是捆绑包将提供指示其要求和功能的元数据。可以从包中的其他工件(例如 web.xml 文件或声明性服务组件文件)推断出一些额外的信息。

即使有代码级依赖,也无法检测任意动态类加载——元数据是必不可少的。

编写一个可以确定捆绑软件的所有可能功能和要求的程序将是一个困难的静态分析问题,这些问题往往等同于停机问题,即不可能。

于 2012-09-19T15:19:12.490 回答