commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [DBCP] DBCP2 and logging
Date Wed, 24 Jul 2013 16:28:55 GMT
While still in Beta, there is also Log4j 2, which let's you optionally use
SLF4J as the back-end.

Gary


On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz <phil.steitz@gmail.com> 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
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > .
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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