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





------- Additional Comments From [EMAIL PROTECTED]  2003-08-26 14:05 -------
Tom,

I just did it and saw that the problem is now corrected. Now faults are first 
looked up based on their XSD type, which is how it should be IMHO.

SOAPFaultDetailsBuilder.onStartChild:
        ...
        ...
        // Look up this element in our faultMap
        // if we find a match, this element is the fault data
        MessageContext msgContext = context.getMessageContext();
        SOAPConstants soapConstants = msgContext.getSOAPConstants();
        OperationDesc op = msgContext.getOperation();
        Class faultClass = null;
        QName faultXmlType = null;
        if (op != null) {
            FaultDesc faultDesc = null;
            // allow fault type to be denoted in xsi:type
            faultXmlType = context.getTypeFromAttributes(namespace,
                                                         name,
                                                         attributes);
            if (faultXmlType != null) {
                faultDesc = op.getFaultByXmlType(faultXmlType);
            }

            // If we didn't get type information, look up QName of fault
            if (faultDesc == null) {
                faultDesc = op.getFaultByQName(qn);
                if (faultDesc != null) {
                    faultXmlType = faultDesc.getXmlType();
                }
            }

Thanks for the clarification,
Andrei.

Reply via email to