as Erik already pointed out, Commons-Logging can be completely configured by the user using system properties. In addition, the application using Commons-Logging can choose to use a push model (passing the Log to "components" using a setLog() method) instead of the pull model ("components" get their own log by calling LogFactory.getLog()), and provide their own means for selecting the log implementation. For Slide this means that the log implementation *could* still be selected via Domain.xml, even though components wouldn't be forced to use the supplied logger.
All that said, I think a migration to Commons-Logging would be a good thing, because it provides a very lightweight and stable API (simpler than the Slide abstraction, even, in a positive way) with implementations for all common logging frameworks, so Slide would not need to duplicate that code. Use of Commons-Logging has become quite common for projects inside and outside of Apache, so developers usually already know how to perform logging with it.
Note that I'm not volunteering to do the migration, I was throwing in the idea/concern when I saw that you added the implementation for JDK1.4 logging to Slide, thus duplicating effort that has already gone into Commons-Logging. Not that it's a lot of effort, really. But in the long term the Commons-Logging code is probably getting a lot more attention, exposure and testing.
-- Christopher Lenz /=/ cmlenz at gmx.de
Am 04.12.2003 um 10:38 schrieb Oliver Zeigermann:
Christopher Lenz wrote:
Oliver,
this might have been discussed before... anyway, any reason not to migrate to using Commons-Logging, which already includes adapters for Log4J, JDK1.4 and the Avalon Logkit?
Well, it has been discussed before and we even had a vote that said:
Logging API will be augmented by a method allowing for both message and
throwable in one call. A general redesign of logging is deferred to
later releases.
Anyway, for later releases, here is my comment: I have tried commons-logging and it seems to have a very strong bias towards log4j. It seemed to me if there is log4j anywhere in the classpath it will use this, even though the user might want to use other logging implementations.
Every more severe is the need to touch (at least that's what I understand) every spot in the code that does logging. That's pretty much of an impact. So, the discussion could be "is it worth it"?
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
