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:11:35 GMT
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>


Mime
View raw message