Java Reference
In-Depth Information
■
org.osgi.framework.system.packages
—Defines the complete set of class
path packages exported by the system bundle
■
org.osgi.framework.system.packages.extra
—Defines an additional set of
class path packages that is appended to the former set
Typically, you'll only use the latter property, because the specification requires the
framework to set a reasonable default for the former. For an example, suppose you're
going to create a version of the paint program that used an embedded framework
instance. In that case, you likely want to put the
SimpleShape
interface on the class
path so you can share a common definition between the application and the bundles.
You configure the framework instance like this:
Map m = new HashMap();
m.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA, "org.foo.shape");
fwk = getFrameworkFactory().newFramework(m);
fwk.start();
The syntax to use when specifying the property is exactly the same as for the
Export-
Package
manifest header, which means you can specify additional packages by separat-
ing them with commas; you can also include version information and attributes.
Necessary, but not sufficient
It's necessary to specify this configuration property to share class path packages
with bundles, but it isn't sufficient to only do this. You must also ensure that the
specified packages are available on the class path when you start your application.
You do so the standard way (by specifying them on the JVM class path).
The need to perform this configuration is an extra step for the application, but from
the bundle's perspective it's business as usual. Bundles need to specify the package on
their
Import-Package
manifest header, as normal, and the framework gives them
access to the package following normal
OSG
i rules.
What about the situation where you don't have a common class available from the
class path? Because the application can't import packages from bundles, there isn't
much you can do here. The main option is to resort to reflection, which is possible
because
OSG
i service lookup can be performed by the class name. Of course, you
should use
BundleContext.getAllServiceReferences()
instead of
BundleContext.
getServiceReferences()
, because the framework will potentially filter results if it
determines that you don't have access to the published service type. This gives you
access to the
ServiceReference
that you can use to get access to the service object so
you can invoke methods on it using reflection.
If you have different definitions of the service class on the outside and inside, you
can try to get fancy and use dynamic proxies to bridge the two types in a generic way.
But this is beyond the scope of this chapter and can easily be avoided by converting
your entire application to bundles.
