You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Rapthor <ra...@lycos.de> on 2006/11/10 15:21:58 UTC
org.apache.xmlrpc.XmlRpcException: No such handler XMLRPCHandler.getAllGroups
Hi,
why do I receive this Exception although I do have specified a method
"getAllGroups". The other method works fine (inBound(x,y)):
public class XMLRPCHandler {
public XMLRPCHandler()
{
}
public void getAllGroups()
{
// blah
}
public String inBound(String from, String to) {
return "Thank you " + from + ", for calling " + to;
}
}
The call looks like this:
XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
config.setServerURL(new URL(url));
XmlRpcClient client = new XmlRpcClient();
client.setTransportFactory(new XmlRpcCommonsTransportFactory(client));
client.setConfig(config);
Object[] params = new Object[0];
client.execute("XMLRPCHandler.getAllGroups", params);
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: org.apache.xmlrpc.XmlRpcException: No such handler XMLRPCHandler.getAllGroups
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 12/13/06, Daniel Rall <dl...@apache.org> wrote:
> 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 :) ?
See the following quote from AbstractReflectiveHandlerMapping (which
provides access to a POJO by scanning its public methods);
protected boolean isHandlerMethod(Method pMethod) {
if (!Modifier.isPublic(pMethod.getModifiers())) {
return false; // Ignore methods, which aren't public
}
if (Modifier.isStatic(pMethod.getModifiers())) {
return false; // Ignore methods, which are static
}
if (!isVoidMethodEnabled() && pMethod.getReturnType() == void.class) {
return false; // Ignore void methods.
}
if (pMethod.getDeclaringClass() == Object.class) {
return false; // Ignore methods from Object.class
}
return true;
}
> Also, how does the current code report this problem when "extension
> mode" is active, and inactive?
Contrary to my believe, a method is silently ignored, if the above
method returns false.
> For POJOs (the more interesting case), XML-RPC handlers trigger an
> exception which complains that void method return values are not
> supported:
In particular, void methods haven't been supported in the past. Then I
see no sense in doing it now.
Jochen
--
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: org.apache.xmlrpc.XmlRpcException: No such handler XMLRPCHandler.getAllGroups
Posted by Daniel Rall <dl...@apache.org>.
On Wed, 06 Dec 2006, Jochen Wiedmann wrote:
> On 12/6/06, Daniel Rall <dl...@apache.org> 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
Re: org.apache.xmlrpc.XmlRpcException: No such handler XMLRPCHandler.getAllGroups
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 12/6/06, Daniel Rall <dl...@apache.org> 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.
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.
Jochen
--
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: org.apache.xmlrpc.XmlRpcException: No such handler XMLRPCHandler.getAllGroups
Posted by Daniel Rall <dl...@apache.org>.
On Fri, 10 Nov 2006, Jochen Wiedmann wrote:
> On 11/10/06, Rapthor <ra...@lycos.de> wrote:
>
> > public void getAllGroups()
> > {
> > // blah
> > }
>
> 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.
Re: org.apache.xmlrpc.XmlRpcException: No such handler XMLRPCHandler.getAllGroups
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 11/10/06, Rapthor <ra...@lycos.de> wrote:
> public void getAllGroups()
> {
> // blah
> }
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
--
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org