On Wed, 06 Dec 2006, Jochen Wiedmann wrote: > On 12/6/06, Daniel Rall <[EMAIL PROTECTED]> wrote: > > >> For historical reasons, void methods are currently unsupported. In > >> other words, as a workaround, change the method to return an int and > >> everything should be fine. You may also file a bug report to have this > >> changed, at least if extensions are turned on. > > > >Jochen, what about mapping this automatically to a basic or empty > >return value (e.g. empty struct, integer value of 1, etc.) even when > >extensions are not turned on? This wouldn't be in violation of the > >spec, only a difference from the original XML-RPC implementation. > >When in extension mode, we could return some type of nil value, which > >would be an actual protocol extension. > > I understand that this is a trap, in which one can fall very easily > and that your suggestion provides a way how to avoid it. > > I am unhappy, though, about the consequences in code. The places where > "void" is being detected and where return values are handled are > currently completely unrelated.
Would you mind providing some pointers into the version 3.x code so I
can take a look to get a better understanding of the situation (saving
you an exhaustive explaination :) ?
Also, how does the current code report this problem when "extension
mode" is active, and inactive?
> Question: How was this handled in 1.2, or 2, when null values haven't
> been supported? If these versions did as you suggest, then I'd be open
> to always return "" rather than null, if extensions are disabled.
> Otherwise, I'd suggest we leave things as they are.
For POJOs (the more interesting case), XML-RPC handlers trigger an
exception which complains that void method return values are not
supported:
public Object execute(String methodName, Vector params) throws Exception
{
...
if (returnValue == null && method.getReturnType() == Void.TYPE)
{
// Not supported by the spec.
throw new IllegalArgumentException
("void return types for handler methods not supported");
}
return returnValue;
}
http://svn.apache.org/repos/asf/webservices/xmlrpc/branches/XMLRPC_1_2_BRANCH/src/java/org/apache/xmlrpc/Invoker.java
http://svn.apache.org/repos/asf/webservices/xmlrpc/branches/XMLRPC_2_0_BRANCH/src/java/org/apache/xmlrpc/Invoker.java
For XML-RPC handlers implementing one of the handler interfaces
(XmlRpcHandler, AuthenticatedXmlRpcHandler, or ContextXmlRpcHandler),
the method return value is always of type Object, so this situation
never comes up.
Thanks, Dan
pgpfXssW6jFGZ.pgp
Description: PGP signature
