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。有明确的捆绑命名方案。

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

第3。使用Manifest中的版本。

此外，您应该使用Manifst中的version属性。对于您来说，这显然不如您的OSGI容器跟踪您的捆绑包。

成功安装所有新捆绑包后，我建议您删除旧捆绑包。如果您在文件名中使用了这个版本，那么这应该很容易。如果您将旧罐放入，您可能会遇到启动时间较慢的情况。这是因为虽然您的容器不使用捆绑包，但他必须加载并检查它们。而且他们也会生活在你的课堂上，可能会增加冲突的风险。

我希望对你有所帮助。这是一个很好的问题！也许一些更有经验的人也会在那里发布建议:)我想听听其他人的所作所为。

OSGi应用程序修补策略

1 个答案: