Encapsulating logging for XML-RPC is more than a good idea, if for no other
reason than for performance and stability (try fixing a production console
java app only to find that the operator hit ctrl-S).

I agree that XML-RPC should support the overiding of a logging method with
the current default behavior (system.out). It would be a trivial change,
backward compatible, and a big improvement.

On top of this, it'd be nice if the logging methods were overloaded as well,
with args in the style of syslog, again with the default behavior routing
thru the simple logger method. Once this is done, we can actually instrument
xmlrpc server with debug log statements controlled by a property-- but this
functionaly can be incrementally added and used by those that can benefit
from it. (like me! ;)

--glenn mccomb

============================================
Glenn A. McComb             tel 858.551.9218
President & CEO             fax 858.777.3302
Navatar LLC                     La Jolla, CA
[EMAIL PROTECTED]            www.navatar.com
============================================
High-Performance Internet & Wireless Systems
     Architecture, Design & Development


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 21, 2002 11:45 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: logging


[moving discussion to dev list]

Jason van Zyl <[EMAIL PROTECTED]> writes:

> On Thu, 2002-06-20 at 16:28, Miguel DeAvila wrote:
> > It would be helpful if the xmlrpc package supported logging via log4j
rather then printing to System.err ...
>>
>> thoughts?
>
> If anything we should probably think about moving towards using the
> commons logging package.

This would be very useful, but again raises the question of how to
deal with external dependencies.  Many users are using the client code
from an applet (I assume that no one is using the server?), and extra
downloads (like most things) are always a PITA from applets.  Building
the external dep's code into the XML-RPC JAR is not a good idea, as it
leads to conflicts and LinkageErrors, the cause of which are very,
very difficult to debug (especially in apps which use multiple JARs,
some of which come from different class loaders).

- Dan

Reply via email to