Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 64547 invoked by uid 500); 21 Feb 2002 13:19:26 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 62143 invoked from network); 21 Feb 2002 13:16:52 -0000 Importance: Normal Subject: RE: [AXIS - PATCH] More logging changes To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Russell Butek" Date: Thu, 21 Feb 2002 07:16:24 -0600 X-MIMETrack: Serialize by Router on D04NMS23/04/M/IBM(Release 5.0.8 |June 18, 2001) at 02/21/2002 08:16:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 butek@us.ibm.com Richard Sitze/Charlotte/IBM@IBMUS on 02/20/2002 04:57:40 PM Please respond to axis-dev@xml.apache.org To: axis-dev@xml.apache.org 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 rsitze@us.ibm.com CORBA Interoperability & WebServices IBM WebSphere Development Russell Butek/Austin/IBM To: axis-dev@xml.apache.org @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 butek@us.ibm.com Tom Jordahl on 02/20/2002 01:38:45 PM Please respond to axis-dev@xml.apache.org To: "'axis-dev@xml.apache.org'" 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:rsitze@us.ibm.com] Sent: Wednesday, February 20, 2002 12:28 PM To: axis-dev@xml.apache.org 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 rsitze@us.ibm.com CORBA Interoperability & WebServices IBM WebSphere Development