Actually I've got a thought on how to add in debug messages without recompiling. For
a horrible hack say I've got a java class
like:
//Constants.java
public class Constants{
public static boolean isDebug(){return true;}
}
And in my main code I call:
if(Constants.isDebug()) log(someNastyFunction());
Now I could keep to versions of a class file generated from Constants.java (one which
returns true, one with returns false)
Replacing the class file Constants.class based upon my needs would effectively turn
debugging on/off. There is an overhead of this
approach for the lookup of the boolean, but it avoids the need to recompile to turn on
debugging. It isn't as nice as having a
debug flag passed in, but it would be a quick hack for most classes. It could even be
used to debug code in "production" by
replacing the class file and restarting. I prefer flags/config files to turn stuff
like this on/off, but it is a relatively quick
hack...
Jonathan
----- Original Message -----
From: "Pier P. Fumagalli" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 19, 2001 1:24 PM
Subject: Re: [TC4.0] Disabling debug output...
> Craig R. McClanahan at [EMAIL PROTECTED] wrote:
> >
> > - However, Pier's proposed approach doesn't deal with a need that I've
> > experienced regularly -- the need to turn on debugging messages
> > dynamically on an existing component, *without* recompiling it. This
> > is NOT simply aesthetics; either you can or you cannot change the level
> > of debugging output at runtime.
>
> You didn't get it Craig... I'm simply proposing to use the if (DEBUG)
> approach _instead_ of commenting out logs in the source file...
>
> Go and look at HttpConnector.java... There are TONS of // (comments) that
> could be replaced with an if (DEBUG).
>
> If you remove the comments, you too have to recompile the sources...
>
> Pier
>
>
