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 Aaron Smuts <aa...@verizon.net> on 2002/02/26 02:56:57 UTC
default handler
When you have a default handler why do you have to specify a method? I
made a xml-rpc lateral cache for JCS and created a default handler for
puts. I'm still working on it, but I ran into a problem with using a
default handler. I didn't specify a method on the send and it wouldn't
work. I specified a .junk method and the problem was solved.
Also, is there a problem returning null? I keep getting some eof error
when the remote methods return null. It may be something else.
Aaron
RE: default handler
Posted by Aaron Smuts <aa...@verizon.net>.
> -----Original Message-----
> From: dlr@despot.finemaltcoding.com
[mailto:dlr@despot.finemaltcoding.com]
> On Behalf Of Daniel Rall
> Sent: Monday, February 25, 2002 10:08 PM
> To: rpc-dev@xml.apache.org
> Cc: aaron.smuts3@verizon.net
> Subject: Re: default handler
>
> "Aaron Smuts" <aa...@verizon.net> writes:
>
> > When you have a default handler why do you have to specify a method?
I
> > made a xml-rpc lateral cache for JCS and created a default handler
for
> > puts. I'm still working on it, but I ran into a problem with using
a
> > default handler. I didn't specify a method on the send and it
wouldn't
> > work. I specified a .junk method and the problem was solved.
>
> The specification <http://xml-rpc.com/spec> requires a "methodName"
> element be sent in the body of the RPC data, where the "methodName"
> body is an textual identifier (rather than an actual Java method
> name). I can't off-hand think of a good way to pick the right method
> from a generic object which is being used as a XML-RPC handler.
> However, for those classes implementing org.apache.xmlrpc's
> XmlRpcHandler interface, I can't see any reason why the server
> couldn't fill this portion of the data if another handler cannot be
> found. If things aren't like this already, patches welcome.
>
Ok. Thanks. I obviously haven't read the spec. No time. . .
It could just default to the execute method in the interface.
> > Also, is there a problem returning null? I keep getting some eof
error
> > when the remote methods return null. It may be something else.
>
> As per the specification <http://xml-rpc.com/spec>, null is not a
> valid return type. Patches improving any error handling of this
> behavior much appreciated.
>
Well that explains it. I'll return some junk or something indicating
success.
Thanks,
Aaron
> Daniel
RE: default handler
Posted by Aaron Smuts <aa...@verizon.net>.
> -----Original Message-----
> From: dlr@despot.finemaltcoding.com
[mailto:dlr@despot.finemaltcoding.com]
> On Behalf Of Daniel Rall
> Sent: Monday, February 25, 2002 10:08 PM
> To: rpc-dev@xml.apache.org
> Cc: aaron.smuts3@verizon.net
> Subject: Re: default handler
>
> "Aaron Smuts" <aa...@verizon.net> writes:
>
> > When you have a default handler why do you have to specify a method?
I
> > made a xml-rpc lateral cache for JCS and created a default handler
for
> > puts. I'm still working on it, but I ran into a problem with using
a
> > default handler. I didn't specify a method on the send and it
wouldn't
> > work. I specified a .junk method and the problem was solved.
>
> The specification <http://xml-rpc.com/spec> requires a "methodName"
> element be sent in the body of the RPC data, where the "methodName"
> body is an textual identifier (rather than an actual Java method
> name). I can't off-hand think of a good way to pick the right method
> from a generic object which is being used as a XML-RPC handler.
> However, for those classes implementing org.apache.xmlrpc's
> XmlRpcHandler interface, I can't see any reason why the server
> couldn't fill this portion of the data if another handler cannot be
> found. If things aren't like this already, patches welcome.
>
Ok. Thanks. I obviously haven't read the spec. No time. . .
It could just default to the execute method in the interface.
> > Also, is there a problem returning null? I keep getting some eof
error
> > when the remote methods return null. It may be something else.
>
> As per the specification <http://xml-rpc.com/spec>, null is not a
> valid return type. Patches improving any error handling of this
> behavior much appreciated.
>
Well that explains it. I'll return some junk or something indicating
success.
Thanks,
Aaron
> Daniel
Re: default handler
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Aaron Smuts" <aa...@verizon.net> writes:
> When you have a default handler why do you have to specify a method? I
> made a xml-rpc lateral cache for JCS and created a default handler for
> puts. I'm still working on it, but I ran into a problem with using a
> default handler. I didn't specify a method on the send and it wouldn't
> work. I specified a .junk method and the problem was solved.
The specification <http://xml-rpc.com/spec> requires a "methodName"
element be sent in the body of the RPC data, where the "methodName"
body is an textual identifier (rather than an actual Java method
name). I can't off-hand think of a good way to pick the right method
from a generic object which is being used as a XML-RPC handler.
However, for those classes implementing org.apache.xmlrpc's
XmlRpcHandler interface, I can't see any reason why the server
couldn't fill this portion of the data if another handler cannot be
found. If things aren't like this already, patches welcome.
> Also, is there a problem returning null? I keep getting some eof error
> when the remote methods return null. It may be something else.
As per the specification <http://xml-rpc.com/spec>, null is not a
valid return type. Patches improving any error handling of this
behavior much appreciated.
Daniel
Re: default handler
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Aaron Smuts" <aa...@verizon.net> writes:
> When you have a default handler why do you have to specify a method? I
> made a xml-rpc lateral cache for JCS and created a default handler for
> puts. I'm still working on it, but I ran into a problem with using a
> default handler. I didn't specify a method on the send and it wouldn't
> work. I specified a .junk method and the problem was solved.
The specification <http://xml-rpc.com/spec> requires a "methodName"
element be sent in the body of the RPC data, where the "methodName"
body is an textual identifier (rather than an actual Java method
name). I can't off-hand think of a good way to pick the right method
from a generic object which is being used as a XML-RPC handler.
However, for those classes implementing org.apache.xmlrpc's
XmlRpcHandler interface, I can't see any reason why the server
couldn't fill this portion of the data if another handler cannot be
found. If things aren't like this already, patches welcome.
> Also, is there a problem returning null? I keep getting some eof error
> when the remote methods return null. It may be something else.
As per the specification <http://xml-rpc.com/spec>, null is not a
valid return type. Patches improving any error handling of this
behavior much appreciated.
Daniel