DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22776>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22776 DBCP should not be writing messages to stderr or stdout ------- Additional Comments From [EMAIL PROTECTED] 2003-08-28 00:04 ------- > I don't think we should add commons-logging. It's important for any messages from DBCP to be logged into the preferred logging arena, and not lost to standard out or error, which may not even be connected to anything (consider processes started as services on Windows). If the database goes down, it would be bad if the new connection creation error got written only to stdout and thus lost, and no message was logged into the official log location. Commons-logging was created for precisely this purpose: for commons libraries to be able to piggyback on an application's already-configured logging mechanism and provide seamless logging. Why is it not a good idea to use it? (I even have a patch ready that converts all the System.{out,err}.println's to log.{info,warning,error)(), along with the build.xml and build.properties.sample changes.. Would it help if I attached it here? P.S. An editorial comment on another statement in that last add: Back to the "AbandonedTimeout is only for development" idea. Stuff does happen - no app is perfect, and it's often preferable to get a temporary error when the connection is reclaimed, than an application lockup or crash from leaked connections. I guess the best way to put it is that a lot of webapps tend to live in a different sort of world, where (unfortunately) testing cycles tend to be shorter and things like this happen. Why make policy like this? Leave the thing in, log a message (like you're doing, only send it to the logger!), and let the app maintainer decide how they want to deal with whatever crisis pops up.. If a connection loss bug escaped through the cracks in testing, this allows the app to limp along until a fix is ready. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
