Java Reference
In-Depth Information
Why do dependencies complicate the issue? Consider updating a given bundle.
Other dependent bundles have potentially loaded classes from the old version of the
bundle. They can't just start loading classes from the new version of the bundle,
because they would see old versions of the classes they already loaded mixed with new
versions of classes loaded after the update. This would be inconsistent. In the case of
an uninstalled bundle, the situation is more dire, because you can't pull the rug out
from under the dependent bundles.
It's worthwhile to limit the disruptions caused by bundle updates or uninstalls. The
framework provides such control by making updating and uninstalling bundles a two-
step process. Conceptually, the first step prepares the operation; and the second step,
called
refreshing
, enacts its. Refreshing recalculates the dependencies of the impacted
bundles. How does this help? It allows you to control when the changeover to the new
bundle version or removal of a bundle occurs for updates and uninstalls, respectively,
as shown in figure 3.19.
We say this is a two-step process, but what happens in the first step? For updates,
the new bundle version is put in place, but the old version is still kept around so bun-
dles depending on it can continue loading classes from it. You may be thinking, “Does
this mean two versions of the bundle are installed at the same time?” Effectively, the
answer is, yes. And each time you perform an update without a refresh, you introduce
yet another version. For uninstalls, the bundle is removed from the installed list of
bundles, but it isn't removed from memory. Again, the framework keeps it around so
dependent bundles can continue to load classes from it.
For example, imagine you want to update a set of bundles. It would be fairly incon-
venient if the framework refreshed all dependent bundles after each individual
update. With this two-step approach, you can update all bundles in the set and then
trigger one refresh of the framework at the end. You can experience a similar situa-
tion if you install a bundle providing a newer version of a package. Existing resolved
bundles importing an older version of the package won't be automatically rewired to
the new bundle unless they're refreshed. Again, it's nice to be able to control the
point in time when this happens. It's a fairly common scenario when updating your
application that some of your bundles are updated, some are uninstalled, and some
are installed; so a way to control when these changes are enacted is helpful.
You trigger a refresh by using the Package Admin Service again. To illustrate how
to use it, let's add a
refresh
command to the shell, as shown next.
BundleA in
revision 1
BundleA in
revision 1
Figure 3.19
Updating
and refreshing bundles is
a two-step process. Most
of the work normally takes
place in the second step
during the framework
refresh operation.
Update
bundleA
BundleA in
revision 2
BundleA in
revision 2
Refresh
BundleB in
revision 1
BundleB in
revision 1
BundleB in
revision 1
