Walter, I have committed some changes, that make
AbstractReflectiveXmlRpcHandlerMapping implement the
XmlRpcMetaDataHandlerMapping interface. Please, note the following:
- The implementation ensures, that the various "system.*" methods return
consistent result. In particular, a method returned by "system.listMethods"
is always able to provide a meaningful result for "system.methodSignature"
and "system.methodHelp".
I don't think this is the right approach. My preference would be to
provide as much information through the interface as possible. I don't
think it inconsistent to list methods for which signatures are
unavailable: better to say "it's there, and that's all the information I
can provide" then to hide methods which do not support the metadata
interfaces.
- I did not implement overloading. My goal is to keep the base classes simple
and clean. I am still open for subclasses, which allow overloading.
I still disagree with this approach. Overloading is a basic feature
that _is_ quite simple, and requiring the addition of a subclass to
implement it results in a poor design where other parts of the code
unrelated to overloading also have to be reimplemented.
I'll work on a way to abstract it out without compromising on the
cleanliness of the architecture, but in my not-so-humble opinion this
extra effort is unreasonable because I don't see why anyone would NOT
want overloading support. It can't do any harm, and it me it seems
unintuitive to map classes with overloaded methods to an RPC interface
by just picking one of them and using that, _especially_ when the RPC
interface itself supports overloading.
I'm sorry to be bringing this argument about overloading into the
mostly-unrelated context of metadata support, but I'm just completely
failing to understand the reasoning that justifies removing what I see
as an important and fairly basic feature of the library. Upgrades are
supposed to enhance functionality, not remove it.
- The code is not checked. It is quite likely, that you'll find bugs.
I'll look through it when I get some time.
- Keep documentation in mind. If you need a pointer to the apt format, see
http://maven.apache.org/guides/mini/guide-apt-format.html
I will look at that later.
