Re: [WORKAROUND] Re: VERY weird problem with commons-logging and Tomcat5
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. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [WORKAROUND] Re: VERY weird problem with commons-logging and Tomcat5
Remy Maucherat wrote: 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. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [WORKAROUND] Re: VERY weird problem with commons-logging and Tomcat5
Hi! Jacob Kjome wrote: You can also use a repository selector. BTW, do you have log4j.jar *and* commons-logging.jar (not commons-logging-api.jar) in WEB-INF/lib? Yes, I do, but I have tried several scenarios with and without either of them in my WEB-INF/lib. Also I tried putting/removing them in common/lib and server/lib. The result was always negative. Hmm... repository selector... never heared of that. Could you kindly point me to some resource about this? Sounds exactly like what I am looking for. Thanks in advance Phil -- And on the seventh day, He exited from append mode. (Book of create(2), line 255) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [WORKAROUND] Re: VERY weird problem with commons-logging and Tomcat5
At 02:22 PM 12/12/2003 +0100, you wrote: Hi! Jacob Kjome wrote: You can also use a repository selector. BTW, do you have log4j.jar *and* commons-logging.jar (not commons-logging-api.jar) in WEB-INF/lib? Yes, I do, but I have tried several scenarios with and without either of them in my WEB-INF/lib. Also I tried putting/removing them in common/lib and server/lib. The result was always negative. Hmm... repository selector... never heared of that. Could you kindly point me to some resource about this? Sounds exactly like what I am looking for. http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging But I have no idea how this will integrate with commons-logging, so unless you are using Log4j exclusively, I cannot guarantee this will work. BTW, ContextJNDISelector has been moved to log4j proper (out of the sandbox) and will be in Log4j-1.3 when it comes out. Get it from CVS if you want to use it. Jake Thanks in advance Phil -- And on the seventh day, He exited from append mode. (Book of create(2), line 255) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[WORKAROUND] Re: VERY weird problem with commons-logging and Tomcat5
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.
'Till later
Phil
Philipp Taprogge wrote:
Hi!
I have a very disgusting problem here... I am developing a webapp which
uses commons-logging and log4j.
All I do is use the commons' Log and LogFactory in my application and
place a log4j.properties file in my WEB-INF/classes.
This property file looks like this (w/out the CR in the middle line of
course):
log4j.rootCategory=DEBUG, warthoglog
log4j.appender.warthoglog=org.apache.log4j.RollingFileAppender
log4j.appender.warthoglog.layout=org.apache.log4j.PatternLayout
log4j.appender.warthoglog.layout.ConversionPattern=%d{ISO8601}
[%-15C{1}] %-5p - %m%n
log4j.appender.warthoglog.File=${catalina.home}/logs/warthog.log
log4j.appender.warthoglog.MaxFileSize=2048KB
log4j.appender.warthoglog.MaxBackupIndex=20
log4j.appender.warthoglog.Append=true
This works fine, except that I get not only my application's log
messages but _ALL_ tomcat debug logging in this file, which firstly
slows down my machine (no wonder) and secondly grows the logfile to a
few MBs just from startup.
What the heck am I doing wrong here? This setup worked perfectly in the
last tomcat4.
Can anyone advice?
Philipp Taprogge
--
I love deadlines, I love the whooshing noise they make as they go by
- Douglas Adams
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [WORKAROUND] Re: VERY weird problem with commons-logging and Tomcat5
You can also use a repository selector. BTW, do you have log4j.jar *and*
commons-logging.jar (not commons-logging-api.jar) in WEB-INF/lib? If not,
put them there and try this scenario again. A repository selector should
not be necessary in this situation. However, I always use one as it
guarantees separate logger repositories for each application (based on JNDI
namespace) with no chance of stepping on each other whether or not I have
log4j.jar in WEB-INF/lib or a parent classloader.
Jake
At 12:40 AM 12/12/2003 +0100, you 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.
'Till later
Phil
Philipp Taprogge wrote:
Hi!
I have a very disgusting problem here... I am developing a webapp which
uses commons-logging and log4j.
All I do is use the commons' Log and LogFactory in my application and
place a log4j.properties file in my WEB-INF/classes.
This property file looks like this (w/out the CR in the middle line of
course):
log4j.rootCategory=DEBUG, warthoglog
log4j.appender.warthoglog=org.apache.log4j.RollingFileAppender
log4j.appender.warthoglog.layout=org.apache.log4j.PatternLayout
log4j.appender.warthoglog.layout.ConversionPattern=%d{ISO8601}
[%-15C{1}] %-5p - %m%n
log4j.appender.warthoglog.File=${catalina.home}/logs/warthog.log
log4j.appender.warthoglog.MaxFileSize=2048KB
log4j.appender.warthoglog.MaxBackupIndex=20
log4j.appender.warthoglog.Append=true
This works fine, except that I get not only my application's log messages
but _ALL_ tomcat debug logging in this file, which firstly slows down my
machine (no wonder) and secondly grows the logfile to a few MBs just from
startup.
What the heck am I doing wrong here? This setup worked perfectly in the
last tomcat4.
Can anyone advice?
Philipp Taprogge
--
I love deadlines, I love the whooshing noise they make as they go by
- Douglas Adams
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
