I think it was somewhere September 2006 when I first read about OSGi. Immediately I saw opportunities to finally come to my long envisioned Service Component Architecture. On top of that I could fix all these classloader issues as well. So good news. Together with Allard we started evaluating the possibilities of OSGi. We tried starting with spring osgi (I know the name has changed, but this is easier), but we were missing some basic knowledge. So back to the roots, use pure OSGi. Because we were using eclipse for a long time, we started using equinox. We even have given a presentation about OSGi in combination with webservice versioning at a dutch java user conference. Because I wanted to use maven and since I am programming with IntelliJ nowadays I was looking for other options. That is when I got back to felix, which has become a very interesting project. After this long introduction it is time to start explaining what this post is all about. With this post I want to share my first steps with apache felix. Watch out for all other posts about the OSGi felix exploration.

First a general idea about the thing we are going to create and the steps to take.

  1. Start a felix instance using java code and interact with the OSGi context from outside
  2. Create bundles using maven 2
  3. Create a service that is exposed as a bundle
  4. Create a simple client

In other posts I want to look at more enterprise possibilities, like exposing using the web, etc. Most of the knowledge I gained for this article I took from the felix website. There are some nice pages about creating bundles, using services, registering listeners. Check their OSGi pages.

Embed the OSGi container in your application

This section is about starting felix from your code and interact with the OSGi context. I am not going to discuss the complete configuration options, I’ll focus on the most easiest possible way to make it work. You can find detailed information on this page. When initializing the felix container you must provide the configuration properties and the activators for the container. Felix provides a special implementation of a TreeMap called the org.apache.felix.framework.util.StringMap. This is a map created to work purely with spring comparison. The following piece of code shows the code for creating the map.

Map<String,String> configMap = new StringMap(false);
configMap.put(FelixConstants.EMBEDDED_EXECUTION_PROP, "true");
    "org.osgi.framework; version=1.3.0," +
    "org.osgi.service.packageadmin; version=1.2.0," +
    "org.osgi.service.startlevel; version=1.0.0," +
    "org.osgi.service.url; version=1.0.0");
configMap.put(AutoActivator.AUTO_START_PROP + ".1",
    "file:" + PATH_TO_MAVEN_REPO + "service-listener-1.0-SNAPSHOT.jar " +
    "file:" + PATH_TO_MAVEN_REPO + "training-service-1.0-SNAPSHOT.jar " +
    "file:" + PATH_TO_MAVEN_REPO + "example-client-1.0-SNAPSHOT.jar " +
    "file:bundle/org.apache.felix.shell-1.0.0.jar " +
    "file:bundle/org.apache.felix.shell.tui-1.0.0.jar ");
configMap.put(BundleCache.CACHE_PROFILE_DIR_PROP, "cache");

There are four part in this configuration:

  1. System packages that are exported by the framework to become available to other bundles
  2. Embedded execution, only used when you embed the Felix container in another java application
  3. AutoActivator, used to install bundles right after starting the container
  4. Bundle cache, where to place the cached bundles

As you can see we install 5 bundles, three of my own that I am going to use in the application and two as provided by the felix framework. The next few lines of code show you how to actually start the felix instance. We create a list of activators that are installed during the context initialization. A special activator is the AutoActivator. This is configured in the properties object as stated above. There we have configured the AutoActivator as well.

List activators = new ArrayList();
activators.add(new AutoActivator(configMap));
activator = new HostActivator();
felix = new Felix(configMap, activators);
try {
} catch (BundleException e) {
    System.err.println("Could not create framework: " + e);

If you look at the code you can see we initialize another activator as well. This is the HostActivator. An interesting way to create a hook in the felix container from a class outside of the application. The following piece of code shows this special activator. Check the method getBundles, this method returns a reference to all available bundles. The launcher has access to this class and can therefore call the activator while not actually being part of the felix container.

public class HostActivator implements BundleActivator {
    private BundleContext context = null;

    public void start(BundleContext bundleContext) throws Exception {
        context = bundleContext;

    public void stop(BundleContext bundleContext) throws Exception {
        context = null;

    public Bundle[] getBundles() {
        Bundle[] bundles = null;
        if (context != null) {
            bundles = context.getBundles();
        return bundles;

You can have a look at the complete sources online at the google code website:

http://code.google.com/p/gridshore/source/browse – check the FelixTryout project.

This is a first step in a number of steps I am going to post. The next step will be about using maven to create a new OSGi bundle.

Powered by Qumana

Starting with OSGi using apache felix (step 1)
Tagged on: