On Nov 19, 2007 11:46 PM, Jörg Schaible <[EMAIL PROTECTED]> wrote: > > Phil Steitz wrote: > > 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? > > Why not using commons-logging? It supports trace level. JUL is really a pain. > It is applicable for applications like Tomcat, but not really for components. > Everybody that tried to use an own JUL-formatter knows what I mean. Big > enterprise companies normally hesitate or simply do not permit to add 3rd > party jars to the JVM classpath.
Can you explain more what you mean about third party jars here? It was general pushback / hesitancy to bring in dependency on commons-logging (or anything else) that led us to think about just using jdk logging. I was going to add a simple formatter (all that I need is to expose the thread ID) and bundle it with pool, making it also available to dbcp. I am open to either approach and don't particularly care which API we use. I just want to minimize conflict / configuration hassles for users. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
