Managing bundles - OSGi in Action - page 314

This stores the current time as a long in the system preferences start node. As you
can see, this is pretty simple stuff, but it's convenient to have a standard service defini-
tion rather than having to invent it yourself.

Isn't this just Java Preferences?
Generally speaking, the Preferences Service is similar to java.util.prefs.Pref-
erences , introduced in Java 1.4. One of the reasons the OSGi Preferences service
exists is because the Java Preferences API isn't available before Java 1.4 and OSGi
still supports Java 1.3. At the same time, the OSGi Preferences Service saves pref-
erences for each bundle independently of other bundles, whereas Java Preferences
saves preferences of one user of the system independently of other users. So the
two, although similar, aren't identical.

This concludes our discussion of bundle configuration. We've covered a lot of
ground. The combination of the Configuration Admin, Metatype, and Preferences
Services provides for flexible approaches when it comes to configuring your bundles,
which can save you a lot of management effort.
So far in this chapter, we've talked about how to manage versions and spent a fair
amount of time showing how to manage bundle configuration data. Now we'll switch
to our final topic: managing when a given bundle is activated after it's started.

9.3 Starting bundles lazily

From chapter 3, you know that starting a bundle involves invoking the Bundle.
start() method on its corresponding Bundle object. If the bundle has a BundleActi-
vator , and it's resolvable, the framework creates an instance of the bundle's activator
and invokes start() on it, allowing the bundle to initialize itself. The act of starting a
bundle and of it being activated are two independent concepts, although typically
they occur together. Sometimes you may want to start a bundle but not necessarily
activate it until some later time. Why? There are two main reasons:

Your bundle's exported packages aren't able to function properly without a
BundleContext (for example, perhaps they require a service from the registry).

■

Your bundle's initialization is costly, and you want to defer it until it's needed.

■

The OSG i specification allows bundles to declare a lazy activation policy, which indi-
cates to management agents that something like one of the previous two issues applies
to it. Of course, you can use alternative approaches to deal with these situations. For
the first issue, you can program the bundle classes to always throw exceptions until
activated. For the second, you can minimize initialization in the bundle activator and
use threads to do work in the background. Sometimes these alternative approaches
are feasible, but sometimes throwing exceptions isn't so clean, nor is it possible to
completely reduce all startup overhead, especially if you're starting lots of bundles. In
these cases, you can use the lazy activation policy.