I'm not involved with [POOL] (so this is mostly from the peanut gallery),
but do strongly think that logging should be minimal for such a low level
component. As such, if there needs to be any logging at all, it should use
JUL. While it would be nice in a development environment so see my bone
headed errors (where I have full control over logging levels with JULI that
I currently use in Tomcat), I want [POOL] to be completely silent in a
production environment. So it should be a lot of work to configure logging
for [POOL] to be higher than DEBUG/TRACE level in a production environment,
since you already screwed up by releasing the code in the first place.
-----Original Message-----
From: Mark Thomas
Sent: Thursday, February 09, 2012 2:25 PM
To: Commons Developers List
Subject: [DISCUSS][POOL] Logging options for Pool2
One of the big design decisions left for pool2 is whether or not to add
logging. If logging is added then that opens up the what to log and with
which logging framework questions.
I do think some form of logging is required.
See POOL-131 for one example of where logging could be useful.
I have a preference for commons-logging. Partly since it is eating our
own dog food, partly because it will make updating Tomcat to use pool2
easier.
I did have a random thought that we could do zero logging but emit JMX
notifications if JMX was enabled. It avoids the "which framework" debate
but uses an approach that is far less widely used in my experience.
All this is because I am (hopefully) getting close to the point where
the pool2 code is ready for an alpha release.
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
