[an oldy but goody] "Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes:
> Daniel Rall <[EMAIL PROTECTED]> writes: > > >All of these statements seem reasonable active and uncommented at the debug > >level. They're unlikely to really clutter the log file(s) as they only run > >at startup. > > And they are put into the catalina.out logfile because the logging > isn't set up yet and log4j then puts stuff to System.out. This is > likely to confuse people or even worse, their servlet engines if they > use something more exotic than Tomcat. > > I was thinking about enabling them unconditionally on debug level but > decided against it, because people already complained about messages > cluttering up their catalina.out files. > > With logging, there _is_ a chicken-egg problem. And I did think about > it. I knew you would have. :-) Since the Dawn of Time, servers have this bootstrapping issue with regard to logging. The Traditional approach is to go ahead and log to stdout/stderr until the daemon's has bootstrapped its logging facilities. Whatever is invoking the daemon (often a user at the commandline, an init.d script, or both) is responsible for handling this output. Since the output is a one-time thing which occurs only during the startup/shutdown processes, it is acceptable. I recommend going ahead and producing that output, either using the SevletContext's logger, or something which sends the output to stdout (like pre-bootstrapped Log4J). From the user's perspective, there isn't actually going to be a lot of output "clusttering up their catalina.out files", since this only happens during Turbine servlet initialization. Any servlet container which can't handle output to stdout/stderr is just plain broken. -- Daniel Rall <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
