Log4j-1.2.x has the concept of separate logger repositories distinguished
using repository selectors. This allows a single shared Log4j instance to
serve up multiple distinct logging configurations; one per/application. This
can also be achieved by using a separate instance of Log4j per/app. Of
course, that depends on how the classloader is implemented. It only works for
child-first, or parent-last, classloading.
Also note that distinguishing logger repositories by classloader is not
generally a good idea because then the shared instance of Log4j ends up with a
reference to a classloader that might be destroyed if the app is
shutdown/restarted, but the appserver keeps running. Tomcat will likely
report this as a memory leak. Using JNDI seems to be a better distinguisher.
See the following for details on repository selectors in Log4j-1.2.x. I don't
know if a similar concept is planned for Log4j-2.0? If so, some serious
thought should go into making it more robust and easier to use than in
Log4j-1.2.x.
http://wiki.apache.org/logging-log4j/AppContainerLogging
Jake
On Tue, 21 Jun 2011 00:30:42 -0700
Ralph Goers <[email protected]> wrote:
On Jun 20, 2011, at 10:52 PM, Mark Struberg wrote:
Hi Ralph!
The problem is that this should be one of n 'pluggable' logger
implementations. Because getting the current ContextClassLoader (for some
servers you even need to do this via a doPrivileged block) can be expensive.
After reading this again and thinking about your question I'm thinking I
must be taking this too literally. Is what you are asking for that each
webapp have its own set of Loggers, Appenders, etc? I guess I don't
understand why each one would need its own implementation. What I would
envision is that each webapp would get its own LoggerContext presumably on
the Thread Context's ClassLoader and that the Loggers and Configuration would
be created using the LoggerContext's class loader.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
