logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Kjome" <h...@visi.com>
Subject Re: log4j-2.0 questions
Date Mon, 27 Jun 2011 14:21:16 GMT

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 <ralph.goers@dslextreme.com> 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: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 


---------------------------------------------------------------------
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