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.
Doug
