xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <rho...@isisnetworks.net>
Subject Re: [VOTE] Release plan
Date Thu, 30 Jan 2003 23:33:06 GMT
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.
>- Dan
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.

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

View raw message