I'll come right out and admit it: commons-logging, at least in its initial form, was my fault, though probably not mine alone.

Back in 2001 I did a fair bit of work refactoring and debugging commons-httpclient. As part of that effort, I replaced a custom setDebug()/System.out.println based logging system with log4j. I did this for several reasons but all of them come down to the fact that a fully-fledged logging system is often quite useful. In fact, that debugging effort probably wouldn't have happened without it.

This change turned out to be controversial, and a runtime dependency upon log4j was in fact vetoed. After an enormous amount of discussion, not all of it pretty, a compromise was finally agreed to. This compromise basically said (a) use a thin wrapper around either log4j or the System.out logging initially implemented and (b) allow the user to specify whether to use log4j or System.out.println based upon a method call (inversion-of-control style I guess) or an external property. I did the first implementation of this. It was later suggested, probably reasonably so, that this "log wrapping" package be extracted from httpclient for use in similar circumstances. In a more robust or complicated form (depending upon your perspective) this eventually became commons-logging.

For all its warts, this brief history of Commons Logging shows the "bazaar-style" of open source development working as it should: the operative word here being "compromise".

Personally, I don't believe it to be especially important that Jakarta Commons committers be able to express their creativity by the selection of logging frameworks. I'd have been happy simply using log4j, and I think Ceki's work with the "light" log4j-ME would have been sufficient to address most of the technical concerns raised. Yet others disagree, and I'll respect that position. Certainly respect for that position has encouraged advocates of alternative logging implementations to participate more fully in Jakarta Commons.

That said, I think Hani and Glen miss the point entirely. The purpose of Commons Logging is not to isolate your code from changes in the underlying logging framework. (That's certainly easy enough to do on your own, and not really worth doing in the first place given the ease of switching from one logging framework to another.) The purpose of Commons Logging is not to somehow be more useful than actual logging frameworks by being more general. The purpose of Commons Logging is not to somehow take the logging world by storm. In fact, there are very limited circumstances in which Commons Logging is useful. If you're building a stand-alone application, don't use commons-logging. If you're building an application server, don't use commons-logging. If you're building a moderately large framework, don't use commons-logging. If however, like the Jakarta Commons project, you're building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can't be sure what logging framework they're going to want to use, then commons-logging might be useful to you.

On a slightly unrelated note, I think that Hani's post fails to adequately explain how the problems caused by trying to integrate systems that use incompatible versions of the same component are unique to Commons Logging. If you want a discussion of the technical issues with Commons Logging, which are quite genuine, there are much better analyses available.