Philipp Taprogge wrote:
Hi!
I still do not know what is causing this behavior, but I found a workaround in case anyone else stumbles upon this problem:
In my log4j.properties I left the log4j.rootCategory property alone and only set log4j.category.package.name.of.my.classes properties for each package in my webapp to DEBUG.
This way I only get the DEBUG output of my own classes and not ALL debug messages generated by the container.
I still wonder why my log4j.properties in /WEB-INF/classes should reconfigure the container's whole logging mechanism. Either this is a major bug or tomcat4's doing it right was one.
I will look into the issue. However, if it's a bug, then not much may be done about it, and likely the fix will need to be in c-l (Tomcat 4 integration of c-l is unreliable).
As Jacob mentioned, you will need both c-l and log4j in /WEB-INF/lib (both the logger and the c-l logger wrapper should reside in the classloader where they are used). Note that this caused big problems in TC 4.1.x, so maybe you didn't do that.
I did review it, and test it with the admin webapp (so Struts based). log4j will be used for all DEBUG or higher logs which are sent through commons-logging for this context while the context classloader of the deployment thread is set to your webapp classloader.
However, this means *a lot*, and includes all the digester events from parsing the web.xml. I think digester should use TRACE for all that stuff. This also includes Struts digester events, etc.
It is possible this wasn't the same in 4.1.x (but it was broken).
Logging from other contexts will go in their defined loggers or common-logging configured loggers.
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxx R�my Maucherat Senior Developer & Consultant JBoss Group (Europe) S�RL xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
