OSGi是否有可能在系统重启时保持捆绑接线，即使现在有一个新的，更高版本可用，我们仍然使用旧版本？重点是，如果某些东西有效，我们不希望通过将旧捆绑包连接到新的依赖关系来冒险。换句话说，我们试图尽可能地隔离更新，以便组件中的更新不会影响AT ALL其他组件（因为旧的bundle仍将用于满足已经连接的依赖项）
举个例子，假设A取决于范围为[1.0.0,2.0.0的B]。我们部署了B版本1.0.0，所以现在A连接到B_1.0.0
现在我们创建一个依赖于逻辑变化的捆绑C，因此它依赖于B，范围为[1.0.1,2.0.0]。所以我们部署B_1.0.1。现在，如果我们重新启动系统，C和A将连接到1.0.1，因为它处于两者的依赖范围内，理论上它是A的“更好”匹配，而不是1.0.0。有没有办法告诉OSGi不要这样做，并尽可能长时间地保持接线（比如，直到旧捆绑实际被删除，在这种情况下，可以使用该范围内的最高版本）
我们目前所做的是禁止范围，因此依赖关系类似于[1.0.0,1.0.0]。这为我们提供了我们想要的更新隔离，但代价是我们基本上失去了模块化;更新我们需要更新依赖项的依赖项，即使依赖项中的代码没有更改。我认为禁止范围是一个巨大的反模式，所以我试图提出一个更好的替代范围，但这将提供我们需要的更新隔离，我的第一个想法是不允许重新连接甚至跨会话
如果重要，我们不会使用OSGi服务。它们都是普通的捆绑包
答案 0 :(得分：2)
第一段中问题的答案很简单：是的，这是OSGi的默认行为。如果在不执行任何捆绑更新或包刷新操作的情况下停止并重新启动框架，则下次启动时接线状态将相同。
但是你改变了第二段的内容。您现在有2个具有不同版本的B导出，A和C都依赖于它，具有不相同的但重叠的范围。重叠是关键。 OSGi总是尝试最小化同一个包的独立导出的数量，因此如果你有两个bundle重叠范围导入，那么框架将尝试将它们连接到相同的版本而不是两个单独的版本。这里重叠的版本是1.0.1，因此A和C都将连接到1.0.0。
您不应该尝试更改此。如果bundle A实际上与范围[1.0.0, 2.0.0)兼容，那你为什么要反对它连接到版本1.0.1？另一方面，如果A实际上只与版本1.0.0而不是1.0.1兼容，那么您应该指定一个非常紧凑的范围，即[1.0.0, 1.0.1)。
最后......你的最后一段让我伤心。普通捆绑包使用服务！