Please consider migrating away from commons-logging and onto slf4j for the reasons mentioned here: http://www.qos.ch/logging/classloader.jsp
The author of log4j went on to write "logback" which is an implementation of slf4j that has much better performance than log4j and much cleaner output. I recommend you evaluate these alternatives seriously and consider them for future releases of Hibernate.
To ease migration you could use the "log4j bridge" mentioned here: http://logback.qos.ch/bridge.html
You simply replace log4j's jar by the bridge jar and all log4j method calls get redirected to logback under the hood.
slf4j does not include MDC/NDC support directly because it is a simple logging facade and not all implementations of that facade support MDC/NDC.
Still, all is not lost. Logback, a slf4j implementation, has MDC support: http://logback.qos.ch/manual/mdc.html
You could depend on slf4j for 99% of your operations (portable) with a dependency on logback for MDC (not portable).
Even without MDC/NDC slf4j provides benefits compared to commons-logging. One of the most annoying issues (you are probably familiar with) is using log4j under Tomcat. You end up with classloader hell and those wonderful ThreadDeath errors on redeploy. If you remove the log4j dependency this should go away.
But I was already considering dropping commons-logging in favor of direct log4j use specifically to get these MDC/NDC features.
I would love to move away from commons-logging as well because of the classloader issues.
Additionally, I would love to keep using a wrapper/facade so that containers can properly integrate our logging.
But I would prefer that the wrapper/facade manage this MDC, NDC. Think about what happens otherwise: I need to statically bind in the various logging implementation classes (or at least do silly reflection calls) anyway in order to achieve this; so I have not removed them as dependencies. The wrapper/facade knows which underlying logging impl is being used and could very easily delegate those MDC/NDC calls itself. Afterall, isn't this the point of a wrapper/facade?
I agree. There is already an open issue against this: http://bugzilla.slf4j.org/show_bug.cgi?id=49
I would encourage you to add your comments there.
Just a thought: instead of talking directly to log4j or logback just code against slf4j for 99% of the calls, for NDC talk directly to logback and in the future when slf4j abstracts that as well you could talk 100% to slf4j.
I put a comment there and my (psuedo-)vote. Lets wait and see where that RFI gets as 3.3 gets closer...
OK, Ceki says he has added this feature in slf4j trunk. And he plans on releasing 1.4.1 in the next few days including this feature. So lets schedule this move for Hibernate 3.3. Need to determine the best migration path in terms of whether to (1) use the bridge concept to not change Hibernate code or (2) use search/replace in Hibernate code to use the slf4j API.