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.
While log4j is something it looks for if not configured otherwise, it is quite simple to configure to use a different implementation even if log4j is on the classpath. A system property can be set to control which implementation is used:
http://jakarta.apache.org/commons/logging/userguide.html#Users
This document also provides all the gory details:
http://jakarta.apache.org/commons/logging/api/org/apache/commons/ logging/package-summary.html
While I have found logging to be a big pain in all my recent applications, at least by using Commons Logging everyone can configure it how they want using whatever lower level logging framework they want. Slide developers would no longer have to deal with it at a configuration level, just point to the above docs and say "it's your problem" :)
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"?
Unifying logging is important though, and whether we like Commons Logging or not, the fact is that its pervasive and not too bad. I use it in my applications and I recently had to configure the output. We don't have log4j in the classpath at all, so it was using JDK1.4 logging - and so all I had to do was set a system property (for JRun) that pointed to my specific .properties file that controlled how I wanted the output.
I'm +1 on Commons Logging in Slide 2 :)
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
