0

在 OSGi 中是否有可能在系统重新启动时保持捆绑连接，即使现在有一个新的更高版本可用，我们仍然使用旧版本？关键是，如果某些东西有效，我们不想通过将旧捆绑包连接到新依赖项来冒险。换句话说，我们正在尝试尽可能多地隔离更新，以便组件中的更新不会影响所有其他组件（因为旧的包仍将用于满足已经连接的依赖项）

例如，假设 A 依赖于范围为 [1.0.0, 2.0.0) 的 B。我们部署 B 的 1.0.0 版本，所以现在 A 连接到 B_1.0.0
现在我们创建一个依赖于逻辑更改的包 C，因此它依赖于范围为 [1.0.1, 2.0.0) 的 B。所以我们部署 B_1.0.1。现在如果我们重新启动系统，C 和 A 将被连接到 1.0.1，因为它在两者的依赖范围内，理论上它比 1.0.0 更适合 A。有什么方法可以告诉 OSGi 不要这样做并尽可能长时间地保持布线（例如，直到实际删除旧捆绑包，在这种情况下，可以使用该范围内的最高版本）

我们目前所做的是不允许范围，因此依赖关系类似于 [1.0.0, 1.0.0]。这为我们提供了我们想要的更新隔离，但代价是我们基本上失去了模块化；要更新依赖项，即使依赖项中的代码没有更改，我们也需要更新依赖项。我认为禁止范围是一个巨大的反模式，所以我试图提出一个更好的范围替代方案，但这会提供我们需要的更新隔离，我的第一个想法是即使跨会话也不允许重新布线

如果重要的话，我们没有使用 OSGi 服务。它们都是普通的捆绑包

4

1 回答 1

2

第一段中问题的答案很简单：是的，这是 OSGi 的默认行为。如果在没有执行任何包更新或包刷新操作的情况下停止并重新启动框架，那么下次启动时的连线状态将相同。

但是，您在第二段中进行了更改。您现在有 2 个具有不同版本的 B 导出，A 和 C 都依赖于它，具有不相同但重叠的范围。重叠是这里的关键。OSGi 总是试图最小化同一个包的独立导出的数量，所以如果你有两个具有重叠范围的包导入，那么框架将尝试将它们连接到相同的版本而不是两个单独的版本。此处重叠的版本是 1.0.1，因此 A 和 C 都将连接到 1.0.0。

你不应该试图改变这一点。如果捆绑包 A 实际上与该范围兼容，[1.0.0, 2.0.0)那么您为什么反对将其连接到版本 1.0.1？另一方面，如果 A 真的只与版本 1.0.0 而不是 1.0.1 兼容，那么您应该指定一个非常严格的范围，即[1.0.0, 1.0.1).

最后……你的最后一段让我很难过。普通捆绑包使用服务！

于 2013-08-12T19:21:07.873 回答