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. > > > > <snip/> > > > > > 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 the logfiles and not bring down my > > production servers. And I will end up understanding it, because I don't > > give up easily, as you may have noticed. > > > > > > > Great. Patches to improve the existing documentation are always welcome. > > > > > I would however like to ask a final question, or maybe make a suggestion : > > > > > > Is it not possible for the Tomcat developers to take into account the > > needs of people like me, who have only a minimal understanding of the > > underlying beauties and refinements, but who nevertheless appreciate Tomcat > > very much as a tool, and to take a step back in our direction and make us > > really impressed and happy ? > > > > > > > Enhancement requests should be added to Bugzilla. Requests with patches tend > > to go looked at much faster than requests without. > > > > > It should be a technical piece of cake for programmers of your capacity, > > to continue to use commons-logging, juli, log4j or whatever you prefer as > > the underlying mechanism, and to make it directly available for people who > > want to get down to the gritty details, while providing the average user > > with an interface that hides away this complexity under a simple connecting > > element. Like for example this : > > > > > > <Logger className="org.apache.juli.FileHandler" > > > directory="logs" prefix="localhost." suffix=".log" > > > timestamp="yyyy-mm" rotate="true" level="FINE"/> > > > > > > You can then tuck away the real underlying properties files wherever the > > system packagers won't find them, or even embed them in the code itself to > > make sure. > > > > > > > I wouldn't link the <Logger /> elements to properties files, I'd just add > > the requested loggers. But that is an implementation detail. The idea looks > > possible at first reading but bear in mind I haven't looked at the code to > > determine if it really is possible. > > > > If you or any one else wants to start looking at coding this, I'll happily > > point them in right direction. Yes there will be a learning curve, but it > > shouldn't be that bad. > > > > > Understand me well : I am not harking back to the old times when life was > > simple, and I understand that Tomcat has gotten more complex and requires a > > correspondingly more powerful logging mechanism. > > > > > > But I believe that the ultimate beauty of a complex piece of machinery, is > > when it can be presented as something so simple and neat that a child could > > use it. I think of that each time I see my son play with his iPod, or my > > mother with her GPS car navigator. > > > > > > > To re-iterate what has been said on this and other lists many times before. > > This is a community. We may have different roles but there isn't the them > > and us you see in a commercial supplier/customer relationship. The lines are > > far more blurred than that. If you want to see change then you have all the > > power you need to make it happen and the most effective way to make that > > change happen is to roll up your sleeves and start contributing. There will > > always be room for improvement and people are free to scratch whatever their > > particular itch is. Yours appears to be logging so I look forward to seeing > > proposed changes to the docs and/or the code. > > > > Mark > > > > > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
