Great! That clears it up. Unfortunately I can't get a clean compile out of the
latest CVS checkout. Inbetween the warnings about enum and deprecation warnings
(yes, yikes, JDK1.5). I get the following errors. Any advice on how to get just
WSDL2Java compiled?
[javac] /home/andym/ws-axis/java/src/org/apache/axis/message/Text.java:30:
org.apache.axis.message.Text is not abstract and does not override abstract
method getUserData(java.lang.String) in org.w3c.dom.Node
[javac] public class Text extends NodeImpl implements javax.xml.soap.Text {
[javac] ^
[javac]
/home/andym/ws-axis/java/src/org/apache/axis/message/CDATAImpl.java:24:
org.apache.axis.message.CDATAImpl is not abstract and does not override
abstract method replaceWholeText(java.lang.String) in org.w3c.dom.Text
[javac] public class CDATAImpl extends org.apache.axis.message.Text
[javac] ^
[javac]
/home/andym/ws-axis/java/src/org/apache/axis/message/CommentImpl.java:31:
org.apache.axis.message.CommentImpl is not abstract and does not override
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
[javac] public class CommentImpl
[javac] ^
[javac]
/home/andym/ws-axis/java/src/org/apache/axis/message/SOAPFaultElement.java:26:
org.apache.axis.message.SOAPFaultElement is not abstract and does not override
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
[javac] public class SOAPFaultElement extends MessageElement implements
javax.xml.soap.SOAPFaultElement {
[javac] ^
[javac]
/home/andym/ws-axis/java/src/org/apache/axis/message/Detail.java:29:
org.apache.axis.message.Detail is not abstract and does not override abstract
method getUserData(java.lang.String) in org.w3c.dom.Node
[javac] public class Detail extends SOAPFaultElement implements
javax.xml.soap.Detail {
[javac] ^
[javac]
/home/andym/ws-axis/java/src/org/apache/axis/message/DetailEntry.java:24:
org.apache.axis.message.DetailEntry is not abstract and does not override
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
[javac] public class DetailEntry extends MessageElement implements
javax.xml.soap.DetailEntry {
[javac] ^
[javac]
/home/andym/ws-axis/java/src/org/apache/axis/message/SOAPDocumentImpl.java:56:
org.apache.axis.message.SOAPDocumentImpl is not abstract and does not override
abstract method renameNode(org.w3c.dom.Node,java.lang.String,java.lang.String)
in org.w3c.dom.Document
[javac] public class SOAPDocumentImpl
[javac] ^
[javac]
/home/andym/ws-axis/java/src/org/apache/axis/message/SOAPFault.java:46:
org.apache.axis.message.SOAPFault is not abstract and does not override
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
[javac] public class SOAPFault extends SOAPBodyElement implements
javax.xml.soap.SOAPFault
[javac] ^
>>> [EMAIL PROTECTED] 12/02/04 05:24PM >>>
Should be fixed in latest CVS.
-- dims
On Thu, 2 Dec 2004 16:11:13 -0800, Simon Fell <[EMAIL PROTECTED]> wrote:
> Yes, .NET doesn't support the soap encoding types. This seems to be a
> "feature" of axis 1.2, there was talk on the axis-dev list of changing
> this back to match axis 1.1, but I don't know what the current status of
> that is.
>
> Cheers
> Simon
>
>
>
> > -----Original Message-----
> > From: ANDREW MICONE [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, December 02, 2004 4:06 PM
> > To: [EMAIL PROTECTED]
> > Subject: PS -- oops WSDL2Java
> >
> > Sorry, misleading header, I was talking about WSDL2Java.
> > Also, I noticed that the other server returns type as
> > "xsd:string[8]" and Axis returns it as "soapenc:string[8]".
> > Is that related? Please help. -- Andy
> >
> > >>> [EMAIL PROTECTED] 12/02/04 03:23PM >>>
> > I'm using WSDL2Java to create a service consumed by a .NET
> > client I can't change for a WSDL we're mandated to use. It
> > has a service called "GetService" defined as follows in the
> > WSDL (details omitted):
> >
> > <complexType name="ArrayOfstring">
> > <complexContent>
> > <restriction base="SOAP-ENC:Array">
> > <attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="string[]"/>
> > </restriction>
> > </complexContent>
> > </complexType>
> > <message name="GetServicesResponse">
> > <part name="return" type="typens:ArrayOfstring"/>
> > </message> <operation name="GetServices"
> > parameterOrder="securityToken serviceType">
> > <documentation>Query services offered by the node</documentation>
> > <input message="tns:GetServices"/>
> > <output message="tns:GetServicesResponse"/>
> > </operation>
> >
> > I'm just using the binding implementation stub to craft a
> > response. The response from the Axis client is as follows:
> >
> > <soapenv:Envelope>
> > <soapenv:Body>
> > <getServicesResponse
> > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
> > <return soapenc:arrayType="soapenc:string[9]"
> > xsi:type="soapenc:Array"> <item
> > xsi:type="soapenc:string">PNWWQX.GetProjects</item>
> > ...
> >
> > Which the .NET client says is an illegal response. ("There is
> > an error in the XML document (1,384)"). A response from
> > another server which it likes is:
> >
> > <soapenv:Envelope>
> > <soapenv:Body>
> > <ns1:GetServicesResponse
> > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
> > <return xsi:type="soapenc:Array" soapenc:arrayType="xsd:string[8]">
> > <item>GetFacilityByName</item>
> >
> > There are only three differences between the messages, which
> > I rank in decreasing likelihood they are causing the problem:
> >
> > 1) That the GetServicesResponse operation defined in the WSDL
> > is sent back as getServicesResponse with an initial lower-case letter.
> >
> > 2) That the response in the second is in a user namespace.
> >
> > 3) The additional type information provided in the first response.
> >
> > I'm thinking the most likely reason is the initial lower-case
> > letter. How can I fix this so the response in the first
> > message looks like the second message using WSDL2Java (i.e.
> > without writing my own customized deserializer for the array). -- Andy
> >
> >
> >
> >
> >
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
