Oh, yeah sure, we do right now resort to source code scrubbing to address
these types of issues, but yuck, tricky sticky stuff is source code
scrubbing.
But wouldn't it be nice if there was a way to just declare
private static Category m_Log = Category.getInstance();
And just have it "magically" get setup with the "correct" category
name?(com.foo.bar.SomeClass)?
It's a nice idea (I think) but as Ceki points out, unless absolutly 100%
reliable it sould not be added to Log4j itsself.
My point was that the technique of using a SecurityManager might in fact be
100% reliable, but needs investigation.
Regards
JOhn Volkar
-----Original Message-----
From: Scott Farquhar [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 15, 2002 8:53 PM
To: Log4J Users List
Subject: Re: Clever Logging?
John,
Surely it would be trivial to write a perl/awk/sed script that checks
the class name against the Category? A lot easier than changing log4j.
Another way to potentially to it is via a doclet. I'm not sure if it is
possible, but this article may give you some more insight:
http://www.devx.com/devxpress/gurl.asp?i=1X1350332X40831
Cheers,
Scott
--
Scott Farquhar :: [EMAIL PROTECTED]
Atlassian :: http://www.atlassian.com
Supporting YOUR J2EE World
John Volkar wrote:
> Reliablity of this mechanism is tied directly to that of SecurityManager
and
> it's getClassContext, so I'd think that it would be quite reliable, unless
> there are security holes?
>
> The LocationInfo object could be corrected by setting ?instanceFQN? I
might
> be misremembering something here?
>
> If I ever get a breather, I might look into this as we've had major cut *
> paste introduced problems getting Category instances set right.
>
> John Volkar
>
> -----Original Message-----
> From: Steve Ebersole [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 14, 2002 9:12 PM
> To: Log4J Users List
> Subject: Re: Clever Logging?
>
>
> Plus the nested LocationInfo object will now be incorrect if you ever want
> to use it because. Basically the LocationInfo will now show this new
> "delegate" class information as opposed to the actual class doing the
> logging.
>
>
> ----- Original Message -----
> From: "Silvert, Stan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, January 14, 2002 2:39 PM
> Subject: Clever Logging?
>
>
>
>>I am responsible for defining standards around how our developers use
>>
> Log4J.
>
>>When our company started using Log4J a couple of months ago, I told
>>developers to use this technique in their code:
>>
>>public class MyClass {
>> private static final Category LOG =
>>Category.getInstance(MyClass.class.getName());
>> private static boolean DEBUG() { return LOG.isDebugEnabled(); }
>>}
>>
>>So, for all debug statements, write something like this:
>> if (DEBUG()) LOG.debug("The value of my vars are: " + v1 + " and " +
>>
> v2);
>
>>If not a debug statement, just do something like this:
>> LOG.info("My info message");
>>
>>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.
>>
>>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();
>> }
>> }
>> private static ClassGetter classGetter = new ClassGetter();
>>
>> /**
>> * Returns the name of the calling class.
>> * Intended to be used from static methods or initializers to
>>automagically
>> * determine the calling class's name.
>> * @return the name of the calling class
>> */
>> public static String getClassName() {
>> return classGetter.getClassName();
>> }
>>
>> ///////////////////////////////////////////////////////////////////
>>
>> /**
>> * Returns <code>true</code> if debugging is enabled for a given
>>category
>> *
>> * @return <code>true</code> if debugging is enabled,
>> * <code>false</code> if not
>> */
>> public static boolean DEBUG() {
>> Category cat = Category.getInstance(classGetter.getClassName());
>> return cat.isDebugEnabled();
>> }
>>
>> ///////////////////////////////////////////////////////////////////
>>
>> /**
>> * Logs the given message with <code>DEBUG</code> priority, to the
>>category
>> * automagically derived from the calling class name.
>> *
>> * @param msg the message to log
>> */
>> public static void debug(String msg) {
>> Category cat = Category.getInstance(classGetter.getClassName());
>> cat.debug(msg);
>> }
>>}
>>
>>This looks very nice and seems to solve all the problems quite well -
>>
> except
>
>>for one thing. I have been reading about how some JIT's can remove stack
>>frames during optimization. This would cause messages to once again be
>>logged under the wrong Category.
>>
>>My questions to the folks on this list are,
>>What is your opinion of both techniques?
>>Do you know other developers who have tried the "clever" approach and run
>>into the "disappearing stack frame" problem?
>>Is there another solution we are overlooking? (short of disabling cut and
>>paste from everyone's IDE)
>>
>>Thanks in advance for your input.
>>
>>Stan Silvert
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
> <mailto:[EMAIL PROTECTED]>
>
>>For additional commands, e-mail:
>>
> <mailto:[EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
