commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [DBCP] DBCP2 and logging
Date Wed, 24 Jul 2013 17:29:10 GMT
On 24/07/2013 17:15, Phil Steitz wrote:

> 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.

It is the smelliness I am trying to avoid. I think that was OK for pool
as there was very few places where we needed to log stuff. DBCP has many
more places and my view is that there are enough of them to do it properly.

> 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?

I haven't come across any for a while but that doesn't mean there aren't
some there somewhere.

If we use JCL then those that support the dogfood argument can do so and
those that prefer SLF4J can just drop JCL and use the SLF4J replacement.
There might be an issue with dependencies in the pom for that approach
but I hope the Maven experts can identify a solution for that.

Mark


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


Mime
View raw message