xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Evers" <aev...@redwood.nl>
Subject Re: PATCH: Refactor XmlRpcServer and friends for flexible threading.
Date Tue, 27 Aug 2002 11:17:42 GMT
> Is a handler name which isn't resolvable really an error to a
> XmlRpcHandlerMapping implementation?  To the caller of getHandler(),
> sure it is.  But is it to the XmlRpcHandlerMapping itself?  (I'm not
> sure.)  I prefer to use exceptions only in exceptional situations (see
> "The Practive of Programming").

Well, I tend to think of a missing handler in an operational XML-RPC
system as calling a method that does not exist. In a production
machine-machine environment this is very much the case. Theexception also adds value by allowing
the mapping implementation
to specify the error message, so that it is possible to say
'too busy', 'backend down' or 'no such method'. Returning null
is not as expressive.

> Can anyone think of a more descriptive name for this than "worker"?

Not I ;)

>> Current classes with new roles:
>> + XmlRpcServer - handle a thread pool and a default handler mapping.
> You should probably note this in the JavaDoc.

I have a few more modifications coming through that externalize
the XmlRpc.Value class (to allow for a cleaner method to customize
the type mapping). The JavaDoc patches will come with this, followed
by some test cases in JUnit.

> ... Please check out a fresh copy and shout if I've missed
> anything.

You've missed Invoker.java ;)


View raw message