Paulo, do you have your code posted somewhere so we can look at it? Scott
> -----Original Message----- > From: robert burrell donkin [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 21, 2001 9:48 AM > To: Jakarta Commons Developers List > Subject: Re: (Logging)[Proposal] A little refactoring > > > commons-logging is currently broken. i think that it shound be fixed. > > maybe paulo's suggestion would make more sense as a competing > branch - > commons-logging 2.0? that way, people can take a look at the > actual code > but we don't have to stop development on other components until it's > finished. > > - robert > > > On Thursday, December 20, 2001, at 11:23 PM, Paulo Gaspar wrote: > > > 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:commons-dev-> [EMAIL PROTECTED] > > org> > > For > additional > commands, e-mail: > > <mailto:[EMAIL PROTECTED]. > > org> > > > > > -- > To unsubscribe, e-mail: > <mailto:commons-dev-> [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]>