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]
