hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: JCL vs SLF4J
Date Mon, 01 Oct 2007 17:00:44 GMT
Eric Baldeschwieler wrote:
> I find our current use of apache commons while depending on specific 
> features of log4j awkward.

Yes, this isn't ideal, but an advantage is that, should we switch to a 
different backend, we only need change the few log4j-specific bits, and 
not every line that logs something.  That's significant.

I have used the JVM's built-in logging and found it lacking.  That's 
what the Hadoop code used initially, and we switched to Commons so that 
we could access log4j's features, and also retain the possibility of 
switching again without having to edit every file.

Torsten Curdt wrote:
> IMHO logging facades are better suited for frameworks ...less useful for applications.

Hadoop is in large part a framework.  We'd like applications that use 
different logging frameworks to be able to use Hadoop.  Ideally the 
log4j-specific bits in Hadoop would be isolated to things like startup 
scripts and main() routines, and not directly used in daemon classes, so 
that one could start a Hadoop cluster using a different logging system 
by, e.g., using different startup scripts and main() routines.  We've 
not maintained that sanctity, but if a contributor does arrive who is 
invested in a different logging framework, it would currently not be too 
hard to repair things to support multiple logging mechanisms.  We should 
think twice before losing that possibility.

As things like KFS arrive on the scene it is all the more important to 
keep Hadoop modular.  Mapreduce and HDFS should be kept independent. 
For example, if a site wishes to use mapreduce on top of KFS, and if KFS 
supports a different logging mechanism, then it will be convenient if 
the mapred code does not presume a specific logging implementation.


View raw message