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]>
