Hi Victor,

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

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 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.

Vincent

Victor Mote a écrit :
I just completed a project to make FOray's logging a bit more flexible. It
now logs from an interface called org.axsl.common.PseudoLogger. Logging
levels are the same as those for java.util.logging.Level (in Java 1.4 and
higher), except that integrals are used instead of Level instances.

I also wrote an implementation org.axsl.common.AvalonLogger, which FOray
uses (for now) when it needs to *create* a logger. Since all loggers in the
font system are supplied to the font system (instead of created within it),
FOP should simply pass a different implementation to keep its logging
consistent within itself. The AvalonLogger is a thin wrapper around an, er,
Avalon ConsoleLogger, and is essentially an Adapter between the Avalon
logging system and PseudoLogger. A similar approach can be used with
whatever logging system FOP decides it wants to use. Writing the adapter
should be fairly trivial, and it should be possible to use any logging
system with this approach.

I hope this makes the integration work a bit easier and the results more
satisfactory to FOP. Please let me know if you have questions.

Victor Mote

Reply via email to