Unfortunately, I guess it is to late to kill the beast...
But I am writing this post anyway, since it keeps on causing harm and since more enlightment around the actual problems it causes obviously is necessary.
My first contact with Commons Logging was in 2002, where it made the application is was currently working on blow up. After tracking down the problem, I solved it using AspectJ by hijacking Commons Logging and swap out the dynamic discovery mechanism to a static one (using Log4J directly), and have been fighting for a Commons-Logging-Free-World (TM) ever since.
If you want to know more about the actual problems it causes and why using class loader hacks to implement a dynamic discovery process is generally a bad idea, read the article Taxonomy of class loader problems encountered when using Jakarta Commons Logging.
I do understand why Commons Logging was invented, it solves a theoretical problem (I am using the word 'theoretical' here, since almost everyone that uses it, uses Log4J as the logging implementation anyway), it is just unfortunate that it became so popular so fast.
However, there are alternatives. If you really need to use a Logging facade (which I do not think you do), you should try out Simple Logging Facade for Java (SLF4J), which uses static (compile time) binding of the Logging implementation, e.g. avoids the above stated problems. They even have a gradual migration path from Commons Logging.
Sorry if I sound bitter, but I just had to get it out... :-)
----
Update:
I just remembered that Chris Nokleberg has a implemented a fancy way of getting rid of Commons Logging (and any other annoying dependency for that matter), it is part of his excellent package JarJar.