commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: [LOGGING] ClassLoader Problems
Date Tue, 23 Apr 2002 15:16:51 GMT

On Tue, 23 Apr 2002 wrote:

> Date: Tue, 23 Apr 2002 10:50:10 +0100
> From:
> Reply-To: Jakarta Commons Developers List <>
> To:
> Subject: RE: [LOGGING] ClassLoader Problems
> Craig,
> Just to clarify, you wrote a LogFactory impl, and put it in the shared
> lib dir (so all apps can use the same instance)?. If so, how do you
> determine which app to rename the category for? I can't think offhand of
> knowing a particular instance / Class instance is in a particular app,
> since no context is passed back (unless there's something on the thread?
> Thread context ClassLoader?).
> Or are you putting the LogFactory per app? I don't see how this could
> work though..

I did the latter (LogFactory per app).  Most of my work is on Tomcat,
where each app has its own class loader.  I left commons-logging.jar in
the common/lib directory (the nightly builds use it) and I can put the
custom LogFactory either in common/lib (to affect all apps) or in
WEB-INF/lib (to affect just the one app).  I used the "services" approach
to registering the factory, by putting a
"META-INF/services/org.apache.commons.logging.LogFactory" file into the
JAR containing my implementation, with one line containing the name of the
implementation class.  That way, selecting this is just a matter of
putting a single JAR file in one place or another -- no properties files
to edit.

The standard LogFactory discovery mechanism works by class loader, so it
is easy to customize separate apps in a container model (like a servlet
container) where separate class loaders are used.  It doesn't help much
with John's proposed use case (two components sharing a single component,
all in one class loader, where you want to sort on the outer component),

Even the latter can be dealt with on a JDK 1.4 system, though, if you
write your LogFactory to walk the call stack and see who the caller was
(see Throwable.getStackTrace() in the 1.4 JavaDocs).

> Ken.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message