CXF: getting exception when using payload="envelope" in combination with wsdlLocation when the wsdl contains headers

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.2.6 (EE only), 3.0.0
  • Fix Version/s: 2.2.7 (EE only), 3.0.1
  • Component/s: Modules: CXF
  • Labels:
    None
  • User impact:
    High
  • Similar Issues:
    None

Description

This issue was created to track the fix for the EE-2002 issue.
This is the original comment from it:

I have tested the Mule 2.2.7 fix against one of our test services. The
service in question no longer throws a TransformerException but the
request still fails with the following exception....

WARNING: Interceptor for
{http://ctp.wcsl.com/wsdl/LottoWager-v1}LottoWagerBinding_v1_0 has
thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not write to XMLStreamWriter.
at
org.apache.cxf.interceptor.StaxOutInterceptor$StaxOutEndingInterceptor.handleMessage(StaxOutInterceptor.java:173)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at
org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:218)
at
org.mule.transport.cxf.CxfServiceComponent$1.write(CxfServiceComponent.java:273)
at
org.mule.transport.http.HttpServerConnection.writeResponse(HttpServerConnection.java:315)
at
org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageReceiver.java:191)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.xml.stream.XMLStreamException: Trying to write
END_DOCUMENT when document has no root (ie. trying to output empty
document).
at
com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1473)
at
com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1502)
at
com.ctc.wstx.sw.BaseStreamWriter.finishDocument(BaseStreamWriter.java:1663)
at
com.ctc.wstx.sw.BaseStreamWriter.writeEndDocument(BaseStreamWriter.java:585)
at
org.apache.cxf.interceptor.StaxOutInterceptor$StaxOutEndingInterceptor.handleMessage(StaxOutInterceptor.java:163)
... 9 more

I have attached a copy of the console log, an export of the Mule project
and an example soap request. The service I have switched over to use the
cxf:inbound-endpoint wsdlLocation attribute is called
WHS_LottoWagerStub-v1 - the endpoint address is
http://localhost:8888/whs/LottoWager-v1.

Let me know if you require any further details.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Pablo Kraan added a comment -

The problem has the same cause that the original MULE-5030 issue, which I think is a bug in CXF.

The root of the problem is in SoapBindingFactory.initializeMessage() method. There CXF
creates a MessageInfo and sets the different message parts inside a list. Each part has an index,
which is the same than its position in the list. Then CXF removes the "headers" parts of the list but
it does not updates the index of the remaining parts. In this case, removes the first part (index 0)
but it does not updates the index of the second part (from 1 to 0).

The problem is manifested inside AbstractOutDatabindingInterceptor.writeParts method:

for (MessagePartInfo part : parts) {
    if (objs.hasValue(part)) {
            Object o = objs.get(part);
            dataWriter.write(o, part, xmlWriter);
    }
 }

The problem is in the call to objs.hasValue(part):

public boolean hasValue(MessagePartInfo key) {
    if (key.getIndex() >= size()) {
            return false;
    }
    return super.get(key.getIndex()) != REMOVED_MARKER;
}

This call return false because key.getIndex() = 1 and size =1. (key.getIndex() should be 0)

I will try to find a workaround for this problem, but I think the right fix should be in CXF,
which should update the part's index everytime it removes a part from the list.

Show
Pablo Kraan added a comment - The problem has the same cause that the original MULE-5030 issue, which I think is a bug in CXF. The root of the problem is in SoapBindingFactory.initializeMessage() method. There CXF creates a MessageInfo and sets the different message parts inside a list. Each part has an index, which is the same than its position in the list. Then CXF removes the "headers" parts of the list but it does not updates the index of the remaining parts. In this case, removes the first part (index 0) but it does not updates the index of the second part (from 1 to 0). The problem is manifested inside AbstractOutDatabindingInterceptor.writeParts method: 
for (MessagePartInfo part : parts) {
    if (objs.hasValue(part)) {
            Object o = objs.get(part);
            dataWriter.write(o, part, xmlWriter);
    }
 }
The problem is in the call to objs.hasValue(part): 
public boolean hasValue(MessagePartInfo key) {
    if (key.getIndex() >= size()) {
            return false;
    }
    return super.get(key.getIndex()) != REMOVED_MARKER;
}
This call return false because key.getIndex() = 1 and size =1. (key.getIndex() should be 0) I will try to find a workaround for this problem, but I think the right fix should be in CXF, which should update the part's index everytime it removes a part from the list.
Hide
Permalink
Pablo Kraan added a comment - - edited

Many thanks to Dan Diephouse who has helped a lot with suggestions about how to fix the problem

Fix 2.2.x
http://fisheye.codehaus.org/changelog/mule/?cs=19768
http://fisheye.codehaus.org/changelog/mule/?cs=19805

Fix 3.0.x
http://fisheye.codehaus.org/changelog/mule/?cs=19806

Fix 3.x
http://fisheye.codehaus.org/changelog/mule/?cs=19809

Show
Pablo Kraan added a comment - - edited Many thanks to Dan Diephouse who has helped a lot with suggestions about how to fix the problem Fix 2.2.x http://fisheye.codehaus.org/changelog/mule/?cs=19768 http://fisheye.codehaus.org/changelog/mule/?cs=19805 Fix 3.0.x http://fisheye.codehaus.org/changelog/mule/?cs=19806 Fix 3.x http://fisheye.codehaus.org/changelog/mule/?cs=19809

People

  • Assignee:
    Pablo Kraan
    Reporter:
    Pablo Kraan
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: