Hi,
I'm one of the committers for commons-logging and am looking into some
memory-related issues when code is run in a servlet-engine environment.
Imagine the following classloader structure (typical for a servlet
engine):
[bootstrap classloader]
|
[shared classloader]
|
[classloader per webapp]
Commons-logging keeps configuration for each webapp separate by keeping
a Map of configurations, keyed by per-webapp classloader. This means
that config is separate regardless of whether the LogFactory class was
loaded via the shared classloader or the per-webapp classloader.
How is the same situation handled in log4j? If log4j.jar is deployed via
the shared classloader, then the individual webapps do *not* deploy
their own copy, but instead use the one present in the shared
classloader then what happens?
It seems to me that log4j searches for a config file *once only*: when
the LogManager class is loaded. This implies that in the above scenario
the individual webapps *must* deploy their own private copies of
log4j.jar if they want their own private logging configuration (and in
addition, the per-webapp classloader must use child-first classloading,
not parent-first). Have I understood correctly?
Note that I'm not recommending the use of a shared classloader; I think
requiring a separate copy is fine if this is the way log4j works, it's
just that the Tomcat docs seem to imply that the shared classloader
approach is the way to go, but I can't see it working.
Thanks,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
