directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: upgrading to nlog4j.1.2.17
Date Tue, 11 Oct 2005 07:10:25 GMT
On Tuesday 11 October 2005 14:13, Noel J. Bergman wrote:
> Or to depend on STANDARD APIs, since some library developers seems to have
> lost their way with respect to preserving absolute compatibility across
> versions.

Why "depend"?? 

Once you understand Paul Hammant's argument of "No Logging", things get very 
clear indeed.

How long does it take for a project to define its own LoggerFactory and Logger 
interface??
Discounting the argumentations, probably 30mins.
Add a provider for Log4J and JDK; 2 hours.
Everything else; 1000s of hours.

You want a new feature; Great, add it.
It is not compatible; Well, only affects this project, so who cares?

So, instead of;

import org.apache.log4j.Logger;

   Logger logger = Logger.getLogger( Abc.class );

why not

import org.apache.directory.logging.LoggerFactory;
import org.apache.directory.logging.Logger;

   Logger logger = LogFactory.getInstance().getLogger( Abc.class );

And you have a single place to swap in and out providers, and can easily 
extend with mechanisms for embeddors to swap in whatever provider they want.


So, instead of having 400 classes depending on Log4J, JULI, UGLI, SLF4J or 
what not, why not have ONE implementation class depend on either or all of 
them, and everything else is an internal affair.


Cheers
Niclas

Mime
View raw message