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]