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: http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-common/src/java/org/axs l/common/AvalonLogger.java?view=markup 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
