> "Andrew Evers" <[EMAIL PROTECTED]> writes:
>
> It would be nice if one could get ahold of a single threaded object
> which can process XML-RPC calls like XmlRpcServer can. It would be
> very cool if someone would factor that code out of XmlRpcServer.
>
>> 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.
>
> Exactly. Is anyone up to this job?
Well, since I suggested it, and I have time to do it at the moment, I'll
have a go at splitting it up.
>From my perusal of the code it seems that XmlRpcServer has four
responsibilities:
1. Maintaining the handlername -> object mapping (in XmlRpcServer).
2. Plumbing extending XmlRpc (in Worker).
3. Managing the thread pool of workers (in XmlRpcServer).
4. Providing automatic invoker support (in Invoker).
1 & 2:
a. Encapsulate the methodName, request, username, and password
into an XmlRpcRequest class. Have a class that extends XmlRpc
(say XmlRpcProcessor) providing:
XmlRpcRequest parseRequest(InputStream, String, String)
XmlRpcRequest parseRequest(InputStream)
These methods would be non-synchronized and non-reentrant.
b. XmlRpcProcessor also provides an executeRequest method that
will use a callback interface to map handlers to objects.
void executeRequest(InputStream, String, String, HandlerMapping)
void executeRequest(InputStream, HandlerMapping)
c. The HandlerMapping interface is a single method
Object getHandler(String methodName)
this will return null for no mapping.
d. The DefaultHandlerMapping class implements HandlerMapping.
XmlRpcServer delegates calls to the DefaultHandlerMapping.
3. The changes above allow external management of threads
including having different threads handle the request
and response, and using the caller thread (for the
servlet engine case).
4. Splitting out the Invoker has recently been suggested by Kevin
Hester (my formatting):
> Of course, the glue class I'm describing is only a
> slight modification of Invoker.
>
> My solution: Make the invoker class public so that
> users can subclass it for custom behavior. In my case,
> I override execute to check for a null return value.
>
> My question to all:
>
> 1) Does this seem like a good solution? It sure
> seems better than people having to reinvent the
> introspection glue.
Andrew.
