Java Reference
In-Depth Information
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.foo
Bundle-Version: 1.0
Import-Package:
org.bar;version="[1.0,2.0)"
Component-Model:
OSGI-INF/foo.xml
Figure 11.2
Component frameworks in OSGi
are generally implemented as
other bundles using the extend-
er pattern. They remove boiler-
plate code from user bundles
(often using metadata files—
OSGI-INF/foo.xml in this case),
allowing the deployer to build
complex business services out
of modular building blocks.
OSGi
framework
META-INF/MANIFEST.MF
OSGI-INF/foo.xml
org/foo/Foo.class
org/foo/FooImpl.class
Component
framework
provider
The lifecycles of components contained in a bundle are subservient to their containing
bundle, meaning that components can only be active if their containing bundle is
active. Beyond that, the lifecycle of an individual component is based on its own
dependencies and constraints. Component frameworks typically define valid and
invalid component lifecycle states based on whether a component's dependencies are
satisfied. Because the lifecycle of the contained components is managed by the compo-
nent framework, component bundles typically don't have bundle activators. A compo-
nent framework listens for bundle lifecycle state changes in the component bundles to
trigger management. As a result, component frameworks introduce some other sort of
callback mechanism (a lifecycle hook ) for components wishing for such notification; you
can think of this as a component activator. Luckily, such lifecycle hooks are usually
unnecessary, because services and service dependencies are managed automatically,
which was the main purpose for having a bundle activator in the first place.
AUTOMATING SERVICE MANAGEMENT
The most immediate benefit of having the component framework manage service
dependencies is the simplification it brings. It removes redundant boilerplate code
for handling each service dependency, and it also eliminates some of the complex,
error-prone aspects.
Consider a trivial example where a component FooImpl depends on service Bar
and should only publish its service when Bar is available. This is the scenario shown
in figure 11.1; the following listing shows the code necessary to achieve it using a
ServiceTracker (refer to chapter 4 for a reminder of how ServiceTracker works).
Listing 11.1 ServiceTracker handling one-to-one dependency on a service
class BarTracker extends ServiceTracker {
private final FooImpl foo;
private final BundleContext ctx;
Search WWH ::




Custom Search