Java Reference
In-Depth Information
}
out.println(success ? “Success” : “Failure”);
}
private PackageAdmin getPackageAdminService() {...}
}
We won't discuss the details of how you obtain the Package Admin Service until the
next chapter; for now, you use the
getPackageAdminService()
method. If the
resolve
command is executed with no arguments, you invoke
resolveBundles()
with
null
, which causes the framework to attempt to resolve all unresolved bundles.
Otherwise, you parse the argument as a list of whitespace-separated bundle identifi-
ers. For each identifier, you get its associated
Bundle
object and add it to a list. After
you've retrieved the complete list of bundles, you pass them in as an array to
resolveBundles()
. The framework attempts to resolve any unresolved bundles of
those specified.
It's worthwhile to understand that the framework may resolve bundles in addition
to those that were specified. The specified bundles are the root of the framework's
resolve process; the framework will resolve any additional unresolved bundles neces-
sary to resolve the specified roots.
Resolving a bundle is a fairly easy process, because the framework does all the hard
work for you. You'd think that'd be it. As long as your bundle's dependencies are
resolved, you have nothing to worry about, right? It turns out the dynamic nature of
the bundle lifecycle makes this an invalid assumption. Sometimes you need to have
the framework recalculate a bundle's dependencies. You're probably wondering,
“Why?” We'll tell you all about it in the next section.
3.5.2
Refreshing bundles
The lifecycle layer allows you to deploy and manage your application's bundles. Up until
now we've focused on installing, resolving, and starting bundles, but there are other
interesting bundle lifecycle operations. How about updating or uninstalling a bundle?
In and of themselves, these operations are as conceptually simple as the other lifecycle
operations. We certainly understand what it means to update or uninstall a bundle. The
details are a little more complicated. When you update or uninstall a resolved bundle,
you stand a good chance of disrupting your system. This is the place where you can start
to see the impact of the framework's dynamic lifecycle management.
The simple case is updating or uninstalling a self-contained bundle. In this case,
the disruption is limited to the specific bundle. Even if the bundle imports packages
from other bundles, the disruption is limited to the specific bundle being updated or
uninstalled. In either case, the framework stops the bundle if it's active. In the case of
updating, the framework updates the bundle's content and restarts it if it was previ-
ously active. Complications arise if other bundles depend on the bundle being
updated or uninstalled. Such dependencies can cause a cascading disruption to your
application, if the dependent bundles also have bundles depending on them.
