Gareth Bryan wrote:
I think runtime swapping of log levels is a very powerful feature: we
should have this feature if it is at all feasible.
Ok, but can we focus on that after the hard stuff is done? All I was
trying to point out was that this project shouldn't worry about creating yet
another logging library. I mean we already have Log4J, LogKit, Commons
Logging, and Avalon's logging abstraction. What more do we need in this
area?
WHen it comes to writing the code that uses the logger, all I want to
care about is the isXEnabled() and the actual log command. All the rest
is academic. If you are saying I need to cache values in my class and
do the job of the Hot Spot compiler, then I am saying you are asking too
much of me.
If you want to swap out log levels, go for it. Just don't add too much
cruft to the component classes to support it. That's all.
Also:
I have written loggers in the past which fail **very** quickly if a
particular level is not enabled. The logger implementation uses a
delegate mechanism whereby when setLogLevel() is called (ie during init),
any log levels which are not operational have their request mapped
through to a NullLogger. Thus the only overhead of calling a log method
for a level which is not enabled is the method location + stack overhead.
I'd be suprised if something similar doesn't happen for log4j impl;
though I'm no expert on log4j
It happens for LogKit, but I have little experience with Log4J.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
