Hi Ralph, Ralph Goers wrote at Mittwoch, 15. April 2009 03:18:
[snip] > Commons Logging's Log method has very few methods - 2 variations for > each of the 6 log levels and then the "is" methods. > > By contrast, SLF4J supports many more variations of these, primarily > because it supports Markers (which I will refer to in a moment). In > addition, SLF4J supports a message syntax that in many cases > eliminates the need to wrap all the logging calls with if > (logger.isXXXEnabled()). > > Next, SLF4J supports the MDC - regardless of whether the > implementation comes from Log4j or Logback. My applications all rely > on this. > > The we get to the SLF4J extensions (where I have commit rights). > XLogger provides some of the APIs that are available in JUL. It uses > Markers to make it easy to filter them. It also provides an > MDCStrLookup that allows the MDC to be accessible in any application > that uses Commons Lang's StrLookup support - which Commons > Configuration does. > > SLF4J also comes with a few utilities such as a profiler and a > StopWatch class. > > Does that help? Yes and no, since it was never the goal of CL to add additional functionality, but to provide a facade for the lowest common set of functionality (and originally it was Log4J that prevented the addition of the trace level ;-). See, we have some global players as customers and all of them use an own logging framework that provides explicit support for their operation management. However, all provide at least a factory for CL. As long as you are building an application you have simply more freedom to select an appropriate logging framework, but for small components (as I consider all components of Apache Commons) you should not force unnecessary incompatibilities. Especially since log messages from such basic components might turn out simply to have a too fine granularity (http://wiki.apache.org/avalon/AvalonNoLogging#head-8d74a8d8ad3e97bdc2f9273f97463de06272c59c). While I am not conforming to the complete article, it has some valid points to consider. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
