Java Reference
In-Depth Information
One of the key drivers for the adoption of
OSG
i is classpath hell; it's difficult in Java
SE
and Java
EE
to know what classes you need and which
JAR
provides them.
OSG
i bun-
dles are different: they define their imports and exports, making it clear whether the
bundle will work at runtime. Unfortunately, the number of packages imported by a
bundle can be large (although it usually isn't for a well-written bundle) and it isn't
always easy to find a bundle that exports them. Even when you have found a bundle
that supplies the required package, you also have to satisfy any packages requirements
that the bundle has! This process can be long and difficult, and it would be annoying
to have to do it manually for anything other than a trivial example. This problem illus-
trates the need for the resolution stage of an enterprise
OSG
i application deployment.
RESOLUTION
As with a provisioner, the fundamental job of a resolver isn't difficult to describe, but
it's a concept that doesn't exist in Java
EE
or Java
SE
and so can be quite confusing for
developers with those backgrounds when they first encounter it.
OSG
i developers, on
the other hand, are familiar with the resolution process, even if they've never used a
resolver to help them with it. This is because all
OSG
i bundles must be resolved within
a runtime framework before they can be used. If you're still a little rusty about the
OSG
i classloading model and the bundle resolution process, it would be a good idea
to get comfortable with section A.4.3 of appendix A before continuing here.
At the core of the resolution phase of
ESA
deployment is a single goal: to identify
the set of bundles that need to be installed to satisfy the dependencies of this applica-
tion. Without running through a resolution phase first, one of two things will happen
to an
ESA
when it's started:
If the
ESA
has no
missing
dependencies in its metadata, then it will already suc-
cessfully resolve within the runtime. In this case, you're lucky and the applica-
tion will work correctly when it's started.
■
In the more common case where an
ESA
has external dependencies that aren't
specified in the application manifest, for example, on a common utility library,
the application won't be deployed properly. At the point the application is
started, one or more of the application bundles won't be able to be resolved by
the
OSG
i framework. These unresolved bundles won't be able to start, and the
application won't work correctly.
■
In Java
EE
it would be almost impossible to identify missing dependencies in advance
of a runtime failure; however, all
OSG
i bundles provide a detailed description of not
only their dependencies, but also the capabilities they provide. Using this metadata, a
resolver can identify all of the dependencies of the bundles within an
ESA
, find which
dependencies are satisfied internally within the
ESA
, and then locate other bundles
that satisfy any remaining dependencies.
Interacting with the provisioner
When the resolver is processing the application content of an
ESA
, it needs to know which
bundles to look at, and what their bundle metadata is, to find out their dependencies.
