Java Reference
In-Depth Information
Bundle C
Bun
d
dle
d
d
C
Bun
Bun
Bun
Bu
u
dle
Bundle B
d
d
dl
d
d
d
l
B
Package X
Public
Private
Priva
a
a
a
a
a
at
e
e
e
Private
Public
Public
Private
ate
Bundle A
P
P
P
P
P
P
P
P
Pac
Package X
kage
X
X
X
X
X
X
Package Z
Figure 12.5
The thread context
ClassLoader
gives Java code in Bundle A visibility of classes that
aren't normally in its class space (solid gray area). But in an OSGi environment, the class space of the
thread context
ClassLoader
(dotted area) may exclude classes normally visible to Bundle A.
not seem like a big deal, but it leads to some sloppy coding. Libraries often end up
using the thread context
ClassLoader
to load their own internal classes, even though
it's only supposed to find classes from the application. For most Java
EE
environments
this will never be a problem, but, as we know,
OSG
i is a little different (see figure 12.5).
OSGI AND THE THREAD CONTEXT CLASSLOADER
In
OSG
i, the thread context
ClassLoader
isn't defined. This immediately causes a sig-
nificant problem for libraries that rely on it. For some libraries, the lack of a thread con-
text
ClassLoader
is fatal, and others can only limp along in a less-than-desirable way.
Because the thread context
ClassLoader
isn't defined by
OSG
i, framework imple-
mentations are free to do as they see fit. This means that the situation for libraries
isn't as bad as it might be. In Equinox, for example, if there's no thread context
ClassLoader
explicitly set, then the framework provides one for you. This avoids
unpleasant
NullPointerException
s, and generally makes life a lot easier, but there's
an important question. What classloader do you get?
In
OSG
i, the classloading model doesn't lend itself well to providing a thread con-
text
ClassLoader
. Clearly it doesn't make much sense to rely on the Java
SE
model of a
single thread context
ClassLoader
set when the thread is created. As threads pass
through different bundles, it would be a huge violation of
OSG
i's modularity for them
all to see the internals of the bundle that created the thread. The Java
EE
model
makes more sense, in that the thread context
ClassLoader
is set differently at various
points through the execution of the application. Unfortunately, core
OSG
i doesn't
define things like servlets or
EJB
s, but it does define bundles. This means that the
default thread context
ClassLoader
is the classloader for the bundle that loaded the
currently executing class.
By setting the thread context
ClassLoader
in this way, Equinox prevents many librar-
ies from completely collapsing, but it doesn't help them to get visibility to resources out-
side their bundle. The bundle also becomes nonportable. As with reflective
