DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
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:
| Code Block |
|---|
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:
| Code Block |
|---|
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;
}
public void stop(BundleContext context)
{
m_context = null;
}
public BundleContext getContext()
{
return m_context;
}
}
|
With 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:
| Code Block |
|---|
package host.core;
import java.util.Map;
import host.service.lookup;
import org.apache.felix.framework.Felix;
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;
public HostApplication()
{
// Create a case-insensitive configuration property map.
Map configMap = new StringMap(false);
// Add the host 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," +
"host.service.command; version=1.0.0");
// Explicitly specify the directory to use for caching bundles.
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(m_lookupMap);
// 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 boolean execute(String name, String commandline)
{
}
}
|