Apache Felix Framework Launching and Embedding

...

[This document describes framework launching introduced in Felix Framework 2.0.0 and continuing with the latest releases; it is incompatible with older versions of the Felix framework.]

• Introduction
• OSGi Launching and Embedding API Overview
  • Creating and Configuring the Framework Instance
  • Starting the Framework Instance
  • Stopping the Framework Instance
• Launching Felix
  • Standard Felix Launcher
  • Custom Felix Launcher
• Embedding Felix
  Embedded Execution Configuration Property
  • Host/Felix Interaction
  • Providing Host Application Services
  • Using Services Provided by Bundles
    • Using Bundle Services via Reflection
    • Other Approaches
• Caveat
• Feedback

Anchor
introduction introduction

Introduction

The Apache Felix OSGi framework Framework is intended to be easily launchable and embeddable. For example, the Felix framework implementation avoids the use of system properties for configuration, since these are globals that and can cause interference if multiple framework instances are created in the same VM. Felix is The framework also implemented tries 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 possiblethe framework in a variety of scenarios; 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 next section provides a Felix API overviewan overview of the standard OSGi launching and embedding API for frameworks, while the remainder of the document is divided into two sections, one focusing on how to launch Felix and one focusing on how to embed Felix into a host application.

OSGi Launching and Embedding API Overview

The Felix class that implements the OSGi framework is implemented by the org.apache.felix.framework.Felix class or just Felix for short. The As part of the R4.2 OSGi specification defines a special bundle, called the System Bundle, that represents the framework at run time and appears like any other bundle in the list of installed bundles. To make this notion even more intuitive, the Felix class implements the launching and embedding API of the OSGi framework has been standardized. The approach is to have the framework implement the org.osgi.framework.Bundlelaunch.Framework interface, which is reiterated here:extends the org.osgi.framework.Bundle interface. These interfaces provide the necessary means to launch and manage framework instances. The Bundle interface is defined as:

public interface Bundle
{
   

public interface Bundle
{
    public BundleContext getBundleContext();
    public long getBundleId();
    public URL getEntry(String name);
    public Enumeration getEntryPaths(String path);
    public Enumeration findEntries(String path, String filePattern, boolean recurse);
    public Dictionary getHeaders();
    public Dictionary getHeaders(String locale);
    public long getLastModified();
    public String getLocation();
    public URL getResource(String name);
    public Enumeration getResources(String name) throws IOException;
    public ServiceReference[] getRegisteredServices();
    public ServiceReference[] getServicesInUse();
    public int getState();
    public String getSymbolicName();
    publicVersion getVersion();
    boolean hasPermission(Object obj);
    public Class loadClass(String name) throws ClassNotFoundException;
    public void start() throws BundleException;
    public void stop() throws BundleException;
    public void uninstall() throws BundleException;
    public void update() throws BundleException;
    public void update(InputStream is) throws BundleException;
}

When you instantiate the Felix class, the resulting object is actually the System Bundle and can be cast to the Bundle interface. The start() method is used to start the framework instance, while the stop() method is used to asynchronously stop the framework instance. The Felix class also includes the following two additional public methodsThe Framework interface is defined as:

public classinterface FelixFramework extends AbstractBundleBundle
{
    publicvoid Felix(MutablePropertyResolver configMutable, List activatorList);
    public void stopAndWait(init();
    FrameworkEvent waitForStop(long timeout);
}

To actually construct a framework instance, the R4.2 specification defines the FrameworkFactory interface:

public interface FrameworkFactory
{
    Framework newFramework(Map config);
}

The first method is the constructor used to instantiate framework instances; the constructor accepts configuration properties and System Bundle activators, which are both described in more detail later. The stopAndWait() method is a synchronous version of the stop() method, used to stop the framework and block the calling thread until the framework is completely stopped. Anchorlaunchinglaunching

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 with the configuration properties.
3. Invoking the org.apache.felix.framework.Felix.start() method.

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.

...

framework factory can be used to create configured framework instances. It is obtained following the standard META-INF/services approach.

Creating and Configuring the Framework Instance

You use the framework factory to construct and configure a framework instance (or by directly instantiating the Felix class). The configuration map may contain any of the framework configuration properties listed in the Apache Felix Framework Configuration Properties document, not the launcher configuration properties. The configuration map is copied and the keys are treated as case insensitive. You are not able to change the framework's configuration after construction. If you need a different configuration, you must create a new framework instance.

Starting the Framework Instance

The start() method is used to start the framework instance. If the init() method was not invoked prior to calling start(), then it is invoked by start(). The two methods result in two different framework state transitions:

• init() results in the framework instance in the Bundle.STARTING state.
• start() results in the framework instance in the Bundle.ACTIVE state.

The init() method is necessary since the framework does not have a BundleContext when it is first created, so a transition to the Bundle.STARTING state is required to acquire its context (via Bundle.getBundleContext()) for performing various tasks, such as installing bundles. Note that the Felix framework also provides the felix.systembundle.activators property that serves a similar purpose, but is not standard. After the init() method completes, the follow actions have been performed:

• Event handling is enabled.
• The security manager is installed if it is enabled.
• The framework is set to start level 0.
• All bundles in the bundle caches are reified and their state is set to Bundle.INSTALLED.
• The framework gets a valid BundleContext.
• All framework-provided services are made available (e.g., PackageAdmin, StartLevel, etc.).
• The framework enters the Bundle.STARTING state.

A call to start() is necessary to start the framework instance, if the init() method is invoked manually. Invoking init() or start() on an already started framework as no effect.

Stopping the Framework Instance

To stop the framework instance, invoke the stop() method, which will asynchronously stop the framework. To know when the framework has finished its shutdown sequence, use the waitForStop() method to wait until it is complete. A stopped framework will be in the Bundle.RESOLVED state. It is possible to restart the framework, using the normal combination of init()/start() methods as previously described.

Launching a Framework

Launching a framework is fairly simple and involves only four steps:

1. Define some configuration properties.
2. Obtain framework factory.
3. Use factory to create framework with the configuration properties.
4. Invoke the Framework.start() method.

In reality, the first step is optional, since all properties will have reasonable defaults, but if you are creating a launcher you will generally want to more than that, such as automatically installing and starting bundles when you start the framework instance. The default Felix launcher defines reusable functionality to automatically install and/or start bundles upon framework startup; see the usage document for more information on configuring the Felix framework 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.

Standard Felix Framework Launcher

The standard Felix framework 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 be resolved by creating a 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[] args) throws Exception
{

...

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 be resolved by creating a 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");

    // (51) IfCheck nofor profilecommand orline profilearguments directory is specified in theand verify usage.
    String bundleDir = null;
    // properties, then ask for a profile name.String cacheDir = null;
    boolean expectBundleDir = false;
    iffor ((profileNameint i == null) && (profileDirName == null)0; i < args.length; i++)
    {
        System.out.print("Enter profile name: ");
if (args[i].equals(BUNDLE_DIR_SWITCH))
        {
    BufferedReader in = new BufferedReader(new InputStreamReader(System.in))     expectBundleDir = true;
        try}
        {else if (expectBundleDir)
        {
    profileName = in.readLine();
      bundleDir = }args[i];
        catch (IOException ex)    expectBundleDir = false;
        {}
        else
     System.err.println("Could not read input.");{
            System.exit(-1)cacheDir = args[i];
        }
    }

    System.out.println("");
        if (profileName.length() != 0)
    if ((args.length > 3) || (expectBundleDir && bundleDir == null))
    {
        System.out.println("Usage: [-b   configProps.setProperty(BundleCache.CACHE_PROFILE_PROP, profileName<bundle-deploy-dir>] [<bundle-cache-dir>]");
        }System.exit(0);
    }

    // (62) ALoad profile directory or name must be specifiedsystem properties.
    if ((profileDirName == null) && (profileName.length()Main.loadSystemProperties();

    // (3) Read configuration properties.
    Properties configProps = Main.loadConfigProperties();
    if (configProps == 0null))
    {
        System.err.println("YouNo must" specify a profile name or directory+ CONFIG_PROPERTIES_FILE_VALUE + " found.");
        configProps  System.exit(-1= new Properties();
    }

    try
    {
    // (4) Copy framework properties from the system properties.
    // (7) Now create an instance of the framework.Main.copySystemProperties(configProps);
        
        m_felix = new Felix(
       // (5) Use the specified auto-deploy directory over default.
    if new MutablePropertyResolverImpl(
bundleDir != null)
    {
          new StringMap(configProps, false)),configProps.setProperty(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY, bundleDir);
    }

    // (6) Use the specified null);
bundle cache directory over default.
    m_felix.start();if (cacheDir != null)
    }{
    catch (Exception ex)    configProps.setProperty(Constants.FRAMEWORK_STORAGE, cacheDir);
    {}

    // (7) Add  System.err.println("Could not create framework: " + ex);a shutdown hook to clean stop the framework.
    String enableHook =  exconfigProps.printStackTracegetProperty(SHUTDOWN_HOOK_PROP);
    if ((enableHook ==  System.exit(-1);null) || !enableHook.equalsIgnoreCase("false"))
    }
}

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 passing in the configuration properties and then call start().

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 launch Felix and make it remotely accessible.

This example launcher project has the following directory structure:

launcher/
   lib/
      org.apache.felix.framework-1.0.0.jar
   bundle/
      org.apache.felix.shell-1.0.0.jar
      org.apache.felix.shell.tui-1.0.0.jar
   src/
      example/{
        Runtime.getRuntime().addShutdownHook(new Thread("Felix Shutdown Hook") {
            public void run()
            {
                try
                {
                    if (m_fwk != null)
                    {
                        m_fwk.stop();
                        m_fwk.waitForStop(0);
                    }
                }
                catch (Exception ex)
                {
                    System.err.println("Error stopping framework: " + ex);
                }
            }
        });
    }

    try
    {
        // (8) Create an instance and initialize the framework.
        FrameworkFactory factory = getFrameworkFactory();
        m_fwk = factory.newFramework(configProps);
        m_fwk.init();
        // (9) Use the system bundle context to process the auto-deploy
        // and auto-install/auto-start properties.
        AutoProcessor.process(configProps, m_fwk.getBundleContext());
        // (10) Start the framework.
        m_fwk.start();
        // (11) Wait for framework to stop to exit the VM.
        m_fwk.waitForStop(0);
         Main.java

The lib/ directory contains the framework JAR file, which also contains the OSGi core 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.

System.exit(0);
    }
    catch (Exception ex)
    {
        System.err.println("Could not create framework: " + ex);
        ex.printStackTrace();
        System.exit(0);
    }
}

The general steps of the standard launcher are quite straightforward:

1. The launcher supports setting the auto-deploy directory (with the -b switch) and setting the bundle cache path with a single argument, so check for this and issue a usage message it there are more than one arguments.
2. 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.
3. 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 framework 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.
4. For convenience, any configuration properties that are set as system properties are copied into the set of configuration properties. This provide an easy way to add to or override configuration properties specified in the config.properties file, since the Felix instance will never look at system properties for configuration.
5. If the -b switch was used to specify an auto-deploy directory, then use that to set the value of felix.auto.deploy.dir.
6. If a single command-line argument is specified, then use that to set the value of org.osgi.framework.storage; relative paths are relative to the current directory unless the felix.cache.rootdir property is set.
7. Add a shutdown hook to cleanly stop the framework, unless the hook is disabled.
8. Create a framework instance using the FrameworkFactory passing in the configuration properties, then initialize the factory instance; see the custom launcher example below to see how the META-INF/services FrameworkFactory is obtained.
9. Use org.apache.felix.main.AutoProcessor, which will automatically deploy any bundles in the auto-deploy directory as well as bundles specified in the felix.auto.install and felix.auto.start configuration properties during framework startup to automatically install and/or start bundles; see the usage document for more information configuration properties and bundle auto-deploy.
10. Invoke waitForStop() to wait for the framework to stop to force the VM to exit; this is necessary because the framework never calls System.exit() and some libraries (e.g., Swing) create threads that will not allow the VM to exit.

The framework is not active until the start() method is called. If no shell bundles are installed and started or if there is difficulty locating the shell bundles specified in the auto-start property, 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 Framework 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 Gogo shell bundles for interactivity, but any other bundles could be used instead. This example launcher project has the following directory structure:

launcher/
   lib/
      org.apache.felix.main-3.0.0.jar
   bundle/
      org.apache.felix.gogo.command-0.6.0.jar
      org.apache.felix.gogo.runtime-0.6.0.jar
      org.apache.felix.gogo.shell-0.6.0.jar
   src/
      example/

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-1.0.0.jar " +
            "file:bundle/org.apache.felix.shell.tui-1.0.0.jar");
        configMap.put(BundleCache.CACHE_PROFILE_DIR_PROP, "cache");

        try
        {
            // Now create an instance of the framework.
            m_felix = new Felix(
                new MutablePropertyResolverImpl(configMap),
                null);
            m_felix.start();
        }
        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.

 Main.java

The lib/ directory contains Felix' main JAR file, which also contains the OSGi core interfaces. The main JAR file is used so that we can reuse the default launcher's auto-install/auto-start configuration property handling; if these capabilities are not needed, then it would be possible to use the framework JAR file instead of the main JAR file. 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 the framework 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 framework launcher.

package example;

import java.io.*;
import org.osgi.framework.launch.*;
import org.apache.felix.main.AutoProcessor;

public class Main
{
    private static Framework m_fwk = null;

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

        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.

System.out.println("======================\n");

        try
        {
            m_fwk = getFrameworkFactory().newFramework(null);
            configMapm_fwk.put(FelixConstants.AUTO_START_PROP + ".1",init();
            AutoProcessor.process(null, m_fwk.getBundleContext());
            "file:bundle/org.apache.felix.shell-1.0.0.jar " +m_fwk.start();
            "file:bundle/org.apache.felix.shell.tui-1.0.0.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_fwk.waitForStop(0);
            System.exit(0);
        }
        catch (Exception ex)
        {
            System.err.println("Could not create framework: " + ex);
            ex.printStackTrace();
            System.exit(-1);
        }
    }

    private static FrameworkFactory getFrameworkFactory() throws Exception
    {
        java.net.URL url = Main.class.getClassLoader().getResource(
            "META-INF/services/org.osgi.framework.launch.FrameworkFactory");
        if (url != null)
          m_felix = new Felix({
            BufferedReader br = new BufferedReader(new MutablePropertyResolverImpl(configMap),
InputStreamReader(url.openStream()));
            try
      null);
      {
             m_felix.start();

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 constructor.

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

javac -d . -classpath lib/org.apache.felix.framework-1.0.0.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-1.0.0.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.

...

   for (String s = br.readLine(); s != null; s = br.readLine())
                {
                    s = s.trim();
                    // Try to load first non-empty, non-commented line.
                    if ((s.length() > 0) && (s.charAt(0) != '#'))
                    {
                        return (FrameworkFactory) Class.forName(s).newInstance();
                    }
                }
            }
            finally
            {
                if (br != null) br.close();
            }
        }

        throw new Exception("Could not find framework factory.");
    }
}

This launcher relies on the default behavior of AutoProcessor to automatically deploy the shell bundles. This simple, generic launcher provides a good starting point if the default Felix launcher is not sufficient. Since very few configuration properties are specified, the default values are used. For the bundle auto-deploy directory, "bundle" in the current directory is used, while for the framework bundle cache, "felix-cache" in the current directory is used.

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

            m_fwk = getFrameworkFactory().newFramework(null);
            m_fwk.init()

These steps get a the framework factory service and use it to create a framework instance with a default configuration. Once the framework instance is created, it is initialized with init().

            AutoProcessor.process(null, m_fwk.getBundleContext());

The AutorProcessor will automatically deploy bundles in the auto-deploy directory and any referenced from the auto-install/start properties. Since we are using an empty configuration, the auto-deploy directory is the bundle directory in the current directory and there are no auto properties. Therefore, in this case, the shell bundles will be installed.

            m_fwk.start();
            m_fwk.waitForStop(0);

...

Embedded Execution Configuration Property

When a Felix instance is embedded in a host application, the host application must inform the Felix instance that it is embedded. To do this, the host application sets the "felix.embedded.execution" configuration property to "true"; this can be accomplished in the same way that all configuration properties are set, i.e., passing it into the Felix constructor via a property resolver. This property specifically controls whether or not the Felix instance will shutdown the JVM (i.e., call System.exit() when the framework is shutdown. When embedding Felix it is generally not desirable for Felix to shutdown the JVM; therefore, by setting this property to "true" it can be avoided.

...

Host/Felix Interaction

In the section on launching Felix above, the Felix constructor 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 a convenient way for host applications to interact with the Felix framework.

Each bundle activator instance passed into the constructor effectively becomes part of the System Bundle. This means that the start()/stop() method of each bundle activator instance in the passed in list gets invoked when the System Bundle's activator start()/stop() method gets invoked. Consequently, each bundle activator instance will be given the system bundle's BundleContext object so that they can interact with the framework externally. While it is possible to get the System Bundle's BundleContext object directly by calling Felix.getBundleContext(), this is generally not as convenient since it requires that you monitor when the System Bundle starts and/or stops. 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;
    }
System.exit(0);

These final steps start the framework and cause the launching application thread to wait for the framework to stop and when it does the launching thread calls System.exit() to make sure the VM actually exits.

    publicprivate static voidFrameworkFactory stopgetFrameworkFactory(BundleContext context)) throws Exception
    {
        m_context = null;...
    }

    public Bundle[] getBundles()
    {
        if (m_context != null)
        {
            return m_context.getBundles();
        }
        return null;
    }
}

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:

This method retrieves the framework factory service by doing a META-INF/services resource lookup, which it can use to obtain the concrete class name for the factory. If you are using Java 6, then you can use the ServiceLoader API in the JRE to further simplify the factory service lookup.

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

javac -d . -classpath lib/org.apache.felix.main-3.0.0.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.main-3.0.0.jar example.Main

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

Embedding the Felix Framework

Embedding the Felix framework into a host application is a simple way to provide a sophisticated extensibility mechanism (i.e., a plugin system) to the host application. Embedding the Felix framework is very similar to launching it 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, 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 the framework above, the Felix class accepts a configuration property called felix.systembundle.activators, which is a list of bundle activator instances. These bundle activator instances provide a convenient way for host applications to interact with the Felix framework.

Each activator instance passed into the constructor effectively becomes part of the system bundle. This means that the start()/stop() methods of each activator instance in the list gets invoked when the system bundle's activator start()/stop() methods gets invoked, respectively. Each activator instance will be given the system bundle's BundleContext object so that they can interact with the framework. 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 Bundle[] getBundles()
    

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

    public HostApplication()
    {
        // Create a case-insensitive configuration property map.
        Map configMap = new StringMap(false);
        // Configure the Felix instance to be embedded.
        configMap.put(FelixConstants.EMBEDDED_EXECUTION_PROP, "true");
        // Add core OSGi packages to be exported from the class path
        // via the system bundle.
        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");
        // Explicitly specify the directory to use for caching bundles.
        configMap.put(BundleCache.CACHE_PROFILE_DIR_PROP, "cache");

        try
        {
            // Create host activator;
            m_activator = new HostActivator();
            List list = new ArrayList();
            list.add(m_activator);

            // Now create an instance of the framework with
            // our configuration properties and activator.
            m_felix = new Felix(
                new MutablePropertyResolverImpl(configMap),
                list);

            // Now start Felix instance.
            m_felix.start();
        }
        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.getBundles();
    }

    public void shutdownApplication()
    {
        // Shut down the felix framework when stopping the
        // host application.
        m_felix.shutdown();
    }
}

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.

...

if (m_context != null)
        {
            return m_context.getBundles();
        }
        return null;
    }
}

Given the above bundle activator, it is now possible to embed the Felix framework 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()
    {
        // Create a configuration property map.
        Map config = new HashMap();
        // Create host activator;
        m_activator = new HostActivator();
        List list = new ArrayList();
        list.add(m_activator);
        configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);

...

Providing Host Application Services

Providing services from the host application to bundles inside the embedded Felix framework instance follows the basic approach laid out in above. The main complication for providing a host application service to bundles is the fact that both the host application and the bundles must be using the same class definitions for the service interface classes. Since the host application cannot import classes from a bundle, this means that the service interface classes must be accessible on the class path, typically as part of the host application itself. The host application then must export the service interface package via the system bundle so that bundles installed into the embedded framework instance can import it. This is achieved using the org.osgi.framework.system.packages configuration property previously presented.

Consider the follow simple property lookup service:

package host.service.lookup;

public class Lookup
{
    public Object lookup(String name);
}

This package is simply part of the host application, which is potentially packaged into a JAR file and started with the "java -jar" command. Now consider the following host application bundle activator, which will be used to register/unregister the property lookup service when the embedded framework instance starts/stops:

package host.core;

import java.util.Map;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.ServiceRegistration;
import host.service.lookup;

public class HostActivator implements BundleActivator
{
    private Map m_lookupMap = null;
    private BundleContext m_context = null;
    private ServiceRegistration m_registration = null;

    public HostActivator(Map lookupMap)
    {
        //try
 Save a reference to the service's backing store.{
        m_lookupMap = lookupMap;
  // Now }

create an instance of publicthe void start(BundleContext context)framework with
    {
        // Saveour aconfiguration reference to the bundle context.
properties.
            m_contextfelix = contextnew Felix(config);
            // CreateNow astart property lookup service implementationFelix instance.
        Lookup lookup = new Lookupm_felix.start();
 {
       }
       public Objectcatch lookup(StringException nameex)
        {
    {
        System.err.println("Could not create framework: " + ex);
  return m_lookupMap.get(name          ex.printStackTrace();
        }
    }

    public Bundle[] getInstalledBundles()
        };{
        // RegisterUse the propertysystem bundle lookupactivator serviceto andgain saveexternal
        // access to the set of serviceinstalled registrationbundles.
        m_registrationreturn = m_contextactivator.registerServicegetBundles();
    }

    public void shutdownApplication()
  Lookup.class.getName(), lookup, null);{
    }

    public void stop(BundleContext context)
    {// Shut down the felix framework when stopping the
        // Unregister the property lookup servicehost application.
        m_registrationfelix.unregisterstop();
        m_context = nullfelix.waitForStop(0);
    }
}

Given the above host application bundle activator, the following code snippet shows how the host application could create an embedded version of the Felix framework and provide the property lookup service to installed bundles:

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

Providing services from the host application to bundles inside the embedded Felix framework instance follows the basic approach laid out in above. The main complication for providing a host application service to bundles is the fact that both the host application and the bundles must be using the same class definitions for the service interface classes. Since the host application cannot import classes from a bundle, this means that the service interface classes must be accessible on the class path, typically as part of the host application itself. The host application then must export the service interface package via the system bundle so that bundles installed into the embedded framework instance can import it. This is achieved using the org.osgi.framework.system.packages.extra configuration property previously presented.

Consider the follow simple property lookup service:

package host.service.lookup;

public interface Lookup
{
    public Object lookup(String name);
}

This package is simply part of the host application, which is potentially packaged into a JAR file and started with the "java -jar" command. Now consider the following host application bundle activator, which will be used to register/unregister the property lookup service when the embedded framework instance starts/stops:

package host.core;

import java.util.Map;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.ServiceRegistration;
import host.service.lookup;

public class HostActivator implements BundleActivator
{
    private Map m_lookupMap = null;
    private BundleContext m_context = null;
    private ServiceRegistration m_registration = null;

    public HostActivator(Map lookupMap)
    {

package host.core;

import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.util.HashMap;
import host.service.lookup.Lookup;
import org.apache.felix.framework.Felix;
import org.apache.felix.framework.util.FelixConstants;
import org.apache.felix.framework.util.StringMap;
import org.apache.felix.framework.util.MutablePropertyResolverImpl;
import org.apache.felix.framework.cache.BundleCache;

public class HostApplication
{
    private HostActivator m_activator = null;
    private Felix m_felix = null;
    private Map m_lookupMap = new HashMap();

    public HostApplication()
    {
        // Initialize the map for the property lookup service.
        m_lookupMap.put("name1", "value1");
        m_lookupMap.put("name2", "value2");
        m_lookupMap.put("name3", "value3");
        m_lookupMap.put("name4", "value4");

        // Create a case-insensitive configuration property mapSave a reference to the service's backing store.
        Mapm_lookupMap configMap = new StringMap(false)lookupMap;
    }

    //public Configurevoid the Felix instance to be embedded.start(BundleContext context)
    {
        configMap.put(FelixConstants.EMBEDDED_EXECUTION_PROP, "true");
        // Add the host provided service interface package and the core OSGi// Save a reference to the bundle context.
        m_context = context;
        // packages to be exported from the class path via the system bundle.
Create a property lookup service implementation.
        Lookup lookup = new configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES,
Lookup() {
             "org.osgi.framework; version=1.3.0," +
public Object lookup(String name)
            {
   "org.osgi.service.packageadmin; version=1.2.0," +
           return "org.osgi.service.startlevel; version=1.0.0," +
m_lookupMap.get(name);
            }
      "org.osgi.service.url; version=1.0.0," + };
        // Register the property lookup "host.service.lookup; version=1.0.0");service and save
        // Explicitly specify the directory to use for caching bundles. the service registration.
        m_registration = m_context.registerService(
        configMap.put(BundleCache.CACHE_PROFILE_DIR_PROP, "cache"    Lookup.class.getName(), lookup, null);

    }

    try
public void stop(BundleContext context)
     {
        // Unregister the property lookup service.
 // Create host activator;
    m_registration.unregister();
        m_activatorcontext = new HostActivator(m_lookupMap);
            List list = new ArrayList();
            list.add(m_activator);

            // Now create an instance of the framework with
            // our configuration properties and activator.
            m_felix = new Felix(
                new MutablePropertyResolverImpl(configMap),
    null;
    }
}

Given the above host application bundle activator, the following code snippet shows how the host application could create an embedded version of the Felix framework and provide the property lookup service to installed bundles:

package host.core;

import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.util.HashMap;
import host.service.lookup.Lookup;
import org.apache.felix.framework.Felix;
import org.apache.felix.framework.util.FelixConstants;
import org.osgi.framework.Constants;

public class HostApplication
{
    private HostActivator m_activator = null;
    private Felix m_felix = null;
    private Map m_lookupMap = new HashMap();

    public HostApplication()
    {
            list);

        // Initialize the map for the property lookup service.
    // Now start Felix instance.
    m_lookupMap.put("name1", "value1");

        m_felixlookupMap.start(put("name2", "value2");
        }m_lookupMap.put("name3", "value3");
        catch (Exception ex)
m_lookupMap.put("name4", "value4");

        {
// Create a configuration property  map.
      System.err.println("Could not createMap framework:configMap "= +new exHashMap();
        // Export the  ex.printStackTrace();host provided service interface package.
        }configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
    }

    public void shutdownApplication()
    {"host.service.lookup; version=1.0.0");
        // ShutCreate downhost theactivator;
 felix framework when stopping the
   m_activator =    // host application.
new HostActivator(m_lookupMap);
        List list  m_felix.shutdown= new ArrayList();
       }
}

Rather than having the host application bundle activator register the service, it is also possible for the the host application to simply get the bundle context from the bundle activator and register the service directly, but the presented approach is perhaps a little cleaner since it allows the host application to register/unregister the service when the system bundle starts/stops.

...

Using Services Provided by Bundles

Using services provided by bundles follows the same general approach of using a host application bundle activator. The main complication for the host application using a service from a bundle is the fact that both the host application and the bundle must be using the same class definitions for the service interface classes. Since the host application cannot import classes from a bundle, this means that the service interface classes must be accessible on the class path, typically as part of the host application itself. The host application then must export the service interface package via the system bundle so that bundles installed into the embedded framework instance can import it. This is achieved using the org.osgi.framework.system.packages configuration property previously presented.

Consider the following simple command service interface for which bundles provide implementations, such as might be used to create an extensible interactive shell:

package host.service.command;

public class Command
{
    public String getName();
    public String getDescription();
    public boolean execute(String commandline);
}

This package is simply part of the host application, which is potentially packaged into a JAR file and started with the "java -jar" command. Now consider the previously introduced host application bundle activator below, which simply provides access to the system bundle context:

package host.core;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

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

    public void start(BundleContext context)
    {
        m_context = context; list.add(m_activator);
        configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);

        try
        {
            // Now create an instance of the framework with
            // our configuration properties.
            m_felix = new Felix(configMap);
            // Now start Felix instance.
            m_felix.start();
        }
        catch (Exception ex)
        {
            System.err.println("Could not create framework: " + ex);
            ex.printStackTrace();
        }
    }

    public void stopshutdownApplication(BundleContext context)
    {
        m_context = null;
// Shut down the felix framework when stopping the
       }

   // host application.
  public BundleContext getContext()
    {m_felix.stop();
        return m_contextfelix.waitForStop(0);
    }
}

Rather than having the host application bundle activator register the service, it is also possible for the the host application to simply get the bundle context from the bundle activator and register the service directly, but the presented approach is perhaps a little cleaner since it allows the host application to register/unregister the service when the system bundle starts/stops.

Using Services Provided by Bundles

Using services provided by bundles follows the same general approach of using a host application bundle activator. The main complication for the host application using a service from a bundle is the fact that both the host application and the bundle must be using the same class definitions for the service interface classes. Since the host application cannot import classes from a bundle, this means that the service interface classes must be accessible on the class path, typically as part of the host application itself. The host application then must export the service interface package via the system bundle so that bundles installed into the embedded framework instance can import it. This is achieved using the org.osgi.framework.system.packages.extra configuration property previously presented.

Consider the following simple command service interface for which bundles provide implementations, such as might be used to create an extensible interactive shellWith this bundle activator, the host application can command services provided by bundles installed inside its embedded Felix framework instance. The following code snippet illustrates one possible approach:

package host.service.corecommand;

public class Command
{
    public String getName();
    public String getDescription();
    public boolean execute(String commandline);
}

This package is simply part of the host application, which is potentially packaged into a JAR file and started with the "java -jar" command. Now consider the previously introduced host application bundle activator below, which simply provides access to the system bundle context:

package host.core;

import org.osgi.framework.BundleActivatorimport java.util.Map;
import host.service.command.Command;
import org.apache.felix.framework.Felix;
import org.apache.felix.framework.util.FelixConstants;
import org.apache.felix.framework.util.StringMap;
import org.apache.felix.framework.util.MutablePropertyResolverImpl;
import org.apache.felix.framework.cache.BundleCache;
import org.osgi.utilframework.tracker.ServiceTrackerBundleContext;

public class HostApplication
{
    private HostActivator m_activator = null;
    private Felix m_felix = null;implements BundleActivator
{
    private ServiceTrackerBundleContext m_trackercontext = null;

    public HostApplication(void start(BundleContext context)
    {
        // Create a case-insensitive configuration property map.m_context = context;
    }

    public void   Map configMap = new StringMap(false);stop(BundleContext context)
    {
    //  Configure the Felixm_context instance= tonull;
 be embedded.
  }

    public BundleContext configMap.put(FelixConstants.EMBEDDED_EXECUTION_PROP, "true");getContext()
    {
    // Add the bundle return m_context;
    }
}

With this bundle activator, the host application can use command services provided by bundles installed inside its embedded Felix framework instance. The following code snippet illustrates one possible approach:

package host.core;

import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import host.service.command.Command;
import org.apache.felix.framework.Felix;
import org.apache.felix.framework.util.FelixConstants;
import org.apache.felix.framework.cache.BundleCache;
import org.osgi.framework.Constants;
import org.osgi.util.tracker.ServiceTracker;

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

    public HostApplication()
    {provided service interface package and the core OSGi
        // packages to be exported from the class path via the system bundle.
        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," +
        // Create a  "host.service.command; version=1.0.0");
configuration property map.
        Map //configMap Explicitly= specify the directory to use for caching bundles.
        configMap.put(BundleCache.CACHE_PROFILE_DIR_PROP, "cache");
new HashMap();
        // Export the host provided service interface package.
        tryconfigMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
        {
    "host.service.command; version=1.0.0");
        // Create host activator;
            m_activator = new HostActivator(m_lookupMap);
            List list = new ArrayList();
            list.add(m_activator);

        configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);

   // Now create an instance of the framework with try
            // our configuration properties and activator.
{
            //  Now create an instance m_felixof =the newframework Felix(with
            // our   new MutablePropertyResolverImpl(configMap),configuration properties.
            m_felix = new  listFelix(configMap);

            // Now start Felix instance.
            m_felix.start();
        }
        catch (Exception ex)
        {
            System.err.println("Could not create framework: " + ex);
            ex.printStackTrace();
        }

        m_tracker = new ServiceTracker(
            m_activator.getContext(), Command.class.getName(), null);
        m_tracker.open();
    }

    public boolean execute(String name, String commandline)
    {
        // See if any of the currently tracked command services
        // match the specified command name, if so then execute it.
        Object[] services = m_tracker.getServices();
        for (int i = 0; (services != null) && (i < services.length); i++)
        {
            try
            {
                if (((Command) services[i]).getName().equals(name))
                {
                    return ((Command) services[i]).execute(commandline);
                }
            }
            catch (Exception ex)
            {
                // Since the services returned by the tracker could become
                // invalid at any moment, we will catch all exceptions, log
                // a message, and then ignore faulty services.
                System.err.println(ex);
            }
        }
        return false;
    }

    public void shutdownApplication()
    {
        // Shut down the felix framework when stopping the
        // host application.
        m_felix.shutdown(stop();
        m_felix.waitForStop(0);
    }
}

The above example is overly simplistic with respect to concurrency issues and error conditions, but it demonstrates the overall approach for using bundle-provided services from the host application. Note, to compile the above code you will need to compile against the Felix framework and Felix OSGi compendium JAR files, since the ServiceTracker classes are included in the compendium JAR file, not the framework JAR fileconditions, but it demonstrates the overall approach for using bundle-provided services from the host application.

Using Bundle Services via Reflection

It possible for the host application to use services provided by bundles without having access to the service interface classes and thus not needing to put the service interface classes on the class path. To do this, the host application uses the same general approach to acquire the system bundle context object, which it can use to look up service objects. Using either an LDAP filter or the service interface class name, the host application can retrieve the service object and then use standard Java reflection to invoke methods on the service object.

Other Approaches

The Transloader project is another attempt at dealing with issues of classes loaded from different class loaders and may be of interest.

Caveat

The code in this document has not been thoroughly tested or nor even compiled and may be out of date with respect to the current Felix source code. If you find errors please report them so the that they can be corrected.

Feedback

Subscribe to the Felix users mailing list by sending a message to users-subscribe@felix.apache.org; after subscribing, email questions or feedback to users@felix.apache.org.