Solved it. It is some screwed up problem with the encoding that AXIS does. For whatever reason the encoding method is changed from XSD to SOAPENC after calling an external web service. Upgrading to 7.0.2 resolves this, presumably due to an updated AXIS driver.
Russ -----Original Message----- From: Snake [mailto:[EMAIL PROTECTED] Sent: 20 December 2006 23:31 To: CF-Talk Subject: RE: Web services being called by non cf source Dave, OK I missed the fact that it did an initial GET, this wasn't showing in my packet sniffer, but I can now see it. The endpoint does resolve successfully, you can browse the cfc?wsdl via the browser. I have now noticed the following. The first time round, the response to the GET has the following data types in the response. <wsdl:message name="getLoginRequest"> <wsdl:part name="GUID" type="xsd:string"/> <wsdl:part name="UserName" type="xsd:string"/> <wsdl:part name="Password" type="xsd:string"/> </wsdl:message> After we run our VRN page that contacts the other remote web service, the toolbar then starts doing GETS again (not sure why), but stops posting. But I noticed that CF has now changed the data types it sends back in the response, which I presume is the problem. <wsdl:message name="getLoginRequest"> <wsdl:part name="GUID" type="soapenc:string"/> <wsdl:part name="UserName" type="soapenc:string"/> <wsdl:part name="Password" type="soapenc:string"/> </wsdl:message> Does this shed any light on the situation. Russ -----Original Message----- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: 20 December 2006 19:41 To: CF-Talk Subject: RE: Web services being called by non cf source > Having been monitoring the http traffic more, I have noticed this. > > The toolbar normally does a POST to mycfc.cfc As soon as we run the > CFM file that calls the other web service, the toolbar then > mysteriously starts doing a GET to mycfc.cfc?wsdl, thus why it is > failing. > > I have no idea how this could happen. There is no prior communication > to this happening, no data sent back that could force the toolbar to > use GET instead of POST, i.e. no redirection header or anything. I'm a bit confused. Normally, if you publish a SOAP web service, the URL given to the client is that of the WSDL file, so your toolbar appears to be doing the right thing. The client GETs the WSDL, and learns the details of your service from it. It can't POST to the actual service endpoint without this information. So, these questions come to mind: Why were you expecting something different? Is the client able to retrieve the WSDL successfully? Can you resolve the endpoint URL successfully from one of the clients in question? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Create robust enterprise, web RIAs. Upgrade & integrate Adobe Coldfusion MX7 with Flex 2 http://ad.doubleclick.net/clk;56760587;14748456;a?http://www.adobe.com/products/coldfusion/flex2/?sdid=LVNU Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:264676 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
