Java Reference
In-Depth Information
(continued)
To get around this, bundles can set the TCCL to their own class loader before touch-
ing log4j, but this is a fragile solution and can confuse the container.
Dealing with the TCCL is tricky. Because the OSGi specifications don't address this
issue, you can't be sure it's handled the same way by different frameworks. For ex-
ample, Apache Felix doesn't do anything in regard to the TCCL, whereas other frame-
works try to automagically set it to the “correct” bundle class loader.
One piece of useful advice to keep in mind is that the TCCL is inherited by threads.
So if you set the TCCL of a given thread, and it in turn creates a new thread, it'll inherit
the same TCCL. Of course, this can be a good or a bad thing, depending on your sit-
uation. The important part is to think about what the TCCL will be for any threads created
by the framework and/or bundles; it will be implicitly inherited if you don't explicitly set it.
13.3.3
Embedded framework example
For a simple illustration of framework embedding, you'll convert the service-based
paint program from chapter 4 into a standalone application with an embedded frame-
work instance. Because the service-based paint program is completely composed of
bundles, you need to transform it into a Java application. The new standalone paint pro-
gram uses an embedded framework instance as a plugin mechanism by which it can
deploy custom shape implementations. Figure 13.4 shows the before and after states.
Before
Shape
A
P
I
Paint
Triangle
Square
Circle
Figure 13.4 a)
Before
The service-based paint program is composed of
five bundle sharing packages and services.
After
Paint,
shape,
and main
JAR
Triangle
Square
Figure 13.4 b)
After
The standalone paint program combines the core
paint program, shape API, and launcher into a
single JAR file that provides and shares the API
with the bundles and uses their services.
Circle
