[ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12361436 ]
Walter Mundt commented on XMLRPC-75: ------------------------------------ Don't worry about the original patches then, as they're not terrribly relevant -- they're both around 3-4 years old at this point, thus this new attempt. However, this is not just "yet another handler mapping." It adds a new interface that custom handlers can implement to support introspection, as well as a new derived Invoker that implements this interface using Java reflection. It also adds a new ContextXmlRpcHandler which makes use of this interface to actually implement the method calls specified by the introspection API, and a function in the SystemHandler to enable those methods if it is so desired. First, I will argue that this is a useful addition to the library. Second, I will argue that this code belongs in the core distribution. For the first point: While introspection is not part of the XML-RPC specification, it is a very useful feature for automatic discovery of services and proxy interface generation, among other things. This particular introspection interface is supported both by the PHP XML-RPC extension here: http://us3.php.net/manual/en/ref.xmlrpc.php and the standard Python XML-RPC server library (although the latter doesn't yet support methodSignature queries automatically). Supporting it here would mean that this library would behave more similarly to other XML-RPC implementations that are available; whether this is desirable in and of itself is debatable, but I think it is if there is no downside to the proposition. For the second: First of all, it's harmless for those who do not wish to take advantage of it. None of the code for actually calling a particular RPC method is changed, so the only possible performance change is (very) slightly larger code size. Second, as I mentioned above, having it bundled increases similarity with other XML-RPC implementations. Third, some changes, that make the introspection API easier to use, such as the new introspection-related methods on the SystemHandler and DefaultHandlerMapping class, and the addition of introspection support to the SystemHandler, could not be implemented as elegantly were the introspection code to be published and maintained separately. Finally, if introspection is not merged into the main source tree, this patch will likely end up out-of-date and useless, just as the previous one did, resulting in people who need introspection support sticking with older versions of the library and being unable to contribute to the project's current code. On the other hand, if it is merged, then it should be fairly easy to see when it breaks and fix it as the changes that require it to be updated are made. > Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) > -------------------------------------------------------------------- > > Key: XMLRPC-75 > URL: http://issues.apache.org/jira/browse/XMLRPC-75 > Project: XML-RPC > Type: New Feature > Components: Source > Versions: unspecified > Reporter: Walter Mundt > Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch > > I've taken Aaron Hamid's Introspection patch (which was in turn derived from > the one here: > http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and > basically rewritten it to work with the current XML-RPC library. > I tried to set it up so that it followed the existing coding style as much as > possible, and would not break any existing applications. For example, when I > needed a list of handlers supported by a particular mapping, I added a new > interface XmlRpcListableHandlerMapping that provides this information, made > the default handler implement it, and designed my code so that if it were not > implemented by a handler in use, everything would work except the > system.listMethods functionality that relies on it. > I hope you will be able to integrate this code into the next version of the > library; please contact me with any questions or issues. I will be attaching > the patch to this issue if I can so that the problem with his previous patch > will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
