commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 22776] - DBCP should not be writing messages to stderr or stdout
Date Thu, 28 Aug 2003 00:04:27 GMT
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 shankar@cotagesoft.com  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.

Mime
View raw message