In the past year or so I have had a recurring nightmare in dealing with Apache’s comons-logging project and its pervasive (and I think misguided) use by a lot of open source projects. The difficulties are well known to those who have had issues using it within web apps on many different web containers, but I think a lot of people are still in the dark about how bad some of these problems are.

I think the memory leak issues have been resolved by simple means, but the use of the dynamic discovery mechanism continues to baffle me to this day. I think this only accurately works in simple java applications that all share a simple classloader mechanism. The problems with commons-logging classloader tricks first showed up in servlet containers because of the classloader heirarchy and I have spent many hours working through those issues in the past year or maybe even two. Today some of us in the OSGi community have run across it again trying to use commons-logging within OSGi frameworks (more specifically, libraries that use commons-logging).

Lather, rinse, repeat…

I have pretty much had it with commons-logging and long ago started using the slf4j library and its toolbox of hacks to get around the dynamic discovery mechanism. Slf4j is similar to commons-logging except that you specify your logging imeplementation by including a log adapter as a jar file so the linking is static. On top of that, slf4j includes a facade that also imeplements the commons logging API so that you can take out commons-logging altogether and use slf4j instead. Obviously this is mainly useful because many, many open source projects blindly use commons-logging even though it is known to have had these issues for quite some time. I have done this many times in the past year with great success, so if you even remotely suspect commons-logging causing problems in your app, I suggest reading this page and give it a shot.