You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by kristian meier <kr...@jentro.com> on 2002/02/25 16:45:57 UTC
xml-rpc over ssl
Hello,
i am quiet new to opensource, etc and i have some small questions.
we are going to use the webserver in our new release. for this we need
SSL. there is a quite convinient tool for setting up the neccassary
ssl-system-properties, the SecurityTools. but unfortunatly there is no
setter-method for the TrustStorePassword and the getter uses the
DEFAULT_KEY_PASSWORD if not set.
what shall i do ? is there any chance that this will be fixed in a maybe
new release ? shall i copy and paste this class to my own sources and
fix it there. shall i prepare a PATCH and to whom i suppose to send this
? are there maybe plans to remove the SecurityTool in future releases,
since right now it is not really usable ?
would be nice if someone answers one or the other question.
Kristian
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
default handler
Posted by Aaron Smuts <aa...@verizon.net>.
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
default handler
Posted by Aaron Smuts <aa...@verizon.net>.
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: xml-rpc over ssl
Posted by Jason van Zyl <jv...@zenplex.com>.
On Mon, 2002-02-25 at 10:45, kristian meier wrote:
> Hello,
>
> i am quiet new to opensource, etc and i have some small questions.
>
> we are going to use the webserver in our new release. for this we need
> SSL. there is a quite convinient tool for setting up the neccassary
> ssl-system-properties, the SecurityTools. but unfortunatly there is no
> setter-method for the TrustStorePassword and the getter uses the
> DEFAULT_KEY_PASSWORD if not set.
>
> what shall i do ?
You can send a patch.
> is there any chance that this will be fixed in a maybe
> new release ? shall i copy and paste this class to my own sources and
> fix it there. shall i prepare a PATCH and to whom i suppose to send this
> ? are there maybe plans to remove the SecurityTool in future releases,
> since right now it is not really usable ?
It's very usable, it's been in use in the project I work on for 6 months
and the secure xmlrpc transfers work just fine.
> would be nice if someone answers one or the other question.
>
> Kristian
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
Re: xml-rpc over ssl
Posted by kristian meier <kr...@jentro.com>.
thanx, Kristian
Daniel Rall wrote:
>
> kristian meier <kr...@jentro.com> writes:
>
> > i am quiet new to opensource, etc and i have some small questions.
> >
> > we are going to use the webserver in our new release. for this we need
> > SSL. there is a quite convinient tool for setting up the neccassary
> > ssl-system-properties, the SecurityTools. but unfortunatly there is no
> > setter-method for the TrustStorePassword and the getter uses the
> > DEFAULT_KEY_PASSWORD if not set.
> >
> > what shall i do ? is there any chance that this will be fixed in a maybe
> > new release ? shall i copy and paste this class to my own sources and
> > fix it there. shall i prepare a PATCH and to whom i suppose to send this
> > ? are there maybe plans to remove the SecurityTool in future releases,
> > since right now it is not really usable ?
> >
> > would be nice if someone answers one or the other question.
>
> Hi Kristian. I've applied the patch you sent a while back for
> SecurityTool. If you come across more problems, please file an issue
> at <http://nagoya.apache.org/bugzilla/>.
>
> For future reference, it's best to send patches in unidiff format
> <http://jakarta.apache.org/site/source.html>. The larger (and more
> concise) the description, and the smaller the size of the patch, the
> more likely that someone will look at it sooner (as opposed to later,
> like this one, where the description and patch was split up over 3
> messages, one of which I forwarded to the list).
>
> Dan
Re: xml-rpc over ssl
Posted by kristian meier <kr...@jentro.com>.
thanx, Kristian
Daniel Rall wrote:
>
> kristian meier <kr...@jentro.com> writes:
>
> > i am quiet new to opensource, etc and i have some small questions.
> >
> > we are going to use the webserver in our new release. for this we need
> > SSL. there is a quite convinient tool for setting up the neccassary
> > ssl-system-properties, the SecurityTools. but unfortunatly there is no
> > setter-method for the TrustStorePassword and the getter uses the
> > DEFAULT_KEY_PASSWORD if not set.
> >
> > what shall i do ? is there any chance that this will be fixed in a maybe
> > new release ? shall i copy and paste this class to my own sources and
> > fix it there. shall i prepare a PATCH and to whom i suppose to send this
> > ? are there maybe plans to remove the SecurityTool in future releases,
> > since right now it is not really usable ?
> >
> > would be nice if someone answers one or the other question.
>
> Hi Kristian. I've applied the patch you sent a while back for
> SecurityTool. If you come across more problems, please file an issue
> at <http://nagoya.apache.org/bugzilla/>.
>
> For future reference, it's best to send patches in unidiff format
> <http://jakarta.apache.org/site/source.html>. The larger (and more
> concise) the description, and the smaller the size of the patch, the
> more likely that someone will look at it sooner (as opposed to later,
> like this one, where the description and patch was split up over 3
> messages, one of which I forwarded to the list).
>
> Dan
Re: xml-rpc over ssl
Posted by Daniel Rall <dl...@finemaltcoding.com>.
kristian meier <kr...@jentro.com> writes:
> i am quiet new to opensource, etc and i have some small questions.
>
> we are going to use the webserver in our new release. for this we need
> SSL. there is a quite convinient tool for setting up the neccassary
> ssl-system-properties, the SecurityTools. but unfortunatly there is no
> setter-method for the TrustStorePassword and the getter uses the
> DEFAULT_KEY_PASSWORD if not set.
>
> what shall i do ? is there any chance that this will be fixed in a maybe
> new release ? shall i copy and paste this class to my own sources and
> fix it there. shall i prepare a PATCH and to whom i suppose to send this
> ? are there maybe plans to remove the SecurityTool in future releases,
> since right now it is not really usable ?
>
> would be nice if someone answers one or the other question.
Hi Kristian. I've applied the patch you sent a while back for
SecurityTool. If you come across more problems, please file an issue
at <http://nagoya.apache.org/bugzilla/>.
For future reference, it's best to send patches in unidiff format
<http://jakarta.apache.org/site/source.html>. The larger (and more
concise) the description, and the smaller the size of the patch, the
more likely that someone will look at it sooner (as opposed to later,
like this one, where the description and patch was split up over 3
messages, one of which I forwarded to the list).
Dan
Re: xml-rpc over ssl
Posted by Jason van Zyl <jv...@zenplex.com>.
On Mon, 2002-02-25 at 10:45, kristian meier wrote:
> Hello,
>
> i am quiet new to opensource, etc and i have some small questions.
>
> we are going to use the webserver in our new release. for this we need
> SSL. there is a quite convinient tool for setting up the neccassary
> ssl-system-properties, the SecurityTools. but unfortunatly there is no
> setter-method for the TrustStorePassword and the getter uses the
> DEFAULT_KEY_PASSWORD if not set.
>
> what shall i do ?
You can send a patch.
> is there any chance that this will be fixed in a maybe
> new release ? shall i copy and paste this class to my own sources and
> fix it there. shall i prepare a PATCH and to whom i suppose to send this
> ? are there maybe plans to remove the SecurityTool in future releases,
> since right now it is not really usable ?
It's very usable, it's been in use in the project I work on for 6 months
and the secure xmlrpc transfers work just fine.
> would be nice if someone answers one or the other question.
>
> Kristian
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
Re: xml-rpc over ssl
Posted by Daniel Rall <dl...@finemaltcoding.com>.
kristian meier <kr...@jentro.com> writes:
> i am quiet new to opensource, etc and i have some small questions.
>
> we are going to use the webserver in our new release. for this we need
> SSL. there is a quite convinient tool for setting up the neccassary
> ssl-system-properties, the SecurityTools. but unfortunatly there is no
> setter-method for the TrustStorePassword and the getter uses the
> DEFAULT_KEY_PASSWORD if not set.
>
> what shall i do ? is there any chance that this will be fixed in a maybe
> new release ? shall i copy and paste this class to my own sources and
> fix it there. shall i prepare a PATCH and to whom i suppose to send this
> ? are there maybe plans to remove the SecurityTool in future releases,
> since right now it is not really usable ?
>
> would be nice if someone answers one or the other question.
Hi Kristian. I've applied the patch you sent a while back for
SecurityTool. If you come across more problems, please file an issue
at <http://nagoya.apache.org/bugzilla/>.
For future reference, it's best to send patches in unidiff format
<http://jakarta.apache.org/site/source.html>. The larger (and more
concise) the description, and the smaller the size of the patch, the
more likely that someone will look at it sooner (as opposed to later,
like this one, where the description and patch was split up over 3
messages, one of which I forwarded to the list).
Dan