+1 to adding the System.out.println test to another target.

--
Tom Jordahl


-----Original Message-----
From: Russell Butek [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 21, 2002 8:16 AM
To: [EMAIL PROTECTED]
Subject: RE: [AXIS - PATCH] More logging changes


This is why I said Richard ALMOST convinced me.  Sure, log.debug is shorter
to type than System.out.println.  But in order to use it I have to turn
debugging on, and grep for my stuff in a potentially huge pile of output.
And then when I'm done I have to remember to turn debugging back off so I
don't accidentally commit my stuff with it turned on.  System.out.println
sounds a whole lot easier.

What I would really like is to keep this test that fails if it encounters
"System.out.println", but not run it as part of the build.  We already have
interop tests that we want to pull out of the build and put into another
harness that gump will run.  This System.out.println test should go into
that harness.

Russell Butek
[EMAIL PROTECTED]


Richard Sitze/Charlotte/IBM@IBMUS on 02/20/2002 04:57:40 PM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:
Subject:  RE: [AXIS - PATCH] More logging changes



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






Reply via email to