Component models and frameworks - OSGi in Action - page 356

Table 11.2 The Declarative Services' raison d'être

Area of concern Discussion

Startup time Because many bundles have bundle activators, the initialization time of each bundle

adds to the initialization time of the entire application.

Memory
footprint

Registering services often implies the creation of many classes and objects up front
to support the services. These classes and objects needlessly consume memory and
resources even if these services are never used.

Complexity A large amount of boilerplate code is required to handle complex service-dependency

scenarios. Management of this code in small scenarios is at a minimum a chore, but
in large environments this boilerplate code represents a real risk in terms of software
maintenance.

dependencies reduces complexity. We'll look into precisely how Declarative Services
does these things in the remainder of this chapter.

11.3.1 Building Declarative Services components

Let's start by example. Consider the circle bundle converted to use Declarative Ser-
vices (the square and triangle bundles follow the same pattern). If you inspect the
contents of the new circle bundle in the chapter11/paint-example-ds/ directory of
the companion code, you'll see that it has the following contents:

META-INF/MANIFEST.MF
OSGI-INF/
OSGI-INF/circle.xml
org/
org/foo/
org/foo/shape/
org/foo/shape/circle/
org/foo/shape/circle/Circle.class
org/foo/shape/circle/circle.png
If you remember the previous version, the first thing you'll notice is that it no longer
contains a BundleActivator implementation. Interesting. If the bundle doesn't have
an activator, how does it provide and use services? The clue you need is located in the
bundle's manifest file, which has the following new entry:

Service-Component: OSGI-INF/circle.xml
This header is defined by the Declarative Services specification. It serves two purposes:
its existence tells the Declarative Services framework that this bundle contains compo-
nents and the referenced XML file contains metadata describing the contained com-
ponents. When a bundle is installed into the OSG i framework, the Declarative Services
framework follows the extender pattern and probes for this manifest entry. If it exists,
the Declarative Services framework takes over management of the contained compo-
nents according to the information in the referenced file.
In Declarative Services, the convention is to place component description files in
the bundle's OSGI-INF / directory following an OSGI-INF /<component-name>.xml