Please read and let me know if anyone has strong opinions either way.
======================================================
The 0.9 version of JSR 101 describes a significantly different
XML <-> Java mapping for faults.
There are two different mappings. One for message parts which
reference a simple type, and one for message parts which
reference a complex type.
Mapping for a Simple Type Message Part
--------------------------------------
This mapping is similar to the one currently performed in Axis
for all faults.
Given the following wsdl:
<message name="FaultSimple" >
<part name="info" type="xsd:string" /> <!-- type is a simple type-->
</message>
<portType name="myPortType">
<operation name="myOperation">
<input message="tns:myOperationInput"/>
<output message="tns:myOperationOutput"/>
<fault name="FaultSimple" message="tns:FaultSimple" />
</operation>
</portType>
A java fault class will be built with the name "FaultSimple"
that extends java.lang.Exception:
package com.example;
public class FaultSimple extends java.lang.Exception {
public FaultSimple(String info) {...}
public String getInfo() {...}
}
Mapping for a ComplexType Message Part
--------------------------------------
<complexType name="Base">
<sequence>
<element name="A" type="xsd:string" />
<element name="B" type="xsd:string" />
</sequence>
</complexType>
<complexType name="Derived">
<complexContent>
<extension base="tns:Base" />
<sequence>
<element name="C" type="xsd:string" />
<element name="D" type="xsd:string" />
</sequence>
</extension>
</complexContent>
</complexType>
<message name="FaultComplex" >
<part name="info" type="tns:Derived" /> <!-- type is a simple type-->
</message>
<portType name="myPortType">
<operation name="myOperation">
<input message="tns:myOperationInput"/>
<output message="tns:myOperationOutput"/>
<fault name="FaultComplex" message="tns:FaultComplex" />
</operation>
</portType>
You would think that the above should produce a java fault class
named FaultComplex, but v0.9 indicates that a java fault class
named Derived should be generated that extends Base.
package com.example;
public class Derived extends Base {
public Derived(String A, String B,
String C, String D) {super(A,B)...}
public String getB() {...}
public String getC() {...}
}
package com.example;
public class Base extends java.lang.Exception {
public Base(String A, String B) {...}
public String getA() {...}
public String getB() {...}
}
There are a number of reasons for this mapping:
1) It establishes an inheritance hierarchy of exceptions.
2) It allows multiple operations to share the hierarchy.
There are a number of generation implications of this mapping.
A) It assumes that the complexTypes can only be explicitly
referenced in a fault or non-fault context. If we support this
mapping, the WSDL2Java emitter will need to detect
collisions and (in my opinion) issue a message and quit.
B) Any complexType that extends a complexType used in a
fault context will need to be mapped as above (instead of
being mapped to a bean class).
C) Any complexType that is the base of a complexType used
in a fault context will need to be mapped as above (instead of
being mapped to a bean class).
D) Need to implement the Java2WSDL reverse mapping.
E) I'll assume that a complexType that is explicitly or implicitly
the restriction of a simpleType will be mapped using the
simple type mapping.
===================================================================
These changes will require additional fault and non-fault context
checking in the WSDL2Java symbol table. It will also require
new mappings for the fault classes (including full constructor
construction similar to what we used to do for beans).
I can start implementing these changes unless I get
strong disagreements.
Thanks!
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
