axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 18685] - Extension of Exception class generates bad client file
Date Fri, 11 Apr 2003 03:06:23 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18685>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18685

Extension of Exception class generates bad client file





------- Additional Comments From odysseas@sysnetint.com  2003-04-11 03:06 -------
I looked through the original version of your WSDL document again and noticed a 
couple of issues. The first one is that it defines multiple times the 
MiddlewareException message in the messages section of the WSDL document and 
that is probably why your version of WSDL2Java was generating multiple 
instances of the MiddlewareException field and getter method in the generated 
exception class. That has now been fixed in the current version of Axis in CVS. 
The second problem is related to the fault definitions within the binding 
section. Rather than to use the <fault><soap:fault> extensibility elements it

makes use of the <soap:body> elements that are appropriate for the input and 
output elements but not for the fault. After reviewing the WSDL 1.1 
specification it seems that this is not the correct definition of faults within 
the SOAP binding section but since you say that this was generated by WebLogic 
7.0 and worked fine for generating stubs using gSOAP then that implies that 
their WSDL processing tools are more leniant and flexible. I was thinking that 
for better interoperability we could modify the code to allow Axis to handle
these cases but it will take some guess work in some cases to resolve the 
faults. They are probably figuring out the fault messages by looking at the 
operation element within the portType section and mapping the messages into 
Java classes that way. That would work just fine for us as well. The issue is a 
bit more complicated if your method generates multiple exceptions. In that case 
you need the name attribute within the binding fault element to identify the 
appropriate fault element within the portType section so ordering would
be the only approach available for identifying the corresponding message for 
each fault that occurs within the binding section. You may want to try using 
the Java2WSDL tool from Axis to generate a WSDL document for your interface and 
then compare the output with what Weblogic has generated.

Mime
View raw message