Launching and Embedding Apache Felix
| Wiki Markup |
|---|
_\[This document is based on Felix 1.0.4.\]_ |
...
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 next section provides a Felix API overview, 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.
API Overview
The Felix class that implements the OSGi framework is org.apache.felix.framework.Felix or just Felix for short. The 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 org.osgi.framework.Bundle interface, which is reiterated here:
...
The first two methods are constructors used to instantiate framework instances; the important parameters of the constructors are the 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.
Launching Felix
Launching Felix is fairly simple and involves only three steps:
...
| Anchor |
|---|
| standard-launcher |
|---|
| standard-launcher |
|---|
|
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:
...
| Anchor |
|---|
| custom-launcher |
|---|
| custom-launcher |
|---|
|
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.
...
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.
| Anchor |
|---|
| config-property |
|---|
| config-property |
|---|
|
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 map. 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.
| Anchor |
|---|
| host-interaction |
|---|
| host-interaction |
|---|
|
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.
...
| Anchor |
|---|
| host-services |
|---|
| host-services |
|---|
|
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.
...
| Anchor |
|---|
| host-service-usage |
|---|
| host-service-usage |
|---|
|
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.
...
| Anchor |
|---|
| service-reflection |
|---|
| service-reflection |
|---|
|
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.
| Anchor |
|---|
| service-other |
|---|
| service-other |
|---|
|
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 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.