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
Stack Overflow用户
发布于 2011-06-22 18:15:27
我个人建议你这样做：
将你的(Java接口)和你的实现拆分成单独的包。
这样，如果只有实现发生了变化，API将保持“活动状态”，从而防止OSGI服务被关闭。服务由接口引用。当然，您的服务使用者应该能够处理(暂时)不存在的服务。
2.有一个清晰的包命名方案。
我会在捆绑包jar文件名中使用版本。您必须区分文件系统中的jars，并且使用文件名中的版本会有很大帮助。此外，如果您不使用版本，我会担心在运行时覆盖jars。从理论上讲，它应该是有效的，但你永远不知道。如果你有版本，你就不会覆盖旧的jars。
3.使用清单中的版本。
此外，您应该使用Manifst中的version属性。这显然比您的OSGI容器跟踪您的捆绑包要少。
在您成功安装所有新的包之后，我建议您删除旧的包。如果你在你的文件名中使用了版本，这应该很容易做到。如果你把旧的jars放在里面，你可能会体验到更慢的启动时间。这是因为尽管您的容器不使用包，但他必须加载和检查它们。而且它们还存在于您的类路径中，并且可能会增加冲突的风险。
我希望这能对你有所帮助。这是一个很好的问题！也许一些更有经验的人也会在那里发布建议:)我想听听别人是怎么做的。
https://stackoverflow.com/questions/5017050
复制相似问题
腾讯云开发者
