On Wed, Jun 18, 2008 at 04:44:21PM -0400, Christopher Schultz wrote: > | 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 :(
Not so. JULI imposes a standard way to configure logging, else it could not find its configuration. Whatever else the packaging team do, they must eventually either let JULI look where it always looks or tell it in a standard way (-Djava.util.logging.config.file=/some/path) where to find it. Either way, you know where to look. The same applies to log4j. It either uses a built-in assumption or is told where to look in a way that is defined by log4j, not your distro. > | 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 There is no occurrence of TOMCAT_HOME in the startup scripts for "real" Tomcat 6.0.16 -- I checked yesterday. There are only two occurrences of that string in the entire kit, and they are in documentation. Maybe this is part of the confusion? [snip] > 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: This is hardly necessary. All TC-related *configuration* files will either be in one place, or they will point to each other. If this was not so, they would not participate in configuring Tomcat and could be ignored. It's not magic; the software has to be able to find all of its bits, and if it can then you can too, by doing the same thing that the software does. Example: Gentoo Linux. If you are starting up something called "tomcat-6", you know (because this is Gentoo) that you should execute /etc/init.d/tomcat-6. That script (which you can read to find out everything it will do) will source /etc/conf.d/tomcat-6, where we easily find the values of CATALINA_HOME and CATALINA_BASE. Look in $CATALINA_BASE/conf and you find all of Tomcat's configuration data. Look in /etc/init.d/tomcat-6 and you will see the command used to start Tomcat. That should be enough information to locate all configuration data -- after all, that's all that Tomcat has to go on. [EMAIL PROTECTED] ~ $ ps ax | grep tomcat 6026 ? S 0:00 /bin/bash /sbin/runscript.sh /etc/init.d/tomcat-6 start 6037 ? Sl 4:28 /opt/sun-jdk-1.6.0.06/bin/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/var/lib/tomcat-6//conf/logging.properties -classpath /usr/share/tomcat-6/lib/:/usr/share/tomcat-6//lib:/opt/sun-jdk-1.6.0.06/lib/tools.jar:/usr/share/tomcat-6//bin/bootstrap.jar:/usr/share/tomcat-6//bin/tomcat-juli.jar -Dcatalina.base=/var/lib/tomcat-6/ -Dcatalina.home=/usr/share/tomcat-6/ -Djava.io.tmpdir=/var/tmp/tomca-6/ org.apache.catalina.startup.Bootstrap start 8722 pts/3 R+ 0:00 grep --colour=auto tomcat See? This Tomcat is explicitly told use JULI for logging, and its configuration is explicitly placed at '/var/lib/tomcat-6/conf/logging.properties'. If java.util.logging.config.file were not defined, JULI would use its built-in rules to find a configuration. If it were not told to use JULI, Commons Logging would use its built-in rules to work out what to do. "ps ax" is specific to the flavor of 'ps' you are running, but "determine the complete command which is running as Tomcat" isn't. [snip] > | 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? The page assumes that one knows how to use 'ant' and a text editor. This is not distribution-specific. How to pass property values to the JRE is perhaps JRE-specific but not distro-specific. One can (and should) document a product's configuration and use relative to what the product "knows", and require that the user understands the details of his own choice of operating environment. Tomcat, in particular, is told the paths represented by catalina.home and catalina.base, and uses that to configure its classloaders, which are used by the chosen logger to locate its default configuration. The name of the default configuration is specified by the chosen logger. The JRE running Tomcat is perhaps told the paths represented by other system properties whose names are specified by the logger. The only distro-specific thing in any of this is the particular paths assigned to these properties, and determining those values is the responsibility of the asker because, as you say, you cannot know them in advance. But an answer expressed in terms of the invariants can be interpreted by the asker and should be sufficient. And there *must* be invariants, a contract between dependency and dependent, or modular software cannot operate. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgp49ZSGbse4L.pgp
Description: PGP signature
