I have been working on adding logging to pool and dbcp per previous discussion here. I started with a partially instrumented version of pool 1.3 that I have been using to investigate bug reports and test performance. I used jdk logging with the following guidelines
* Finest (trace) level for detailed/diagnostic logging * Finer level for things a commons developer may want to know * Fine (debug) level for things a developer of an app using this component may want to know * Config level for configuration-modification events * Info level for things a system administrator may want to know * Warning level for things indicating a recoverable problem * Severe level for things indicating a problem that the component could not recover from I used fully qualified class names for loggers, flags, logp and a custom formatter that adds the thread id to the log message. While running with Config or higher levels, there does not appear to be any measurable performance impact, the instrumentation seriously clutters the already complex code. So I guess what I would like to propose is that we release both fully instrumented and minimally instrumented jars for these components, with the minimally instrumented version in trunk and a "-inst" version built from a copy of the release tag. This is essentially what I have done for (most of) pool 1.3, which I would like to complete and commit to a branch and release as pool-1.3-inst or somesuch. Similarly for dbcp-1.2.2-inst and then for subsequent versions. I know this seems like extra work for components that we are lacking volunteers for, but it could really help in resolving user issues if instrumented jars were available. Alternatively, we could just move forward with dbcp 1.3, pool 1.4, adding "Config-level" logging (or event notification) only. Thoughts? Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
