开发者

OSGi Application Patching Strategy

开发者 https://www.devze.com 2023-02-11 07:46 出处:网络
What are appropriate mechanisms for patching an OSGi container. 开发者_开发百科1) Should the bundles (binaries/jars) have the same name as the old ones then:

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.  

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.

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?

We are using the Equinox OSGi container.

Cheers,


I myself would advice you do to this:

1. Split your API (Java-Interfaces) and your implementation in to separate bundles.

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. Have a clear bundle naming scheme.

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. Use versions in the Manifest.

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.

0

精彩评论

暂无评论...
验证码 换一张
取 消