Jochen Wiedmann (JIRA) wrote:
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12367658 ]
Jochen Wiedmann commented on XMLRPC-75:
---------------------------------------
Walter, I have added the interfaces XmlRpcListableHandlerMapping, and
XmlRpcMetaDataHandler. Please note:
- I have added some comments. They represent my thoughts. As such, they are
questionable.
Please read them carefully and verify, whether they meet your expectations.
Hmm, they seem to be based on the PHP implementation of these methods,
and I'm not sure of the meaning of the one describing the expected
behavior of system.methodSignature for a non-signature-supporting
method. My thought is to just return an empty outer list.
Also, should there be a difference between the "method does not support
X" response and the "no such method" response? I am thinking to return
an empty result for the first, and give a "fault" response
(XmlRpcException) for the second.
- I have added methods getMethodSignatures() and getMethodHelp() to the handler
mapping.
Obviously, the will usually be implemented by simply calling the respective
handlers
methods. However, I find it thinkable, that a handler mapping will not do
this.
Hmm, I think I see your point, although it does mean adding boilerplate
code for any mapping that does the expected thing.
If the above is fine for you, then I suggest the following steps to follow:
- Modify your XmlRpcSystemImpl to use the handler mapping methods.
(Nice idea, btw, to implement it like this. Did you note, that it can easily
be
added to the property mappings by simply adding a property "system"?
Dynamic addition isn't required.)
Actually, because it has no zero-argument constructors, the current
PropertyHandlerMapping cannot instantiate it. I'm adding support for
passing itself to objects when necessary.
- Make the default handler mappings implement listable handler mapping.
- Same for the default handlers, which should implement metadata handler.
Working on this now.