For the sake of completeness for anyone else that may encounter this problem, I've found that for gSOAP, you can specify SOAP 1.1 when generating the WSDL with "soapcpp -1". The (-1) argument also prevents the import statement from being added to the WSDL.
--- In [email protected], "wubac1" <wub...@...> wrote: > > Thanks, Pete. > > If I remove the import will that import other client types (C++, Java, etc) > negatively? > > --- In [email protected], Peter Farland <pfarland@> wrote: > > > > There you go - the schema definition for SOAP 1.1 is implied for our > > processing of WSDL, so you could remove that import. > > > > Pete > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of wubac1 > > Sent: Friday, March 20, 2009 1:57 PM > > To: [email protected] > > Subject: [flexcoders] Re: Flex app fails when moved to server hosting web > > services > > > > There is an import: > > > > <import namespace="http://schemas.xmlsoap.org/soap/encoding/"; > > schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/> > > > > > > --- In [email protected], Peter Farland <pfarland@> wrote: > > > > > > Hmm, if it's not the SOAP address location, then perhaps there is a WSDL > > > or Schema import or include? Can you look around in the <types> section? > > > > > > Pete > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > > > Behalf Of wubac1 > > > Sent: Friday, March 20, 2009 1:23 PM > > > To: [email protected] > > > Subject: [flexcoders] Re: Flex app fails when moved to server hosting web > > > services > > > > > > Also, I removed the call to the operation completely and see that the > > > failed request for the crossdomain.xml from xmlsoap.org is generated by > > > the loading of the WSDL: > > > > > > ws = new WebService(); > > > ws.loadWSDL(mywsdlloc); <-- the GET is successful, but it subsequently > > > requests http://schemas.xmlsoap.org/crossdomain.xml, which produces a 404 > > > > > > --- In [email protected], Peter Farland <pfarland@> wrote: > > > > > > > > I'd take a look at the <soap:address location="..." /> in the WSDL for > > > > your service and port (typically towards the bottom of the WSDL) and > > > > note the host that is being contacted. What location is mentioned here? > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]] On > > > > Behalf Of wubac1 > > > > Sent: Friday, March 20, 2009 2:29 AM > > > > To: [email protected] > > > > Subject: [flexcoders] Flex app fails when moved to server hosting web > > > > services > > > > > > > > I have a Flex application that runs fine from my desktop. When I move > > > > the files to a virtual machine that already hosts the web services for > > > > the app, it no longer works as expected. Now, when the app creates a > > > > WebService and calls an operation, I see that the WSDL if located and > > > > downloaded, but the operation never executes. Via Charles, I see a > > > > "404 Not Found" for URL http://schemas.xmlsoap.org/crossdomain.xml. > > > > While I do not call any services at xmlsoap.org, it is part of the > > > > namespaces in my web services. Any suggestions as to correcting this > > > > problem on the VM? > > > > > > > > > > > > > > > > > > > ------------------------------------ > > > > > > -- > > > Flexcoders Mailing List > > > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > > Alternative FAQ location: > > > https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 > > > Search Archives: > > > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups > > > Links > > > > > > > > > > > > > ------------------------------------ > > > > -- > > Flexcoders Mailing List > > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > Alternative FAQ location: > > https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 > > Search Archives: > > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links > > >
