commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roger L. Whitcomb" <Roger.Whitc...@actian.com>
Subject RE: [DBCP] DBCP2 and logging
Date Wed, 24 Jul 2013 16:41:13 GMT
AFAIK, some of the classloader "issues" with CL still remain (see http://xnet.wanconcepts.com/jcl/furtherAnalysis.html
but also see here: http://commons.apache.org/proper/commons-logging/tech.html) So, IMO Commons
projects still ought to use it, if for no other reason than to understand what the issues
are in practice (vis-à-vis dog-fooding).  And one of the original authors of JCL proposes
that it SHOULD be used in just this situation (DBCP):  http://radio-weblogs.com/0122027/2003/08/15.html

<quote>
If however, like the Jakarta Commons project, you're building a tiny little component that
you intend for other developers to embed in their applications and frameworks, and you believe
that logging information might be useful to those clients, and you can't be sure what logging

framework they're going to want to use, then commons-logging might be useful to you.
</quote>

~Roger Whitcomb

-----Original Message-----
From: Phil Steitz [mailto:phil.steitz@gmail.com] 
Sent: Wednesday, July 24, 2013 9:15 AM
To: Commons Developers List
Subject: Re: [DBCP] DBCP2 and logging

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message