[slf4j-dev] Review of slf4j

[Jacob Kjome]

At 11:39 AM 5/15/2005 +0200, you wrote:
 >
 >
 >At 04:55 5/15/2005, Jacob Kjome wrote:
 >
 >>Spring is for managing components.  All IOC frameworks are for managing
 >>components.  I don't think a simple String could be mistaken for a
 >>component.  I'm torn on whether loggers are?  I argued a while back for it
 >>until you came up with UGLI.  My objection back then was that UGLI didn't
 >>yet exist and I wasn't sure it ever would.  You made it happen and it has
 >>evolved into slf4j.  With the drop-in replacements for logging
 >>implementations including simple and even NOP, I'm not sure I see the need
 >>to clutter the interface with loggers.
 >
 >Jake, what do you mean by "need to clutter the interface with loggers"?
 >What interface, that of POJOs?

MyComponent(DataSource dsource, Logger logger)

MyComponent(DataSource dsource)

Which one looks nicer to you?  Imagine all your components requiring 
constructors taking loggers!  One of the reasons for using IOC is to avoid 
hiding dependencies that your class needs.  For instance, internally 
looking up a DataSource via JNDI.  This makes things hard for testing and 
it is not apparent from a look at the API that the the component depends on 
living in a J2EE container.  IOC solves these issues.  However, would you 
ever think of looking up a Logger via JNDI?  So why would one use IOC to 
fix a problem that didn't exist previously?  One might want to be 
consistent and treat all dependencies the same way.  However, loggers don't 
ever cause application failure (at least in principal) as a failed JNDI 
lookup would.  If one doesn't care to log, don't bother configuring 
it.  Logging is not critical to the functioning of the class.  The only 
advantage I can see to exposing loggers is being able to name them in 
configuration.  However, a consistent naming scheme such as 
MyClass.class.getName() should resolve that issue and avoid pushing this 
work out to the IOC configurator.  And given the existence of slf4j, being 
a non-harmful logging framework (as opposed to common-logging crashing 
applications because of its brittle discovery process) and a tiny 
dependency (especially with the optional NOP implementation),  I just think 
that logging is a different beast that IOC need not be concerned with.


 > Anyway, I still do not have the required
 >understanding of IOC frameworks to judge whether loggers should be managed
 >by IOC. I am at a stage where I can make seemingly relevant noises about
 >the subject without really understanding it. As such, please consider the
 >comments in my previous message as guesswork.
 >

No problem.  I'm not claiming to be an expert either.  I've just been 
following the progress of the various frameworks for a while and have 
thought about the issues enough to generate an (arguably) informed opinion.

 >As for slf4j, it still has a long way to go before being widely adopted.
 >It's just at the beginning of a long road.
 >

yes, but the mere existence is progress over vaporware.

Jake

 >>Jake
 >
 >--
 >Ceki Gülcü
 >
 >   The complete log4j manual: http://www.qos.ch/log4j/
 >
 >
 >_______________________________________________
 >dev mailing list
 >dev at slf4j.org
 >http://slf4j.org/mailman/listinfo/dev
 >
 >