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 Wed, 19 Dec 2001 09:08:24 GMT
Okay, I had my first peek at Jylog and (first impression!) it goes too far. 
What I need a logging package to tell me is:
- where did I go
- and what values did I drag along

So if I could define points of interest (package names, method names + 
parameter values, variable names) which I want to see dumped 
chronologically, with the threadname before it, that would be enough.

Now I have not studied it, but I can imagine that the variable thing is a 
problem... Hmmm. Well, something to do during christmas vacation.

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


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


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