Daniel Rall wrote:
Is it the 1.2 branch which needs the base-64 fixes backported into it? I'm all for improving the performance, but I wouldn't hold up a release on account of it.Agreed, we need to put what we have into the 1.2 branch (once the voting is officially over).
I will port the fixes to Codec. However, the XML-RPC JAR should not contain any classes in the org.apache.commons.codec package -- experience has shown me that this can lead to horribly difficult to debug class loading problem, and often result in LinkageErrors when one application includes multiple versions of the same class in its classpath. I have already experienced enough of this horror with XML-RPC's inclusion of the SAX API. The only way I've successfully debugged this problem is by dumping a list of all the classes in my app, looking for duplicates, and comparing their bytecode sizes. Software like Tomcat which uses multiple class loaders increases the difficulty of this sort of debugging exponentially.Point taken. Do you suggest introducing another explicit dependency at runtime? Or do we keep a copy of Base64.java in our o.a.x.util package (amounting to an implicit dependency). The problem with keeping a copy is that it easily gets out of sync.
- Dan
Anyone know what Turbine does about their dependency on xmlrpc? I know Slide keeps an out-of-sync copy of the Jakarta HttpClient in their codebase, and I think they are looking at changing that.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
