Java Reference
In-Depth Information
bundles that are using packages from an uninstalled bundle. This allows the frame-
work to clear up the uninstalled bundles. An uninstalled bundle that's unable to be
removed because it's still providing packages to another bundle is sometimes known
as a zombie bundle .
Updating a bundle is an operation that isn't possible in standard Java. An update is
like an atomic uninstall/reinstall operation that allows the content of a bundle to be
changed. The full explanation of bundle update behavior is rather involved, and a
complete description isn't in the scope of this topic, but one of the more common
side effects is as a direct result of the behavior for an uninstallation. If a bundle A 1 is
being updated to A 2 , and it provides packages to another bundle B, then the old ver-
sion of the bundle A 1 can't be removed without breaking B. This situation doesn't
stop the update from occurring, but it does mean that you end up with both A 1 and
A 2 available at the same time! B will continue to use A 1 (until it's refreshed), but
future resolutions will all wire to A 2 . Similarly to uninstallation, refreshing the frame-
work after an update allows the framework to clear up old versions of bundles and to
generally sort everything out.
If you're confused by uninstallation and update, we don't blame you; they're con-
ceptually the most difficult part of the bundle lifecycle (though writing an OSG i
resolver would be a harder task if you were to implement a framework!). Probably the
most important thing to take from this is that dynamic dependency management is
hard, and sometimes you can end up in some pretty odd situations. Fortunately OSG i
has solved these issues with well defined, if slightly interesting, consequences.
Managing dependencies in a dynamic system
Bundles may be stopped at any time. What happens to bundles that depend on the
stopped bundle? In most cases, very little. When a bundle is stopped, it still has a
ClassLoader , so its exported packages remain available to other bundles that are
wired to it. One thing that does change is that the stopped bundle no longer has a
BundleContext . This means that any services that the bundle registered while it was
started are forcibly unregistered by the framework (assuming the bundle didn't tidy
up after itself!). Obviously, bundles that depended on these services are no longer
able to use them, but if the stopped bundle is started again, then things usually (in a
well-designed system) return to their original state.
Uninstalling a bundle is a much more destructive operation than stopping it. An unin-
stalled bundle isn't able to provide packages in any resolution, and it definitely can't pro-
vide any services. The framework automatically removes uninstalled bundles, but
sometimes this isn't possible. If the uninstalled bundle was providing packages to other
bundles before it was uninstalled, then these wirings will keep the uninstalled bundle's
ClassLoader alive. This is often called a zombie bundle; the bundle isn't alive anymore,
and there's no way to bring it back, but somehow it's still walking around. The system
can be reconciled by restarting the framework, by calling refreshPackages on the
PackageAdmin service, or by calling refreshBundles on the FrameworkWiring service.
Search WWH ::

Custom Search