Java Reference
In-Depth Information
It's possible that the resolver won't be able to find a set of bundles that has no missing
dependencies, or even that it won't be able to locate one of the application content
bundles. This is known as a
resolution failure
, and indicates that the
ESA
can't be
deployed successfully. Resolution failures can typically be fixed either by adding miss-
ing bundles to the
ESA
archive, or preferably for shared bundles, by adding them to a
bundle repository against which the
ESA
is being resolved.
When an
ESA
can be successfully resolved, you find that there's another constraint
on the versions of bundles that make up the application content—it makes sense to
take a version of a bundle that can resolve. Rather than selecting the highest version
of a bundle that fits into the required range, deployments will select the highest ver-
sion of the bundle that can be resolved given the other bundles known to the resolver.
Having selected the bundles that are to be deployed, the result of the resolution is
then passed to the provisioner. At this point, the provisioner can download
all
the
bundles needed to run the
ESA
and the flexibility of the application manifest is col-
lapsed into a single, repeatable deployment. (To ensure the deployment is repeatable,
it's stored as a
DEPLOYMENT.MF
file.) This means that there's no risk of the applica-
tion installing different bundles into the framework each time it's started, which
would make problems hard to debug!
ESA version ranges
The version ranges used in ESAs are important, and as with any version range we
strongly advise the use of semantic versioning to limit the range of acceptable bun-
dles. For example, you may require a particular bug fix, establishing a micro version
minimum, and wish to avoid function creep, with
version="[1.0.3,1.1.0)"
. Other
applications may be a little looser and choose to allow functional enhancements. Crit-
ically, regardless of the version range you provide, after the application is deployed,
a single version has been selected in the resolution phase. This is the bundle that
will be used when running the application. Some runtimes will let you reresolve a de-
ployed application to pick up updates, selecting a new fixed bundle version that will
be used from then on.
As you've now seen, the interplay between provisioning and resolution can be quite
involved, which is one of the main reasons that so many people struggle to differenti-
ate the two processes. If you find yourself a little confused, remember the following:
Provisioning is about locating and downloading bundles that aren't contained in the
ESA
. Resolution is about determining what additional bundles are needed to make the
application content work at runtime.
Because subsystems were introduced after a number of alternate solutions such as
EBA
s,
PAR
s, and Karaf features had already been developed, it may take a while for the
fragmentation in this area to be eliminated. The
OSG
i subsystems specification stan-
dardizes many of the best bits of the earlier
OSG
i application models. We'll consider
these alternatives in sections 4.3 and 4.4. (In case you're wondering, subsystems were
