Close.. :-)
Actually, what I said was to use log.debug
and leave log.info alone. The updated (soon to be checked in by Russell)
integration guide spells out
how to configure Log4J to turn debugging on/off by individual class (or
package or...).
IFF you can assure the community that your log.info calls will be removed
(there is a risk, does anyone care?) after you debug, then using the higher
priority allows you to filter out other debug statements in the code. My
suggestion:
log.debug("russell: my message");
then
fgrep "russell" axis.log
or something similar.... also makes it easy to remove YOUR log statements,
and less likely to cut out more desirable (sorry russell :-) log.debug or
log.info...
Regarding log.info, It's likely that we (I?) will need to review all
current uses (also log.error and log.fatal) to minimize verbose behavior.
We need to consider where these will appear (console!) during runtime when
integrated into an application server.
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
Russell
Butek/Austin/IBM To: [EMAIL PROTECTED]
@IBMUS cc:
Subject: RE: [AXIS - PATCH] More
logging changes
02/20/2002 02:49
PM
Please respond
to axis-dev
+1.
I'm concerned about checking for System.out.println, too, but I've been
talking with Richard Sitze about it and he's almost won me over. It's a
philosophy thing. When I'm debugging, I use System.out.printlns all the
time. I'd hate a test to fail while I'm debugging because of them. But
instead of "System.out.println("...")" I should use "log.info("...")". I
have a little bit of concern that I'll see lots of other log.info stuff
that I don't care about, but Richard promises me that log.info should not
be used as much as AXIS uses it, so when it's cleaned up, then my log.info
calls will be almost the only ones that occur.
Russell Butek
[EMAIL PROTECTED]
Tom Jordahl <[EMAIL PROTECTED]> on 02/20/2002 01:38:45 PM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: [AXIS - PATCH] More logging changes
+1
These changes look good.
I am a bit dubious about checking the comments for System.out.println's,
but it might catch some cruft that shouldn't be checked in.
--
Tom Jordahl
-----Original Message-----
From: Richard Sitze [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 20, 2002 12:28 PM
To: [EMAIL PROTECTED]
Subject: [AXIS - PATCH] More logging changes
Some of these may be more controversial, so I'd appreciate a review by
interested parties before anyone applies the patch (diff -u, right?).
(See attached file: diffs.txt)
Summary of changes:
0. Everyone needs to learn how to edit/override log4j.properties rather
than writing code with System.out.println.... The tests will fail for most
such code.
1. New jar file, only needed for test (doesn't need to be distributed).
to be added in new directory test/lib: (See attached file:
jakarta-oro-2.0.5.jar)
2. test/utils/TestSrcContent.java is a "check-in" test that verifies
aspects of the source code. It has been changed to use a list of triplets:
regex (Perl5) filename, regex file-content, and content-match flag (should
or shouldn't be in file...). Matching names and content generate an error.
It currently looks for:
- direct use of log4j (error)
- use of System.out.println or System.err.println. Eexceptions are
AxisFault.java, Version.java, client/AdminClient.java,
providers/BSFProvider.java, utils.tcpmon.java, and all tooling in wsdl.
3. Outside of the listed exceptions, I've removed use of
System.out.println or System.err.println and replaced with log.info,
log.debug, or log.error as seemed appropriate (thereby allowing test to
pass :-).
4. To facilitate output that USE to appear, I've changed the log4j
properties file to allow INFO, ERROR, and FATAL log messages to be dumped
to the console.... of course we see even more now.
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
