That can't be used most of the time (log objects aren't serializable for instance) and it's inefficient.
2010/8/7 Torsten Curdt <tcu...@vafer.org>: > private Log log = LogFactory.getLog(this.getClass()); > > http://wiki.apache.org/commons/Logging/StaticLog > > > On Sat, Aug 7, 2010 at 18:36, Ted Dunning <ted.dunn...@gmail.com> wrote: >> This really would be nice to have. >> >> Sent from my iPhone >> >> On Aug 6, 2010, at 8:36 PM, "cmaj135" <cmaj...@gmail.com> wrote: >> >>> nod >>> >>> >>> >>> >>> cmaj135 >>> 2010-08-07 >>> >>> >>> >>> 发件人: Doug Bateman >>> 发送时间: 2010-08-07 10:11:35 >>> 收件人: Commons Developers List >>> 抄送: >>> 主题: LogFactory.getLog() >>> >>> Dear Commons Developers, >>> >>> Here's a suggestion for the commons-logging package... >>> >>> Presently, in Apache Commons, the most common way to get a logger is to do >>> something like: >>> >>> >>> public class MyClass { >>> private static Log log = LogFactory.getLog(MyClass.class); >>> } >>> >>> >>> Notice how MyClass.class (or alternatively a string name) is passed as a >>> parameter. The annoying aspect of this is that sometimes the class name >>> doesn't get updated when doing copy/paste operations. A desirable >>> alternative might be: >>> >>> >>> public class MyClass { >>> private static Log log = LogFactory.getLog(); //class name inferred from >>> call stack >>> } >>> >>> >>> >>> With such an approach there are two possible concerns I can foresee: >>> >>> Call stack inspection isn't terribly fast. However since Loggers are >>> generally initialized only once, when the class is first loaded, performance >>> isn't likely to be a major problem. >>> Commons-logging is Java 1.1 compatible. Thus care must be taken to ensure >>> compatibility isn't broken. >>> Commons-logging doesn't depend on commons-lang, and thus the utilities in >>> commons-lang cannot be used. >>> >>> In Java 1.4, the call stack is easily obtained using >>> Thread.getCallStack(). Prior to Java 1.4, the only way to obtain the call >>> stack is to inspect the stack trace of an exception. >>> >>> >>> I've attached to this email a proof of concept implementation. It tests >>> successfully in Java 1.0+ and Java 1.4+. In order to ensure the >>> implementation doesn't break for Java 1.0, I used reflection to invoke the >>> Java 1.4 APIs when they are available. >>> >>> Cheers, >>> Doug >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org