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]

Reply via email to