commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Date Fri, 24 Apr 2009 09:39:40 GMT
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.

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

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.


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

View raw message