OSGi—the basics - Enterprise OSGi in Action - page 351

After installation into a framework, an OSG i bundle is in the INSTALLED state, and is a
pretty boring, inert object. An INSTALLED bundle doesn't have a classloader and can't
provide code or packages to anyone. What happens to the bundle next is the real magic
of OSG i, and is known as the resolution process. When all of a bundle's dependencies
are available in the OSG i framework (there are exported packages available for all of its
imports), then the framework resolver will attempt to resolve the bundle. This process
creates fixed wires between package imports and exports, obeying the versioning crite-
ria declared in the metadata. If a consistent set of wires can be created for a bundle,
then that bundle is said to be RESOLVED . A RESOLVED bundle is much more interesting
than an INSTALLED bundle—it has a classloader, and so classes and resources can be
loaded from the moment the bundle resolves. The wires created by the resolver have a
huge impact on how classes are loaded in OSG i, but also guarantee that dependencies
are available at runtime and eliminate the risk of a NoClassDefFoundError .

A.4.4 Starting and stopping bundles

After a bundle has entered the RESOLVED state, it's eligible to be STARTED . Given that
classes can be loaded from a bundle as soon as it's resolved, some people get confused
as to what starting a bundle means. A few things happen when a bundle starts, such as
the invocation of a bundle's BundleActivator , if it has one, and moving the bundle to
the ACTIVE state.
The most important change on starting a bundle is that an active BundleContext is
created for a bundle as it starts. The BundleContext can be used by a bundle to inter-
act with the framework, influence the lifecycle of other bundles, and most impor-
tantly, access the OSG i Service Registry.
Stopping a bundle is, unsurprisingly, more or less the inverse of starting a bundle.
The framework moves the bundle back into the RESOLVED state, it calls the stop
method on the bundle's BundleActivator , and it ensures that any services registered
by the bundle are unregistered from the Service Registry.

A.4.5 Uninstalling and updating bundles

When a bundle is no longer needed in a runtime it can be uninstalled. Contrary to
what you might expect, uninstalling a bundle doesn't remove it from the runtime!
Uninstalled bundles are marked so that they're no longer eligible to provide packages
when the framework resolver attempts to resolve new bundles, but they continue to
provide packages to existing bundles.
An uninstalled bundle that's still providing packages to other bundles (that aren't
also uninstalled) can't be removed immediately; doing so would forcibly take the
package away from the running bundles and result in a rather unpleasant mess. Unin-
stalled bundles are only able to be discarded by the framework when no other
resolved bundle is wired to them. Typically, after a bundle is uninstalled, the frame-
work is refreshed using PackageAdmin.refreshPackages() or bundle.adapt(Frame-
workWiring.class).refreshBundles() . This causes the framework to reresolve any