Hi again, > > Worked great! Thanks! > > Yes, but I've re-opened the bug, because it really isn't re-encoding the > request parameters correctly. The WSProxy, along with the newer > HttpProxy, get request parameters from two different sources. > > The first is from the "src" attribute, like so: > > <map:generate > type="wsproxy" > src="http://foo.bar/endpoint?parm1=val1&parm2=val2"/> > > The second is from any parameters that were passed to the matching > pipeline. All of the parameters are gathered together and then shipped > off to the remote server in one go. Check out the fetch() method of the > WebServiceProxyGenerator.
Early on I noticed trouble here when testing and manually changed all the & characters to & in my src string. The example you show didn't do that--does it work for you as written above? Just checked--I get the error: The reference to entity "dev-t" must end with the ';' delimiter. So it would seem that manual encoding is necessary in the src attribute? I even get the error while editing my sitemap in Eclipse with the SunBow plug-in, so this is enforced by the schema, it seems... > The problem is that the parameters in the first example, which are > included in the src attribute, are not being correctly encoded. I have > yet to fix this, but I'll work on it. The WSProxy will probably > eventually go away in favor of the HttpProxyGenerator, soon anyway. Can you explain the latter a little more? I don't really know the relative merits of the two... <snip> > > Interesting. What happens if I don't want to pass my parameters along? > > The other problem that I found is when you want to "rename" the request > parameters which are then passed to the wsproxy. (When you don't want to > pass all the parameters along or you wish to rename them). > > In this case, you would have something like this: > > <map:match pattern="formSubmit"> > <map:generate type="file" > src="http://foo.com/service?parm1=val1&parm2={request-param:fo > oParam}"/> > <map:serialize type="xml"/> > </map:match> > > I noticed there was a "RawRequestParameterModule" which provides the > "undecoded" request parameter. Your specific problem I believe was that > the use of {request-param:actor} was causing the parameter to be decoded > with the space (to "johnny depp"), and then you were directly sending > that string with the space to the remote service, which is incorrect. > The correct use would be {raw-request-param:actor}. That makes sense, though I'm not sure I've seen it work correctly yet. When I submit my form it encodes my parameters with a +: http://localhost:8888/Amazon/doRestSearch.html?actor=johnny+depp and I get 0 results. I observed early on that my request only worked when the URL was written out with a %20 in place of the +. So I'm wondering if raw-request-param converts it appropriately. > Note that you don't actually need the WSProxy in your case, since it's > all XML over HTTP (the FileGenerator can handle that just fine), and you > don't neccesarily want to pass all of your form variables directly > through to Amazon. That makes sense now that I see my parameters are passed transparently. I have yet to see type="file" work correctly. Changing wsproxy to file I've got: <map:generate type="file" src="http://xml.amazon.com/onca/xml3?t=webservices-20&dev-t=[dev-token]&; amp;{raw-request-param:actor}&mode=dvd&type=lite&page=1&f=xm l" /> I get 0 results. Changing the wsproxy to file in your working example also produces 0 results. Is there something else that has to change besides the type when using the FileGenerator? So, in summary, passing the parameter transparently through (as in your first example) worked great. I have not yet used request-param or raw-request-param with any success. > Yep, it's taken me a while to get back into digging through everything > again. I suppose for now, use the FileGenerator, along with the > raw-request-param InputModule. I ran into problems getting the WSProxy > to encode stuff, even stuff coming out of the raw-request-module. I > suspect this bug also occurs inside the HttpProxy, so I will have a look > at both. Part of my problems are from my inexperience with > commons-httpclient, which both the WSProxy and the HttpProxy use. I'd like to follow your suggestion, if I could get it to work! I'll start checking the logs for errors if you don't see an obvious syntactical problem above. > Tony Jeff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
