DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28961>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28961 loggers shift files but don't roll (not deleting oldest files by prescribes file count) ------- Additional Comments From [EMAIL PROTECTED] 2004-05-28 18:09 ------- The Remy I'm referring to is Remy Maucherat, another Tomcat developer. Please ignore that reference, though, as it is too long to explain and not a big deal anyways ;) I understand that to you rolling implies also deleting files as configured by the deployer/integrator/administrator. My concept of rolling is different, and includes only the rolling itself, not removal or archival of any kind. Those are separate concerns which merit separate policies, as we're doing for example in log4j 1.3. So yes, we ARE saying to tomcat deployers / integrators / administrators that they're responsible for assuring their server logs don't run out of space. Just like we tell application developers on the tomcat-user list to NOT use the Loggers, and use a logging toolkit like log4j if at all possible, because of the enhanced features those toolkits provides. Though Loggers are required by the Servlet Specification, not even simple rolling is required, and so tomcat would be perfectly in line to just dump all output to System.out. That said, I can see the value in log4j/java.util.logging proxies, so if you submit code for them, I'll be glad to review/comment/commit it as needed. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
