XFire
  1. XFire
  2. XFIRE-1056

faultactor element disappears when detail element is present in SOAP Fault

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2.6
    • Fix Version/s: 1.2.7
    • Component/s: None
    • Labels:
      None
    • Environment:
      Xfire 1.2.6, SOAP 1.1 (other environment factors are irrelevant. see description)
    • Number of attachments :
      1

      Description

      When the XFire client receives a SOAP Fault, it is parsed into an XFireFault (exception). However, if this SOAP Fault contains a "detail" element, the faultactor element is no longer parsed.

      I have debugged the parsers and found the exact cause and location of the error:
      When de details element is parsed, there is one call too many on r.next (r = XMLStreamReader) in StaxBuilder.java on line 446. This causes the pointer to be on the start element of the "faultactor" tag. After returning to the file Soap11FaultSerializer.java on line 68 and returning back to the loop, on line 40, there is another call to r.next (r = same XMLStreamReader instance as above).

      The result is that the element following the "details" element in the SOAP Fault (in my case that is "faultactor") is never parsed.

        Activity

        Hide
        Allard Buijze added a comment -

        This is the class file as I (quickly) modified it. This seems to work, but haven't been able to test it thoroughly.

        Modifications are on line 242: boolean firstEntry = true;
        line 245: int stackLevel = 0;
        line 297: stackLevel--;
        line 326: stackLevel++;
        line 467-onwards:
        if (r.hasNext() && (stackLevel > 0 || firstEntry))

        { firstEntry = false; event = r.next(); }

        else

        { break; }

        Sorry for not attaching a normal patch file. If I have time, I will try to create one.

        Show
        Allard Buijze added a comment - This is the class file as I (quickly) modified it. This seems to work, but haven't been able to test it thoroughly. Modifications are on line 242: boolean firstEntry = true; line 245: int stackLevel = 0; line 297: stackLevel--; line 326: stackLevel++; line 467-onwards: if (r.hasNext() && (stackLevel > 0 || firstEntry)) { firstEntry = false; event = r.next(); } else { break; } Sorry for not attaching a normal patch file. If I have time, I will try to create one.

          People

          • Assignee:
            Dan Diephouse
            Reporter:
            Allard Buijze
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: