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 <[EMAIL PROTECTED]> on 12/18/2001 06:57:50 AM

Please respond to "Log4J Developers List" <[EMAIL PROTECTED]>

To:   "'Log4J Developers List'" <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]]
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:[EMAIL PROTECTED]]
> 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 <[EMAIL PROTECTED]>@porivo.com on 12/17/2001 01:57:15 PM
>
> Please respond to "Log4J Developers List"
> <[EMAIL PROTECTED]>
>
> Sent by:  [EMAIL PROTECTED]
>
>
> To:   [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> "Measuring end-to-end Web performance"
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>


<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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to