commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Date Fri, 24 Apr 2009 21:09:54 GMT
Mark Thomas wrote:
> Ate Douma wrote:
>> Mark Thomas wrote:
>>> I have seen similar issues in Tomcat's internal logging with
>>> java.util.logging, log4j and commons-logging. Why will this be any
>>> different with slf4j?
>> Because sfl4j does not use the ContextClassLoader to determine the
>> logger instance but compile-time binding.
>> Exactly the reason why CL doesn't work and slf4j does.
>> I think using slf4j for Tomcat internal logging would solve this too.
> I still don't get how slf4j solves all of the web app container logging
> issues. I might have to download slf4j and try a few things out.
> In the meantime consider this:
> Two web applications both using slf4j with java.util.logging and both
> using a third party library that has a logger called "MyLogger".
> When web app one uses the library, slf4j will return - via a call to
> j.u.l.getLogger() - a new logger called MyLogger. When web app two uses
> the library it will get the same logger instance as web app one. This
> type of behaviour is often at the root of permgen memory leaks.
If these libraries (slf4j + third party library) both are *separately* within the WEB-INF/lib
of their own webapp as you replied in a later 
message, *and* the webcontainer uses PARENT_LAST classloading policy (as standard by Tomcat),
effectively you'll end up with two separate 
instances of MyLogger (as being loaded by different classloaders) and all should be fine,
at least when using log4j.
How a global JUL configuration will work out in this case I don't know for sure because, to
be honest, I always do my best to stay far away 
from using JUL.

> Remy had to write a new LogManager for j.u.l to work around this.
> If you use slf4j/log4j with your webapp you should not see this issue as
> the logger repository would be at the webapp level rather than globally
> as it is with j.u.l.
Right :)

> That said, I'd still be worried about cross-context
> calls and webapps getting instances of loggers loaded by other webapps
> and would want to do some very careful testing.
When using slf4j+log4j and PARENT_LAST webapp classloader policy as is the servlet spec recommendation
(I won't say requirement because some 
people/companies disagree, but *I* think that is the only sensible configuration and interpretation
of the spec), you should not need to worry.



> I freely admit this stuff makes my head hurt every time I have to try
> and figure out one of these bugs. If slf4j solves all of these issues
> I'd really like to understand how.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message