That's what commons-logging is trying to do. As I understand it, we don't want to depend on commons-logging, because a variety of people hate it due to classloading issues. We stick with j.u.l, and then provide a convenient mechanism to switch from j.u.l to Log4J (or whatever).
However, Spring does depend on commons-logging. So, as soon as we call spring, spring calls commons-logging. If the only logger in sight is j.u.l, all is well, or, at least, as well as all ever is with commons-logging. If log4j is in the classpath, then commons-logging will connect to that, and we will continue to talk to j.u.l, unless the app makes the LogUtils call to switch to Log4j. The LogUtils class is, in some ways, the wrapper you are looking for, except that it does not grab control of spring logging. To do so, it would have to talk to the commons logging API. Thus my wondering if we could detect if commons-logging is turned on without setting into motion it's problematic class-loading behaviors.
