Sounds great in english! I'd actually like to start using log4j with my xmlrpc code, so when you get it commitable, I'd love to play with it.Hmm, thread revival. Had to go back to the archives to check out what I had said. This proposal looks like a solution.
Log itself is an interface, LogFactory is a class. The tiniest possible implementation we could build would be to have our own LogFactory that copies the real LogFactory public API and implements Log itself and does very little. This could be pretty small, and provide the required functionality. The problem then becomes keeping current with the LogFactory public API, since we need to keep binary compatibility.
I'd prefer having a createLog() method in its own interface, which then either creates a BasicLog (logs everything to stderr, dependent on setting of XmlRpc.debug) or calls an instance of XmlRpcLog to create the Log instance (via commons logging by default). I just built a trial implementation, it's about 4k/2k including the Log interface from commons logging.
I think I may have put that comment there. Check bug 16383.As a separate issue, I just looked at how the applet stuff works, and it is only dependent on the Base64 class from the main package. Although this doesn't seem to be included in applet jar ;). Everything else it repeats in SimpleXmlRpcClient. There is a comment to the effect that this should really all be done with the core classes. Current classes are 16k/8k (20k/10k including Base64).
Including the core proper into the applet would make it much bigger, but moving SimpleXmlRpcClient up a level and leveraging the code in XmlRpc would result in a small increase in the size of the applet code delivered (I think that it will actually be a decrease, since the secure/ directory is currently packaged), but have the advantage of being simpler to maintain.
Andrew.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16383
