The bad news is that I was wrong about having a fix for the Axis code to correct your problem. I was mis-interpreting my debug, and there is n bug in WSDLReader or any of the Axis code that is causing this problem.
The good news is that I discovered the real problem in the wsdl you're trying to use. It is definitely non-compliant, both with the W3C note for WSDL 1.1 and the MIME standard (RFC 1521, find it here: http://www.faqs.org/rfcs/rfc1521.html)
There was a subtle problem staring me in the face, and I can't believe I was missing it. Forget what I've said in my previous messages. Here's the story.
There are two problems with the wsdl:
1. Some of the <input...> and <output...> elements in the bindings section have both a name and a message attribute. It is legal to have these attributes in the <input..> and <output...> elements, but they are used improperly in this wsdl. The name atttribute in an <input...> or <output...> element is supposed to refer to an <input...> or <output...> element that is assigned that very name somewhere in the wsdl file. This is not the case. Some of the <input...> and <output...> elements have name attributes that appear in no <input...> or <output...> element anywhere in the wsdl file. This is non-compliant, and it is the source of the Exception you've been getting. Furthermore, this non-compliant usage only appears in messages with <mime...> elements in them, which explains why the problem appeared to be connected to MIME usage.
Example:
Here is an excerpt from the wsdl you're trying to use, where a message is defined that is used in the "Send" operation.
<message name="Send1Request"> <part name="Account" type="xs:string"/> <part name="Password" type="xs:string"/> <part name="JobArt" type="xs:int"/> <part name="EmpfaengerNr" type="xs:string"/> <part name="EmpfaengerListe" type="xs:base64Binary"/> <part name="SendText" type="xs:string"/> <part name="SendFile1" type="xs:base64Binary"/> <part name="SendFile2" type="xs:base64Binary"/> <part name="SendFile3" type="xs:base64Binary"/> <part name="SendeDatumZeit" type="xs:dateTime"/> <part name="Schalter" type="xs:string"/> </message>
Here's how the "Send" <operation...> element in the portTypes section references this message:
<operation name="Send">
<input message="tns:Send1Request"/>
<output message="tns:Send1Response"/>
</operation>No problem so far. But now see how the "Send" <operation...> element in the bindings section references this message. Look at the element I have marked with ********.
<operation name="Send">
<soap:operation soapAction="urn:XMLWSIntf-IXMLWS#Send" style="rpc"/>
<input message="tns:Send1Request" name="Send1Request"> *******
<mime:multipartRelated>
<mime:part>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; namespace="urn:XMLWSIntf-IXMLWS"/>
</mime:part>
<mime:part>
<mime:content part="EmpfaengerListe" type="application/binary"/>
</mime:part>
<mime:part>
<mime:content part="SendFile1" type="application/binary"/>
</mime:part>
<mime:part>
<mime:content part="SendFile2" type="application/binary"/>
</mime:part>
<mime:part>
<mime:content part="SendFile3" type="application/binary"/>
</mime:part>
</mime:multipartRelated>
</input>
The value of the message attribute is fine, but the name attribute is defining a name for the <input...> element in the bindings section that doesn't match any <input...> element in the portTypes section, since the latter have no name attribute defined. Another way to think of it is that the name attribute in the <input...> element above is referencing a non-existent element. It is attempting to associate the bindings <input...> element with an <input...> element in the portTypes ection with the same value for its name attribute. There is no such element. There is an <input...> element in the portType <operation...> element with a MESSAGE attribute (not a NAME attribute) equal to Send1Request. And there is a <MESSAGE...> element (not an <INPUT...> element) in the Types section with a name attribute set to Send1Request. A very subtle difference for us humans, but computers find it rather obvious. The end result is a mismatch between the operations in the bindings section and the portTypes section of the wsdl.
The simplest fix is simply to remove the name attribute and its definition, and leave the message attribute intact, in the element marked with ****** above. You will also need to to do this for all other <input...> and <output...> elements in the bindings section that have a name attribute, which occurs only where <mime...> elements are included in a <message...> element. The wsdl from the Interop testing that we discussed earlier took a different approcah. It defined a name attribute for the <input...> and <output...> elements in the portType section, and then used these names as values for the name attributes of the <input...> and <output...> elements in the bindings section. Either approach works.
2. My earlier comment about an additional Exception (null pointer) being caused by an improper value for the type attribute of the <mime:content...> elements is still valid. These values are specified as "application/binary." This is not governed by the wsdl spec, but by the MIME spec, whcih defines the only valid sub-types for the application type as "octet-stream", "postscript", or an extension-token that begins with "x-." Any other application sub-types must be registered with IANA. Changing the sub-type to "octetstream" resolved the NullPointerException probelm. (I used "octetstream" vice "octet-stream" because that's the way it was in the Interop wsdl. I assume "octet-stream" will work as well.
Here's the modified wsdl that incorporates the above fixes, and runs successfully with Axis 1.1. I think you now have sufficient warrant to request the wsdl be changed, and there is clearly no change to the service behavior associated with this change.
</operation>
<operation name="Send">
<soap:operation soapAction="urn:XMLWSIntf-IXMLWS#Send" style="rpc"/>
<input message="tns:Send1Request" name="Send1Request">
<mime:multipartRelated>
<mime:part>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; namespace="urn:XMLWSIntf-IXMLWS"/>
</mime:part>
<mime:part>
<mime:content part="EmpfaengerListe" type="application/binary"/>
</mime:part>
<mime:part>
<mime:content part="SendFile1" type="application/binary"/>
</mime:part>
<mime:part>
<mime:content part="SendFile2" type="application/binary"/>
</mime:part>
<mime:part>
<mime:content part="SendFile3" type="application/binary"/>
</mime:part>
</mime:multipartRelated>
</input>
From: "Steffen Heil" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> Subject: RE: Beginners help Date: Thu, 15 Apr 2004 20:05:30 +0200
Mark,
Once again, thank you so much. I am far from understanding, what's going on behind the scenes.
> If you want me to send you the modified wsdl that worked for me, let me know.
It would be very grateful, if you could send it to me.
As I am usure, can you tell me, wether these changes will only change the representation of the wsdl or will they change the meaning the the wsdl file? Exspecially, should the modified file work with the existing service?
Regards, Steffen
_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee� Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
