That was THE reason why I adopted Avalon new wrappers instead. I ported them out of Avalon and they work just fine. There are NO dependencies from the rest of the framework except for a formatter that can be dropped.
I also improved (IMHO) an existing AbstractLoggable class and I am now porting an XML based configurator for LogKit from Avalon Excalibur. This one has more dependencies but it is ok. Next I will adapt the simple property configuration code for LogKit and Log4J used at Velocity, (will looking at Turbine too). So, this set includes: - Wrappers for Log4J, LogKit and the JDK 1.4 Logging API; - Really simple internal logger + NoOp logger; - Log4J has its own XML configuration and LogKit gets one; - Ability to use a hierarchy of loggers in an API independent way. Only the configuration is API dependent. Will soon (next week) include simple property configuration. Still no plans on evolving the JDK 1.4 Logging API. This is the best logging code I found around Jakarta. It just picked it from several projects and would like to see it together in the Commons where it would have a wider use. And it is working fine across a 500 class and 75 Kloc piece of code. My interest is to keep the functionality I have now without being alone taking care of it. (Trying to cut on the above numbers.) =:o) If there is interest I can put it a "commons" package and post it tomorrow. Have fun, Paulo Gaspar > -----Original Message----- > From: robert burrell donkin [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 20, 2001 11:20 PM > To: Jakarta Commons Developers List > Subject: (Logging)[Proposal] A little refactoring > > > i've been adding logging (using commons-logging) into betwixt and found > that commons-logging is a little bit broken. rather than fix the > symptom - > that the log level constants were altered a little and that broke > a lot of > code - i'd prefer to refactor by introducing an abstract implementation > Log that handles the log level logic (ie. stops calls going to the > implementation implementation) and make the existing implementations > inherit. hopefully this would stop logging breaking like that again. > > i'm willing to code these changes if this plan's acceptable. > > - robert > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>