Stephane: That will *almost* always work. As the article I cited states, "that only makes the problem less likely, rather than removing it. Suppose the content is a SAX library -- it's quite possible that the CDATA terminator string, "]]>", will show up."
While passing a **SAX library** is highly unlikely, what is more likely is the XML document being passed itself contains CDATA - this will fail unless you pre-process the inner CDATA (e.g. insert a space between the two "]" - and don't forget to handle occurrences of "] ]" in the original XML!). That brings us back to some form of converting the XML before sending it, and un-converting it on the receiving side. As noted in the article, BASE64 is the best-known general solution but it will increase the size of the document. However, what you propose will work if you KNOW that the inner XML can *not* contain CDATA. That's not a general solution, but then Bruce may not need a fully general solution. Isaac Newton didn't! BTW, another not-fully-general way is to modify the definition (in the WSDL) of the "getEnvelopeRecipientReturn" element changing it's type from xsd:string to xsd:any. This permits the inclusion of XML within the element. This still suffers from the problems mentioned in the cited article (no prolog, you have to expand entities within the inner XML, etc.) so it's not fully general. So perhaps we should ask Bruce: how general do you need this to be (e.g., are there any constraints on the contained XML?), and can you modify the WSDL to achieve your goal? John -----Original Message----- From: Stephane Antonietti [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 7:29 PM To: Apache AXIS C User List Subject: Re: returning XML as xsd:string Hi Guys I was playing with this stuff a couple of months ago. Did you try to embed you XML string in CDATA Tag. I works fine for me. Then you prevent your XML parser to deal with that string. Hope it'll help Regards -- Stephane Antonietti Sr Technical Consultant Experian-Scorex, Monaco ----------------------------------------------- Tel : +377 97 98 54 89 Fax: +377 97 98 54 54 Mob:+377 678 635 347 ----------------------------------------------- [EMAIL PROTECTED] www.experian-scorex.com John Bodfish wrote: > Bruce: > > > > Embedding an XML document in a SOAP message (which is an XML document > itself) is nearly impossible to do in with any guarantee that it will > work for any arbitrary document - unless you transform the XML document > into a character encoding that won't contain any characters that are > treated specially by the XML parser at the receiving end. > > > > See http://webservices.xml.com/pub/a/ws/2002/08/28/endpoints.html for > more details. The author's conclusion: "Unfortunately, while it can be > prohibitively expensive (in terms of message size and memory use), > Base64 strings have been the only approach that works and is portable." > Note that if you choose this approach your application (and those you > exchange message with) will have to convert the embedded XML document to > and from Base64. > > > > John > > > > ------------------------------------------------------------------------ > > *From:* Bruce McHaffie [mailto:[EMAIL PROTECTED] > *Sent:* Tuesday, February 08, 2005 4:36 PM > *To:* '[email protected]' > *Subject:* returning XML as xsd:string > > > > Hi, I have a Java web service that returns xsd:string data to the Axis > C++ client. I have noticed that if the returned string contains angle > brackets (<>) then the client fails (with a heap corruption message -- > I'm running in debug). The SOAP message is returned correctly, and the > start element is found. The error seems to happen when the client tries > to parse the message for the content of the string. > > > > Client fails at: getElementAsString( AxisChar* pName, AxisChar* pNamespace) > > File is: SoapDeSerializer.cpp > > Line number is: 3049 in Axis C++ 1.4, > > Call is: m_pNode = m_pParser->next (true); > > > > Sample SOAP message that fails: > > > > <soapenv:Envelope> > <soapenv:Body> > <getEnvelopeRecipientResponse > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> > <getEnvelopeRecipientReturn xsi:type="xsd:string"><Any string at > all></getEnvelopeRecipientReturn> > </getEnvelopeRecipientResponse> > </soapenv:Body> > </soapenv:Envelope> > > > > Sample SOAP message that works: > > > > <soapenv:Envelope> > <soapenv:Body> > <getEnvelopeRecipientResponse > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> > <getEnvelopeRecipientReturn xsi:type="xsd:string">Any string at > all</getEnvelopeRecipientReturn> > </getEnvelopeRecipientResponse> > </soapenv:Body> > </soapenv:Envelope> > > > > I tried escaping the angle brackets with < and > but that didn't > solve the problem. Any ideas? > > > > Thanks, > > > > Bruce. > > > **************************************************************************** *********************************************************** This e-mail and any attachments may be confidential and/or legally privileged. If you have received this e-mail and you are not a named addressee, please inform the Experian-Scorex IT Service Desk on +377 97 98 54 54 and then delete the e-mail from your system. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail. Although Experian-Scorex routinely screens for viruses, addressees should scan this e-mail and any attachments for viruses. Experian-Scorex makes no representation or warranty as to the absence of viruses in this E-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of its clients and business, Experian-Scorex may monitor and read e-mails sent to and from its servers **************************************************************************** **********************************************************
