Steve,
Forgot to mention another added benefit of using a monitor (callback)
interface is that you don't need a commons-logging dependency.
If you define a DBCPMonitor interface to announce notable events
you can leave the decision to have a dependency on logging up to the
user of the API. So DBCP does not need a commons-logging dependency.
You might stuff a Null monitor that does nothing into DBCP at first
and allow others to be set by the user. Users can implement
a logging version of the monitor interface that uses commons-logging.
Alex
> -----Original Message-----
> From: Alex Karasulu [mailto:aok123@bellsouth.net]
> Sent: Monday, April 19, 2004 2:29 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: Replace System.out, System.err and printStackTrace() with
> Commons Logging?
>
> Hi Steve,
>
> > -----Original Message-----
> > From: Viens, Steve [mailto:Stephen.Viens@FMR.COM]
> >
> > I've been looking through the DBCP source this morning and have noticed
> > several instances where System.out, System.err and printStackTrace()
> > have been used to write error or status messages to the console.
> >
> > I'm wondering if there's any interest in a contribution that would
> > replace these calls with calls to the commons-logging package instead?
> > I'm making these changes to my own copy anyway - so I'm just curious if
> > there's any interested in having them contributed back. The downside is
> > that this would make DBCP dependent on the commons-logging library which
> > (IMHO) is worth it I think.
>
> PMFJI, but I think you're right on. I've not dealt with DBCP but
> logging over writing to stderr and stdout is far better - I'd rather
> have the extra dependency. Plus take a look at the use of monitors
> verses simple logging. It's a technique I picked up from a fellow
> named Paul Hammant. Here's a link to something he wrote about the
> topic of using monitors (callbacks) as opposed to using logging:
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonNoLogging
>
> To quote the wiki - "In short - this solution gives maximum flexibility,
> maximum embeddability, for no cost.
>
> Cheers,
> Alex
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|