xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Evers" <andrew.ev...@redwood.com>
Subject Re: WebServer.java
Date Wed, 14 Aug 2002 08:52:58 GMT
> 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.



Mime
View raw message