I sent an email today describing a small patch which simply does a bit more refactoring with the XmlRpcRequest object, deprecating the various execute() methods that were around to use this central object. I also added a few more fields to it, and the accumulation of headers (which aren't used at the moment). This patch should hopefully be very straightforward. I haven't written any extra test cases, but 'ant test' passes the test cases. My intention is to hopefully build on this with an introspection patch and/or interceptors patch. A Kevin Hester seems to have already contributed a patch implementing the exact same introspection I would (it all derives from the same original patch). My introspection mods are sitting on my disk at work, I wanted to take one step at a time. However it seems that maybe people don't want introspection in (for security reasons), which is fine. Already (again) I hear someone asking about adding the ability to modify HTTP headers. I hate to beat the same drum over again, but I have frequently replied to posts saying that the interceptors patch would handle this, not to much avail. With the patch I sent today, at least this is a possibility without interceptors (because now XmlRpcRequest holds the headers).
As far as my original attempts to get the interceptors patch noticed, you can find some of the history here: http://marc.theaimsgroup.com/?a=93724818900001&r=1&w=2 (it doesn't go all the way back because I started back when Hannes Wolfner was still running the project from his site) To defend myself, I did describe what files were touched, what the patch did, and supplied a web page with further documentation on the flow of control, etc (it's all still there at: http://aeolus.cit.cornell.edu/xmlrpc/xmlrpc.html). I also included a verbosely documented fully working example usage (http://aeolus.cit.cornell.edu/xmlrpc/InterceptorsSample.java.html). I'm not sure if this counts as a "test case"...it is not a JUnit test case although it could encapsulated by one. This was an update to a preexisting patch of mine, and I don't remember any feedback indicating I should provide any further test case. I don't mind my patch being rejected, as long as I am at least told as much. It is just frustrating to see people ask for the same functionality over and over again which could be provided by a patch sitting on my hard drive. Personally, I don't see a critical need for introspection, however to do anything but basic HTTP authentication (and perhaps SSL, I've never tried that with this package), some sort of hooking mechanism is critical. CORBA has it, Tomcat has it, JBoss has it, even Axis appears to have it to some extent. The overhead of XML parsing/generating, and network IO probably dwarves any other aspect of the library. I think we are going to have to move to SOAP here (which is why I am investigating hooking mechanisms in Axis) because that is the train the industry has jumped on, so if the Apache xml-rpc community really doesn't want interceptors I'm not going to force it. Aaron Hamid
