logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: log4j-2.0 questions
Date Tue, 21 Jun 2011 07:15:07 GMT

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.

Are you saying you want each webapp in a servlet container to use the same logging API but
have different backing implementations or that they should each use the same implementation
but be able to have their own configuration or something else?

The Log4J 2 API locates its implementation(s) by finding all the instances of META-INF/log4j-provider.xml.
 At the moment it expects to find just one. I haven't really figured out what it should do
if there is more than one implementation.  But I'm still not sure if that is what you are
talking about (hence my question above).  I guess what I'm asking is if what Logback is doing
is sufficient or if you think there is something else that needs to be done as I don't believe
SLF4J or Logback do anything in doPrivileged blocks and I don't believe Log4j 1.x does either.
 From the way I understand that Logback handles this is that it looks for the implementation
on the current Threads ContextClassLoader and if that fails then it uses the ClassLoader of
the class doing the loading. I've pretty much planned on doing the same thing.

Ralph




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message