Java Reference
In-Depth Information
13.3.2
Who's in control?
If you're going to pursue the embedded framework route, you may run into a few
other issues related to who's expecting to be in control. Generally speaking, the
OSG
i
framework assumes it's in control of the
JVM
on which it's running. If you're embed-
ding a framework, you probably don't want it to be in control or at least want it to
share control with the application in which you're embedding it. It's not uncommon
to run into issues related to
JVM
singleton mechanisms, such as
URL
and content han-
dler factories or security.
Singleton mechanisms like these are only intended to be set once at execution time.
OSG
i framework implementations need to be responsible for initializing these mecha-
nisms to properly implement specification functionality. When a framework is embed-
ded in another application, often the application assumes it's in control of these
singletons. The
OSG
i specification doesn't specifically address these aspects of frame-
work embedding, so how implementations deal with it is undefined. Some frameworks,
like Apache Felix, go to lengths to try to do the right thing, but the right thing often
depends on the specific use case. If you run into issues in these areas, you'll have to con-
sult the documentation or support forums for your specific framework implementation.
Another area where issues arise is in the use of the Thread Context Class Loader
(
TCCL
). If you're not familiar with this concept, each thread in Java has a class loader
associated with it, which is its
context class loader
. The
TCCL
provides a backdoor mech-
anism to subvert Java's normal, strict hierarchical class loading. Application servers and
various frameworks use this mechanism to deal with class-loading dependencies that
can't be shoehorned into hierarchical class loading. Unfortunately, this crude attempt
at dealing with class-loading dependencies doesn't mesh well with
OSG
i modularity.
Thread Context Class Loader travails
The TCCL can be both a blessing and a curse. Used correctly, it can enable access
to classes in places where it wouldn't otherwise be possible; but it can have unex-
pected side effects in cases where modularity is enforced. Embedding an OSGi
framework is a typical example of where things may go wrong. This can happen if the
outside application or container sets the context class loader. In this case, it's leak-
ing classes into the class space of bundles being accessed from the outside. Typical
examples of situations in which problems can occur include the following:
■
Libraries that prefer the TCCL over their own class loader
■
Libraries that rely on the TCCL mechanism and don't attempt to get the correct
class loader
■
An outside container that expects a certain TCCL on a callback
One prime example for the first case is logging. Consider a situation where you're em-
bedding an OSGi framework inside a container using log4j for logging. The container
will obviously have log4j on its class path. Now, if the container happens to set the
TCCL to its own class loader and then calls into the framework, a bundle using log4j
may end up with unexpected problems because classes from the container can be
found that shouldn't, or vice versa.
