Java Reference
In-Depth Information
Java's ability to write custom classloaders and add classes dynamically to a running
system isn't to be sniffed at. It's this feature that makes much of
OSG
i possible. But
Java's classloading
API
s are too low-level to be widely useful on their own. What
OSG
i
provides is a layer that harnesses this dynamism and makes it generally available to
developers who aren't interested in writing their own classloaders or hand-loading all
the classes they need.
BUNDLE LIFECYCLES
Unlike most
JAR
files on the standard Java classpath,
OSG
i bundles aren't static entities
that live on the classpath indefinitely. Dividing classloading responsibility among mul-
tiple classloaders enables the entire system to be highly dynamic. Bundles can be
stopped and started on demand, with their classloaders and classes appearing and dis-
appearing from the system as required. Bundles that have been started are guaran-
teed to have their requirements met; if a bundle's dependencies can't be satisfied, it
won't be able to start. The complete state machine for bundle lifecycles is sufficiently
simple to display in a single picture (see figure 1.6).
refresh
Installed
Stopping
update
stop
uninstall
Resolved
Active
stop
uninstall
start
Uninstalled
Starting
Figure 1.6
Bundles may move between the installed, resolved, starting, active, and stopping states. A
starting bundle can be lazily activated, and if so it won't move to the active state (crossing the dashed
line) until it's needed by another bundle. A bundle is resolved if it's installed and all its dependencies
are also resolved or started. When a bundle is uninstalled, it's no longer able to start, nor can it provide
packages to any new bundles.
