logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cakalic, James" <James.Caka...@heybridge.com>
Subject RE: automatic trace insertion
Date Tue, 18 Dec 2001 18:44:35 GMT
We wrote a base class which all the data classes extend. Among other things
it implements a reflection-based toString() that properly interrogates
superclasses and permits Modifier-based filtering. If anyone is interested I
can see if it would be permissible for me to post it.

Jim Cakalic

> -----Original Message-----
> From: Benson Chen [mailto:benson@porivo.com]
> Sent: Tuesday, December 18, 2001 12:39 PM
> To: Log4J Developers List
> Subject: Re: automatic trace insertion
> 
> 
> 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>
> 


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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message