DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
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.\]_Wiki Markup
- Introduction
- OSGi Launching and Embedding API Overview
- Launching Felix
- Embedding Felix
- Caveat
- Feedback
...
You use the framework factory to construct and configure a framework instance (or by directly instantiating the Felix class). The configuration map may contain the following OSGi standard properties:
org.osgi.framework.system.packages- specifies a list of packages the system bundle should export from the environment; if this is not set, then the framework uses a reasonable default fault.org.osgi.framework.system.packages.extra- specifies a list of additional packages the system bundle should export from the environment that are appended to the packages specified inorg.osgi.framework.system.packages; there is no default value for this property.org.osgi.framework.bootdelegation- specifies a list of packages that should be made implicitly available to all bundles from the environment (i.e., no need to import them); there is no default value for this property and its use should be avoided.org.osgi.framework.bundle.parent- Specifies which class loader is used for boot delegation. Possible values are:bootfor the boot class loader,appfor the application class loader,extfor the extension class loader, andframeworkfor the framework's class loader. The default isboot.org.osgi.framework.storage- specifies the path to a directory, which will be created if it does not exist, to use for bundle cache storage; the default value for this property is "felix-cache" in the current working directory.org.osgi.framework.storage.clean- specifies whether the bundle cache should be flushed; the default value for this property is "none", but it can be changed to "onFirstInit" to flush the bundle cache when the framework is initialized.org.osgi.framework.startlevel.beginning- specifies the start level the framework enters upon startup; the default value for this property is 1.
Felix also has the following, non-standard configuration properties:
felix.cache.rootdir- specifies which directory should be used to calculate absolute paths when relative paths are used for theorg.osgi.framework.storageproperty; the default value for this property is the current working directory.felix.systembundle.activators- specifies aListofBundleActivatorinstances that are started/stopped when the System Bundle is started/stopped; the specified instances will receive the System Bundle'sBundleContextwhen invoked.felix.log.logger- specifies an instance oforg.apache.felix.framework.util.Loggerthat the framework uses as its default logger.felix.log.level- specifies an integerStringwhose value indicates the degree of logging reported by the framework; the default value is "1" and "0" turns off logging completely, otherwise log levels match those specified in the OSGi Log Service (i.e., 1 = error, 2 = warning, 3 = information, and 4 = debug).felix.startlevel.bundle- specifies the start level for newly installed bundles; the default value is 1.felix.bootdelegation.implicit- specifies whether or not the framework should try to guess when to boot delegate when external code tries to load classes or resources; the default value is "true".framework.service.urlhandlers- specifies whether or not to activate the URL Handlers service for the framework instance; the default value is "true", which results in theURL.setURLStreamHandlerFactory()andURLConnection.setContentHandlerFactory()being called.
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.
| Warning | ||
|---|---|---|
| ||
Felix configuration properties have change considerably starting from |
...
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 Gogo 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:
| No Format |
|---|
launcher/
lib/
org.apache.felix.main-23.0.0.jar
bundle/
org.apache.felix.gogo.command-0.6.0.jar
org.apache.felix.gogo.shellruntime-10.46.0.jar
org.apache.felix.gogo.shell.tui-10.46.0.jar
src/
example/
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 Felix 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 Felix framework launcher.
| Code Block |
|---|
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 Felix.Launcher");
System.out.println("======================\n");
try
{
m_fwk = getFrameworkFactory().newFramework(null);
m_fwk.init();
AutoProcessor.process(null, m_fwk.getBundleContext());
m_fwk.start();
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)
{
BufferedReader br = new BufferedReader(new InputStreamReader(url.openStream()));
try
{
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.");
}
}
|
...
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 two shell bundles will be installed.
| Code Block |
|---|
m_fwk.start();
m_fwk.waitForStop(0);
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.
...
| No Format |
|---|
javac -d . -classpath lib/org.apache.felix.main-23.0.0.jar src/example/Main.java |
...
| No Format |
|---|
java -cp .:lib/org.apache.felix.main-23.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.
| Anchor | ||||
|---|---|---|---|---|
|
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 Felix 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 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.
...
In the section on launching Felix 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. The ability offered by these activators can also be accomplished by invoking
| Warning | ||
|---|---|---|
| ||
The |
...
use |
...
directly. Otherwise, the approach would be very similar. |
Each activator instance passed into the constructor effectively becomes part of the System Bundlesystem bundle. This means that the start()/stop() methods of each activator instance in the list gets invoked when the System Bundlesystem bundle's activator start()/stop() methods gets invoked, respectively. Each activator instance will be given the System Bundlesystem bundle's BundleContext object so that they can interact with the framework. Consider following snippet of a bundle activator:
...
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:
| Code Block |
|---|
public class HostApplication
{
private HostActivator m_activator = null;
private Felix m_felix = null;
public HostApplication()
{
// Create a configuration property map.
Map configMapconfig = new HashMap();
// Create host activator;
m_activator = new HostActivator();
List list = new ArrayList();
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(configMapconfig);
// 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.stop();
m_felix.waitForStop(0);
}
}
|
Notice how the HostApplication.getInstalledBundles() method uses its activator instance to get access to the System Bundlesystem 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.
...
| Code Block |
|---|
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()
{
// 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 configuration property map.
Map configMap = new HashMap();
// Export the host provided service interface package.
configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
"host.service.lookup; 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);
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 shutdownApplication()
{
// Shut down the felix framework when stopping the
// host application.
m_felix.stop();
m_felix.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.
...
| Code Block |
|---|
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()
{
// Create a configuration property map.
Map configMap = new HashMap();
// Export the host provided service interface package.
configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
"host.service.command; version=1.0.0");
// Create host activator;
m_activator = new HostActivator();
List list = new ArrayList();
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();
}
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.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.
...