Making a new thread, this was buried in the replies to a Bugzilla message. :)
We started some discussions about using the Commons Logging package late last year. I think we decided to go forward with it as the size of the JARs we would need to include was small.
Why do we need the system property and the reflection trickery? Shouldn't we just have a Log for each instance of XmlRpcClient and XmlRpcServer? The Commons Logging facilities for discovering and instantiating a Log implementation seem ample.
After we settle that point, I would be thrilled to see this in the codebase.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Andrew Evers wrote:
Hi guys, I've just been doing some debugging of one of our packages that uses XML-RPC to perform some of its communication. One thing we needed to do is get accurate information about the methods and parameters sent in RPC's. Having omitted to put this information into our own code, I tried to use the XmlRpc debug facilities.I noticed a few things that I would like to fix: 1. There is no System property to set to enable debugging, this makes enabling debugging in the field difficult. I think there should be a System.getProperty in a static initializer in the XmlRpc class that enables debugging if the 'org.apache.xmlrpc.XmlRpc.debug' system property is set to anything. 2. The current debugging goes to a mix of System.out and System.err, probably for testing vs debugging purposes. This really needs to be logged via a dedicated debugging/tracing facility that can log to various locations (especially application log files). There are four obvious logging facilities available: a. System.out/err - not feasible in large or multi-threaded apps. b. Java 1.4 Logging API - I have no great love for this, and it is only available in 1.4. It should be an option though. c. Log4J - my preferred logging library, but not everyone's. d. Jakarta Commons Logging API - Jakarta wrapper for any or all of the above, which should be possible to use at the cost of importing one class (NoOpLog) and one interface (Log). Or, even one interface if lots of nullity checking is done. The Jakarta Commons Logging API is probably the best of the lot, and with a little work the impact of using it can be kept to a minimum. The applet can be distributed with only the Log interface and NoOpLog (and maybe SimpleLog). In order to keep the packaging as light as possible, the logging API would only be enabled if a System property 'org.apache.xmlrpc.XmlRpc.Log' is specified. This would then trigger a little reflection trickery to create an instance of the specified class. This constructor would be responsible for using the LogFactory in the Jakarta Commons Logging API to create a Log instance, or setting up a Log instance in some other manner. My implementation (not yet done, but 1 night's work) would be to add a protected static Log field called log to the XmlRpc class and change the System.out/err statements to: if (log.isXXXEnabled()) { log.XXX(expression); } And, add some extra code to log XmlRpcClientException's to the error facility (these exceptions are thrown when something serious occurs processing an RPC that is not the fault of the caller). The facilities available are: (the least serious) trace - xml parsing and timing information debug - request/response XML documents info - requests/responses and parameters warn - XmlRpcException (?) error - XmlRpcClientException fatal (the most serious) Does anyone have any other ideas on this, or am I duplicating anyone's work? I am planning on doing this work within the next few days. So, pipe up soon ;) Andrew.