logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Chen <ben...@porivo.com>
Subject Re: automatic trace insertion
Date Tue, 18 Dec 2001 18:28:04 GMT
Scott,

I guess my preference is using log4j to help with both unit testing and system
testing.  In a perfect world, there wouldn't be bugs and we wouldn't need to
have great libraries like log4j to help us debug but this is reality.  We are
in fact human and we are not going to be able to anticipate everything that
happens in our code.  But it is really going to come down to your comfort
level.  If you work in a small team and there is a lot of trust between the
developers then yeah, you may be able to get away with not needing a lot of log
statements.  But when I was a IBMer, I worked on large scale projects that
crossed departments and even region.  You may trust your own code but you'll
never know who's code is broken unless you have proper tracing to pinpoint
who's at fault.  You're right that we are taking risks when we use third party
software because that's another error entry point but I'm really happy with the
way this open source community can quickly patch holes and come out with new
releases.  I think everything is a risk but you have to take those calculated
risks.  These are software development questions that everyone is going to have
to figure out and decide what works best.  To be honest, I've only been writing
code for 5 years so I'm still learning but you start to figure out the
inefficiencies and question how best to do things so you don't repeat history.
Thanks for the feedback though!  -Benson

Scott Coleman wrote:

> I like the idea of an intelligent agent, excellent. But I think this is an
> overkill. We should to a degree trust our code, it should have already been
> unit tested. To have log statements (even if the log statements are
> automatically generated) in every method, private as well as public implies
> that there is no trust in the code. I know it is frustrating when an
> exception occurs, and it takes a long time to find the source but hopefully
> this will add to the incentive to test and write better code.
> Also by adding all this extra logging are we not adding the risk that more
> exceptions could occur in the generated code, as it is using log4j as
> well???
>
> Just my thoughts,
> Scott
>
> -----Original Message-----
> From: Benson Chen [mailto:benson@porivo.com]
> Sent: Tuesday, December 18, 2001 6:15 PM
> 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>


Mime
View raw message