Learning lifecycle - OSGi in Action - page 82

You may still be thinking, “I'm not convinced that all these identification mechanisms
are necessary. Couldn't you find the Bundle object using the bundle's symbolic name
and version from chapter 2?” Yes, you could, because the framework allows only one
bundle with a given symbolic name and version to be installed at a time. This means
the bundle symbolic name and version pair also act as an execution-time identifier.
Why so many forms of identification?
History plays a role here. As mentioned in chapter 2, the notion of using a bundle's
symbolic name and version to uniquely identify it didn't exist in versions of the spec-
ification prior to R4. Therefore, prior to R4, it made sense to have internally and ex-
ternally assigned identifiers. Now it makes less sense, because the bundle's
symbolic name and version pair are externally defined and explicitly recognized inter-
nally by the framework.
There's still a role for the bundle identifier because in some cases the framework treats
a lower identifier value as being better than a higher one when deciding between two
otherwise equal alternatives, such as when two bundles export the same version of
a given package. The real loser here is the bundle location, which doesn't serve a
useful purpose other than potentially giving the initial URL of the bundle JAR file.
Although one instance of Bundle exists for each bundle installed into the framework,
at execution time there's also a special instance of Bundle to represent the framework
itself. This special bundle is called the system bundle ; and although the API is the same,
it merits its own discussion.
THE SYSTEM BUNDLE
At execution time, the framework is represented as a bundle with an identifier of 0,
called the system bundle . You don't install the system bundle—it always exists while the
framework is running.
The system bundle follows the same lifecycle as normal bundles, so you can manip-
ulate it with the same operations as normal bundles. But lifecycle operations per-
formed on the system bundle have special meanings when compared to normal
bundles. One example of the special meaning is evident when you stop the system
bundle. Intuitively, stopping the system bundle shuts down the framework in a well-
behaved manner. It stops all other bundles first and then shuts itself down completely.
With that, we conclude our high-level look at the major API players in the lifecycle
layer ( BundleActivator , BundleContext , and Bundle ). You now know the following:
■ BundleActivator is the entry point for the bundles, much like static main() in
a standard Java application.
■ BundleContext provides applications with the methods to manipulate the OSG i
framework at execution time.
■ Bundle represents an installed bundle in the framework, allowing state manipu-
lations to be performed on it.