[slf4j-dev] Review of slf4j

[robert burrell donkin]

curse of evolution shortcut keys strikes again :(

here's the complete version...

-------- Forwarded Message --------
> From: robert burrell donkin <rdonkin at apache.org>
> To: slf4j developers list <dev at slf4j.org>
> Subject: Re: [slf4j-dev] Review of slf4j
> Date: Fri, 03 Jun 2005 17:11:58 +0100
> On Mon, 2005-05-16 at 12:51 +0800, Niclas Hedhman wrote:
> > On Saturday 14 May 2005 20:50, Ceki Gülcü wrote:
> 
> <snip>
> 
> > IMO, there is an impedance mismatch between the Logger frameworks and the 
> > application frameworks. On one side Loggers are tightly related to the 
> > overall application, on the other the the Logger framework is independent of 
> > the application. This mismatch is not helping, and perhaps the solution only 
> > comes with AOP.
> > 
> > 
> > To summarize;
> >  1.  LogFactory.getInstance( this )  is a pattern that we framework folks 
> > like. It gives us a chance to trap classes that tries to use the Logger 
> > framework diretly.
> > 
> >  2.  Logger addChild( String name ) is also a method we really like to have in 
> > the Logger interface. That should cover the API side of simple integration 
> > into the framework management system, and easy for Pico style IoC.
> >   public MyClass( Logger logger )
> >   {
> >       m_myPart = new MyPart( logger.addChild( "mypart" ) );
> >   }
> > 
> > 
> > AFAICT, those two should make very little impact on the API users, but be a 
> > big difference for me and my projects.
> 
> IMHO  

niclas has made some important points

> here's my understanding of the problem (maybe right, maybe wrong but
> probably somewhere between ceki and niclas). 
> 
> modern frameworks (whether IOC or not) divide an application into
> semantic chunks. libraries may be reused in many different places within
> an application. threads may be recycled. 
> 
> let's say foo is a common library reused in a large but modular
> application. modules moo and woo both reuse foo. from a brick
> perspective foo just wants to log it's information in a fashion that
> allows it to be integrated smoothly into the widest possible variety of
> applications (and so frameworks and environments).

when used in a modular framework, each instance of class bar in foo is
not only part of a standalone library but also part of a module. it may
be that turning on logging for bar for the whole application would
simply fill the logs and slow the application to a crawl.

if there's a problem in moo then it'd be good to be able to turn on
logging for bar only in moo. this is one reason why many frameworks
provide logging services. 

there are also good reasons why many of those using frameworks to create
applications prefer a single method (let's save the argument about
whether it's good or not for another day ;) to configure all services
including logging. another reason why many frameworks include logging. 

having review a lot of the debate, i do think that there are some
promising ideas.

i like the idea of passing the instance to retrieve a log for that
instance. i also wonder whether there's a connection to be made between
logging domains and the use of logging within frameworks.

- robert