Managing bundles - OSGi in Action - page 317

This may sound a little odd, because deferring activation sounds like a good
thing to do all the time. Why pay the cost of activating a bundle before it's needed?
You could start all bundles lazily and they would only activate when another bundle
used them, right? There's a fly in the ointment with this approach. Suppose your
bundle provides a service. If your bundle isn't activated, it won't ever get a chance
to publish its service in its bundle activator. Thus, no other bundles will be able
to use it, and it will never be activated lazily. So, even if it were possible to apply an
activation policy to a bundle externally, it wouldn't always end up working the way
you intended.
One final detail for bundles declaring an activation policy: the specification offers
fine-grained control over which precise packages trigger lazy activation. The specifica-
tion defines include and exclude directives, which declare a comma-separated list of
included and excluded packages, respectively. For example:

Bundle-ActivationPolicy: lazy; include:="com.acme.service"
A bundle with this metadata will only be lazily activated if a class is loaded from its
com.acme.service package.
Assuming you have bundles with the declared lazy activation policy, the manage-
ment agent has the final say as to whether their activation is deferred. In chapter 3,
you learned about using Bundle.start() to start and eagerly activate a bundle. If
you call Bundle.start() with no arguments on a bundle with lazy activation policy,
it will be activated eagerly, as normal. To start the bundle with lazy activation, you
must call Bundle.start() with the Bundle.START_ACTIVATION_POLICY flag. When
you use this flag, you're saying that you want to start the bundle using its declared
activation policy. A bundle with no activation policy will be started eagerly as usual,
whereas one with the lazy policy will have its activation deferred as described in the
previous section.
There's no requirement to start bundles declared as “lazy” lazily. Eagerly starting a
bundle is always acceptable; it means you're willing to pay for the startup cost immedi-
ately. In most cases, eager activation is more than sufficient, so you won't need to
worry about activation policies. But in those situations where it's required, it can make
your life simpler.
That's it! We've covered a variety of bundle management topics. Let's review what
you've learned in this chapter.

9.4 Summary

In this chapter, we discussed how to manage bundles, including a range of issues:

You must carefully consider the versioning of both packages and bundles when
working with OSG i.

■

The OSG i specification recommends, but doesn't prescribe, versioning policies.
It's up to you to define and adhere to such as policy.

■

Managing bundles also involves managing bundle configuration data.

■