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.
Regards,
Ate
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
