Java Reference
In-Depth Information
Symbolic-Name: org.foo.shell
[ 2] [INSTALLED] Foo Bundle
Location: file:foo.jar
Symbolic-Name: org.foo.foo
You install a bundle and resolve it using the
resolve
command
B
, which transitions it
to the
RESOLVED
state. Using the
refresh
command
C
, you transition it back to the
INSTALLED
state.
At this point, you've achieved a lot in understanding the lifecycle layer; but before
you can finish, we need to explain some nuances about updating bundles. Let's get to it.
3.5.3
When updating isn't updated
One of the gotchas many people run into when updating a bundle is the fact that it
may or may not use its new classes after the update operation. We said previously
that updating a bundle is a two-step process, where the first step prepares the
operation and the second step enacts it, but this isn't entirely accurate when you
update a bundle. The specification says the framework should enact the update
immediately, so after the update the bundle should theoretically be using its new
classes; but it doesn't necessarily start using them immediately. In some situations,
after a bundle is updated, new classes are used; in other situations, old classes are
used. Sounds confusing, doesn't it? It is. Why not just wait until a refresh to enact
the new revision completely?
The answer, as you might guess, is historical. The original R1 specification defined
the update operation to update a bundle. End of story. There was no Package Admin
Service. With experience, it became clear that the specified definition of
update
was
insufficient. Too many details were left for framework implementations to decide,
such as when to dispose of old classes and start using new classes. This led to inconsis-
tencies, which made it difficult to manage bundle lifecycles across different frame-
work implementations. This situation resulted in the introduction of the Package
Admin Service in the R2 specification, to resolve the inconsistencies around update
once and for all. Unfortunately, the original behavior of update was left intact, due to
backward-compatibility concerns. These concerns leave you with the less-than-clean
approach to bundle update that we have today, but at least it's fairly consistent across
framework implementations.
Back to the issue of an updated bundle sometimes using old or new classes. As
arcane as it may be, there is a way to understand what's going on. Whether your bun-
dle's new classes or the old classes are used after an update depends on two factors:
Whether the classes are from a private package or an exported package
■
If the classes are from an exported package, whether they're being used by
another bundle
■
Regarding the first factor:
If the classes come from a private bundle package (one that isn't exported), the
new classes become available immediately no matter what.
■
