xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: WebServer.java
Date Thu, 22 Aug 2002 17:34:35 GMT
"Andrew Evers" <aevers@redwood.nl> writes:

> 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).

Looks right on, and worth adding to its header documentation.  I'd do
it myself, but don't want to interfere with your changes; would you
include this list of responsibilities in your patch?

> 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.

Excellent suggestion!  This follows the pattern set by the servlet
API, Apache's httpd, and many other request/response app framework
I've worked with.  Were you thinking protected or public for the
method scoping?

I would be +1 on deprecating the XmlRpc class, moving its content into
a new XmlRpcProcessor class, and having the original XmlRpc class
extend the new one.

> 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)

I like it.  Why do to suggest passing the HandlerMapping into the
method call rather than having the XmlRpcProcessor maintain that
information internally?

> c. The HandlerMapping interface is a single method
>      Object getHandler(String methodName)
>    this will return null for no mapping.

Why not use the Map interface instead of a custom HandlerMapping?
Though HandlerMapping might have a narrower interface (which is nice),
is it really worth the trade-off of introducing a new object type?
The less custom object types involved in a package, the easier I find
it to understand (especially as a new developer/user).  It seems that
alternate mapping types could be just as easily supplied through
custom Map implementations.

> d. The DefaultHandlerMapping class implements HandlerMapping.
>    XmlRpcServer delegates calls to the DefaultHandlerMapping.

See above comment.

> 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).

Yay!

> 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.

Yup.
-- 

Daniel Rall <dlr@finemaltcoding.com>

Mime
View raw message