https://issues.apache.org/bugzilla/show_bug.cgi?id=56166
--- Comment #1 from Konstantin Kolinko <knst.koli...@gmail.com> --- Changing severity to enhancement. Thank you, but "Potential bugs" in many cases are not actual bugs. 1. From admin's point of view too many logs are a bad thing. They administer the server, they aren't debugging it. 2. In many of these cases there will be some observable effect elsewhere (e.g. Tomcat not starting) and usually some logging elsewhere. 3. Issues that do not break normal operation are not errors. E.g. a malformed request should not be logged as an error, as that can be used to fill up the logs. They may be logged at debug level. Some interesting cases are logged at info level once per day through UserDataHelper class. 4. Code that is not called (for cases that "should never happen", as documented) should not be there. It is dead weight that cannot be tested and behaves in an unknown way. In several places that say "an exception cannot happen", it cannot really happen, because Tomcat implementation behind those JavaEE API classes is known, and does not throw such exceptions. A quick review, just looking at the patch "Maybe"s: ------ > SpnegoAuthenticator +0. Maybe, with s/error/debug/ I am not very familiar with that code though. > ClassLoaderLogManager +0. Maybe, with different message >StoreLoader +0. Catching a Throwable isn't good. I'd be better to fix this. >RewriteValve +0. It would be better to propagate an error, not log it. Beware that if this can be triggered it would be triggered by client's request, so it should be at debug logging or behind an UserDataHelper. "Won't"s: ------ >CoyoteAdapter -1. Not an issue. Interruptions happen (e.g. at shutdown). They are not an error. >Request -1. Not an issue. Tomcat-specific implementations behind those APIs are known. Exceptions do not happen here (dead code). >ApplicationFilterFactory, >DefaultInstanceManager, >NamingContextListener >StandardServer >StandardService -0. Unlikely. I think these are likely already have an effect elsewhere (e.g. Tomcat not starting) or are logged elsewhere. >StatusTransformer -1. It should suppress RuntimeExceptions. If something fails, it will be noted by empty output. >BaseModelMBean, >ManagedBean -1. Not an issue. >PoolProperties -1. You wouldn't want a random toString() call to fill up logs. You will see that a string value is truncated. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
