logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Randall" <crand...@tivre.com>
Subject RE: Clever Logging?
Date Mon, 14 Jan 2002 21:38:45 GMT
Getting information from the stack trace will be much easier in JDK 1.4
with the new Throwable class. The stack trace is represented as an array
which you can get reliable data out of.

Too bad JDK 1.4 is lagging WAY BEHIND! Any idea when it will be
released?

Chris

-----Original Message-----
From: Ceki Gülcü [mailto:ceki@qos.ch]
Sent: Monday, January 14, 2002 1:35 PM
To: Log4J Users List
Subject: Re: Clever Logging?


At 15:39 14.01.2002 -0500, you wrote:
>That all worked fine, except that developers would make the mistake of
>putting the wrong class name inside the getInstance() method.  This
would
>usually happen when they would cut and paste code.  

The idea of automatically discovering the caller class name has been
suggested before, I believe by Anders Kristensen along similar lines.
It would be nice to have a reliable method to retrieve the caller
class name. However, I am not aware of any such method.

>So, one of our developers came up with a clever solution to cut down on
the
>mistakes.  He created a logging utility that could automatically read
the
>stack frames, discover which class logged the message, and invoke
logging
>from the proper Category.
>
>Here is how he did it:
>
>public class LogUtil {    
>    /**
>     * Extends <code>java.lang.SecurityManager</code> to provide the
><code>getClassName()</code>
>     * method.
>     */
>    private static class ClassGetter extends SecurityManager {
>        // Inner class necessary because getClassContext() is protected
>        
>        /**
>         * Returns the name of the calling class.
>         * @return  the name of the calling class
>         */
>        public String getClassName() {
>            // getClassContext() returns the current execution stack
trace
>            // as an array of classes -- the element at index 0 is the
class
>            // of the currently executing method, the element at index
1 is
>            // the class of that method's caller, and so on. So, 0 is
going
>            // to be this class (ClassGetter), 1 will be LogUtil, and 2
will
>            // be the magic number we are after.
>            return getClassContext()[2].getName();
>        }
>    }

This is pretty smart. However, is it guaranteed to work? How long do
you think it will take you to debug a problem with
getClassContext()[2].getName() compared to a typo? The goal was to
avoid errors, remember? Can it be that you are trading one evil with
even a worse one? 

If getClassContext()[2].getName() is guaranteed to work, then it is a
useful feature, otherwise it is evil. I would not take any chances...


>    public static boolean DEBUG() {
>        Category cat =
Category.getInstance(classGetter.getClassName());
>        return cat.isDebugEnabled();
>    }            

The DEBUG method calls Category.getInstance method which is
not particularly fast. As such, this DEBUG method will incur
a constant penalty. I suspect this is not what you want.


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:
<mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:log4j-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>


Mime
View raw message