Java Reference
In-Depth Information
a bundle update, as well as reinstalling a stale bundle, requires an implementation-
specific back door into the
OSG
i framework, because the framework specification isn't
transactional over multiple lifecycle operations. This is why the Deployment Admin
specification doesn't mandate full transactional behavior.
In this section, we've looked at two different ways of deploying bundles. Which
approach to choose depends on your needs.
OBR
is geared toward discovery and
installation of bundles together with the transitive closure of their dependencies.
Deployment Admin provisions sets of bundles and their required resources as com-
plete units. These provide solutions to many of the deployment and discovery tasks
you'll need for a management agent. Of course, if necessary, you can always use the
core
OSG
i
API
to create something for your specific needs.
Now that you know how to deploy bundles to the
OSG
i framework, we need to look at
one final management-related task. After deploying a set of bundles, sometimes you need
to control their relative activation order. We'll discuss this management activity next.
10.2
Ordering bundle activation
In certain scenarios, you may need to control the relative order in which deployed bun-
dles are activated and/or deactivated. There are some good reasons to control such
ordering, but there are many more bad ones. Best practice dictates that you should create
your bundles to be independent of activation and deactivation ordering.
OSG
i allows
bundles to listen for lifecycle events from other bundles because it eliminates the need
to order dependencies and allows bundles to be aware of changes and react to them.
Ordering constraints are another form of coupling among bundles, which severely limits
their ability to be reused and arbitrarily composed. A bundle shouldn't require that func-
tionality from another bundle be available for it to be started itself; instead, it should wait
for the functionality to become available and then continue with its own functionality.
Having said that, there are a few valid reasons why you may want to ensure that a
given bundle is activated before another. For example, you may want to implement a
splash screen to display the progress of your application's startup. If your splash screen
is developed as a bundle, you need a way to ensure that it's activated first. After all, what
good would a splash screen showing the startup progress be if it came up last? You can
generalize this kind of functionality as a high-priority feature, which in general
requires ordering because it needs preferred treatment. In addition to high-priority
features, ordering may be needed in two other scenarios:
When a bundle violates the best practices mentioned earlier and relies on
implicit activation ordering during startup. In reality, you should consider fix-
ing or replacing such a bundle; but if you can't, then you must ensure that the
bundles it depends on are started first. Again, this is extremely bad practice,
and you should feel a generous amount of shame until the bundle is fixed.
■
When bundles can be grouped into sets with certain desirable properties. For
example, you may define a set of bundles comprising a safe mode, where you
deactivate all but a small set of trusted bundles and provide limited core func-
tionality for safety or security reasons. Other examples include diagnostic or
power save modes.
■