Java Reference
In-Depth Information
The most interesting states are installed, resolved, and active. An installed bundle
doesn't expose any classes until it's resolved. After it's resolved by having its depen-
dencies satisfied, it can provide classes to other bundles. An active bundle can interact
directly with the OSG i framework and change the behavior of the system by automati-
cally executing nominated code.
Giving bundles a lifecycle has a few implications. The ability to execute code on
bundle activation allows the system to dynamically update its behavior. Classes need
not be loaded until required, reducing the memory footprint of the system. Because
classes have the possibility of not being loaded, the system is able to ensure loaded
classes have their dependencies satisfied. Overall, the system is both flexible and
robust, which we think is pretty appealing!
OSG i's classloading is at the heart of what makes it different from standard Java. It's an
elegant and scalable system. Unfortunately, it's also one of the greatest sources of
problems when adapting applications that weren't designed with modularity in mind
to run in an OSG i environment.
Instead of every class in the virtual machine being loaded by a single monolithic class-
loader, classloading responsibilities are divided among a number of classloaders (see fig-
ure 1.7). Each bundle has an associated classloader, which loads classes contained within
the bundle itself. If a bundle has a package import wired to a second bundle by the
framework resolver, then its classloader will delegate to the other bundle's classloader
Bundle C
Classloader C
Bundle B
Classloader B
Bundle A
Classloader A
Figure 1.7 The JVM contains many active classloaders in an OSGi environment. Each bun-
dle has its own classloader. These classloaders delegate to the classloaders of other bun-
dles for imported packages, and to the environment's classloader for core classes.
Search WWH ::

Custom Search