OSGi 应用程序修补策略

Question

修补 OSGi 容器的适当机制是什么？

      1) Should the bundles (binaries/jars) have the same name as the old ones then:
            a.  Replace the bundle with the with the new bundle (manifest has been  
              modified to reflect the new version) in the plug-ins folder and,  
            b.  Invoke update <bundle id> <bundle name>.
      2) Or Should the bundles have version information encoded in the file name   
            a.  Copy the new bundle to the plug-ins folder
            b.  Invoke update <bundle id> file:plugins/<new Bundle name>
      3) Or other alternatives, possibly an OBR (not sure of the pros and cons) also 
         we may be constrained by the amount of work involved in retrofitting an OBR.  

我注意到的一件事是，在某些情况下，会在特定包的“数据根”下创建一个包文件（看起来像重命名的 jar）。这种情况是在调用更新时的所有情况下发生还是仅在特定情况下发生。

关于上述内容有什么建议、优点、缺点等等吗？或者有更好的选择吗？基本上我的想法是，用修补后的二进制文件替换原始二进制文件会很好，从 OSGi 上下文来看这是一个好主意吗？

我们正在使用 Equinox OSGi 容器。

干杯，

Answer 1

我本人建议您这样做：

1。将您的 API（Java 接口）和实现拆分为单独的包。

这样，如果只有实现发生更改，API 就会保持“活动”状态，从而防止 OSGI 服务被关闭。服务由接口引用。当然，您的服务使用者应该能够处理（暂时）不存在的服务。

2.有一个清晰的捆绑包命名方案。

我会在捆绑包 jar 文件名中使用版本。您必须区分文件系统中的 jar，并且使用文件名中的版本有很大帮助。另外，如果你不使用版本，我会担心在运行时覆盖罐子。理论上它应该有效，但你永远不知道。如果您有版本，则不会覆盖旧罐子。

3.在清单中使用版本。

此外，您应该在清单中使用版本属性。这对于您来说显然不如您的 OSGI 容器来跟踪您的包。

---

成功安装所有新捆绑包后，我建议您删除旧捆绑包。如果您在文件名中使用了版本，这应该很容易做到。如果您保留旧罐子，您可能会遇到启动时间变慢的情况。这是因为虽然您的容器不使用捆绑包，但他必须加载并检查它们。而且它们也存在于您的类路径中，可能会增加冲突的风险。

我希望这对你有一点帮助。这是一个好问题！也许一些更有经验的人也会在那里发表建议:)我想听听其他人是怎么做的。