commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [DBCP] DBCP2 and logging
Date Fri, 26 Jul 2013 23:24:10 GMT
Perhaps an event listener for all dbcp events?  Then folks can log it
themselves.  I would be concerned about performance unless of course the
events are delivered asynchronously.

On Wednesday, July 24, 2013, Phil Steitz wrote:

> On 7/24/13 12:56 AM, Mark Thomas wrote:
> > I'm working my way through the open DBCP bugs with a view to getting the
> > DBCP code (and the POOL code as some changes may be required there) into
> > a state where it is ready for the first v2 release.
> >
> > I've quickly reached DBCP-154 that requests that logging is added. This
> > is not a new request and goes back to DBCP-4 and possibly earlier. From
> > memory there are a number of open DBCP bugs that require some form of
> > logging. There are also lots of places where DBCP logs directly to
> > stdout or stderr.
> >
> > This quickly brings us to the point of having to decide which logging
> > framework to use. This is largely the same debate we had for POOL [1]
> > but with a few key differences:
> > - there are many more places where logging is required
> > - there are many more places where logging could be useful
> >
> > Because of the volume of logging, I don't believe the JMX approach used
> > for POOL is viable for DBCP.
> >
> > Therefore, I intend to go ahead and add a dependency on Commons-Logging.
>
> First, many thanks for jumping back in!
>
> I have two basic questions:
>
> 1) Do we absolutely need logging itself or is there some other way
> we could satisfy the needs here?  IIRC, there are basically two
> things that "require" logging in DBCP: a) abandoned connections b)
> exceptions / warnings.  In a), we want users to be able to log the
> stack trace of the code that opened the connection.  Case b) splits
> into all kinds of different stuff.  This may be a little smelly, but
> I wonder if we could not shove what is really needed in normal
> operations into JMX properties (which would just hold information
> from recent messages) and support a debug mode where things get
> spewed as today to System.err or a configured LogWriter.
>
> 2) Are there any real reasons that commons-logging will not meet the
> need?  I have read the other messages on this thread and have not
> seen a concrete reason, other than "others like slf2j better."  Have
> we in fact definitively resolved the classloader-related issues that
> used to make commons-logging a bad choice?
>
> If the answer to 1) is we absolutely need logging and 2) comes down
> to a matter of taste, I am +1 on commons-logging because I agree
> with the dogfood argument and also do-ocracy ;)
>
> Phil
> >
> > Mark
> >
> >
> > [1] http://markmail.org/message/zuufedzkfx62v5eq
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
> >
> > .
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message