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