Re: Logging for Dummies in Tomcat 5.5/6.0
According to this text from http://minaret.biz/tips/tomcatLogging.html#tomcat_5_5_logging : "The configuration described here results in the creation of two log files for Tomcat 5.5 and three log files for Tomcat 5.0: the Servlet log file (only with Tomcat 5.0), which will roll over to a new file every night; the Commons Logging data via log4j (which will also roll over every night) and the catalina.out file, which will only contain messages that have been printed to standard output and standard error. The last file will grow forever but well behaved applications within your Tomcat server should not be printing to standard out or error, so this should not really be an issue (in general, the file should remain zero length)." I created the log4j.properties and it is actually produced with log statements, but catalina.out still gets the same logstatements plus system.out's. Another thing, the logging.properties has any impact on which application logs are written? regards emerson On 13/08/2008, emerson cargnin <[EMAIL PROTECTED]> wrote: > If I redirect log4j logs as described int he page below, is it not > adivisable to remove the console redirection to catalina.out? > > http://minaret.biz/tips/tomcatLogging.html#tomcat_5_5_logging > > emerson > > On 20/06/2008, Mark Thomas <[EMAIL PROTECTED]> wrote: > > André Warnier wrote: > > > To attempt a summary of the discussions so far, it sems that there are two > > distinct groups : Tomcat developers, and Tomcat users, > > > > > > > There might be two lists but I don't think it is quite that simple. The > > standard ASF definitions can be found here > > http://www.apache.org/foundation/how-it-works.html#roles > > > > > The developers seem to be happy with the logging and its documentation as > > it is, and consider it clear, or at least accessible. The users, as far as > > I can tell from the correspondence I receive, generally have a different > > opinion. > > > > > > > This is less a user/developer(actually committer in ASF terms) issue and > > more one how complex your environment is. For the simple environments, the > > Tomcat 4 appeared to be fine although often there were some nasty memory > > leaks hiding in the background. For the complex ones there was a world of > > pain trying to get logging configured. There were often instances of the > > logs for webapp A being logged to webapp B. The root causes of this were > > many. Take a look at the dev archive and/or Bugzilla if you want more info. > > > > > I believe that the difference of opinions rests basically on the following > > : at some point in time, the developers of Tomcat - who it should be > > remembered do this for free - decided that maintaining Tomcat's own logging > > mechanism wasn't really worth their time and efforts, considering that there > > existed already a couple of external libraries (packages?) which did the job > > better anyway. > > > > > > > This is not correct. I encourage you to read the code, or at least the > > build.properties.default file, before making such assertions. TC4 to TC6 all > > use commons logging. > > > > > They thus split that part off, allowing them to concentrate on more > > interesting and rewarding parts of the code. > > > > > > > Also not true. The TC4 logging simply wasn't up to the job. See above. > > > > > And they have no intention of moving back. > > > > > > > Absolutely. You are not goign to find any committer prepared to replace a > > working logging system with a broken one. > > > > > Them being the developers of a product offered free of charge, nobody can > > or should discuss their decision or blame them for it. > > > > > > > Anyone is free to join the developers list and discuss ways of improving > > the code. It helps a lot if you are prepared to roll up your sleeves and > > contribution bug reports, test cases or patches (to code or documentation). > > > > > What I personally believe they forgot at that point, is that there are > > many users of Tomcat who are not pure Java or Tomcat developers; that these > > users, having acquired over time a reasonable understanding of how to use > > Tomcat - if not necessarily how it works inside - now suddenly are faced > > with the need to get acquainted with a whole bunch of things of which they > > do not have a clue (commons-logging, juli, log4j), which per se do not > > really interest them (because they are not mainly Java developers) and which > > by themselves require quite an investment in time in order to start > > understanding how they work. > > > > > > > In this case bits needed to be replaced so it actually worked. Along the way > > the configuration process was changed. Given the choice between the old and > > the new, I'd take the implementation that actually works every time. > > > > > > > > > I don't think I need to continue. Mere Tomcat users will understand what > > I mean, and Tomcat developers can imagine what the average bloke using > > Tomcat occasionally, thinks when he stu
Re: Logging for Dummies in Tomcat 5.5/6.0
If I redirect log4j logs as described int he page below, is it not adivisable to remove the console redirection to catalina.out? http://minaret.biz/tips/tomcatLogging.html#tomcat_5_5_logging emerson On 20/06/2008, Mark Thomas <[EMAIL PROTECTED]> wrote: > André Warnier wrote: > > To attempt a summary of the discussions so far, it sems that there are two > distinct groups : Tomcat developers, and Tomcat users, > > > > There might be two lists but I don't think it is quite that simple. The > standard ASF definitions can be found here > http://www.apache.org/foundation/how-it-works.html#roles > > > The developers seem to be happy with the logging and its documentation as > it is, and consider it clear, or at least accessible. The users, as far as > I can tell from the correspondence I receive, generally have a different > opinion. > > > > This is less a user/developer(actually committer in ASF terms) issue and > more one how complex your environment is. For the simple environments, the > Tomcat 4 appeared to be fine although often there were some nasty memory > leaks hiding in the background. For the complex ones there was a world of > pain trying to get logging configured. There were often instances of the > logs for webapp A being logged to webapp B. The root causes of this were > many. Take a look at the dev archive and/or Bugzilla if you want more info. > > > I believe that the difference of opinions rests basically on the following > : at some point in time, the developers of Tomcat - who it should be > remembered do this for free - decided that maintaining Tomcat's own logging > mechanism wasn't really worth their time and efforts, considering that there > existed already a couple of external libraries (packages?) which did the job > better anyway. > > > > This is not correct. I encourage you to read the code, or at least the > build.properties.default file, before making such assertions. TC4 to TC6 all > use commons logging. > > > They thus split that part off, allowing them to concentrate on more > interesting and rewarding parts of the code. > > > > Also not true. The TC4 logging simply wasn't up to the job. See above. > > > And they have no intention of moving back. > > > > Absolutely. You are not goign to find any committer prepared to replace a > working logging system with a broken one. > > > Them being the developers of a product offered free of charge, nobody can > or should discuss their decision or blame them for it. > > > > Anyone is free to join the developers list and discuss ways of improving > the code. It helps a lot if you are prepared to roll up your sleeves and > contribution bug reports, test cases or patches (to code or documentation). > > > What I personally believe they forgot at that point, is that there are > many users of Tomcat who are not pure Java or Tomcat developers; that these > users, having acquired over time a reasonable understanding of how to use > Tomcat - if not necessarily how it works inside - now suddenly are faced > with the need to get acquainted with a whole bunch of things of which they > do not have a clue (commons-logging, juli, log4j), which per se do not > really interest them (because they are not mainly Java developers) and which > by themselves require quite an investment in time in order to start > understanding how they work. > > > > In this case bits needed to be replaced so it actually worked. Along the way > the configuration process was changed. Given the choice between the old and > the new, I'd take the implementation that actually works every time. > > > > > I don't think I need to continue. Mere Tomcat users will understand what > I mean, and Tomcat developers can imagine what the average bloke using > Tomcat occasionally, thinks when he stumbles upon this. > > (And yes, it is from a particular packaging of Tomcat, but that's not the > point here; the official one is not simpler). > > > > Different people will have different views on the simplicity of the logging. > If all you want to do is make a small change I don't think there is much > difference. If you want to understand it, TC4 looks simpler but the > class-loading complexities which are not at all obvious at first glance (or > after several hours pouring over the code) will come back to bite you when > you think you understand what is going on. > > > Now above I am playing somewhat dumb, because since this thread started, I > have already started to understand some aspects of the above. > > But even with this increased understanding, my basic feeling about it > remains that it looks like a gigantic overkill and waste of time compared to > the needs - and time available for this - of most Tomcat users. > > To look at it another way, by making this change, and for most simple > cases, one has replaced 3 lines inserted in server.xml or context.xml, by > hundreds of lines "all over the place" (I am counting the docs, because they > are needed now, and they were not before). > > I c
Re: Logging for Dummies in Tomcat 5.5/6.0
André Warnier wrote: To attempt a summary of the discussions so far, it sems that there are two distinct groups : Tomcat developers, and Tomcat users, There might be two lists but I don't think it is quite that simple. The standard ASF definitions can be found here http://www.apache.org/foundation/how-it-works.html#roles The developers seem to be happy with the logging and its documentation as it is, and consider it clear, or at least accessible. The users, as far as I can tell from the correspondence I receive, generally have a different opinion. This is less a user/developer(actually committer in ASF terms) issue and more one how complex your environment is. For the simple environments, the Tomcat 4 appeared to be fine although often there were some nasty memory leaks hiding in the background. For the complex ones there was a world of pain trying to get logging configured. There were often instances of the logs for webapp A being logged to webapp B. The root causes of this were many. Take a look at the dev archive and/or Bugzilla if you want more info. I believe that the difference of opinions rests basically on the following : at some point in time, the developers of Tomcat - who it should be remembered do this for free - decided that maintaining Tomcat's own logging mechanism wasn't really worth their time and efforts, considering that there existed already a couple of external libraries (packages?) which did the job better anyway. This is not correct. I encourage you to read the code, or at least the build.properties.default file, before making such assertions. TC4 to TC6 all use commons logging. They thus split that part off, allowing them to concentrate on more interesting and rewarding parts of the code. Also not true. The TC4 logging simply wasn't up to the job. See above. And they have no intention of moving back. Absolutely. You are not goign to find any committer prepared to replace a working logging system with a broken one. Them being the developers of a product offered free of charge, nobody can or should discuss their decision or blame them for it. Anyone is free to join the developers list and discuss ways of improving the code. It helps a lot if you are prepared to roll up your sleeves and contribution bug reports, test cases or patches (to code or documentation). What I personally believe they forgot at that point, is that there are many users of Tomcat who are not pure Java or Tomcat developers; that these users, having acquired over time a reasonable understanding of how to use Tomcat - if not necessarily how it works inside - now suddenly are faced with the need to get acquainted with a whole bunch of things of which they do not have a clue (commons-logging, juli, log4j), which per se do not really interest them (because they are not mainly Java developers) and which by themselves require quite an investment in time in order to start understanding how they work. In this case bits needed to be replaced so it actually worked. Along the way the configuration process was changed. Given the choice between the old and the new, I'd take the implementation that actually works every time. I don't think I need to continue. Mere Tomcat users will understand what I mean, and Tomcat developers can imagine what the average bloke using Tomcat occasionally, thinks when he stumbles upon this. (And yes, it is from a particular packaging of Tomcat, but that's not the point here; the official one is not simpler). Different people will have different views on the simplicity of the logging. If all you want to do is make a small change I don't think there is much difference. If you want to understand it, TC4 looks simpler but the class-loading complexities which are not at all obvious at first glance (or after several hours pouring over the code) will come back to bite you when you think you understand what is going on. Now above I am playing somewhat dumb, because since this thread started, I have already started to understand some aspects of the above. But even with this increased understanding, my basic feeling about it remains that it looks like a gigantic overkill and waste of time compared to the needs - and time available for this - of most Tomcat users. To look at it another way, by making this change, and for most simple cases, one has replaced 3 lines inserted in server.xml or context.xml, by hundreds of lines "all over the place" (I am counting the docs, because they are needed now, and they were not before). I can imagine on the other hand that for developers this might be an immense improvement, but again that's not the point here. You need to get it out of your head the this was done for the benefit of anyone but the users. The changes were made for the benefit of users so that we had a logging system that worked. I will continue to study it of course, because I have no choice if I want to twiddle ever so slightly with
Re: Logging for Dummies in Tomcat 5.5/6.0
Hi. I'm back.
First of all, I appreciate the information received already as a
response to my initial post, and I am thankful for it. I keep on reading
and collecting the new stuff coming, and getting enlightened by it.
There is a lot of information there, which for a large part - in my
opinion - is not in the current Tomcat published documentation, or not
in a way that a person with occasional and superficial contact with
Tomcat can find or understand.
But, together with the insights gained through this list, it slowly
starts to click into place.
This discussion started (a couple of threads ago) with a request on
logging configuration, made by a user - me - who could not make sense of
the files on his system(s), either belonging to Tomcat or produced by
it. It quickly degenerated into a slinging match mostly related to
Tomcat packaging.
To attempt a summary of the discussions so far, it sems that there are
two distinct groups : Tomcat developers, and Tomcat users, and that
their views differ sometimes substantially on what a logging system
should do, and what a documentation should contain and how it should be
written. That is probably normal, because each person is looking at it
in a different way, in function of his needs.
The developers seem to be happy with the logging and its documentation
as it is, and consider it clear, or at least accessible. The users, as
far as I can tell from the correspondence I receive, generally have a
different opinion.
I believe that the difference of opinions rests basically on the
following : at some point in time, the developers of Tomcat - who it
should be remembered do this for free - decided that maintaining
Tomcat's own logging mechanism wasn't really worth their time and
efforts, considering that there existed already a couple of external
libraries (packages?) which did the job better anyway. They thus split
that part off, allowing them to concentrate on more interesting and
rewarding parts of the code. And they have no intention of moving back.
Them being the developers of a product offered free of charge, nobody
can or should discuss their decision or blame them for it.
What I personally believe they forgot at that point, is that there are
many users of Tomcat who are not pure Java or Tomcat developers; that
these users, having acquired over time a reasonable understanding of how
to use Tomcat - if not necessarily how it works inside - now suddenly
are faced with the need to get acquainted with a whole bunch of things
of which they do not have a clue (commons-logging, juli, log4j), which
per se do not really interest them (because they are not mainly Java
developers) and which by themselves require quite an investment in time
in order to start understanding how they work.
From a user point of view, how to express it better than comparing
logging in Tomcat 4.1, with logging in Tomcat 5.5 :
- to create a logfile in Tomcat 4.1, the user inserted this in his
server.xml or context.xml at the appropriate place :
Basically, that was it. If you needed logging at another level, you
just copied this section and pasted it wherever logically it seemed to
fit. It wasn't terribly flexible, and did not help immensely for
debugging code, but that was not the main purpose, and for the main
purpose of the vast majority of users, it sufficed.
One did not really need to understand how a Logger worked, and one could
rather easily guess from the atributes what could be tweaked and how.
Unless you really wanted to do something special, you did not even need
to go to the documentation or to Tomcat's Users List.
And it was amazingly and elegantly simple. There are really not a lot
of software products where you can just get a new logfile at whatever
level by dropping a simple paragraph in a configuration file.
- to create a logfile in Tomcat 5.5or 6.0 on the other hand, one starts
instead with this (once one has found it) :
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4admin.org.apache.juli.FileHandler,
5host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
...(edited for brevity, if you can believe that)...
and, to start understanding the above, one *must* at least read the page at
http://tomcat.apache.org/tomcat-5.5(6.0)-doc/logging.html
and even so, one is constantly reminded that, to /really/ understand
what is going on, one should start by understa
Re: Logging for Dummies in Tomcat 5.5/6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, Okay, I lied about shutting up until someone paid me. Maybe I should threaten to keep posting until I get paid. ;) Mark H. Wood wrote: | 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 package manager may have done all kinds of unholy things with the CLASSPATH (which, in a standard TC install, is ignored, so we can't exactly support questions like 'why does my CLASSPATH look like X on gnu/linux distro Z'). If the CLASSPATH is boned (from our perspective), the logging.properties file could be /anywhere/ and we would /not/ know it. | 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. See above. |> $ 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? Forgive me for using a colloquialism: this refers to the place where you actually installed Tomcat. "Installed it from a package manager", you say? Well, then, I can't tell you where the heck to CD. | 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. So, let me attempt to paraphrase what you're saying: TC installs are very easy to sort out because you either have a) a "standard" TC install where everything matches the official documentation or b) the package manager has kept things configured in such a way that it ought to be easy to figure out". Well, the very existence of this thread is proof that either your assertion is wrong, or there are a lot of lazy people out there who refuse to do their own (light) research. [snip snip snip] | See? This Tomcat is explicitly told use JULI for logging, and its | configuration is explicitly placed at | '/var/lib/tomcat-6/conf/logging.properties'. Forgive me for being elitist, but I would have figured that out in a second. The half-point of this whole argument is that the TC love-and-hugs support group (this list) shouldn't have to know the ins and outs of every distro's way of doing things. We just don't have that kind of time. If you find someone on the list who happens to have, say, Gentoo experience, well, then, you're in luck. If you get Chuck, he'll tell you to install from the canonical package if you want him to help you. |> [http://tomcat.apache.org/tomcat-6.0-doc/logging.html] |> |> 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. If you are reading that page, you are either a software developer or a software deployer. If you don't know how to use a text editor, you should be fired. There, I said it. I'm not sure knowledge of 'ant' is necessary for any of that. | This is not distribution-specific. How to pass property values to the | JRE is perhaps JRE-specific but not distro-specific. Exactly. It shouldn't have anything to do with the distro. This gets back to the OP who asserts that it's not straightforward to figure out what the heck is going on, and suggests that we outline every distro's style and how to follow the trail. We shouldn't have to do that. We should have official docs (we do!) that cover the material necessary (which I believe they do). They include examples, specific places to find things, etc. IF they have been relocated by a package manager, we cannot be responsible. What I'm saying is: don't come crying to us when your package-managed version doesn't match the official docs... go and cry to your package manager and say "what the heck happened to logging.properties?" (or whatever). | One can (and should) document a product's configura
Re: Logging for Dummies in Tomcat 5.5/6.0
On Thu, Jun 19, 2008 at 12:41:30AM +0200, André Warnier wrote: > My idea was, maybe naively, that Tomcat was like any other program, fairly > logical, and that things in it happen for a reason. > Thus that when Tomcat starts, it knows, from some top-level configuration > file, where to look for instructions as to what logging system to use, and > has an idea about where the configuration for that stuff is. > And that this knowledge could be communicated to me somehow without > breaking some official secrecy vow. > > What really puzzled me however, was that going down the hierarchy of > configuration files and directories, I never seemed to find a link between > Tomcat and the logging it was doing. What you are missing is that Tomcat is not the top of the chain of userspace software here; the Java Runtime Environment is. The JRE loads Tomcat and quite a bit of other stuff as well. That "other stuff" is available to Tomcat. A sufficiently new Tomcat version includes Commons Logging (JCL), which is a generalized interface to logging functions which depends on some other package to actually do the logging. Commons Logging has its own internal rules for figuring out what it is supposed to do, and it can get information from the JRE to help in that process. This information does not pass through Tomcat; Commons Logging asks the JRE directly for the values of various "system properties", which values are assigned on the commandline which starts the JRE and directs it to load Tomcat. The actual logging package wrapped by Commons Logging (such as JULI or Log4j) in turn has its own rules to locate its configuration data, and again some of those rules depend on information that it may be able to get from the JRE, again without Tomcat's intervention. So Tomcat, Commons Logging, and e.g. JULI each have their own configuration and none really knows about any of the others. The JRE knits it all together. So, to understand the behavior of logging in Tomcat, you don't need to know much at all about Tomcat, but you do need to understand the actual logger, Commons Logging, and some aspects of the JRE. What you *may* need to know about Tomcat is how it rearranges class loading, because if one of these packages is not told where to find its configuration then some of its built-in rules will search for a configuration file using the classloader hierarchy. > I am starting to see the error of my ways. > What I am, ever so slowly, starting to think I understand (I hope), is that > Tomcat /may/ not itself know; that your refusal to tell me may not after > all have been motivated by a desire to keep the knowledge into your inner > circle of initiates; but that instead, it is some other piece of software > that "hooks" into Tomcat to "steal" the things to be logged, and that this > other piece of thing is the (only) one that knows it's own configuration. Close. The JRE mediates. Tomcat asks for an instance of JCL and the JRE creates one, which (while being created) will have groped around and found a logging package to wrap. The loggin package instance will have groped around and found a configuration which tells it how to log stuff. Tomcat doesn't know or need to know what JCL is using to emit log records; JCL knows that. In turn JCL doesn't know or need to know what the selected logging package is supposed to do; the logger knows. Each component uses the JRE to find the stuff it wants to know. > And thus that for instance Tomcat itself knows nothing about that file > /var/lib/tomcat5.5/conf/logging.properties Correct. It's only there rather than somewhere else because a default search for a properties file will look there, given the classloading setup established by Tomcat. > which I discovered long ago on my Linux Debian Etch system, but could not > figure out how Tomcat found it or used it. Tomcat doesn't find or use it. The logging package does that. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite. pgpInunMsNEg7.pgp Description: PGP signature
Re: Logging for Dummies in Tomcat 5.5/6.0
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/3R+ 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 "kno
RE: Logging for Dummies in Tomcat 5.5/6.0
> From: André Warnier [mailto:[EMAIL PROTECTED] > Subject: Re: Logging for Dummies in Tomcat 5.5/6.0 > > What really puzzled me however, was that going down the hierarchy of > configuration files and directories, I never seemed to find a link > between Tomcat and the logging it was doing. You need to realize that Tomcat logging is not a self-contained system; it utilizes the commons-logging APIs to keep things simple, and, by default, JULI under that. As stated in the doc, JULI is an extension of the standard java.util.logging, so you really need to reference that documentation first: http://java.sun.com/javase/6/docs/technotes/guides/logging/overview.html http://java.sun.com/javase/6/docs/api/java/util/logging/LogManager.html Open source developers may be even more loathe to write documentation than ones that get paid for it, so it's extremely unlikely anyone is going to spend time paraphrasing some other party's doc just for inclusion in Tomcat's files. > What I am, ever so slowly, starting to think I understand > (I hope), is that Tomcat /may/ not itself know Not only doesn't know, but doesn't care - that's up to the logging package that the Tomcat administrator chooses to use. > your refusal to tell me may not after all have been motivated by > a desire to keep the knowledge into your inner circle of initiates; There's no "inner circle of initiates"; rather, there are a fair number of people who have taken the time to read the docs, look at the code (it is open source, after all), and experiment. > Now, for example, if I were to delete all the references, in the > logging.properties above, to "1catalina.org.apache.juli.FileHandler", > would that then simply get rid of all the daily logfiles of the form > /var/log/tomcat5.5/catalina.-mm-dd.log > , or would it bring down my whole Tomcat server ? Why don't you try it, and see? (I don't know the answer.) > Of course I may be totally wrong with my guesses above, and become > totally desperate as Chuck next shoots me down. The only thing to shoot you down over is perhaps a bit of excess verbosity :-) Seriously, try some of the things you're asking about and see what happens - not in production, of course. > what role the java.util.logging.ConsoleHandler gimmick > plays in all this It's not a gimmick, it's just another logging handler that writes selected stuff to stdout. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging for Dummies in Tomcat 5.5/6.0
Chris,
don't give up yet, please.
There is a single question here.
While I still do not agree with some of your comments below, I *do*
immensely appreciate the time you put into it, the civility with which
you answered, and the clues it provides.
I also do understand that it is not easy to try to help someone, when
you do not even know where things are, or how much someone may have
mangled it.
My idea was, maybe naively, that Tomcat was like any other program,
fairly logical, and that things in it happen for a reason.
Thus that when Tomcat starts, it knows, from some top-level
configuration file, where to look for instructions as to what logging
system to use, and has an idea about where the configuration for that
stuff is.
And that this knowledge could be communicated to me somehow without
breaking some official secrecy vow.
What really puzzled me however, was that going down the hierarchy of
configuration files and directories, I never seemed to find a link
between Tomcat and the logging it was doing.
I am starting to see the error of my ways.
What I am, ever so slowly, starting to think I understand (I hope), is
that Tomcat /may/ not itself know; that your refusal to tell me may not
after all have been motivated by a desire to keep the knowledge into
your inner circle of initiates; but that instead, it is some other piece
of software that "hooks" into Tomcat to "steal" the things to be logged,
and that this other piece of thing is the (only) one that knows it's own
configuration.
And thus that for instance Tomcat itself knows nothing about that file
/var/lib/tomcat5.5/conf/logging.properties
which I discovered long ago on my Linux Debian Etch system, but could
not figure out how Tomcat found it or used it.
And this file contains stuff like
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4admin.org.apache.juli.FileHandler,
5host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
(the above being one single line), and to follow,
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
.. continued with similar stuff apparently related to the other apps.
I would thus hasard a wild guess that the logging mechanism used is
"juli", rather than "log4j".
And that thus the bottom of the page at
http://tomcat.apache.org/tomcat-5.5-doc/logging.html
might be the applicable one for this case.
In that case, I would certainly not break it by attempting an uninformed
switch to log4j, and would instead start twiddling with what is there.
However, my initial joy at finally discovering an initial thread to hang
on to, gets severely dampened when I subsequently discover the following
paragraph, which, would you believe it, reads to me like some highly
sophisticated PSK code to which I do not have the key :
* A prefix may be added to handler names, so that multiple
handlers of a single class may be instantiated. A prefix is a String
which starts with a digit, and ends with '.'. For example, 22foobar. is
a valid prefix.
* As in Java 5.0, loggers can define a list of handlers using the
loggerName.handlers property.
* By default, loggers will not delegate to their parent if they
have associated handlers. This may be changed per logger using the
loggerName.useParentHandlers property, which accepts a boolean value.
* The root logger can define its set of handlers using a .handlers
property.
* System property replacement for property values which start with
${sytstemPropertyName}.
I mean, I do understand the part "A prefix is a String which starts with
a digit, and ends with '.'. For example, 22foobar. is a valid prefix.",
but the rest is a bit mysterious, and I am worried that I might have to
understand it, before I start deleting lines and such.
Or not ?
Now, for example, if I were to delete all the references, in the
logging.properties above, to "1catalina.org.apache.juli.FileHandler",
would that then simply get rid of all the daily logfiles of the form
/var/log/tomcat5.5/catalina.-mm-dd.log
, or would it bring down my whole Tomcat server ?
I will venture another couple of guesses, even :
- that the link between the highest level of the Tomcat server (catalina
?) and the specific files "catalina.-mm-dd.log", is made via the
line above
Re: Logging for Dummies in Tomcat 5.5/6.0
-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 ?
Logging for Dummies in Tomcat 5.5/6.0
Hi.
Following another couple of threads which were leading to not much, and
where it seemed evident that there was a notable difference in
competence and understanding between the protagonists, I would like to
start a new one, targeted at Tomcat Logging Dummies like me, but where
Tomcat gurus are of course gratefully welcome to enlighten us.
Here are the basic premises :
Assume that one is not a Java nor Tomcat expert, just someone who has to
install a piece of software called Tomcat, because that is what his
users would like to have, to run nice Java applications.
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).
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.
Assume that one has read the Tomcat logging page at
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
and it's equivalent for Tomcat 5.5, and that one has even read the
commons-logging documentation at http://commons.apache.org/logging/
but that one admits that one is too dumb to really understand what is
said there.
I believe also that it can be assumed that one does not know the
difference between common-logging, juli, log4j or anything like it, and
that one does not really care to know more about it than one absolutely
needs to know in order to get a logfile.
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 ?
- 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.
Now, this was also pretty much what one could do in Tomcat 4, by using a
element at whichever level one deemed necessary. And it was
probably not perfect from a purist or developer point of view, but it
was fairly simple to configure for the occasional Tomcat admin.
So, without going into many technical considerations about why it was
changed, is there a simple set of analogies that one could use between
an old and a new configuration, to achieve similar aims ?
My purpose is *not* to use the logging interface programmatically, since
I have no access to any source code of any of the applications. I would
just assume they are doing the right thing so that I can re-direct their
output to some file I choose, or to the intergalactic void if I so
choose (like /dev/null), or just tell them to shut up via some setup
parameter. But, if it looks like one of them is misbehaving, I would
like to know how to really squeeze the last logbyte out of it so that I
can go and rub the user's nose in it, or bug the developer about fixing
his code.
- 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 ?
In other words, currently I have far too many logfiles and I don't know
where they are coming from. I'd like to simplify initially, and then
slowly and incrementally, as I get a better understanding of how it
works, rebuild what I need in terms of details.
My basic purpose is to have logfiles that show me, in not too much
detail, when Tomcat starts and stops, the important things that happen
to it, and in case of an error, enough information to find out where it
happened and why in general terms.
a) I have a Tomcat with one single host ("localhost") and 3 applications
: a "manager", a "host-manager", and a custom application called
"MyApp". That's the way it came in the box. Each of those at the
moment produces a separate logfile, daily, to which one adds another set
of daily "catalina" logs.
That's just a bit much.
I would like to have, for the whole of Tomcat :
- one monthly file that shows the equivalent of an Apache "error log"
- one monthly file that shows the equivalent of an Apache "access log"
and that's pretty much it.
So I need first to undo what's there, and then to put in what's needed.
How do I do
