OSGi applications vs. bunch of bundles

When I speak of a OSGi application, then i mean a group of bundles, which result in a application. Such a breakdown seems obvious when using OSGi. The single parts of the application communicate through the OSGi registry. One of the benefits is that you can replace a part of the application at the runtime and it want affect the other parts.

Unfortunately there is no way in OSGi to differ between bundles, which belong to different applications. This nuisance probably has a historical reason. OSGi originally was meant to run on small devices with decent amount of bundles. Today OSGi is used in projects like Eclipse IDE which hundreds of bundles inside the OSGi container. When I start my current installed Eclipse IDE (./eclipse -console) and type “ss” in the console it shows over 600 installed bundles. I have only few extra plug-ins installed. Other installations of Eclipse IDE surely get more the 1000 bundles. If I want to uninstall a plug-in over the console I would have my hands full by searching the bundles, which belongs to that plug-in. Instead I would use the update-manager of eclipse. In a different project, where I use OSGi (Equinox in my case) I do not have a update-manger, only the console.

Together with my application (composed of 6 bundles) there are a servlet container, the spring framework and few libraries installed in the OSGi container. When I develop on my application I am actually not interested in the other bundles. Some of them remain untouched since installed once. Nevertheless I have to go trough the list with all bundles, when I look for my application. It would be handy to list the bundles, which belongs to my application with a single command. Furthermore it would be handy to change the status of those bundles with a single command. As you can read in those blogs[1][2], I am not the only one missing such a feature. So I looked around whether there are already existent solutions. I discovered the Platform Archive (PAR), which was introduced by SpringSource with the release of the SpringSource dm Server (former SpringSource Application Platform). A PAR is a regular JAR-file carrying multiple OSGi bundles. When you deploy the PAR all the packaged bundles will be installed automatically. Actually the PAR concepts fixes all my problems and offers equal management functionalities as known from normal WAR and EAR archives. As PARs are currently only supported by the SpringSource dm Server this is not a solution for all OSGi runtimes. In addition to that one of the issues with the PAR archive is, that it has to bew rebuild if one bundle is updated.

To gain some more flexibility I wanted to add the desired functionality to the Equinox myself. What I want is a way to compose groups of bundles without to violate the OSGi specification, so I still can install the bundles in a different OSGi container. Furthermore I want the bundles to remain separated. After a look in the source code of equinox I realized that I don’t even have to extend the OSGi framework itself. I only have to implement the CommandProvider interface in the org.eclipse.osgi.framework.console package and build a bundle which registers a instance of the resulting class in the OSGi registry. That’s what you do in order to add your own commands to the Equinox console.

The resulting class looks like this:

1public class GroupCommandProvider implements CommandProvider {
2   private BundleContext bctx;
3 
4   public GroupCommandProvider(BundleContext bctx) {
5      this.bctx = bctx;
6   }
7 
8   public String getHelp() {
9      return "\tstopgroup <group> - stops all bundles in the specified group.";
10   }
11 
12   public void _stopgroup(CommandInterpreter ci) throws BundleException {
13      String groupToStop = ci.nextArgument();
14      if (groupToStop == null)
15         return;
16 
17      Bundle[] bundles = bctx.getBundles();
18      for (Bundle bundle : bundles) {
19         String currentGroup = (String) bundle.getHeaders().get("Bundle-Group");
20         if (currentGroup == null || !currentGroup.equals(groupToStop))
21            continue;
22 
23         if (bundle.getState() == Bundle.ACTIVE) {
24            bundle.stop();
25         }
26      }
27   }
28}

The interesting method is _stopgroup(). By calling it you can stop all bundles with a specified value in the “Bundle-Group” field in the manifest file.

A manifest file could look like this:

1Manifest-Version: 1.0
2Bundle-ManifestVersion: 2
3Bundle-SymbolicName: de.codecentric.mybundle
4Bundle-Group: myGroup
5Bundle-Version: 0.1.0
6Import-Package: org.osgi.framework

All bundles with the same “Bundle-Group” value can be sopped by typing “stopgroup myGroup” in the equinox console.

In order to get the GroupCommandProvider working, you need a activator which registers a instance in the OSGi registry. It could look like this:

1public class Activator implements BundleActivator {
2   private CommandProvider commandProvider;
3 
4   public void start(BundleContext bctx) throws Exception {
5      commandProvider = new GroupCommandProvider(bctx);
6      bctx.registerService(CommandProvider.class.getName(), commandProvider, null);
7   }
8 
9   public void stop(BundleContext arg0) throws Exception {
10      commandProvider = null;
11   }
12}

In order to benefit from the GroupCommandProvider you probably will have to write methods to start, uninstall and update a group of bundles. In the method for starting a group of bundles you will have to differ between bundles which need to be started and those which don’t. I decided to extend the “Bundle-Group” field in the manifest file by a additional attribute. So it looks like this “Bundle-Group: myGroup;startable=true”. I think the _stopgroup() method clarifies the idea.

This solution doesn’t provide as much features as the PAR does, but it suites my needs. We will have to wait and see whether the OSGi will get some grouping capabilities in the future.