[slf4j-dev] Review of slf4j

[Niclas Hedhman]

On Saturday 14 May 2005 20:50, Ceki Gülcü wrote:
> right minds would want to configure their loggers using a BeanFactory with
> some underlying XML file as specification? Why would anyone trade a
> programming language like java to manage objects for something as clumsy as
> a XML config file?

You don't. It is the frameworks doing of making it automatically for you. 
Spring and Pico may not have these management extensions, and Spring's 
excessive use of XML is probably detrimental to the whole IoC notion on 
Loggers (I have turned anti-XML for configuring apps.)

Ok, I think you can't see the forest for all the trees. My question of 
principle is; How can a leaf object have any clue of how the Logger strategy 
of the application looks like? Yet, Log4J promotes that.

> Admittedly, I still don't get it. Well, there are obvious advantages to
> managing some objects with a framework like Spring, but managing something
> as fine-grained as a logger? Would you manage String objects using Spring?
> I don't think so...

No, Spring *should* have better management extension points/hooks, where you 
can add such functionality.

My "point" is not Spring or Pico per se, but the principle of IoC and that 
slf4j can support it.

In traditional Avalon Logger strategy, loggers are structured in application 
structures instead of letting each class decide which structure it should 
follow, i.e. AFAIK most do the Logger.getLogger( MyClass.class ). The Avalon 
container creates the Loggers according to some strategy (varies between 
containers), and is not the concern of the leaf object (a.k.a component).
The IoC principle is basically; The leaf object doesn't know what kind of 
structure the overall application wants.

Example; The use of NDC and MDC (IMHO hard to grasp and get working) in Log4J 
is a result of the non-IoC principles. If Loggers were passed in the 
constructor (or through setters :o( ) the manager of Loggers at the request 
level would fork the Logger tree along Sessions or something.


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.


I hope this is acceptable. :o)

And Ceki; Sorry if you wasted time learning Spring. (I am not a Spring fan 
either, due to the excessive XML use).


Cheers
Niclas