I have this project that started years ago and still uses old Apache 1.1 version of the XML-RPC library. A few days ago I needed to add an extra functionality to the services it exposes. The underlying API for the new service works a lot with array of objects which is not friendly with that version of XML-RPC library.
The thing is that up until version 3.x of Apache library, Vector and Hashtable were only Java classes that could be used for transferring collections (<array> and <struct> XML-RPC types respectively). So naturally, I thought this was an ideal opportunity to upgrade to 3.x version, which is much better in handling various Java constructs (Object[] among them) as XML-RPC types. This is where surprises started to pop up.
First of all, the 3.x branch is not compatible with older versions. That’s usually not a problem, just provide a migration guide and it all should be well. But things are not that simple in this case. The problem with 3.x branch is that (so far) it doesn’t support registering objects as XML-RPC handlers. This is one of fundamental requests for this kind of library, and I still can’t believe how it could be missing in such a project. Instead, it is advised that you configure your handlers through properties file, such as:
Calculator=org.apache.xmlrpc.demo.Calculatoror the same thing thorough the code:
PropertyHandlerMapping phm = new PropertyHandlerMapping();
phm.addHandler("Calculator", org.apache.xmlrpc.demo.Calculator.class);But I don’t want that. I want that my “fully-configured” objects serve requests. This approach, suggested by project documentation, forces that every object must be responsible for obtaining its own configuration, which is exactly the opposite of configuring our applications through various IoC containers (as preached in last few years). In this way there is no simple way in which you can expose your Spring beans through the XML-RPC interface.
I’m aware that I can make my own implementation of the XmlRpcHandlerMapping interface (or some of its derivates), but I don’t really want to go that way. For now, it’s just simpler to modify my current handlers to return Vectors and Hashtables. So I’ll stick to the branch 2.x of the Apache’s library.
And for the future, if I ever need to change my XML-RPC infrastructure, here’s my wish list (influenced mostly by positive experiences with XFire):
- Support for “advanced” type conversion between Java and XML-RPC types
- Support for annotation similar to those defined in JSR 181 (much simpler of course). I want to be able to say, this class is a handler for this URL and these methods should be exposed. The library should do the rest.
- Support for Spring integration (in more than one way) – through servlets, remoting, XBeans, etc.
- No need for standalone web-server, a proper Jetty integration would be more than enough.
- The previous request simplifies the whole implementation a lot, since an appropriate HTTP server (Jetty in case of standalone applications) would be responsible of security and similar tasks.
Or to put it in other words, it should be just an simple implementation of the protocol (with type support like in Apache 3.x) focused on good integration in Java infrastructure (as an easily configured component for various Java servers, containers and frameworks). No HTTP-related stuff is needed.