Launching and Embedding Felix

• Introduction
• Launching Felix
  • Standard Felix Launcher
  • Custom Felix Launcher
• Embedding Felix
  • Host/Felix Interaction
  • Providing Host Application Services
  • Using Services Provided by Bundles

Introduction

The Apache Felix OSGi framework is intended to be easily launchable and embeddable. For example, Felix avoids the use of system properties for configuration, since these are globals that can cause interference if multiple framework instances are created in the same VM. Felix is also implemented to multiplex singleton facilities, like the URL stream handler factory. The goal is to make it possible to use Felix in as many scenarios as possible; however, this is still just a goal. In other words, this is a work in progress and if any issues arise, it would be greatly appreciated if they are brought to the attention of the Felix community. The remainder of this document is divided into two main sections, one focusing on how to launch Felix and one focusing on how to embed Felix into a host application.

Launching Felix

Launching Felix is fairly simple and involves only three steps:

1. Defining some configuration properties.
2. Creating an instance of org.apache.felix.framework.Felix.
3. Invoking the org.apache.felix.framework.Felix.start() method with the configuration properties.

The only configuration properties that are actually required to start Felix are ones that tell it where/how to locate the bundle cache profile directory where installed bundles will be cached. Felix' bundle cache implementation allows you to configure the location where bundles are cached using configuration properties. At a minimum, either a bundle cache profile name or directory must be specified; see the bundle cache document for more detailed information on configuring the bundle cache.

Besides configuration properties for the bundle cache, it is usually necessary to set the org.osgi.framework.system.packages configuration property to export packages from the class path, such as the OSGi interface classes (e.g., org.osgi.framework) on which all bundles depend. If you are creating a launcher for Felix, then the felix.auto.start configuration property may also be used to automatically install and start various bundles; see the usage document for more information on configuring Felix and on the various configuration properties.

The remainder of this section describes how the standard Felix launcher works as well as how to create a custom launcher for Felix.

Standard Felix Launcher

The standard Felix launcher is very simple and is not intended to solve every possible requirement; it is intended to work for most standard situations. Most special launching requirements should likely create their own custom launcher. This section describes how the standard launcher works. The following code represents the complete main() method of the standard launcher, each numbered comment will be described in more detail below:

    public static void main(String[] argv) throws Exception
    {
        // (1) Load system properties.
        Main.loadSystemProperties();

        // (2) Read configuration properties.
        Properties configProps = Main.loadConfigProperties();

        // (3) Copy framework properties from the system properties.
        Main.copySystemProperties(configProps);

        // (4) See if the profile name property was specified.
        String profileName = configProps.getProperty(BundleCache.CACHE_PROFILE_PROP);

        // (4) See if the profile directory property was specified.
        String profileDirName = configProps.getProperty(BundleCache.CACHE_PROFILE_DIR_PROP);

        // Print welcome banner.
        System.out.println("\nWelcome to Felix.");
        System.out.println("=================\n");

        // (5) If no profile or profile directory is specified in the
        // properties, then ask for a profile name.
        if ((profileName == null) && (profileDirName == null))
        {
            System.out.print("Enter profile name: ");
            BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
            try
            {
                profileName = in.readLine();
            }
            catch (IOException ex)
            {
                System.err.println("Could not read input.");
                System.exit(-1);
            }
            System.out.println("");
            if (profileName.length() != 0)
            {
                configProps.setProperty(BundleCache.CACHE_PROFILE_PROP, profileName);
            }
        }

        // (6) A profile directory or name must be specified.
        if ((profileDirName == null) && (profileName.length() == 0))
        {
            System.err.println("You must specify a profile name or directory.");
            System.exit(-1);
        }

        try
        {
            // (7) Now create an instance of the framework.
            m_felix = new Felix();
            m_felix.start(
                new MutablePropertyResolverImpl(new StringMap(configProps, false)),
                null);
        }
        catch (Exception ex)
        {
            System.err.println("Could not create framework: " + ex);
            ex.printStackTrace();
            System.exit(-1);
        }
    }

The general steps of the standard launcher are quite straightforward:

1. Load any system properties specified in the system.properties file; this file is typically located in the conf/ directory of the Felix installation directory, but it can be specified directly using the felix.system.properties system property. This file is not needed to launch Felix and is provided merely for convenience when system properties must be specified. The file is a standard Java properties file, but it also supports property substitution using ${<property-name} syntax. Property substitution can be nested; only system properties will be used for substitution.
2. Load any configuration properties specified in the config.properties file; this file is typically located in the conf/ directory of the Felix installation directory, but it can be specified directly using the felix.config.properties system property. This file is used to configure the Felix instance created by the launcher. The file is a standard Java properties file, but it also supports property substitution using "${<property-name}" syntax. Property substitution can be nested; configuration and system properties will be used for substitution with configuration properties having precedence.
3. For convenience, any configuration properties that are set as system properties will be copied into the set of configuration properties to provide an easy way to add to or override configuration properties specified in the config.properties file.
4. Try to load the profile name or profile directory configuration properties. At least one of these must be specified so that the bundle cache knows where to save installed bundles.
5. If either the profile name or profile directory configuration property has not been specified, then ask the user to specify a profile name and add it to the current set of configuration properties.
6. Error if there is no profile name or profile directory.
7. Create the Felix instance and call start(), passing in the configuration properties.

The framework is not active until the start() method is called. If no shell bundles are specified in the config.properties file or if there is difficulty locating the shell bundles that are specified, then it will appear as if the framework is hung, but it is actually running without any way to interact with it since the shell bundles provide the only means of interaction.

Custom Felix Launcher

This section creates a bare-bones launcher to demonstrate the minimum requirements for creating an interactive launcher for the Felix framework. This example uses the standard Felix shell bundles for interactivity, but any other bundles could be used instead. For example, the shell service and telnet bundles could be used to lauch Felix and make it remotely accessible.

This example launcher project has the following directory structure:

launcher/
   lib/
      org.apache.felix.framework-0.8.0-SNAPSHOT.jar
      org.osgi.core-0.8.0-SNAPSHOT.jar
   bundle/
      org.apache.felix.shell-0.8.0-SNAPSHOT.jar
      org.apache.felix.shell.tui-0.8.0-SNAPSHOT.jar
   src/
      example/
         Main.java

The lib/ directory contains the JAR files for the framework as well as the OSGi interfaces. The bundle/ directory contains the shell service and textual shell interface bundles that will be used for interacting with the framework instance. Note: If you do not launch Felix with interactive bundles, it will appear as if the framework instance is hung, but it is actually just sitting there waiting for someone to tell it to do something. The src/example/ directory contains the following Main.java file, which is a very simplistic Felix launcher.

package example;

import java.util.Map;
import org.osgi.framework.Constants;
import org.apache.felix.framework.Felix;
import org.apache.felix.framework.cache.BundleCache;
import org.apache.felix.framework.util.MutablePropertyResolverImpl;
import org.apache.felix.framework.util.StringMap;
import org.apache.felix.framework.util.FelixConstants;

public class Main
{
    private static Felix m_felix = null;

    public static void main(String[] argv) throws Exception
    {
        // Print welcome banner.
        System.out.println("\nWelcome to Felix.");
        System.out.println("=================\n");

        Map configMap = new StringMap(false);
        configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES,
            "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(FelixConstants.AUTO_START_PROP + ".1",
            "file:bundle/org.apache.felix.shell-0.8.0-SNAPSHOT.jar " +
            "file:bundle/org.apache.felix.shell.tui-0.8.0-SNAPSHOT.jar");
        configMap.put(BundleCache.CACHE_PROFILE_DIR_PROP, "cache");

        try
        {
            // Now create an instance of the framework.
            m_felix = new Felix();
            m_felix.start(
                new MutablePropertyResolverImpl(configMap),
                null);
        }
        catch (Exception ex)
        {
            System.err.println("Could not create framework: " + ex);
            ex.printStackTrace();
            System.exit(-1);
        }
    }
}

This launcher has all information hard coded in it, unlike the default Felix launcher, which loads configuration properties from files and performs variable substitution. This simple launcher provides a good starting point if the features of the default launcher are not necessary. For example, if you want to create a launcher that automatically deletes the bundle cache directory each time it starts, then it is quite easy to figure out how to do that with this simple launcher.

By breaking down the above source code into small chunks, it is quite easy to see what is going on.

        Map configMap = new StringMap(false);

This simply creates a map to hold configuration properties where the keys are strings and lookups are case insensitive.

        configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES,
            "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");

This sets the Constants.FRAMEWORK_SYSTEMPACKAGES configuration property (string value "org.osgi.framework.system.packages"), which specifies the class path packages the system bundle should export; this is how classes on the class path are made available to bundles. This example only exports the core OSGi API packages, but other JRE packages could also be added, such as javax.swing. For example, the default Felix launcher defines properties for all packages in various JRE versions (e.g., 1.3.x, 1.4.x, 1.5.x) and appends them to this property using property substitution.

        configMap.put(FelixConstants.AUTO_START_PROP + ".1",
            "file:bundle/org.apache.felix.shell-0.8.0-SNAPSHOT.jar " +
            "file:bundle/org.apache.felix.shell.tui-0.8.0-SNAPSHOT.jar");

This sets the FelixConstants.AUTO_START_PROP configuration property (string value "felix.auto.start"), which is a space-delimited list of bundle URLs that the framework will automatically install and start when the framework starts. However, this property key cannot be used as is; it must be appended with a "." and then a number, where the number represents the start level for the bundle when it is installed. In this particular example, ".1" is appended to the property name, thus the two bundles will be installed into start level one. This example uses relative file: URLs, which will load the bundles from the bundle/ directory assuming that the launcher is started from the root directory of the launcher project. It is also possible to specify absolute URLs or remote URLs.

        configMap.put(BundleCache.CACHE_PROFILE_DIR_PROP, "cache");

This sets the last configuration property, BundleCache.CACHE_PROFILE_DIR_PROP (string value "felix.cache.profiledir"), which is a string that specifies the precise directory to be used as the bundle cache profile directory; the Felix bundle cache supports other properties to configure its behavior, but those are not covered here. In this example, the bundle cache profile directory is specified as a relative directory called "cache". Assuming that the launcher is executed from the root directory of the launcher project, then the bundle cache profile directory will be created in the root directory of the project.

            m_felix = new Felix();
            m_felix.start(
                new MutablePropertyResolverImpl(configMap),
                null);

The last steps create the framework instance and start it. The configuration property map is converted to an instance of a PropertyResolver before being passed into the Felix.start() method.

The following command compiles the launcher when run from the root directory of the launcher project:

javac -d . -classpath lib/org.apache.felix.framework-0.8.0-SNAPSHOT.jar:lib/org.osgi.core-0.8.0-SNAPSHOT.jar src/example/Main.java

After executing this command, an example/ directory is created in the current directory, which contains the generated class file. The following command executes the simple launcher when run from the root directory of the launcher project:

java -cp .:lib/org.apache.felix.framework-0.8.0-SNAPSHOT.jar:lib/org.osgi.core-0.8.0-SNAPSHOT.jar example.Main

After executing this command, a cache/ directory is created that contains the installed bundles, which were installed from the bundle/ directory.

Embedding Felix

Embedding Felix into a host application is a simple way to provide a sophisticated extensibility mechanism (i.e., plugin system) to the host application. Embedding Felix is very similar to launching Felix as described above, the main difference is that the host application typically wants to interact with the framework instance and/or installed bundles/services from the outside. This is fairly easy to achieve with Felix, but there are some subtle issues to understand. This section presents the mechanisms for embedding Felix into a host application and the issues in doing so.

Host/Felix Interaction

In the section on launching Felix above, the start() method was used to start a Felix framework instance executing. The start() method accepts two arguments, the first being the configuration properties for the framework, the second being a list of bundle activator instances. These bundle activator instances provide the foundation for how the host application interacts with the Felix framework.

Each bundle activator instance passed into the start() method effectively becomes part of the System Bundle. This means that the start()/stop() method of each bundle activator instance in the list gets invoked when the System Bundle's activator start()/stop() method gets invoked. Consequently, each bundle activator instance will be passed the system bundle's BundleContext object so that they can interact with the framework externally. Consider following snippet of a bundle activator:

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

    public void start(BundleContext context)
    {
        m_context = context;
    }

    public void stop(BundleContext context)
    {
        m_context = null;
    }

    public BundleContext getContext()
    {
        return m_context;
    }
}

Given the above bundle activator, it is now possible to embed Felix into a host application and interact with it as the following snippet illustrates:

public class HostApplication
{
    private HostActivator m_activator = null;
    private Felix m_felix = null;

    public HostApplication()
    {
        Map configMap = new StringMap(false);
        configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES,
            "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(BundleCache.CACHE_PROFILE_DIR_PROP, "cache");

        try
        {
            // Now create an instance of the framework.
            m_felix = new Felix();

            // Create host activator;
            m_activator = new HostActivator();

            // Now start Felix instance with our config properties
            // and activator.
            m_felix.start(
                new MutablePropertyResolverImpl(configMap),
                m_activator);
        }
        catch (Exception ex)
        {
            System.err.println("Could not create framework: " + ex);
            ex.printStackTrace();
        }
    }

    public Bundle[] getInstalledBundles()
    {
        // Use the system bundle activator to gain external
        // access to the set of installed bundles.
        return m_activator.getContext().getBundles();
    }
}

Notice how the HostApplication.getInstalledBundles() method uses its activator instance to get access to the System Bundle's context in order to interact with the embedded Felix framework instance. This approach provides the foundation for all interaction between the host application and the embedded framework instance.

Providing Host Application Services

to do

Using Services Provided by Bundles

to do