#ifdef

A client’s project requires a Java solution to fit their deployment strategy. One specific component of the implementation is an XML-RPC server. Using Groovy would be useful because there is a lot of XML being slung around as parameters. I could go with the Groovy XMLRPCServer, but it does not support SSL.

No problem, I’ll find a Java solution and Groovify it. How about the Apache XML-RPC implementation?. Excellent. However, I need to know that it works in its most basic, i.e. Java form. I’d rather not sandbox up an entire XML-RPC solution just to see how this thing works. Though small, there ought to be a better way than throwaway, experimental code. A nice way to deal with this is to use the published Calculator example with easyb.

The calculator class was unchanged. Here’s the easyb story that combines the xmlrpc server and client sides.

import org.apache.xmlrpc.client.*;
import org.apache.xmlrpc.webserver.*;
import javax.servlet.http.*;

scenario "apache xmlrpc server should work", {

        given "an xmlrpc servlet",{
          def sum = 0
          servlet = new XmlRpcServlet()
        }

        and "a servlet webserver", {
          webServer = new ServletWebServer(servlet, 4000)
          webServer.start()
        }

        when "the calculator.add method is invoked by an xmlrpc client", {
          config = new XmlRpcClientConfigImpl()
          config.setServerURL(new URL("http://127.0.0.1:4000/"))

          client = new XmlRpcClient()
          client.setConfig(config)

          sum = client.execute("Calculator.add", [33, 9])
        }

        then "the sum should be correct", {
          sum.shouldEqual 42
        }

        and "stop the webServer", {
          webServer.shutdown()
        }
}

Also, very nice how easyb allows some relaxation of the strict Java syntax in the xmlrpc client section. That starts to suggest what a Groovy subclass might look like. Next, a git commit to capture this working example in a readable form for the lifetime of the project.