commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <>
Subject RE: (Logging)[Proposal] A little refactoring
Date Thu, 20 Dec 2001 23:23:38 GMT
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 

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

If there is interest I can put it a "commons" package and post it 

Have fun,
Paulo Gaspar

> -----Original Message-----
> From: robert burrell donkin []
> 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:   
> <>
> For additional commands, e-mail: 
> <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message