Announcing new interceptors patch

[ar...@cornell.edu]

Hello all,

  Back in February I wrote a patch that added "interceptor" functionality 
to the Helma XML-RPC library by Hannes Wallnoefer.  This first cut was 
a bit crude in the API it supplied for modifying calls.

(http://xmlrpc.helma.org/archives/xmlrpc/2001-February/000366.html)

I have recently been able to free up time and have taken a look again at 
the library, now moved to Apache.org, with apparently no changes (or very 
few).  I have recently refactored and rewritten the interceptor 
functionality from scratch, with a richer interceptor API, much more JavaDoc 
documentation and code comments, and a more extensive and documented 
example client/server.  I have isolated my changes as much as possible to 
helper classes, making minimal changes to the actual codebase of the 
library.

Explanation, download, and instructions of the patch can be found at:

http://aeolus.cit.cornell.edu/xmlrpc.html

(please don't kill my Tomcat, this is a workstation ;)

The patch is 68 Kb (if that means anything to anybody), introduces 6 new 
classes 2 of which are interfaces for the client and server 
interceptors, another 2 of which are rather small utility classes, and 
the last 2 of which are thin wrappers for keeping a list of 
interceptors.  The patch touches 5 XML-RPC classes: WebServer.java, to 
add  constructors accepting a specified XmlRpcServer object, and for header 
inspection; XmlRpcClient.java and XmlRpcClientLite.java, to add methods 
to register and interceptors, and read/write headers; XmlRpcServer.java, 
to modify the execute() call with more parameters, and to call server 
side interceptors; and XmlRpcProxyServlet, again, very minorly, to 
retrieve and collect headers before/after calling XmlRpcServer.

Now that the XML-RPC library is bundled with Ant, this patch works "out 
of the box".  I would like to hear any and all feedback.  I would 
*really* like to move off our complex CORBA infrastructure to an XML-RPC 
based solution, but cannot do this and maintain the same level of 
security (Kerberos security with stream encryption) which is mandatory 
for us, without "interceptor" functionality like this in the library.  
Not having to maintain a parallel fork would make my life a lot easier :)
This functionality should not affect performance very much at all if 
unused (and even less so if the library were switched to the
unsynchronized Java 2 Collections API)...it would amount to a handful of 
no-op calls.

Aaron Hamid
Cornell University