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

Reply via email to