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.
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.
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.
Search WWH ::

Custom Search