Yes, thanks, agreed - that would simplify/rationalise the logging using Avalon logkit.
But it would not allow the use of LOG4J or Java 1.4 logging without edit/recompile, AFAIK. For most source files, the changes to convert to Commons Logging would be very similar to those needed to tidy up the logging categories, which is why I thought it might be useful to consider. But I am happy to stick with LogKit if everyone else is. [One could always do the Commons Logging change later - it would be simple using Eclipse!] I would like to be able to change the logging level without having to edit the properties file. I can contribute a patch to add a command line option to do this (calling the LoggingManager method). I'll try and get some patches out this weekend. The changes to getLoggerFor() could be done as one or more patch files - which is easiest for the commiters? One giant patch, one per file, or perhaps one per functional area (core, protocol etc)? By the way, LoggingManager seems to be in jorphan.jar, which strikes me as a bit odd. Sebastian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 29 May 2003 20:24 To: JMeter Developers List Subject: RE: Logging suggestions There is a LoggingManager class in the jorphan code that I use that's really simple, and it has a public method you can call to change the priority for any category at runtime. It just needs to be made static and you have exactly what you want. Furthermore, all classes currently have some code that looks like this: transient private static Logger log = LoggingManager.getLoggerFor("jmeter.engine"); Rather than this line of code, it could be: private static Logger log = LoggingManager.getLoggerFor(this.getClass().getName()); Replacing all the code is long and tedious, but not particularly dangerous. Just don't do any reformatting of classes while your doing it, and you're not likely to interfere with anyone else (and no one's particularly active right now, it seems). Then the categories need to be adjusted in JMeter.properties to reflect package names. There's no need to set lines in JMeter.properties for every class, but just some key packages (since it's hierarchical and sub-packages and classes will inherit from parent package settings), and maybe a line or two describing how to micro-manage the logging, for those interested. -Mike On 29 May 2003 at 18:41, BAZLEY, Sebastian wrote: > Given that changing the logging category would mean changes to all source > files that use logs, it seems to me that it might be worth taking the > opportunity to start using the Commons Logging wrapper interface. > > This offers more flexibility, e.g. choice of logging package at run-time. > > But it does add an extra method call. > > If others think it is useful, I can pursue this further (with the aim of > providing patches). > > S. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 22 May 2003 20:09 > To: JMeter Developers List > Subject: Re: Logging suggestions > > > It all sounds reasonable. Actually, the way logging is setup now, we should > > just the fully qualified classname as the logging category, because I've > made > logging work hierarchically. In other words, if you say logging is at the > DEBUG level for org.apache.jmeter.engine, then it will be that for > org.apache.jmeter.engine.StandardJMeterEngine as well. But, you could also > override the setting for individual classes, if that was your choice. The > amount > of change wouldn't be that much - updating the log initializers and changing > > the properties file. > > And I have no problem updating the logkit. > > -Mike > > On 22 May 2003 at 17:20, BAZLEY, Sebastian wrote: > > > Some thought on enhancements to logging - just wondering if anyone else > > concurs/disagrees. > > [If there is general agreement, I can contribute patches.] > > > > * The log format is fixed in LoggingManager.java; recompilation is needed > to > > change this. > > > > I would like at least to change %{priority} to %5.5{priority} so that e.g. > > WARN and DEBUG messages are aligned in the log file. > > It would be useful if the format string could be over-ridden by a Jmeter > > property or similar. > > > > * Logging categories are rather broad - for example jmeter.elements > includes > > lots of different classes. > > Might it not be clearer to use the package name (without org.apache.)? > > [Could probably create a utility function to generate the package name > > automatically.] > > > > This would obviously entail quite a few code changes, but they could be > > automated or introduced gradually. > > > > * A more recent version (1.2) of Avalon Logkit is available - would it > make > > sense to use that instead of 1.0.1? {as far as I can make out, there are > no > > changes that would affect JMeter, but there are a few bug fixes). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
