I assume this is a bug in the wsproxy generator, as I've told the wsproxy generator to use a wsproxy-method of POST - which it does, but then proceeds to use parameters instead of body content.
U> The WSProxyGenerator uses a HTTPClient that is capable of posting XML as
U> the entire post body. However, it doesn't (AFAIK) pass this U> functionality on to the Cocoon user. If you are able to make it do so, I
U> think it would be a useful, and potentially quite simple, patch. Are you
U> willing/able to have a go?
I'm afraid not at the moment. My java knowledge is sketchy at best and I'm very swamped with billable work.
Thanks for clarifying wsproxy generator's behaviour.
Hello,
I missed this thread due to email issues, but I'd like to jump in here a second if I may:
When you say "parameters" do you mean URL parameters,
e.g.: index.html?a=foo&b=bar
as opposed to putting the request parameters in the body of the POST?
Be aware the WebServiceProxyGenerator may eventually be deprecated, and there are other generators in the "proxy" block.
Parameter handling in the WSProxy has always been a little goofy, because of the need to combine parameters which were POSTed along with parameters defined on the src attribute of the generator, such as:
<map:generate type="wsproxy" src="http://example.com/servlet/Whatever?foo=bar"/>
The foo=bar key/value pair needs to be merged with any parameters that were sent to the proxy as POST or GET originally.
The WSProxy defaults to GET. If you need a POST, use it like this:
<map:generate type="wsproxy" src="http://foo";> <map:parameter name="wsproxy-method" value="post"/> </map:generate>
The value=POST can be any case, so post or PoSt or POST works. You can also explicitly set it to GET, which doesn't do much except for be a little more verbose in the sitemap.
Any more questions, just ask.
Regards,
Tony
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
