File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Other Application Frameworks and the fly likes Updating a bundle (or a feature) in OSGi Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Updating a bundle (or a feature) in OSGi" Watch "Updating a bundle (or a feature) in OSGi" New topic
Author

Updating a bundle (or a feature) in OSGi

Augusto Sellhorn
Ranch Hand

Joined: May 24, 2007
Posts: 57
So a nice feature of OSGi is the ability to manage multiple versions of modules at the same time. However, when we install new bundles in our container, every time we increment the version id (say from an mvn url) a new bundle is installed.

So if I had bundle example.bundle.A, version 1.0.0.0
And the install bundle example.bundle.A, version 1.0.0.1

I now have two bundle.As in my environment.

Is there a way to do this in place? That is, update that same bundle (by id maybe?) but replace the old version with the new one, while also preserving the same bundle id (and install order in the container).

I have the same question about features, but kind of curious first at the bundle level.
Richard S. Hall
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
Augusto Sellhorn wrote:So a nice feature of OSGi is the ability to manage multiple versions of modules at the same time. However, when we install new bundles in our container, every time we increment the version id (say from an mvn url) a new bundle is installed.

So if I had bundle example.bundle.A, version 1.0.0.0
And the install bundle example.bundle.A, version 1.0.0.1

I now have two bundle.As in my environment.

Is there a way to do this in place? That is, update that same bundle (by id maybe?) but replace the old version with the new one, while also preserving the same bundle id (and install order in the container).

I have the same question about features, but kind of curious first at the bundle level.


BundleContext.installBundle() is how you install a new bundle.
Bundle.update() is how you update an existing bundle.
Stuart McCulloch
author
Greenhorn

Joined: Feb 14, 2011
Posts: 21
Richard S. Hall wrote:
Augusto Sellhorn wrote:So a nice feature of OSGi is the ability to manage multiple versions of modules at the same time. However, when we install new bundles in our container, every time we increment the version id (say from an mvn url) a new bundle is installed.

So if I had bundle example.bundle.A, version 1.0.0.0
And the install bundle example.bundle.A, version 1.0.0.1

I now have two bundle.As in my environment.

Is there a way to do this in place? That is, update that same bundle (by id maybe?) but replace the old version with the new one, while also preserving the same bundle id (and install order in the container).

I have the same question about features, but kind of curious first at the bundle level.


BundleContext.installBundle() is how you install a new bundle.
Bundle.update() is how you update an existing bundle.

As Richard said, install is different from update. Sometimes you want more than one version of a bundle installed (ie. you might have two applications loaded with different requirements) in which case you can install them alongside each other. In other situations you want to update an already installed bundle, say to rollout a fix, which is a different process. It's also important to remember that updating is a two-step process in OSGi. Existing applications won't immediately use the updated packages, you need to initiate a refresh (PackageAdmin.refreshPackages) which will then stop and re-start the affected bundles so they can rewire to the new packages.

(In advanced cases this may involve persisting user state so the application can restart seamlessly)
Augusto Sellhorn
Ranch Hand

Joined: May 24, 2007
Posts: 57
Cool, thanks!

See, for the longest time I've been installing like this;

install mvn:foo.bar/bar-example/1.0

Then when I recompile the project, I do an update [bundle id]. No problem right? Update on equinox and felix, just reuses the url given by the install.

I didn't realize update had an optional location argument. So I just tried;

update [bundle id] mvn:foo.bar/bar-example/2.0

And it updates the bundle with the new code, while keeping the same bundle id, and replacing the previous version.

Great thanks!

On to the next, related question, are features part of the OSGi standard? And for features, I don't see an equivalent to update ...
Richard S. Hall
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
Augusto Sellhorn wrote:
On to the next, related question, are features part of the OSGi standard? And for features, I don't see an equivalent to update ...


Since I don't know what you are talking about, I am pretty sure the answer is "no". Are you talking about something like the features in Apache Karaf? There is nothing in the spec like this, although the Enterprise expert group is working on a subsystems spec, which should do similar things.
Augusto Sellhorn
Ranch Hand

Joined: May 24, 2007
Posts: 57
Actually I am using karaf, so yeah, karaf has a feature:install command (and features have a version) but I don't really see how you can do an update of a feature. I got the impression features were not officially in the spec, but I thought they were a common feature of other containers too (like equinox and felix).
Stuart McCulloch
author
Greenhorn

Joined: Feb 14, 2011
Posts: 21
Augusto Sellhorn wrote:Actually I am using karaf, so yeah, karaf has a feature:install command (and features have a version) but I don't really see how you can do an update of a feature. I got the impression features were not officially in the spec, but I thought they were a common feature of other containers too (like equinox and felix).

Eclipse also has features, but they're not quite the same as in Karaf - the idea of atomically installing a related set of bundles (and providing some isolation between sets of bundles) is common, but has yet to be standardized by the OSGi Alliance. There is the DeploymentAdmin compendium service, but that has the drawback that you cannot share bundles between deployment packages.
Richard S. Hall
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
Augusto Sellhorn wrote:Actually I am using karaf, so yeah, karaf has a feature:install command (and features have a version) but I don't really see how you can do an update of a feature. I got the impression features were not officially in the spec, but I thought they were a common feature of other containers too (like equinox and felix).


I'm not too familiar with Karaf, so you'd probably have to ask on their mailing list. As I mentioned, though, such functionality might eventually be covered in a new subsystems spec being worked on within the OSGi Alliance.

As far as Felix and Equinox providing such features, it isn't really a good idea, since these features would tie anyone that used them to that specific framework implementation. You should only use standard features from the framework implementation. All other functionality should come from modules on top, which will then allow you to use other framework implementations. This is the Karaf approach, for example.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Updating a bundle (or a feature) in OSGi