-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
Okay, I'll bite. André Warnier wrote: | Assume that one has installed Tomcat 5.5 (or 6.0) on some system just by | using the standard software package management system for his Operating | System, and consequently finds himself with some Tomcat installation, | whose settings and layout have been chosen by a real guru (in both | Tomcat and in software packaging). Note that everything starts to fall apart right about .... here. ^^^ | Assume that the Tomcat in question works fine, but that it writes | logfiles all over the place (or all over time), and that one would like | to understand where these logfiles come from, and either slightly change | which logfiles are being produced, or add a specific logfile for a | specific application, or something simple like that. Okay. Sounds good. | Assume that one has read the Tomcat logging page at | http://tomcat.apache.org/tomcat-6.0-doc/logging.html Although the this is a good reference, you cannot follow any of the instructions on that page, because the logging has likely been set up in advance by the package manager. Since there is no standard way to configure logging (among package managers, that is), nobody on this list who doesn't have explicit experience with your OS/version/patchlevel/package manager can help you :( | The kind of things one would like to know are : | | - where to start ? | In other words, here I have a Tomcat and it is working and it is writing | logfiles, but I do not have a clue which kind of logging mechanism it is | using, either directly or indirectly. How do I find out ? What would be great is if you could, say, identify a log file (say, catalina.out) and then say "where did this come from"? The answer is easy, if you use the standard package from tomcat.apache.org: $ cd $TOMCAT_HOME $ grep catalina.out `find -type f` If I run this command on my stock TC 5.5 install, I get these results: ./bin/catalina.sh ./webapps/jsp-examples/WEB-INF/classes/validators/DebugValidator.java ./webapps/tomcat-docs/printer/jndi-datasource-examples-howto.html ./webapps/tomcat-docs/printer/setup.html ./webapps/tomcat-docs/jndi-datasource-examples-howto.html ./webapps/tomcat-docs/setup.html Ignoring the documentation and code results, I can see that bin/catalina.sh mentions catalina.out. Let's take a look, shall we? Reading catalina.sh, you'll find that this line appears in several places in the script: ~ >> "$CATALINA_BASE"/logs/catalina.out 2>&1 & after certain commands. This indicates that catalina.out is redirected standard output. Just got grins, let's come up with another one. I've got a file called localhost.2008-06-18.log in my "logs" directory. How'd it get there? Lessee... $ grep -l 'localhost.*\.log' `find -type f ` conf/logging.properties Hey! Look at that! A file just for setting up logging properties? That's crazy! ...rinse, repeat. Unfortunately, if you installed your TC from a package manager, you probably don't have all the TC-related files in a single place. That wouldn't be such a big deal if it didn't take quite a while to grep every file on your system: $ grep catalina.out `find / -type f` ... snore .... TC and package management gurus indeed. The problem is that the UNIX philosophy has always been "there's one binary, a config directory somewhere under /etc, and the logs go under /var/log". It's bad enough that we have to have dozens of config files and deployment directories for Apache httpd... TC makes it even worse because it's more application-based than directory-based. ClassLoaders and system properties and endorsed libraries, oh my! Shoehorning TC into a semi-typical Linux (or UNIX) package management scheme often leads to confusion with people who read official documentation that suggests that the world is otherwise. And we (on this list) get the fallout, instead of the wankers from the distros who muck everything up in the first place. ...but I digress. Let's move on. | - how does it work ? | In other words : it would seem that the kind of logging adopted in | Tomcat 5.5/6.0 is very powerful and flexible, allowing one to decide "at | the top" which mechanism is being used, and then define either some | overall generic logging settings for the whole Tomcat and valid for all | components and applications, and/or refine this at just about each | hierarchical level of Tomcat, Engine, Connector, Host, application and | whatnot, at whatever level of detail one needs between CRASH and CHATTY. | Great. Yup. See the aforementioned logging.properties file. And read the TC logging documentation, which you assumed was read. If you look through the logging.properties file, you may gain some insight into how the output from each level/application/host/etc is routed into separate files. | - how does one set up a really simple logging configuration, but one | that will allow in the future some gradual tailoring and refinement | without complete redesign ? Use the one that came configured with your TC installation. Locate the logging.properties file, and "simplify" it, whatever that means. Take out loggers you don't want. Run everything into /var/log/all-tomcat.log. Do whatever you want. Examples come with the stock TC install from tomcat.apache.org. Your distro doesn't? Hmm. Complain to them. Our documentation is short, and following the instructions ends up working. | I would like to have, for the whole of Tomcat : | - one monthly file that shows the equivalent of an Apache "error log" I don't see a way to make juli rotate logfiles on a different schedule than once per day. I /do/ know that log4j can do it by using a DailyRollingFileAppender (with rolling set to 'monthly'). If I were doing this myself, I would follow the instructions on TC's logging page to switch from using juli to using log4j, and then configure log4j to emit the log you describe above. This is easier for me, because I have much more familiarity with log4j than with juli/jdk-logging/whatever. If I were adamant about using juli, I would probably read all about how to configure java 1.4 logging. | - one monthly file that shows the equivalent of an Apache "access log" This is done using an AccessLogValve, which is somewhat orthogonal to the issue of "logging" as it is being covered, here. This has been pretty consistent across TC versions. | b) when the above is achieved, then I'd like to re-introduce a separate | access log for each Host. How do I do that ? Different <Valve> under each host. http://www.google.com/search?q=tomcat%20access%20log | c) when the above is achieved, then I'd like to re-introduce a separate | log for just the "MyApp" application. How do I do that ? That depends. Do you want to just log the Tomcat-specific log messages, or those from your own application? I'm guessing that, given yout lack of familiarity of logging systems in webapps, you are not using commons-logging in your own web application. That pretty much means that you're not going to get everything into one log file unless you can convince TC to hook into your application-specific logging system. If you just want the former, and you've already switched to log4j (as I suggest above), you'll need to add further configuration to log4j. You'll need an appender (which writes log messages to something -- file/xmtp/whatever) and you will need to identify the logger that dumps to that appender. Given the examples provided in logging.properties, I'd do something like this and see if it works: log4j.appender.MyApp=org.apache.log4j.DailyRollingFileAppender log4j.appender.MyApp.file=/path/to/your/logs/MyApp.log # Set DRFA to roll on a monthly basis log4j.appender.MyApp.DatePattern='.'yyyy-MM log4j.appender.MyApp.layout = org.apache.log4j.PatternLayout log4j.appender.MyApp.layout.conversionPattern= %d [%t] %-5p %c- %m%n # Do not overwrite files log4j.appender.MyApp.append=true # Configure this 'category' (logger) to go to MyApp's logfile log4j.category.org.apache.catalina.code.ContainerBase.[Catalina].[localhost].[/MyApp]=INFO,MyApp | And no, the page at http://tomcat.apache.org/tomcat-6.0-doc/logging.html | is not enough to answer the above. It assumes from the reader a greater | knowledge of Java and Tomcat than most Tomcat users have, and it | presupposes, I guess, that the installed Tomcat has been built | on-the-spot from the original Tomcat distribution How can we document a distribution we not only do not distribute, but have no control over? | and I believe that this is not the case for the majority of subscribers to this "Tomcat | users" list. The majority of posts on this list either do not mention their use of package management, or end up being solved by removing the package-managed TC installation and starting from scratch (and then following the correct documentation). Okay, that's the last thing I'm saying about logging for a while without getting paid. :p - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhZc6UACgkQ9CaO5/Lv0PAVlwCeJ8gYvMaE3nVmpZdrYMDnMuTF dmYAn1akmjKdv2hhBDrxiNihKhQeCvY3 =ChqB -----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]
