[prev in list] [next in list] [prev in thread] [next in thread]
List: log4j-dev
Subject: Re: automatic trace insertion
From: "Tom Eugelink" <tom_eugelink () hotmail ! com>
Date: 2001-12-20 8:15:14
[Download RAW message or body]
Sometimes I wonder if typos are a disease. Appologies. Probably caused by
the time of day.
>From: "Tom Eugelink" <tom_eugelink@hotmail.com>
>Reply-To: tbee@tbee.org
>To: log4j-dev@jakarta.apache.org
>Subject: Re: automatic trace insertion
>Date: Thu, 20 Dec 2001 09:11:35 +0100
>
>Sure!
>
>The proxy class only works on interface (unfortunately it does not copy a
>class definition, only an interface).
>
>First you need to write the wrapper class "Logger" that will automatically
>assume the identity of the interface it wraps and has the hook method
>"invoke". All calls to the actual calls are rerouted to "invoke". I took
>out
>as some code so the core frame is clear.
>
>
>import java.lang.reflect.*;
>import org.apache.log4j.*;
>
>/**
>* This class logs calls to an interface to log4j
>* It is assumes that if no logging is active, this wrapper is not created
>in
>the first place.
>*/
>public class Logger
>implements InvocationHandler
>{
> // remember who we're delegating
> private Object iDelegate;
>
> // remember the log4j category we're logging to
> org.apache.log4j.Category iLog4J;
>
> /**
> * initialize this wrapper
> */
> public Logger(Object pObject, org.apache.log4j.Category pLog4J)
> {
> // remember
> iDelegate = pObject;
> iLog4J = pLog4J;
> }
>
> /**
> * invoke a method
> */
> public Object invoke(Object pProxy, Method pMethod, Object[] pArgs)
> throws Throwable
> {
> // log the call
> // ... reflection code here to dump the parameters to a string
> iLog4J.debug(" ==> " + pMethod.getName() + lParameters);
>
> // invoke the method
> // mandatory! This replaces the actual call to the class
> Object lObject = null;
> try
> {
> lObject = pMethod.invoke(iDelegate, pArgs);
> }
> catch(IllegalAccessException lException)
> {
> // something went wrong in reflection, this is a logger error
> iLog4J.error(lException.toString());
> }
> catch(InvocationTargetException lException)
> {
> // forward runtime exceptions
> if
>(RuntimeException.class.isAssignableFrom(lException.getTargetException().getClass()))
> {
> RuntimeException lRuntimeException =
>(RuntimeException)lException.getTargetException();
> iLog4J.debug(" <== " + pMethod.getName() + "= EXCEPTION: "
>+
>lRuntimeException.getMessage() );
> throw lRuntimeException;
> }
>
> // log the error
> iLog4J.error(lException.getTargetException().toString());
> }
>
> // log return
> iLog4J.debug(" <== " + pMethod.getName() + "=" + lObject);
>
> // return the return value
> return lObject;
> }
>}
>
>
>
>
>And then you need to use the logger. In this case I have a factory which
>instantiates a "TaglibCoreDefault" implementation of the "TaglibCore"
>interface.
>
>...
> // create the default Core
> lTaglibCore = new TaglibCoreDefault();
>
> // if logging is activated, wrap the core in a logger
> if (cLog4J.isDebugEnabled())
> {
> lTaglibCore = (TaglibCore) Proxy.newProxyInstance(
> Thread.currentThread().getContextClassLoader()
> , new Class[] {TaglibCore.class}
> , new de.westlb_systems.taglibs.Logger(lTaglibCore, cLog4J)
> );
> }
>
> // just use lTaglibCore
>...
>
>
>If logging is off, the actual Core is used, if logging is on, the wrapper
>is
>used. So no performance penalty when not logging.
>
>The advantage here is that this works at runtime (unlike the "optimizer
>removes logging code" solutions), so you can start logging without having
>to
>use a different version of the source (which of course might not show the
>same behaviour).
>
>If only it was able to wrap around a class...
>
>Tom
>
>
>>From: chandra.swaminathan@kodak.com
>>Reply-To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
>>To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
>>Subject: Re: automatic trace insertion
>>Date: Wed, 19 Dec 2001 14:03:45 -0800
>>
>>
>>From: Chandra Swaminathan
>>
>>Tom,
>>
>>Can you provide some more detail (possibly an example) on the java Proxy
>>class that you are talking about and how exactly it helps to get the
>>performance loss to 0. I was interested in your suggestion but don't know
>>how this can be implemented. Is it possible to do it without re-compiling
>>the application?
>>
>>Chandra.
>>
>>
>>
>>
>>
>>"Tom Eugelink" <tom_eugelink@hotmail.com> on 12/19/2001 12:37:59 AM
>>
>>Please respond to "Log4J Developers List" <log4j-dev@jakarta.apache.org>
>>
>>To: log4j-dev@jakarta.apache.org
>>cc:
>>Subject: Re: automatic trace insertion
>>
>>
>>As a "I just stumbled into the Log4J developer list because maybe..."
>>reader
>>of these emails, but still a seasoned developer (15+ years), I do feel
>>inclined to make a few comments on logging:
>>
>>1. You never know (when writing code) what you want to log, because you do
>>not know what problem you will be solving.
>>2. Adding logging code ALWAYS has a performance penalty (even if it is
>>only
>>an IF statement). Most ideally logging code can be deactivated completely
>>until it is needed.
>>
>>Based on the first statement you would want to add as many Log4J lines as
>>possible, of course with good categories, so you can figure out what is
>>going on. This is INCLUDING setters and getters, just to make sure data
>>has
>>gotten where it should be going.
>>
>>And this is of course in conflict with the second statement. That is why I
>>often use the Proxy class in java (this class automatically wraps around
>>an
>>interface and provides a hook for all methods, from where I call Log4J).
>>The
>>wrapper is only created when logging is enabled, thus resulting in 0
>>performance loss when debugging is off.
>>
>>Now, it seems to me that the Jylog does something similar: if not logging,
>>no listener is present, so no performance penalty (the logging feature is
>>always present in the JVM). And since Log4J suggest using categories that
>>resemble the package structure, filtering log data on package structure
>>should come very close to this approach.
>>
>>In other words: I am charmed by the Jylog idea. Not new (because all IDE
>>use
>>it) but interesting because it focuses on logging.
>>
>>Tom
>>
>>
>>
>> >From: Benson Chen <benson@porivo.com>
>> >Reply-To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
>> >To: Log4J Developers List <log4j-dev@jakarta.apache.org>
>> >Subject: Re: automatic trace insertion
>> >Date: Tue, 18 Dec 2001 13:38:50 -0500
>> >
>> >Vincent,
>> >
>> >Yup, I don't doubt that that's the way to do it.... nice clean
>>separation
>> >of
>> >logic and data. In order to make sense of the trace, everyone has to
>>make
>> >sure that the toString() method is implemented for each data object.
>> >Actually
>> >this leads to another question (which might need another thread)... does
>> >anyone know of some code that automatically creates toString() methods?
>> >Possibly using reflection to get instance variables and fills in the
>> >toString() method for you. As you can see, I'm a proponent of any form
>>of
>> >automation... maybe because I'm lazy. :-) -Benson
>> >
>> >Vincent Massol wrote:
>> >
>> > > In our case, the data objects are just that ... data objects. These
>> > > objects are manipulated by business methods (they are passed as
>> > > parameters or returned). As you can seem, the AspectJ code I have
>> > > provided does log all the parameters using the toString()
>>representation
>> > > of an object. So each of our object has a printable toString method.
>> > >
>> > > -Vincent
>> > >
>> > > > -----Original Message-----
>> > > > From: bchen@porivo.com [mailto:bchen@porivo.com] On Behalf Of
>>Benson
>> > > Chen
>> > > > Sent: 18 December 2001 17:15
>> > > > To: Log4J Developers List
>> > > > Subject: Re: automatic trace insertion
>> > > >
>> > > > Well sometimes logging those setter methods are just as important
>> > > because
>> > > > you
>> > > > want to know as you trace through your code that some object's
>>state
>> > > has
>> > > > been
>> > > > modified. As to solve the volume problem, I wouldn't enable
>>logging
>> > > to
>> > > > your
>> > > > whole system all at once unless of course you are doing system
>> > > testing.
>> > > > The
>> > > > beauty of log4j is that you can have all sorts of categories (one
>>for
>> > > each
>> > > > class) to allow you to enable or disable traces depending on what
>>you
>> > > are
>> > > > interested in and the amount of volume you want to deal with.
>> > > > Actually, one thing I was thinking about was having some sort of
>> > > > intelligent
>> > > > trace enablement where all traces are disabled by default but if a
>> > > > RuntimeException is thrown, you have code that goes through the
>>stack
>> > > > trace
>> > > > and enables trace logs for classes/methods leading up to the
>> > > exception.
>> > > > This
>> > > > way when you run your system again, you'll have logs tailored to
>> > > watching
>> > > > exactly what events occurred before your system blew up.
>> > > > Again, I'm not dictating how you should use log4j, but I would
>>think
>> > > that
>> > > > being able to easily get at more information is always best. But
>> > > using
>> > > > log4j
>> > > > in any capacity is better than none at all. :-) -Benson
>> > > >
>> > > > Vincent Massol wrote:
>> > > >
>> > > > > You are right, Paul, it is important not to log everything, as
>>logs
>> > > tend
>> > > > > to grow big very quickly and performance suffer a lot. In my
>>project
>> > > we
>> > > > > use AspectJ to log entries and exits with the following rules :
>> > > > >
>> > > > > - public methods that accept at least one parameter (static and
>> > > > > non-static),
>> > > > > - exclude the data object packages (we have all our data objects
>>-
>> > > > > setter/getter objects - located in a package)
>> > > > >
>> > > > > These rules seem to strike a good balance (at least for us).
>>Then,
>> > > we
>> > > > > use the log4j configuration to turn on/off logging for specific
>> > > > > categories.
>> > > > >
>> > > > > -Vincent
>> > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: Paul Glezen [mailto:pglezen@us.ibm.com]
>> > > > > > Sent: 18 December 2001 15:07
>> > > > > > To: Log4J Developers List
>> > > > > > Subject: RE: automatic trace insertion
>> > > > > >
>> > > > > > Scott brings up an important point. Do you really want to
>>trace
>> > > every
>> > > > > > method? Even simple getters/setters? Not only will there be a
>> > > > > > performance
>> > > > > > penalty (acceptable in some circumstances), it would also
>>create
>> > > more
>> > > > > > volume than you might want.
>> > > > > >
>> > > > > > Paul Glezen
>> > > > > > Consulting IT Specialist
>> > > > > > IBM Software Services for WebSphere
>> > > > > > 818 539 3321
>> > > > > >
>> > > > > >
>> > > > > > Scott Coleman <scott.coleman@soltima.com> on 12/18/2001
>>06:57:50
>> > > AM
>> > > > > >
>> > > > > > Please respond to "Log4J Developers List"
>> > > > > <log4j-dev@jakarta.apache.org>
>> > > > > >
>> > > > > > To: "'Log4J Developers List'" <log4j-dev@jakarta.apache.org>
>> > > > > > cc:
>> > > > > > Subject: RE: automatic trace insertion
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > I have not read the whole article yet, but I think you will get
>>a
>> > > > > heavy
>> > > > > > performance penalty if you use JPDA.
>> > > > > > Can someone please explain to me why you would want to log both
>> > > entry
>> > > > > and
>> > > > > > exit calls, for such a thin layer in the code. I thought that
>>it
>> > > was
>> > > > > meant
>> > > > > > to be very fast. So why would you want to add the performance
>> > > overhead
>> > > > > of
>> > > > > > logging entry and exit information. If you were to go down this
>> > > path
>> > > > > would
>> > > > > > it not be better to use jdk 1.4's new assert feature ?
>> > > > > >
>> > > > > > Regards
>> > > > > > Scott
>> > > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: Cakalic, James [mailto:James.Cakalic@heybridge.com]
>> > > > > > Sent: Monday, December 17, 2001 11:37 PM
>> > > > > > To: 'Log4J Developers List'
>> > > > > > Subject: RE: automatic trace insertion
>> > > > > >
>> > > > > >
>> > > > > > This article about Jylog -- a JPDA based logging generator --
>>just
>> > > > > > appeared
>> > > > > > on JavaWorld. Perhaps it relevant?
>> > > > > >
>> > > http://www.javaworld.com/javaworld/jw-12-2001/jw-1214-jylog.html
>> > > > > >
>> > > > > > Jim
>> > > > > >
>> > > > > > > -----Original Message-----
>> > > > > > > From: Paul Glezen [mailto:pglezen@us.ibm.com]
>> > > > > > > Sent: Monday, December 17, 2001 4:25 PM
>> > > > > > > To: Log4J Developers List
>> > > > > > > Subject: Re: automatic trace insertion
>> > > > > > >
>> > > > > > >
>> > > > > > > Hi Benson,
>> > > > > > >
>> > > > > > > It's not as easy as it looks to do "intelligently". While it
>>is
>> > > > > often
>> > > > > > > taught that methods should have a single entry point and exit
>> > > > > > > point, not
>> > > > > > > many programmers adhear to this. It is not at all uncommon
>> > > > > > > to find return
>> > > > > > > statements in if-blocks and try-catch blocks. Sometimes the
>> > > > > > > exit logic can
>> > > > > > > get very convoluted.
>> > > > > > >
>> > > > > > > I've always been partial to single exit logic. I didn't
>> > > > > > > become a fan until
>> > > > > > > trying to insert trace statements, just as you describe, in
>> > > > > > > other people's
>> > > > > > > code. It can be a nightmare.
>> > > > > > >
>> > > > > > > - Paul
>> > > > > > >
>> > > > > > > Paul Glezen
>> > > > > > > Consulting IT Specialist
>> > > > > > > IBM Software Services for WebSphere
>> > > > > > > 818 539 3321
>> > > > > > >
>> > > > > > >
>> > > > > > > Benson Chen <benson@porivo.com>@porivo.com on 12/17/2001
>> > > 01:57:15 PM
>> > > > > > >
>> > > > > > > Please respond to "Log4J Developers List"
>> > > > > > > <log4j-dev@jakarta.apache.org>
>> > > > > > >
>> > > > > > > Sent by: bchen@porivo.com
>> > > > > > >
>> > > > > > >
>> > > > > > > To: log4j-dev@jakarta.apache.org
>> > > > > > > cc:
>> > > > > > > Subject: automatic trace insertion
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Hi all,
>> > > > > > >
>> > > > > > > I'm interested in automatically inserting log4j trace
>> > > > > > > statements at the
>> > > > > > > beginning of all methods and right before the end of a method
>> > > > > (return
>> > > > > > > statement or thrown exception). I'm presuming most people
>>have
>> > > > > worked
>> > > > > > > on projects with extensive class libraries and it would be
>>great
>> > > if
>> > > > > > > there was a class parser that could intelligently insert
>>log4j
>> > > > > > > statements automatically. If there isn't anything out there
>> > > > > > > like that,
>> > > > > > > does anyone know of a java class parser that can be used to
>> > > > > > > do this sort
>> > > > > > > of thing? Thoughts or ideas? Thanks!
>> > > > > > >
>> > > > > > > --
>> > > > > > > Benson Chen
>> > > > > > > Director of Software Engineering
>> > > > > > > Porivo Technologies, Inc.
>> > > > > > > Phone: (919)806-0566x12
>> > > > > > > E-Mail: benson@porivo.com
>> > > > > > > "Measuring end-to-end Web performance"
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > To unsubscribe, e-mail:
>> > > > > > > <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>> > > > > > > For additional commands, e-mail:
>> > > > > > > <mailto:log4j-dev-help@jakarta.apache.org>
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > To unsubscribe, e-mail:
>> > > > > > > <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>> > > > > > > For additional commands, e-mail:
>> > > > > > > <mailto:log4j-dev-help@jakarta.apache.org>
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > > <font size="1">Confidentiality Warning: This e-mail contains
>> > > > > information
>> > > > > > intended only for the use of the individual or entity named
>>above.
>> > > If
>> > > > > the
>> > > > > > reader of this e-mail is not the intended recipient or the
>> > > employee or
>> > > > > > agent
>> > > > > > responsible for delivering it to the intended recipient, any
>> > > > > > dissemination,
>> > > > > > publication or copying of this e-mail is strictly prohibited.
>>The
>> > > > > sender
>> > > > > > does not accept any responsibility for any loss, disruption or
>> > > damage
>> > > > > to
>> > > > > > your data or computer system that may occur while using data
>> > > contained
>> > > > > in,
>> > > > > > or transmitted with, this e-mail. If you have received this
>> > > e-mail
>> > > > > in
>> > > > > > error, please immediately notify us by return e-mail. Thank
>>you.
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > To unsubscribe, e-mail: <mailto:log4j-dev-
>> > > > > > unsubscribe@jakarta.apache.org>
>> > > > > > For additional commands, e-mail: <mailto:log4j-dev-
>> > > > > > help@jakarta.apache.org>
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > To unsubscribe, e-mail: <mailto:log4j-dev-
>> > > > > > unsubscribe@jakarta.apache.org>
>> > > > > > For additional commands, e-mail: <mailto:log4j-dev-
>> > > > > > help@jakarta.apache.org>
>> > > > >
>> > > > > --
>> > > > > To unsubscribe, e-mail: <mailto:log4j-dev-
>> > > > unsubscribe@jakarta.apache.org>
>> > > > > For additional commands, e-mail: <mailto:log4j-dev-
>> > > > help@jakarta.apache.org>
>> > > >
>> > > > --
>> > > > Benson Chen
>> > > > Director of Software Engineering
>> > > > Porivo Technologies, Inc.
>> > > > Phone: (919)806-0566x12
>> > > > E-Mail: benson@porivo.com
>> > > > "Measuring end-to-end Web performance"
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > To unsubscribe, e-mail: <mailto:log4j-dev-
>> > > > unsubscribe@jakarta.apache.org>
>> > > > For additional commands, e-mail: <mailto:log4j-dev-
>> > > > help@jakarta.apache.org>
>> > > >
>> > >
>> > > --
>> > > To unsubscribe, e-mail:
>> ><mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>> > > For additional commands, e-mail:
>> ><mailto:log4j-dev-help@jakarta.apache.org>
>> >
>> >--
>> >Benson Chen
>> >Director of Software Engineering
>> >Porivo Technologies, Inc.
>> >Phone: (919)806-0566x12
>> >E-Mail: benson@porivo.com
>> >"Measuring end-to-end Web performance"
>> >
>> >
>> >
>> >
>> >--
>> >To unsubscribe, e-mail:
>><mailto:log4j-dev-unsubscribe@jakarta.apache.org
>> >
>> >For additional commands, e-mail:
>><mailto:log4j-dev-help@jakarta.apache.org
>> >
>> >
>>
>>
>>_________________________________________________________________
>>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>>
>>
>>--
>>To unsubscribe, e-mail:
>><mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail:
>><mailto:log4j-dev-help@jakarta.apache.org>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>><mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail:
>><mailto:log4j-dev-help@jakarta.apache.org>
>>
>
>
>_________________________________________________________________
>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
>--
>To unsubscribe, e-mail: <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>
>
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
--
To unsubscribe, e-mail: <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic