OSGi应用程序修补策略 [英] OSGi Application Patching Strategy

问题描述

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

What are appropriate mechanisms for patching an OSGi container.

      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)是在特定捆绑软件的数据根"下创建的.在调用更新的所有情况下还是仅在特定情况下会发生这种情况.

One thing I’ve noticed is that in some instances a bundle file (looks like the renamed jar) is created under the ‘Data Root’ of the particular bundle. Should this happen in all cases when update is invoked or only in specific cases.

关于上述内容是否有任何建议，利弊等.还是有更好的选择?基本上，我的想法是将原始二进制文件替换为修补后的二进制文件会很好，从OSGi上下文来看这是个好主意吗?

Are there any recommendations, pros, cons, etc.. about the above. Or is there better alternative? Basically my thinking is that it would be nice to have the original binaries replaced with the patched binaries, is this a good idea from an OSGi context?

我们正在使用Equinox OSGi容器.

We are using the Equinox OSGi container.

干杯

推荐答案

我本人会建议您这样做:

I myself would advice you do to this:

1.将您的API(Java接口)和您的实现分成单独的捆绑软件.

这样，如果仅实现更改，则API保持有效"状态，这可以防止OSGI服务被关闭.服务由接口引用.当然，您的服务使用者应该能够(临时)处理不存在的服务.

This way if only the implementation changes the API is kept "alive" which prevents OSGI-services to be shutdown. Services are referenced by the interface. Of course your service consumers should be able to deal with (temporarily) non-existing services.

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

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

I would use versions in the bundle jar file name. You have to distinguish the jars in the file system and working with versions in the file name helps a lot. Also, if you do not use version, I would be worried of overwriting jars at runtime. Theoretically it should work, but you never know. If you have versions you would'nt overwrite old jars.

3.使用清单中的版本.

此外，您还应该在清单中使用version属性.显然，这对您来说要比OSGI容器跟踪捆绑包要少.

Additionally you should use the version property in the Manifst. This is obviously less for you than it is for your OSGI container to keep track of your bundles.

成功安装所有新捆绑软件后，我建议您删除旧捆绑软件.如果您在文件名中使用了版本，则应该很容易做到.如果您将旧的罐子放在里面，则可能会遇到启动时间变慢的情况.这是因为尽管您的容器不使用捆绑包，但他必须加载并检查捆绑包.然后他们也就生活在您的课堂中，可能会增加发生冲突的风险.

After you successfully installed all your new bundles I would advice you to delete the old ones. If you used versions in your file name this should be fairly easy to do. If you leave the old jars in, you probably are going to experience slower startup times. This is because although your container does not use the bundles he has to load and check them. And also they are then living in your classpath and may increase the risk of conflicts.

希望对您有所帮助.这是一个很好的问题！也许一些更有经验的人也会在这里发布建议:)我想听听别人的建议.

I hope that helps you a bit. This is a good question! Maybe some more experienced people will post there suggestions too :) I would like to hear what others do.

这篇关于OSGi应用程序修补策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！