Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
Understandable. I was a little dismayed to see that what had been more automatic in Tomcat-5.0.xx had become less so in Tomcat-5.5. What I mean is, in Tomcat-5.0.xx, one could add a Logger to the context configuration file, deploy that with the webapp, and dynamically get a log file for ServletContext.log() output. In Tomcat-5.5, one has to have this in the logger config file at Tomcat startup, therefore forcing one to predict the apps that will be deployed to the appserver during runtime ... I was trying to achieve this with multiple separate log4j.properties, one in the container (common/classes/) for the uncaught stack trace and other general logging, and others in each webapp. With my setup below I was expecting to get THREE files: catalina.out (with stdout/err), tomcat.log (with the container's log4j output), and bar.log (with the webapp's log4j output, which I changed from ServletContext.log() to use Logger.info()). Instead, I got only catalina.out and tomcat.log, the latter containing everything that I thought the webapp would be sending to bar.log. And this should have worked. It works in every case I have ever tried. I suggest you double and triple check that you have log4j.jar in both common/lib and WEB-INF/lib and make sure you have log4j.properties in both common/classes and WEB-INF/classes. OK, thanks to your vote of confidence in the method, I dug further and discovered that my WEB-INF/classes/log4j.properties was never being found. If I put the log4j.properties into the same jar (in WEB-INF/lib) with the class that was instantiating the Logger, it worked correctly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
Quoting Adrian Robert [EMAIL PROTECTED]: Understandable. I was a little dismayed to see that what had been more automatic in Tomcat-5.0.xx had become less so in Tomcat-5.5. What I mean is, in Tomcat-5.0.xx, one could add a Logger to the context configuration file, deploy that with the webapp, and dynamically get a log file for ServletContext.log() output. In Tomcat-5.5, one has to have this in the logger config file at Tomcat startup, therefore forcing one to predict the apps that will be deployed to the appserver during runtime ... I was trying to achieve this with multiple separate log4j.properties, one in the container (common/classes/) for the uncaught stack trace and other general logging, and others in each webapp. With my setup below I was expecting to get THREE files: catalina.out (with stdout/err), tomcat.log (with the container's log4j output), and bar.log (with the webapp's log4j output, which I changed from ServletContext.log() to use Logger.info()). Instead, I got only catalina.out and tomcat.log, the latter containing everything that I thought the webapp would be sending to bar.log. And this should have worked. It works in every case I have ever tried. I suggest you double and triple check that you have log4j.jar in both common/lib and WEB-INF/lib and make sure you have log4j.properties in both common/classes and WEB-INF/classes. OK, thanks to your vote of confidence in the method, I dug further and discovered that my WEB-INF/classes/log4j.properties was never being found. If I put the log4j.properties into the same jar (in WEB-INF/lib) with the class that was instantiating the Logger, it worked correctly. That's extremely odd. What version of Tomcat are you running? That's a bug because WEB-INF/classes should be put in the classpath before jars in WEB-INF/lib. Jake - 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]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
OK, thanks to your vote of confidence in the method, I dug further and discovered that my WEB-INF/classes/log4j.properties was never being found. If I put the log4j.properties into the same jar (in WEB-INF/lib) with the class that was instantiating the Logger, it worked correctly. That's extremely odd. What version of Tomcat are you running? That's a bug because WEB-INF/classes should be put in the classpath before jars in WEB-INF/lib. This is 5.5.7, with the 1.4 compatibility package on MacOS. I've experienced similar issues before with different tomcat versions, though I had forgotten that in this case.. Note I do NOT unpack the app from a war, just copy the full hierarchy straight under webapps. Also, the WEB-INF/classes/log4j.properties file was a symblic link. Maybe one of these makes a difference? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Thu, 03 Mar 2005 12:11:27 -0500, Adrian Robert [EMAIL PROTECTED] wrote: That's extremely odd. What version of Tomcat are you running? That's a bug because WEB-INF/classes should be put in the classpath before jars in WEB-INF/lib. I agree it's very odd. This is 5.5.7, with the 1.4 compatibility package on MacOS. I've experienced similar issues before with different tomcat versions, though I had forgotten that in this case.. Note I do NOT unpack the app from a war, just copy the full hierarchy straight under webapps. Also, the WEB-INF/classes/log4j.properties file was a symblic link. Maybe one of these makes a difference? Yes, I think the symlinking is the issue. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
Quoting Adrian Robert [EMAIL PROTECTED]: OK, thanks to your vote of confidence in the method, I dug further and discovered that my WEB-INF/classes/log4j.properties was never being found. If I put the log4j.properties into the same jar (in WEB-INF/lib) with the class that was instantiating the Logger, it worked correctly. That's extremely odd. What version of Tomcat are you running? That's a bug because WEB-INF/classes should be put in the classpath before jars in WEB-INF/lib. This is 5.5.7, with the 1.4 compatibility package on MacOS. I've experienced similar issues before with different tomcat versions, though I had forgotten that in this case.. Note I do NOT unpack the app from a war, just copy the full hierarchy straight under webapps. Also, the WEB-INF/classes/log4j.properties file was a symblic link. Maybe one of these makes a difference? That makes a huge difference. Symbolic links are not enabled by default. I believe there is some sort of allowLinking property you can set in the context configuration file for the app. I don't recall the syntax for that, though. See the Tomcat docs for info. Once you have that set, it will probably work as expected. Jake - 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]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
OK, thanks to your vote of confidence in the method, I dug further and discovered that my WEB-INF/classes/log4j.properties was never being found. If I put the log4j.properties into the same jar (in WEB-INF/lib) with the class that was instantiating the Logger, it worked correctly. That's extremely odd. What version of Tomcat are you running? That's a bug because WEB-INF/classes should be put in the classpath before jars in WEB-INF/lib. This is 5.5.7, with the 1.4 compatibility package on MacOS. I've experienced similar issues before with different tomcat versions, though I had forgotten that in this case.. Note I do NOT unpack the app from a war, just copy the full hierarchy straight under webapps. Also, the WEB-INF/classes/log4j.properties file was a symblic link. Maybe one of these makes a difference? It turns out it WAS the symbolic link. I get the following results: - symbolic link, relative (e.g., WEB-INF/classes/log4j.properties - resources/log4j.properties): not found - symbolic link, absolute (e.g., WEB-INF/classes/log4j.properties - /usr/java/tomcat/webapps/foo/WEB-INF/classes/resources/log4j.properties - OR - regular file: found and prevents common/classes/log4j.properties from being found (tomcat-general stuff goes into webapp's log file) - file in jar with class that instantiates Logger: both tomcat's (common/classes/) and webapp's log4j.properties are found and heeded Sorry about the bother if this is just standard knowledge of how tomcat operates on Unix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Mar 1, 2005, at 6:45 PM, Remy Maucherat wrote: On Tue, 01 Mar 2005 18:18:49 -0500, Adrian Robert [EMAIL PROTECTED] wrote: However, I can't seem to find the right combination of log4j.properties lines, or maybe I'm trying something impossible. (I can't find good docs on the uses of log4j.properties when used inside the hierarchical classloading context that tomcat provides.) What keeps happening is that the webapp's log statements keep going into the global tomcat log. Would I be better off with JDK logging instead? I am working at the moment on a small package (which will be an implementation of java.util.logging) which will allow you doing that using the JDK logging. The main issue with it as supplied in the JDK is that there is only one global configuration per JVM. The trick is to make that per classloader, with delegation, so that webapps are isolated. At the moment, I think log4j is your only choice (unfortunately, I'm no expert, so I can't give you tricks with this particular configuration). In the same package, I will also provide a handler with daily rotation. It should be done by the end of the week (it doesn't work at the moment, I'm busy debugging ;) ). Great news. I'm happy to help test this. I'd rather use JDK logging than log4j if possible to avoid an additional deployment dependency. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Mar 2, 2005, at 12:25 AM, Jacob Kjome wrote: You first talk about ServletContext.log(), but then talk about log4j loggers in your app. These are two completely separate things. Which were you focusing on? With your setup, it it makes sense that ServletContext.log() messages are going to catalina.log. However, if you have log4j.jar in WEB-INF/lib and your application log4j logging is going to catalina.log, then your setup is different than what you describe here. There is quite simply no way that can happen given the setup you've described. They should go to bar.log since that's the only appender that your application's log4j configuration can see. In any case, you don't need a separate log4j.jar in WEB-INF/lib for ServletContext.log() messages to go to app-specific log files. Just define those in your log4j.properties just like you have defined the host logger. Here's my setup for Log4j-1.2.9 in common/classes.log4j.properties (You can use log4j.xml when using Log4j-1.3 because it uses a the new JoranConfigurator which doesn't define a log4j.dtd. The current DOMConfigurator's dtd defines the logger name attribute as an ID and the host and context logger names that Tomcat uses characters not allowed in attributes of type id) Thanks for your input.. I realize I wasn't clear about one thing. I don't want to define webapp-specific logging in the tomcat-global log4j.properties file. Instead, I want individual log4j.properties stored under webapp/*/WEB-INF/classes to cause logging to web-app specific files, without the container needing to be hard-coded for the webapps it is hosting. I was trying to achieve this with multiple separate log4j.properties, one in the container (common/classes/) for the uncaught stack trace and other general logging, and others in each webapp. With my setup below I was expecting to get THREE files: catalina.out (with stdout/err), tomcat.log (with the container's log4j output), and bar.log (with the webapp's log4j output, which I changed from ServletContext.log() to use Logger.info()). Instead, I got only catalina.out and tomcat.log, the latter containing everything that I thought the webapp would be sending to bar.log. ... log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localho st].[/myapp]=INFO, MYAPP log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[loc alhost].[/myapp]=false I don't understand this bracket notation. Is it documented anywhere? Is interpretation of it something implemented by tomcat or by log4j? Would it help me achieve what I'm trying to get without changing my webapp's code away from ServletContext.log()? BTW, you don't need commons-logging in your webapp. It is only Tomcat that needs it, so just put it in common/lib, not WEB-INF/lib. You can continue to put log4j.jar in both places if you desire. Otherwise, you can also use a repository selector to separate webapp logging with a single log4j.jar in common/lib. This makes more sense to start doing with Log4j-1.3, though, using the ContextJNDISelector. You get the same effect by having log4j.jar in WEB-INF/lib since the classloader isolation will, effectively, create logging isolation per webapp. Hmm.. I'm using log4j-1.2.9. I had the jar in both places but wasn't getting the isolation since my webapp was still pumping things into tomcat.log according to the container's log4j.properties.. However, I'm creating the logger in a static block in one of my webapp's classes -- could that have been the issue? At 06:18 PM 3/1/2005 -0500, you wrote: I'm having trouble approximating the earlier tomcat per-context Logger functionality using log4j under tomcat-5.5. Basically, I would like to have one file coming out under $CATALINA_BASE/logs/ per web application context. This appears to be no longer possible through ServletContext.log(). So I tried using log4j: 1) put log4j.jar, commons-logging.jar in common/lib AND webapps/*/WEB-INF/lib 2) put log4j.properties in common/classes AND webapps/*/WEB-INF/classes However, I can't seem to find the right combination of log4j.properties lines, or maybe I'm trying something impossible. (I can't find good docs on the uses of log4j.properties when used inside the hierarchical classloading context that tomcat provides.) What keeps happening is that the webapp's log statements keep going into the global tomcat log. Would I be better off with JDK logging instead? common/classes/log4j.properties --- log4j.rootLogger info, R log4j.appender.R org.apache.log4j.RollingFileAppender log4j.appender.R.File ${catalina.base}/logs/tomcat.log log4j.appender.R.MaxFileSize 10MB log4j.appender.R.MaxBackupIndex10 log4j.appender.R.layoutorg.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern %p %t %c - %m%n
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Wed, 02 Mar 2005 09:22:33 -0500, Adrian Robert [EMAIL PROTECTED] wrote: ... log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localho st].[/myapp]=INFO, MYAPP log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[loc alhost].[/myapp]=false I don't understand this bracket notation. Is it documented anywhere? Is interpretation of it something implemented by tomcat or by log4j? Would it help me achieve what I'm trying to get without changing my webapp's code away from ServletContext.log()? The logger names used in Tomcat are documented in the configuration pages. For example for webapps, it's here, in the Logging paragraph: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Wed, 02 Mar 2005 09:21:08 -0500, Adrian Robert [EMAIL PROTECTED] wrote: On Mar 1, 2005, at 6:45 PM, Remy Maucherat wrote: On Tue, 01 Mar 2005 18:18:49 -0500, Adrian Robert [EMAIL PROTECTED] wrote: However, I can't seem to find the right combination of log4j.properties lines, or maybe I'm trying something impossible. (I can't find good docs on the uses of log4j.properties when used inside the hierarchical classloading context that tomcat provides.) What keeps happening is that the webapp's log statements keep going into the global tomcat log. Would I be better off with JDK logging instead? I am working at the moment on a small package (which will be an implementation of java.util.logging) which will allow you doing that using the JDK logging. The main issue with it as supplied in the JDK is that there is only one global configuration per JVM. The trick is to make that per classloader, with delegation, so that webapps are isolated. At the moment, I think log4j is your only choice (unfortunately, I'm no expert, so I can't give you tricks with this particular configuration). In the same package, I will also provide a handler with daily rotation. It should be done by the end of the week (it doesn't work at the moment, I'm busy debugging ;) ). Great news. I'm happy to help test this. I'd rather use JDK logging than log4j if possible to avoid an additional deployment dependency. Actually, this is still an extra dependency: you have to add a JAR (10KB at the moment, but it'll likely grow to 12KB once I finish the needed extensions to the standard java.util.logging) for the core (the LogManager) and the rotating file handler (the JDK impl's handler don't have anything which rotates). It works by providing a replacement impementation for the JDK's LogManager which keeps a per classloader set of loggers. This is configured using a per classloader logging.properties (same format as the main logging.properties of the JDK, but with a few additional tricks to allow more flexibility with defining handlers and assigning them to loggers whenever needed). Properties files are simple, and are a good default. If no logging.properties exist anywhere, the JDK configuration will be used. Support for other configuration sources can be done using separate LogManager implementations. At the moment, the code will live in the Tomcat CVS, but the general consensus is to migrate it to commons eventually. We'll see. I don't know either if it will be included in the Tomcat binary; at the moment, I'd say it will not. The seed code for the new LogManager (which is attached to bug 33143) is here: http://issues.apache.org/bugzilla/attachment.cgi?id=14036 It doesn't actually work, and all it does is separate logger instances (which is quite good already, as you can programmatically set levels, assign handlers, etc, but you need to code for java.util.logging to use that). So I'm working on extending it at the moment to allow non programmatical configuration, where your webapp can simply be coded for commons-logging. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
Quoting Adrian Robert [EMAIL PROTECTED]: On Mar 2, 2005, at 12:25 AM, Jacob Kjome wrote: You first talk about ServletContext.log(), but then talk about log4j loggers in your app. These are two completely separate things. Which were you focusing on? With your setup, it it makes sense that ServletContext.log() messages are going to catalina.log. However, if you have log4j.jar in WEB-INF/lib and your application log4j logging is going to catalina.log, then your setup is different than what you describe here. There is quite simply no way that can happen given the setup you've described. They should go to bar.log since that's the only appender that your application's log4j configuration can see. In any case, you don't need a separate log4j.jar in WEB-INF/lib for ServletContext.log() messages to go to app-specific log files. Just define those in your log4j.properties just like you have defined the host logger. Here's my setup for Log4j-1.2.9 in common/classes.log4j.properties (You can use log4j.xml when using Log4j-1.3 because it uses a the new JoranConfigurator which doesn't define a log4j.dtd. The current DOMConfigurator's dtd defines the logger name attribute as an ID and the host and context logger names that Tomcat uses characters not allowed in attributes of type id) Thanks for your input.. I realize I wasn't clear about one thing. I don't want to define webapp-specific logging in the tomcat-global log4j.properties file. Instead, I want individual log4j.properties stored under webapp/*/WEB-INF/classes to cause logging to web-app specific files, without the container needing to be hard-coded for the webapps it is hosting. Understandable. I was a little dismayed to see that what had been more automatic in Tomcat-5.0.xx had become less so in Tomcat-5.5. What I mean is, in Tomcat-5.0.xx, one could add a Logger to the context configuration file, deploy that with the webapp, and dynamically get a log file for ServletContext.log() output. In Tomcat-5.5, one has to have this in the logger config file at Tomcat startup, therefore forcing one to predict the apps that will be deployed to the appserver during runtime. Of course, Tomcat could continue to use the Logger syntax, but only have it mean to programatically use the currently configured logger implementation to add the logger to the existing config rather than literally create a catalina logger which no longer exists. This would continue to make Tomcat-5.5 more involved in logging than it should, though. I think Yoav Shapira has it right when he says that Tomcat should not really be directly involved in logging, but use the external implementation. I'm not sure what the solution is. Probably needs more discussion. I was trying to achieve this with multiple separate log4j.properties, one in the container (common/classes/) for the uncaught stack trace and other general logging, and others in each webapp. With my setup below I was expecting to get THREE files: catalina.out (with stdout/err), tomcat.log (with the container's log4j output), and bar.log (with the webapp's log4j output, which I changed from ServletContext.log() to use Logger.info()). Instead, I got only catalina.out and tomcat.log, the latter containing everything that I thought the webapp would be sending to bar.log. And this should have worked. It works in every case I have ever tried. I suggest you double and triple check that you have log4j.jar in both common/lib and WEB-INF/lib and make sure you have log4j.properties in both common/classes and WEB-INF/classes. One thing that can trip people up is having a log4j.xml file somewhere in the classpath, whether it is in a jar or in WEB-INF/classes. Log4j looks for log4j.xml first and only looks for log4j.properties if it doesn't find it. If a rogue log4j.xml file is sitting in the classpath somewhere your webapp might be using it rather than the log4j.properties you think it is using. This is one of the reasons I always use XML config files rather than property files. I only use log4j.properties for Tomcat-5.5 because of incompatibilities with Tomcat-5.5 context and host logger names and Log4j-1.2.x's dtd. Again, Log4j-1.3 solves this be no longer having a DTD. ... log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localho st].[/myapp]=INFO, MYAPP log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[loc alhost].[/myapp]=false I don't understand this bracket notation. Is it documented anywhere? Is interpretation of it something implemented by tomcat or by log4j? Would it help me achieve what I'm trying to get without changing my webapp's code away from ServletContext.log()? See Remy's message about this. It is detailed in the Tomcat docs. BTW, you don't need commons-logging in your webapp. It is only Tomcat that needs it, so just put it in common/lib, not WEB-INF/lib. You can continue to put
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Wed, 2 Mar 2005 11:09:56 -0600, Jacob Kjome [EMAIL PROTECTED] wrote: Quoting Adrian Robert [EMAIL PROTECTED]: exists. This would continue to make Tomcat-5.5 more involved in logging than it should, though. I think Yoav Shapira has it right when he says that Tomcat should not really be directly involved in logging, but use the external implementation. I'm not sure what the solution is. Probably needs more discussion. That's the idea. Logging services should be external, rather than proprietary to Tomcat. the problem comes that we need some kind of defaults (like the current one, which is use whatever java.util.logging defaults are configured). Hmm.. I'm using log4j-1.2.9. I had the jar in both places but wasn't getting the isolation since my webapp was still pumping things into tomcat.log according to the container's log4j.properties.. However, I'm creating the logger in a static block in one of my webapp's classes -- could that have been the issue? Do you have webapp libraries sitting in a shared classloader such as shared/lib or common/lib? That would do it. 1. Make sure all your application classes are in WEB-INF/lib or WEB-INF/classes 2. Make sure log4j.jar is in WEB-INF/lib (remove commons-logging.jar if it is there. If you don't specifically need it, it can, and will, cause problems for you) 3. Make sure log4j.jar and commons-logging.jar (not commons-logging-api.jar!!!) are in common/lib 4. Make sure you have log4j.properties in both common/classes and WEB-INF/classes. You might even want to switch to using a log4j.xml config file for your webapp just to be sure that you aren't picking another log4j.xml file improperly distributed in a jar file. If you do all the above, logging should work as you expect. Note that for ServletContext.log() statements to go to context-specific files, you will still have to define the loggers as detailed in the example log4j.properties that I sent in my previous email. It's a bit tricky sometimes. For example, getting the container logger a bit too early, when the context CL isn't set to the webapp CL (it doesn't exist yet) can get you a logger based on the main configuration. That's an issue with the current CVS code, but I think it should be ok with the version used here (although it's tough to be 100% sure). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Tue, 01 Mar 2005 18:18:49 -0500, Adrian Robert [EMAIL PROTECTED] wrote: I'm having trouble approximating the earlier tomcat per-context Logger functionality using log4j under tomcat-5.5. Basically, I would like to have one file coming out under $CATALINA_BASE/logs/ per web application context. This appears to be no longer possible through ServletContext.log(). So I tried using log4j: 1) put log4j.jar, commons-logging.jar in common/lib AND webapps/*/WEB-INF/lib 2) put log4j.properties in common/classes AND webapps/*/WEB-INF/classes However, I can't seem to find the right combination of log4j.properties lines, or maybe I'm trying something impossible. (I can't find good docs on the uses of log4j.properties when used inside the hierarchical classloading context that tomcat provides.) What keeps happening is that the webapp's log statements keep going into the global tomcat log. Would I be better off with JDK logging instead? I am working at the moment on a small package (which will be an implementation of java.util.logging) which will allow you doing that using the JDK logging. The main issue with it as supplied in the JDK is that there is only one global configuration per JVM. The trick is to make that per classloader, with delegation, so that webapps are isolated. At the moment, I think log4j is your only choice (unfortunately, I'm no expert, so I can't give you tricks with this particular configuration). In the same package, I will also provide a handler with daily rotation. It should be done by the end of the week (it doesn't work at the moment, I'm busy debugging ;) ). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
You first talk about ServletContext.log(), but then talk about log4j loggers in your app. These are two completely separate things. Which were you focusing on? With your setup, it it makes sense that ServletContext.log() messages are going to catalina.log. However, if you have log4j.jar in WEB-INF/lib and your application log4j logging is going to catalina.log, then your setup is different than what you describe here. There is quite simply no way that can happen given the setup you've described. They should go to bar.log since that's the only appender that your application's log4j configuration can see. In any case, you don't need a separate log4j.jar in WEB-INF/lib for ServletContext.log() messages to go to app-specific log files. Just define those in your log4j.properties just like you have defined the host logger. Here's my setup for Log4j-1.2.9 in common/classes.log4j.properties (You can use log4j.xml when using Log4j-1.3 because it uses a the new JoranConfigurator which doesn't define a log4j.dtd. The current DOMConfigurator's dtd defines the logger name attribute as an ID and the host and context logger names that Tomcat uses characters not allowed in attributes of type id) log4j.appender.A1=org.apache.log4j.ConsoleAppender log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%-5p[%-8.8t]: %39.39c %-6r - %m%n log4j.appender.LOCALHOST=org.apache.log4j.RollingFileAppender log4j.appender.LOCALHOST.File=${catalina.home}/logs/localhost.log log4j.appender.LOCALHOST.MaxFileSize=1000KB log4j.appender.LOCALHOST.MaxBackupIndex=1 log4j.appender.LOCALHOST.layout=org.apache.log4j.PatternLayout log4j.appender.LOCALHOST.layout.ConversionPattern=%-5p[%-8.8t]: %39.39c %-6r - %m%n log4j.appender.MYAPP=org.apache.log4j.DailyRollingFileAppender log4j.appender.MYAPP.File=${catalina.base}/logs/localhost_myapp.log log4j.appender.MYAPP.DatePattern='.'-MM-dd log4j.appender.MYAPP.layout=org.apache.log4j.PatternLayout log4j.appender.MYAPP.layout.ConversionPattern=%c{1} %-6r - %m%n log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/myapp]=INFO, MYAPP log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/myapp]=false log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=INFO, LOCALHOST log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=false log4j.rootLogger=INFO, A1 Note that I use a ConsoleAppender because when I run from the command line, I want the output going to the command window. When I use a service, the service captures the console output and writes it to a log file named stdout.log. This is why I don't specify the file. It is done for me (and rolled daily for me). Also note the use of additivity on the host and context loggers. This is to avoid double logging to the appender configured by the root logger and the one specifically configured for the host/context log. BTW, you don't need commons-logging in your webapp. It is only Tomcat that needs it, so just put it in common/lib, not WEB-INF/lib. You can continue to put log4j.jar in both places if you desire. Otherwise, you can also use a repository selector to separate webapp logging with a single log4j.jar in common/lib. This makes more sense to start doing with Log4j-1.3, though, using the ContextJNDISelector. You get the same effect by having log4j.jar in WEB-INF/lib since the classloader isolation will, effectively, create logging isolation per webapp. Jake At 06:18 PM 3/1/2005 -0500, you wrote: I'm having trouble approximating the earlier tomcat per-context Logger functionality using log4j under tomcat-5.5. Basically, I would like to have one file coming out under $CATALINA_BASE/logs/ per web application context. This appears to be no longer possible through ServletContext.log(). So I tried using log4j: 1) put log4j.jar, commons-logging.jar in common/lib AND webapps/*/WEB-INF/lib 2) put log4j.properties in common/classes AND webapps/*/WEB-INF/classes However, I can't seem to find the right combination of log4j.properties lines, or maybe I'm trying something impossible. (I can't find good docs on the uses of log4j.properties when used inside the hierarchical classloading context that tomcat provides.) What keeps happening is that the webapp's log statements keep going into the global tomcat log. Would I be better off with JDK logging instead? common/classes/log4j.properties --- log4j.rootLogger info, R log4j.appender.R org.apache.log4j.RollingFileAppender log4j.appender.R.File ${catalina.base}/logs/tomcat.log log4j.appender.R.MaxFileSize 10MB log4j.appender.R.MaxBackupIndex10 log4j.appender.R.layoutorg.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern %p %t %c - %m%n #log4j.logger.org.apache.catalina info, R