Erik van Oosten schrieb: > Christopher, > > As I wrote already on Feb 17: > There is another aproach, as taken by http://code.google.com/p/log5j/. > It is > a wrapper around log4j. I wish they had made it for SLF4J! > > I am still waiting for someone to this for SLF4J. It should not be hard. I > did not yet find the time myself :( >
Sigh. Broken broken broken. Re the "feature" for determining which category to create a logger for, see the documentation for Exception.getStackTrace. There is no guarantee that valid info about the callstack is available. So this code will work fine under unit testing, then may start emitting messages to the wrong categories when run in a high-performance environment. That will be fun to debug... Re the printf-style formatting: log.debug("format str", arg0, arg1, arg2); is exactly equivalent to: push "format str" onto stack tmp = new Object[3]; tmp[0] = arg0; tmp[1] = arg1; tmp[2] = arg2; push tmp onto stack invoke log.debug (and of course garbage-collect the tmp object later..) So in practice, for good performance you need if (log.isDebugEnabled()) around each call anyway. In which case, the printf-style stuff gives no performance benefits at all; if something is going to be logged then the formatting is nowhere near the bottleneck step. The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is slightly better, as it avoids the "new Object[]" call. But for best performance, isDebugEnabled should be used anyway. Regards, Simon _______________________________________________ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user