On 11/19/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > sebb wrote: > > > Phil Steitz <[EMAIL PROTECTED]> wrote: > > > 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 > > > Might have been better to use one of the logging facades - or can JUL > > be configured to co-operate with other logging implementations? > > ref: http://www.crazysquirrel.com/computing/java/logging.jspx > http://tomcat.apache.org/tomcat-6.0-doc/logging.html > http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/juli/package-su > mmary.html > > > > > 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. > > > So there are now two versions of code that need to be maintained: > > - a simpler trunk > > - more complicated tag version > > > Seems to me that this adds a huge load to the release process, unless > > some way can be found to add the logging automatically. > > I also see that as a concern, including for maintanence, unless the > instrumentation could be automated during the build process. > > > > 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. > > Given that it isn't a performance hit, and given the benefits that are > claimed, I would sooner we maintain a single branch with instrumentation > than two branches. > > Phil, your thoughts?
Thanks for the feedback. I agree that maintaining a single branch is best, but what I am struggling with is how ugly the already complex code becomes when I add (appropriately flagged) trace-level logging capabilities, which I have found useful in troubleshooting issues. I guess the best approach is to forego trace-level logging and get some basic instrumentation into trunk. I will start committing this for pool and dbcp and welcome suggestions for improvement. Any other comments on the naming, levels, use of JUL before I start? Phil > > --- Noel > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
