解决了捆绑包的 OSGI 捆绑包的依赖关系后会发生什么答案

【问题标题】：What Happens to dependencies of a OSGI bundle of a bundle once its resolved解决了捆绑包的 OSGI 捆绑包的依赖关系后会发生什么
【发布时间】：2017-05-24 03:12:26
【问题描述】：

我有一个 OSGI Bundle A 和 Bundle B。 Bundle B 依赖于 Bundle A。

Bundle B 和 Bundle A 都处于活动状态。

现在我需要了解以下场景对 Bundle B 的影响

1) 我已经停止了 Bundle A，Bundle B 会发生什么。

2) 我已经卸载了 Bundle A。Bundle B 会发生什么。

3) 我已经停止了 Bundle A，然后我停止了 Bundle B，现在我正在尝试从已安装状态解析 B。

4) 我已经卸载了 Bundle A，然后我停止了 Bundle B，现在我正在尝试从已安装状态解析 B。

谁能回答这个问题？

我已经使用 apache Felix 控制台进行了尝试，在上述任何情况下我都没有看到对 B 的任何影响。

谁能帮我解决这个问题？

【问题讨论】：

最好的方法是在 Apache servicemix 中使用 2 个包含测试代码的包进行尝试。
澄清一下，这些是按顺序排列的吗？还是单独的场景，每个场景分别遵循前两句话中描述的状态？
@Shinchan 我已经尝试过了，但在这两种情况下我总是认为对 B 没有影响，我对此没有任何解释。我正在找人确认。
@JWoodchuck 这些是独立的独立场景。是的，在每个场景之前，前两个陈述总是正确的。

标签： java dependencies osgi bundle osgi-bundle

【解决方案1】：

影响应该如下：

无（停止与分辨率无关）
什么都没有（B 仍然使用 A 导出的包，直到您执行 refresh）
无（停止与分辨率无关）
B 不应该解决 -- 除非另一个包能够提供 B 所依赖的包。

更新

在 cmets 中，@Ngupta 询问“请分享一些解释，说明为什么 B 总是被解析，即使它需要的包不再存在”。

我的回答：B 将保持处于已解决状态，即使您卸载了它的依赖项。但是，如果 B 缺少依赖项，它将不会转换到已解决状态。

您可以通过执行refresh 强制 B 重新解析（并且此重新解析应该失败），这是您可以从 Gogo shell 执行的操作。事实上，您应该始终在执行一系列安装、更新或删除操作后发送refresh。

【讨论】：

我发现这并没有发生在我身上。我的 B 总是得到解决（即使在第 4 种情况下也是如此）。你能否分享一些关于为什么 B 总是被解析的解释，即使它需要的包不再存在。
您需要提供更多信息。 B对A的依赖是什么样子的，你是怎么卸载A的，卸载A后你到底对B做了什么等等。
特别是，您对 (4) 中对 B 所做的事情的描述不清楚。您说“我停止了 Bundle B，现在我正在尝试从已安装状态解析 B”。你是如何让 B 进入 INSTALLED 状态的？仅仅停止它不会实现这一点，因为停止与分辨率无关。
关于您的问题：即使您卸载 B 的依赖项，B 也将始终保持处于已解决状态。但是，如果 B 缺少依赖项，它将不会转换到已解决状态。您可以通过执行refresh 来强制 B 重新解析（并且此重新解析应该失败）。
在第四个场景中，我停止了我的 OSGi Bundle 并重新启动了 OSGI 容器。所以我的 B 进入了已安装状态，由于缺少依赖而无法解析。