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]>

Reply via email to