Search code examples
javamigrationxml-rpc

Migrating Apache xmlrpc from 2.0.1 to 3.1.3 - How to deal with the removal of the SecureWebServer and related APIs?

I'm upgrading java xmlrpc from 2.0.1 (org: xmlrpc; module: xmlrpc) to 3.1.3 (org: org.apache.xmlrpc; modules: xmlrpc-client, xmlrpc-server, xmlrpc-commons) in preparation of a migration to JDK 11. Because this project has been split into separate modules for client and server and, I have to fix about three dozen compilation errors. Most of these aren't a big problem. However, I've run into a bit of a roadblock in that there are a number of classes related to secured XMLRPC connections that have been removed in version 3.0:

org.apache.xmlrpc.secure.SecureWebServer; // including setParanoid(boolean), acceptClient(String) and addHandler(string, Handler)
org.apache.xmlrpc.AuthenticatedXmlRpcHandler;
org.apache.xmlrpc.secure.SecureXmlRpcClient; // including setBasicAuthentication(username, password)

We use these in the following ways:

  • We have a SecureWebServer class that extends from the Apache SecureWebServer, though I don't know if we need this anymore because it appears like the only reason we overrode this was for improved shutdown logic, which seems to be improved already in the 3.1.3 release.
  • We have a custom Handler class that extends from AuthenticatedXmlRpcHandler. This handler uses a custom ValueProvider for additional logic related to Timestamps and other types that weren't supported in 2.0.1. I don't know if we need this ValueProvider anymore either.
  • We have a client/server architecture and allow our users to optionally encrypt the communication between the server and the client. Because of this, we have a bunch of logic to configure a SecureXmlRpcClient if necessary.

I've tried to find a migration guide for migrating from 2.X to 3.X versions, and while the Apache site on XMLRPC does contain explanations to some extent, it's not quite the same as a migration guide. Best I can tell, you should now use a config class? It's somewhat confusing, and I'm wondering if it's still necessary to use separate secure and insecure classes.

The above might be more detail than is necessary for the question, which is: How do I handle the removal of separate servers and clients for secure xmlrpc calls in XMLRPC 3.0? Like, do I still need to create separate secure and insecure clients and servers in code, or can everything now use the default XMLRPC server and client with no differentiation between secure and insecure servers and clients?

Solution

  • Like, do I still need to create separate secure and insecure clients and servers in code, or can everything now use the default XMLRPC server and client with no differentiation between secure and insecure servers and clients?

    Yes you still need the separate implementations. In 3.x it is up to clients to provide secure set up.

    There are couple of ways

    On server side you will need to override createServerSocket to substitute for secure SSLServerSocket similar to what 2.x had.

    On client side you have initialize with SSLServerSocketFactory on the XmlRpcCommonsTransportFactory to create ssl factory. Basic Auth can be configured using XmlRpcHttpClientConfig.

    Alternatively on server side you could use the full blown servlet container like tomcat or jetty which comes up its own ssl factory.

    For client side you can use Httpcient to cover ssl.

    You can find some details on how to configure the XmlRpcServlet and client

    https://ws.apache.org/xmlrpc/server.html

    https://ws.apache.org/xmlrpc/client.html