> I would very much like to dump the WebServer class in favor of > wrapping the XmlRpcServer in a HttpServlet (and not using a XML-RPC > client to make requests like the current XmlRpcProxyServlet does). > Basically, we'd mark it as deprecated and cease maintainence on it. As > is, it has serious problems (as does a lot of the code in this > package).
Funny that, I was looking at replacing the WebServer for our local implementation so that I could split off a particular class of HTTP request. The problem with relying entirely on a servlet engine is one of speed (mentioned already), but also of dependencies. The current xml-rpc package is quite small and is self-contained. Requiring a servlet implementation means that an application that uses xml-rpc must embed and distribute a servlet engine, be embedded in a servlet engine, or distributed as a WAR or similar. I haven't seen a servlet engine that is as simple to embed as the WebServer (although I would like to be wrong). I think that people embedding XML-RPC functionality in their applications may also be concerned about losing control over how threads and synchronicity are managed. If you embed the current XmlRpcServer as part of a servlet doPost() method, then there is a conflict between the threading done by the servlet engine, and that done by the XmlRpcServer. The servlet engine has already allocated a thread to the request, there is no need to pool and manage threads again. It seems to me that the current XmlRpcServer does a good job of handling threads in normal operation (without a servlet engine out front). If the Worker was split out, and passed an extra callback interface to handle the URI -> object mapping, then it would be easy to embed XML-RPC into an arbitary HTTP implementation without embedding either the XmlRpcServer or the WebServer. Andrew.
