-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David,
David Fisher wrote: | All | my contexts logs are hijacked by Roller, and that is a roller question | that I can't ask due to my weird configuration. But if I understood | better how logging and tomcat interact I could understand. All of the logs are hijacked by roller, or only the one in which Roller is actually deployed? If you moved Roller libraries (or the whole thing) into Tomcat's lib directory, then you are probably making a mistake (your other memory issues notwithstanding). Tell me how you want your logs to act, and I'll try to give you a configuration you can start with, and hopefully improve upon. | My host context on Tomcat 4.1.31 looks like: | | <Host name="my.url.com" appBase="webapps-url" > | <Valve className="org.apache.catalina.valves.AccessLogValve" | directory="logs" prefix="my_url_access." suffix=".log" | pattern="common"/> | <Logger className="org.apache.catalina.logger.FileLogger" | directory="logs" prefix="my_url_logger." suffix=".log" | timestamp="true"/> | </Host> | | In Tomcat 5.5.26: | | <Host name="my.url.com" appBase="webapps-unity" > | <Valve | className="org.apache.catalina.valves.FastCommonAccessLogValve" | directory="logs" prefix="my_url_access." | suffix=".log" pattern="common"/> | </Host> I don't believe that these two configurations do the same thing. Are you asserting that they do, or that this was the best you could do? The 4.1.31 configuration does both access logging (like Apache httpd common log formatting) plus a general logger for interesting things that happen within the <Host> itself. Your 5.5 config only logs accesses. | How do I translate my 4.1.31 Logger to log4j in Tomcat 5.5.25? How do I | do the same for JULI logging? How do I combine the two? I'm no expert in JULI, but I can tell you that my experience was log4j was a bit confusing. I've been using log4j forever in my own applications, so I figured that configuring commons-logging within Tomcat to use log4j would be a breeze. It wasn't, unfortunately. I was also trying to introduce commons-logging in my own applications for whatever reason ;) My first problem was that the commons-logging documentation seems to indicate that the "best" logging system available would be chosen, and gives a load order in which log4j is detected before using the juli fallback. That appears to be true in the general sense, except that commons-logging is set up /before/ any contexts are loaded. That means that log4j needs to be in the server/shared/common lib directory in order for it to be detected. I'm not a big fan of that, since I like to use a clean Tomcat install so that upgrading isn't such a PITA. So, the first thing I learned was that I needed the following: 1. log4j.jar in my webapp's WEB-INF/lib directory (duh) 2. log4j.properties (or XML or however you indend to init log4j) needs ~ to be in my webapp's WEB-INF/classes directory (duh) 3. commons-logging.jar 4. commons-logging.properties in my webapp's WEB-INF/classes directory ~ Mine looks like this: org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger 5. Use a ServletContextListener to shutdown commons-logging cleanly when ~ the context gets cleaned-up (details elsewhere for brevity). This last point seems counter-intuitive given that a) commons-logging says that it will look for log4j before falling-back on juli and b) commons-logging has already been initialized, so why does it automagically re-configure itself to work within the webapp? See below. At this point, commons-logging should start emitting log messages to your configured log4j log files. As indicated in another post, I'm using DailyRollingFilAppender which will roll depending on the pattern you use for the date in the filename, rather than strictly "daily", as the name of the class might suggest. | How does the classloader come into play? I know it has some affect | because there is mention in the docs of tomcat/common/ vs. tomcat/shared/? Yup. ClassLoaders are important because of the way they (duh) load classes. Most ClassLoaders are implemented like this: public Class loadClass(String className) { ~ Class clazz = parentClassLoader.loadClass(className); ~ if(null == clazz) ~ clazz = this.actuallyLoadTheClass(className); ~ return clazz; } That is, the parent class loader is consulted first when loading classes. The WebappClassLoader, in contrast (and specified in the servlet spec) does this: public Class loadClass(String className) { ~ Class clazz = this.actuallyLoadTheClass(className); ~ if(null =-= clazz) ~ parentClassLoader.loadClass(className); ~ return clazz; } Note that it's behavior is exactly the opposite: libraries found in both your webapp AND the Tomcat shared or common lib directories (which are unified in TC 6, btw) will be loaded FROM YORU WEBAPP, not from the parent classloader. This is actually to your advantage, since it allows you to trump libraries loaded (directly) by Tomcat in your own webapp, thus having much more control over your own application. Now, back to logging. Since commons-logging.jar is in your own webapp, a re-configuration occurs when your webapp is initialized (actually, it's not re-configuration... the TC commons-logging instance has already been configured.... it's just that your webapp's instance of commons-logging is now being loaded and configured for the first time). When you configure commons-logging for your own application (for me, through log4j.properties), you can selectively log various classes and log levels to different files. Here's my configuration for log4j in development: # hash marks indicate comments log4j.rootCategory=INFO,A1 # A1 is the "appender", which is something that actually writes log # statements to a file/whatever log4j.appender.A1=org.apache.log4j.FileAppender log4j.appender.A1.file = @app-log-dir@/log4j.log log4j.appender.A1.layout = org.apache.log4j.PatternLayout log4j.appender.A1.layout.conversionPattern = %d [%t] %-5p %c- %m%n log4j.appender.A1.append = true # Turn-up the logging level on our code. log4j.category.[our base package name] = ALL This configures a single appender (A1) that writes to a file. No rolling or anything like that. Our code (identified by package on that last line) emits 100% of the logging statements to our file. All other classes (Tomcat, commons-digester, other libraries) are limited to INFO and higher statements. | Do the answers differ for Tomcat 6? TC 5.5 and TC 6 are very similar, so I'm guessing that logging configuration is very similar. | Now do you see why we simple users who must spend time programming their | apps, are confused? Especially when you go from having a VERY SIMPLE | interface to options you don't care about but are forced to make. Like | which health care plan? What about following the directions in http://tomcat.apache.org/tomcat-6.0-doc/logging.html? I haven't followed them myself, but they are quite straightforward. | | This is critical to me, I ought to go to Tomcat 6 and Java 6 as I go to | Apache / Tomcat (for load balancing, SSL front end and splitting parts | of webapps between differently configured tomcats, I certainly don't | want to waste time with logging configuration, | | Regards, | Dave | | | | | | --------------------------------------------------------------------- | To start a new topic, e-mail: users@tomcat.apache.org | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhWw8QACgkQ9CaO5/Lv0PB9bQCgnx4Fp1jSOHATDsTWi4/c5emr AJgAoIWEWyp69wzXBg+IK8Pnfu5eQWve =Lr7G -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]