• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Updating a bundle (or a feature) in OSGi

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
author
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic