OSGi应用程序修补策略

问题描述：

什么是修补OSGi容器的适当机制。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容器。

干杯，

答

我自己会建议你做这个：

1.分割你的API（Java的接口），并以单独的电缆束您的实现。

这种方式如果只有实现更改API保持“活动”，从而防止OSGI服务被关闭。服务由接口引用。当然你的服务消费者应该能够处理（暂时）不存在的服务。

2.有一个明确的捆绑命名方案。

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

3.在Manifest中使用版本。

此外，您应该使用Manifst中的版本属性。对于你来说这显然比你的OSGI容器跟踪你的包要少。

你成功安装了所有新的包后，我会建议你删除旧的。如果您在文件名中使用了版本，这应该相当容易。如果你离开旧罐子，你可能会遇到较慢的启动时间。这是因为虽然您的容器不使用捆绑包，但他必须加载并检查它们。而且他们还生活在你的班级路线中，并可能增加冲突的风险。

我希望能帮助你一点。这是一个很好的问题！也许一些更有经验的人也会发布建议:)我想听听其他人的做法。

OSGi应用程序修补策略

相关推荐