Hi guys, thanks for the responses. I have a lot of leeway in defining the content of the XML that is returned, so changing the WSDL is not a problem, neither is embedding in a CDATA tag. Basically this solution does not have to be general.
But, I haven't been able to make either option work. When I naively change the type of the response to xsd:any in the WSDL, then WSDL2Ws fails with the error message:
at java.lang.Thread.run(Thread.java:595)
org.apache.axis.wsdl.wsdl2ws.WrapperFault: java.io.IOException: Type {http://www
.w3.org/2001/XMLSchema}any is referenced but not defined.
at org.apache.axis.wsdl.wsdl2ws.WSDL2Ws.<init>(WSDL2Ws.java:112)
at org.apache.axis.wsdl.wsdl2ws.WSDL2Ws.main(WSDL2Ws.java:1138)
Caused by: java.io.IOException: Type {http://www.w3.org/2001/XMLSchema}any is re
ferenced but not defined.
Do I have to put the xsd:any into a complex type first? As in:
<element name="getRecipientResponse">
<complexType>
<sequence>
<xsd:any xmlns:xsd="http://www.w3.org/2001/XMLSchema"/>
</sequence>
</complexType>
</element>
and then use that element when I define the message?
The broken WSDL looks like this (change xsd:any to xsd:string and WSDL2Ws is happy).
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://localhost:8080/axis/UserNameLookupService.jws" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://localhost:8080/axis/UserNameLookupService.jws" xmlns:intf="http://localhost:8080/axis/UserNameLookupService.jws" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:message name="getRecipientRequest">
<wsdl:part name="emailId" type="xsd:string"/>
</wsdl:message>
<wsdl:message name="getRecipientResponse">
<wsdl:part name="getRecipientReturn" type="xsd:any"/>
</wsdl:message>
<wsdl:portType name="UserNameLookupService">
<wsdl:operation name="getRecipient" parameterOrder="emailId">
<wsdl:input message="impl:getRecipientRequest" name="getRecipientRequest"/>
<wsdl:output message="impl:getRecipientResponse" name="getRecipientResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="UserNameLookupServiceSoapBinding" type="impl:UserNameLookupService">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getRecipient">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getRecipientRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="getRecipientResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:8080/axis/UserNameLookupService.jws" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="UserNameLookupServiceService">
<wsdl:port binding="impl:UserNameLookupServiceSoapBinding" name="UserNameLookupService">
<wsdlsoap:address location="http://localhost:8080/axis/UserNameLookupService.jws"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Bruce.
-----Original Message-----
From: John Bodfish [mailto:[EMAIL PROTECTED]]
Sent: February 8, 2005 8:58 PM
To: 'Apache AXIS C User List'
Subject: RE: returning XML as xsd:string
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
>
