Vincent Hennebert wrote:

> What I liked with the Avalon Logger is the one-to-one 
> correspondance between it and Commons' Log; commons just has 
> one more level which is trace. So writing a Logger adapter 
> that delegates logs to a Log instance is trivial.
> Now it's different because PseudoLogger has 7 log levels + 1 
> debug level, whereas commons Log has 6 levels with different 
> purposes. The best mapping that I see is the following:
> PseudoLogger -> Log
> finest          trace
> finer           trace
> fine            trace
> debug           debug
> config          info
> info            info
> warning         warn
> severe          error

Actually there is not a level named "debug", although I might have defined
that constant equal to "finest" in one of the earlier versions. Here is the
way I mapped the Avalon levels in the AvalonLogger implementation:

FINEST      debug
FINER       info
FINE        info
CONFIG      info
INFO        info
WARNING     warn
SEVERE      error

> Log's fatal level wouldn't be used. Writing an adapter in the 
> other way would have been somewhat easier (and BTW 
> corresponds to commons' Jdk14Logger).
> Personally I tend to find Commons log levels more intuitive 
> and useful than the Jdk ones: I don't really know what to do 
> with 3 fine, finer, finest and one config levels. May I 
> suggest you to use Commons' style of levels instead?
> That said, this is by no means dramatic. For me it's just a 
> matter of writing another wrapper.

I don't really feel strongly about it either, but perhaps a bit more
strongly than you for the following reasons:
1. From a sheer "standard" aspect, I wanted to stay as close to the Java
logging system as possible. I would have used the java.util.logging.Level
instances (for type safety) instead of numeric constants, except for trying
to retain Java 1.3 compatibility.
2. I prefer to allow for more granularity rather than less (within reason),
even if we don't think we need it right now.
3. This is one of those things that you can change on Tuesday to make one
party happy, then change back again on Wednesday to make another party
happy, all for very little benefit. In short, there is no way to make
everyone happy.

Also, I don't know if you noticed the following methods:
    info(String message)
    warn(String message)
    error(String message)
    debug(String message)
which correspond directly to the Avalon methods of the same name, and are
intended to provide a sort of mapping for them. I don't mind adding one more
called trace(String message) if that would make the mapping concept more
clear for you.

In short, it isn't a big deal to me either, but I would prefer to leave it
alone unless there is some compelling reason to change. When you say
"somewhat easier", we're talking about a pretty trivial difference, right?
Probably just 7 case statements instead of 5? If not, I will be glad to
rethink this.

> I agree that it's a bit cleaner if the font system has its 
> own logging rules, independently of other existing logging 
> systems. So no problem for me.

Yes, I thought this was pretty nice. The other thing it allowed me to do is
to make the FOray logging system very generic. I use the PseudoLogger
interface everywhere. When I need to instantiate a logger, I can use a
static method to do that. This means that I could switch over to a new
logging system for the price of changing the static method and writing a new
wrapper/adapter that implements PseudoLogger.

Victor Mote

Reply via email to