Java Reference
In-Depth Information
12.3.1
Common problems with loggers in OSGi
The structure of a logging framework sounds like a great, modular design that should
be ideal for an
OSG
i environment. That would be the case if, for example, the applica-
tion used the Service Registry to obtain a logging implementation. Using a static fac-
tory demonstrates the first big problem with logging frameworks.
LOADING THE LOGGING IMPLEMENTATION
The
API
for logging frameworks almost always contains the static factory for obtaining
the logger. This means that the logging
API
has to load the logging implementation
class. This isn't a problem if the implementation is in the same bundle, but many
implementations have pluggable backends that are packaged separately. These plug-
gable implementation classes aren't
API
, but unless they're packaged inside the same
bundle they have to be exported anyway.
If the logging
API
were to have a hard dependency on each possible implementa-
tion, then it would mean that you needed all of the possible implementations to be
installed into the
OSG
i framework for your logger to even resolve. Clearly this is a bad
idea, meaning that the dependencies must be optional. But this still means that all of
the potential implementations must be known in advance to be loadable!
Another problem introduced by the static factory is that it divorces the client (in
this case, the class doing the logging) from the lifecycle of the logging implementa-
tion. If the implementation is stopped, or even uninstalled, then the client has no way
of knowing that their logger needs to be thrown away.
The separation of the logging
API
from the implementation isn't only an issue
when trying to load the logging internals; it also causes problems when trying to load
configuration files and customizations.
CLIENT-PROVIDED RESOURCES
One of the common concerns for libraries is how they can be configured. For some
libraries, the amount of configuration is sufficiently small that it can be provided in
some sort of registration call, or even be passed in whenever the library is called. For
most libraries, this solution is insufficient; as the amount of configuration grows, it
becomes increasingly unmanageable in code. Furthermore, it's unpleasant to require
users to recompile their code to change their configuration.
Normally this sort of issue is solved by using an
XML
file or properties file, either
in a fixed, library-specific location within the client
JAR
, or in a client-specified loca-
tion. This is the most common way to configure a logging framework. As we're sure
you'll remember from section 12.2.3, the way that the logging framework loads
resources provided by the client is by using the thread context
ClassLoader
. For all
the reasons we covered then, this doesn't always work in
OSG
i. By the time the library
code is invoked, the thread context
ClassLoader
can no longer see the content of
the
OSG
i bundle.
Unfortunately, it's not only configuration files that cause an issue. Logging frame-
works, like many other types of libraries, often allow clients to configure customized
plug-in classes using configuration. Clearly the logging framework uses the thread
