-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris,
On 2/9/12 5:00 PM, C C wrote: >> From: Christopher Schultz <ch...@christopherschultz.net> >> >> So log4j.properties is located in WEB-INF/classes? Where is >> log4j.jar? > > My log4j.properties is in WEB-INF/classes, and log4j.jar is in > WEB-INF/lib. Okay. >> Do you have any other code in this example webapp -- for >> instance, something that actually loads the log4j.properties >> file? > > I don't have any other code in my example webapp. The only code is > that ExceptionServlet. In the ExceptionServlet I don't have any > code that loads log4j.properties or configures log4j in any way. I wouldn't expect Tomcat to configure log4j for you in that case. I'm surprised that it somehow worked in Tomcat 5.5. >> In order to use log4j with Tomcat 6.0 and 7.0, you need to >> download some Tomcat "extras" as described here: >> http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j > > Thanks, I've done this, and found it doesn't really address my > problem. My problem is not that I want Tomcat6/7 to use log4j for > logging, my problem is that, when my ExceptionServlet throws the > ServletException, on TC5.5 the exception was logged in the > webapp's log, whereas on TC6/7 it was logged in Tomcat's > localhost.log. Gotcha. I know for my webapps, I explicitly configure error handlers in web.xml to catch errors, log them, and show nice messages to users. > Konstantin provided a response which seemed to make sense: an > exception thrown by a servlet is probably logged using > Servlet.log(), so the log message should end up in the Context > file. Because my webapp also had commons-logging.jar in > WEB-INF/lib, that was probably interfering with / taking over the > commons-logging.jar that is shipped with TC5.5. If I remove all > the logging jars from my webapp on TC5.5, the behavior looks like > TC6/7, where the servlet's exception is logged in Tomcat's log. It's quite possible that Tomcat 5.5 wasn't re-naming packages to avoid this kind of class interference, and that Tomcat was logging to the webapp's logger. That's not how I understand the class and resource loading stuff to work, but I've been wrong before. Perhaps Tomcat was using the "wrong" context class loader when trying to load the logging configuration and getting yours. That might do it. >> I wouldn't expect that at all, unless your log4j.properties file >> lives at the server level and not at the webapp level. So, which >> is it? > > Again, log4j.jar and log4j.properties at the webapp level. I think > my understanding of where a servlet exception should be logged is > incorrect, and the fact my webapp had commons-logging.jar somehow > interfered with where the exception was logged. Does that sound > about right? Right: configure one or more error-page(s) in web.xml and point them at a servlet that can log the errors appropriately. On the other hand, you can configure Tomcat to log stuff that goes to ServletContext.log() to go to the log file of your choice: you just have to set it up using CATALINA_BASE/conf/logging.properties instead of inside your webapp (which is one reason I wouldn't favor doing it: because your logging configuration is outside of your webapp's control). Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk80TT4ACgkQ9CaO5/Lv0PA/3gCfQr0756AsyEmrf4ZrFuylXejv nIYAoKy89JB3liogP/btzi4zvoO2CCcb =tFkg -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
