Hi guys, I've just committed a bunch of changes to allow support for SSL using the new Transport/TransportFactory paradigm. The hard work was done by Chris Jackson and Larry Meader who have already posted to this list.
I've created a new DefaultXmlRpcTransportFactory that can load other XmlRpcTransportFactory instances either by class name, or by a short name registered in an internal Hashtable (as we do with SAX drivers). XmlTransportFactory now has some extra semantics. A transport factory can be loaded and used dynamically if it defines a constructor that takes a Properties instance. This instance can be pre-configured with at least the URL and basic authentication information, and may define its own specific properties. The code submitted by Chris/Larry depends on Sun's com.sun.net.ssl package, so it's been isolated in the secure.sunssl subpackage. It compiles/links OK, but its not been tested very much. It works by setting up some backdoor trickery that will register the com.sun.net.ssl classes as the provider for https: URL's. Since this is one-off and not per-connection, it's all been moved to the factory constructor. The transport instances themselves are still of type DefaultXmlRpcTransport (that uses URLConnection). This means that using SunSSLTransport will configure your entire application to use Sun's SSL implementation for "https://"; URLConnection instances. This may not be the desired behaviour, so it has not been set as default. To use the provider, either call setTransport yourself (nicer, since you can handle the exception)or it will be called automatically the first time you connect to an https URL. I'm looking at how to provide a more generic solution, since there is a javax API for loading JSSE providers, but this will most likely require a later version of JSSE that has more interfaces in the javax.net.ssl package. A note on why createTransport() in XmlRpcTransportFactory has no parameters: The semantics as I see them are that an XmlRpcTransport instance represents a physical connection to a server, and that the factory is responsible for creating and configuring these instances. As far as use cases goes, this means: One server, one connection per RPC: Create an XmlRpcClient for the URL. (You will use DefaultXmlRpcTransport). One server, custom transport: Create an XmlRpcClient with a URL and the appropriate transport factory (!! URL is not always used) One server, pipelined RPC's: Create an XmlRpcClient for the URL (!! URL is not always used). Create an XmlRpcTransport however you like: via the default transport factory via a transport factory you made. via a transport constructor. Pass it in to execute(request, transport) Multiple servers: 1. Use one of the first two cases, but create a client per server. 2. Use the last case and create the transport instances yourself (with or without a factory). !! - I just noticed this, and it will be fixed, however it involves changing at least adding a getURL() method to XmlRpcTransport, and maybe (longer term) modifying AsyncCallback to take a transport instead of a URL. Having one client and multiple servers becomes difficult to handle because of all the properties it may be necessary to override in the underlying transport implementation. This problem has already occured with authentication information (which is not elegantly handled at the moment), and will likely worsen with all the options available for different SSL operations. This is best programmed explicitly (Multiple servers case) than attempting to do it generically in our code. Andrew.
