Glenn Nielsen wrote: > Remy Maucherat wrote: > >> [EMAIL PROTECTED] wrote: >> >>> glenn 2002/08/26 05:15:59 >>> >>> Modified: catalina/src/share/org/apache/catalina/connector >>> RequestBase.java >>> catalina/src/share/org/apache/catalina/core >>> StandardContext.java >>> Log: >>> Fix for BUG 11947. Change where startCapture/stopCapture is >>> invoked to >>> prevent memory leaks from the SystemLogHandler. >> >> >> >> I'd like log swallowing to be optional and disabled by default. It >> will confuse users too much otherwise (they're used to using Sys.out >> to debug). >> It is also not a good idea to pay the performance cost when the >> feature is not needed IMO. >> >> I plan to add a "swallowOutput" flag to StandardContext, with its >> default to false. >> >> Remy >> > > I do think the feature is needed, especially for production systems. > > Many API's used by a web application don't know they are being used in a > web > application and have no access to the servlet context log, they use stderr > and stdout. It is very confusing during production if errors generated by > these API's are put in catalina.out and other errors are in the Context > log. > Putting all the stdout/stderr output for a web app into one log makes it > easier > to debug a problem. Also, when the output goes to catalina.out there > are no > timestamps which makes it difficult to correlate output in catalina.out > with > the context log. > > For me, debugging is easier if everything related to a webapp is in the > same log, > and with timestamps. > > This is just a change in behaviour, I don't see a problem with having it > enabled > by default as long as it is documented. > > -0 for adding the flag > -1 for setting default behaviour to disable putting stderr/stdout in the > context log.
Most Tomcat users are developers, and do not care about your "production" ready feature. IMO system administrators will have to tweak their Tomcat installation, no matter what we do. OTOH, casual developers are going to be deeply confused and annoyed by the feature. I'm not happy with the patch you committed yesterday, and which forced redirection (at the cost of adding two synced hashtable operations in the critical path). So -1 for the patch you committed yesterday. (I think the code I just committed is an acceptable compromise, so I'd appreciate it if you retracted your veto; if you don't, we'll have to revert the last 2 StandardContext commits) Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
