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.
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).
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.
Search WWH ::