logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Eugelink" <tom_eugel...@hotmail.com>
Subject Re: automatic trace insertion
Date Thu, 20 Dec 2001 08:15:14 GMT
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>


Mime
View raw message