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