Sun SSL transport and transport factories in general.

[Andrew Evers <ae...@redwood.nl>]

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.