Java Reference
In-Depth Information
context
ClassLoader
to load these plug-in classes as well as the configuration, creat-
ing yet another problem.
Given the unpleasant problems we see, you might expect existing logging
frameworks to be a lost cause in
OSG
i. Clearly, their Java
EE
behavior doesn't stand
much chance of working properly in
OSG
i. There are some things you can do to
improve matters.
12.3.2
Avoiding problems in OSGi
You can improve the situation for logging frameworks in
OSG
i in a number of ways;
some are more invasive to the code than others, but they do demonstrate useful ways
to work around some of the problems that afflict Java libraries in
OSG
i. Many of these
workarounds aren't normally recommended, but it's important to understand where
rules can be bent.
CAREFUL PACKAGING
One of the big problems we noted with logging frameworks is the fact that although
the
API
and implementation are notionally separate, from a modularity perspective
they're tightly coupled. This is because the
API
needs to be able to load the implemen-
tation classes.
One of the things you can do to avoid the lifecycle and classloading problems asso-
ciated with this packaging is to package the logging
API
and logging implementations
as a single bundle. Clearly, there are advantages and disadvantages to this approach.
One of the big advantages is that by including the
API
and implementation in the
same bundle, you're always guaranteed to be able to load the implementation.
Another big advantage of packaging the
API
and implementation together is that it's
impossible for the implementation to be changed independently of the
API
, leaving
clients in an inconsistent state.
Given the advantages of this packaging, you might expect it to be the default, but
there are some negative side effects. First, you have to package any logging implemen-
tation with the
API
, which dramatically bloats the bundle. Given that different clients
may want different implementations, this can be a significant problem. It also only
helps for logging implementations that you know you need ahead of time.
Given that packaging the logging
API
and implementation together solves prob-
lems, you might expect that packaging the logging library with the client would be
even better. To an extent this is true. If you package the logging library with the client,
then it will gain visibility of any configuration files and plug-ins; on the other hand,
you'll have to bloat every single client, wasting runtime resources. Effectively, by doing
this you're creating an even worse version of the Java classpath!
Our recommendation is to avoid packaging the logging library with the client
code, unless there's only one client bundle. Even then you should think twice. What
you can do is to package commonly used logging implementations along with the
API
.
This will reduce some of the optional package import spaghetti, prevent some of the
logging internals from having to be exported, and also avoid lifecycle problems.