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 22724] New: - Faults with identically named parts are not always properly deserialized
Date Tue, 26 Aug 2003 08:22:40 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=22724>.
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=22724

Faults with identically named parts are not always properly deserialized

           Summary: Faults with identically named parts are not always
                    properly deserialized
           Product: Axis
           Version: 1.1
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Serialization/Deserialization
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: Andrei.Iltchenko@nl.compuware.com


The above problem is caused by the way QNames for FaultInfo and FaultDescr 
objects are formed. The following pieces of code taken from AXIS 1.1 final 
clarify the issue.


SymbolTable.faultsFromSOAPFault:
		...
		...
            String soapFaultNamespace = "";
            
            Iterator faultIter = bFault.getExtensibilityElements().iterator();
            for (; faultIter.hasNext();) {
                Object obj = faultIter.next();
                if (obj instanceof SOAPFault) {
                    foundSOAPFault = true;
                    soapFaultUse = ((SOAPFault)obj).getUse();
                    soapFaultNamespace = ((SOAPFault)obj).getNamespaceURI(); // 
<-- namespaceURI
                    break;
                } else if (obj instanceof UnknownExtensibilityElement) {
			...
			...                
                }
            }
            ...
            ...
            Fault opFault = operation.getFault(bFault.getName());
            if (opFault == null) {
                ...
            }
            // put the updated entry back in the map
            faults.add(new FaultInfo(opFault,
                    Use.getUse(soapFaultUse),
                    soapFaultNamespace,
                    this));


FaultInfo:
    ...
    public FaultInfo(Fault fault, Use use, String namespace,
            SymbolTable symbolTable) {
        ...
        ...
        Part part = getFaultPart();
        if (part == null) {
            this.qName = null;
        }
        else if (part.getTypeName() != null) {
            this.qName = new QName(namespace, part.getName()); // <-- localName
        }
        ...
    } // ctor
    ...
    ...
    public QName getQName() {
        return qName;
    } // getQName


JavaStubWriter.writeFaultInfo:
        ...
        Map faultMap = bEntry.getFaults();
        // Get the list of faults for this operation
        ArrayList faults = (ArrayList) faultMap.get(bindOp);

        // check for no faults
        ...
        // For each fault, register its information
        for (Iterator faultIt = faults.iterator(); faultIt.hasNext();) {
            FaultInfo info = (FaultInfo) faultIt.next();
            QName qname = info.getQName();
            Message message = info.getMessage();

            // if no parts in fault, skip it!
            ...

            // Get the Exception class name
            String className = Utils.getFullExceptionName(message, symbolTable);

            // output the registration API call
            pw.println("        oper.addFault(new 
org.apache.axis.description.FaultDesc(");
            pw.println("                      " + Utils.getNewQName(qname) 
+ ",");  // <-- the QName value is taken from the corresponding FaultInfo object
            pw.println("                      \"" + className + "\",");
            pw.println("                      " + Utils.getNewQName
(info.getXMLType()) + ", ");
            pw.println("                      " + Utils.isFaultComplex(message, 
symbolTable));
            pw.println("                     ));");
        }


FaultDesc:
    ...
    ...
    public FaultDesc(QName qname, String className,
                     QName xmlType, boolean complex) {
        this.qname = qname;
        this.className = className;
        this.xmlType = xmlType;
        this.complex = complex;
    }

    public QName getQName() {
        return qname;
    }
    ...
    ...


As a result, the QName of a FaultInfo as well as the QName of the corrsponding 
FaultDescr object is a combination of the name of the fault's message part and 
the value of the fault's namespace attribute, e.g. the QName of a FaultInfo 
object generated for the following soap fault element would 
be '{urn:AddressFetcher2}ex'.

  <wsdl:message name="Exception">
    <wsdl:part name="ex" type="typens:addressException"/>
  </wsdl:message>

  <wsdl:binding name="name" type="typens:AddressBook">
    ...
    <wsdl:operation name="addEntry">
      ...
      <wsdl:fault name="fa">
        <soap:fault name="SoapFault" use="encoded" 
namespace="urn:AddressFetcher2"/>
      </wsdl:fault>
    </wsdl:operation>
  </wsdl:binding>


This poses problems when deserializing faults with code generated by WSDL2Java 
for documents similar to the one below:

  <wsdl:message name="Exception">
    <wsdl:part name="ex" type="typens:addressException"/>
  </wsdl:message>
  <wsdl:message name="Exception1">
    <wsdl:part name="ex" type="typens1:addressException1"/>
  </wsdl:message>


  <wsdl:binding name="name" type="typens:AddressBook">
    ...
    <wsdl:operation name="addEntry">
	...
      <wsdl:fault name="fa">
        <soap:fault name="SoapFault" use="encoded" 
namespace="urn:AddressFetcher2"/>
      </wsdl:fault>
      <wsdl:fault name="fa1">
        <soap:fault name="SoapFault1" use="encoded" 
namespace="urn:AddressFetcher2"/>
      </wsdl:fault>
    </wsdl:operation>
  </wsdl:binding>

Here we will eventually have two FaultDescr objects whose QName's are 
identical, and the following piece of code 
from 'SOAPFaultDetailsBuilder.onStartChild' will always find the first 
FaultDescr object registered for the operation called:

        MessageContext msgContext = context.getMessageContext();
        SOAPConstants soapConstants = msgContext.getSOAPConstants();
        OperationDesc op = msgContext.getOperation();
        Class faultClass = null;
        QName faultXmlType = null;
        if (op != null) {
            FaultDesc faultDesc = op.getFaultByQName(qn);  // <-- finds the 
first descr.
            // allow fault type to be denoted in xsi:type
            if (faultDesc == null) {
                ...
            } else {
                faultXmlType = faultDesc.getXmlType();    
            }
            if (faultDesc != null) {
                // Set the class
                try {
                    faultClass = ClassUtils.forName(faultDesc.getClassName());
                } catch (ClassNotFoundException e) {
                    // Just create an AxisFault, no custom exception
                }
            }
        } else {
            ...          
        }

As a result, on the client side, an exception object of 
type 'typens:addressException' will be constructed, even though an exception of 
type 'typens1:addressException1' might have been thrown on the server.

We tracked this behaviour down to the changes of dims as of 2003/01/19.


Thank you,
Andrei.

Mime
View raw message