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
