You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Thomas J Johnson <tj...@us.ibm.com> on 2022/10/24 16:00:23 UTC
JAX-WS 'soap' prefix issue on CXF 3.4.1

Hey all,

We recently upgraded from CXF 2.6.2 to CXF 3.4.1, and we are hitting an issue where if a SOAP request comes into CXF that has the SOAP 1.1 namespace as a default namespace and does not contain a prefix, like this request:


<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">

  <Body>

    <ns2:wsmain xmlns:ns2="http://com.example/">

      <arg0>

        <REQ2000 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"></REQ2000>

        <REQUEST xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"></REQUEST>

      </arg0>

    </ns2:wsmain>

  </Body>

</Envelope>


then generates the following error:

Caused by: org.apache.cxf.binding.soap.SoapFault: local part cannot be "null" when creating a QName
                at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:87)
                at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:53)
                at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:42)
                at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
                at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112)
                at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:142)
                at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:75)
                at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
                at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:836)
                at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1758)
                at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1632)
                at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1424)
                at org.apache.cxf.ext.logging.LoggingOutputStream.postClose(LoggingOutputStream.java:53)
                at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:228)
                at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
                at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:691)
                at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
                at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
                at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
                at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:444)
                at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:359)
                at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317)
                at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
                at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)

Since that error doesn’t seem to include much info, I’ve enabled faultStackTraceEnabled=true config. And this error with the config enabled:

Caused by: java.lang.IllegalArgumentException: local part cannot be "null" when creating a QName
                at javax.xml.namespace.QName.<init>(QName.java:185)
                at com.sun.xml.internal.stream.events.AttributeImpl.<init>(AttributeImpl.java:80)
                at com.sun.xml.internal.stream.events.AttributeImpl.<init>(AttributeImpl.java:76)
                at com.sun.xml.internal.stream.events.NamespaceImpl.<init>(NamespaceImpl.java:50)
                at com.sun.xml.internal.stream.events.XMLEventFactoryImpl.createNamespace(XMLEventFactoryImpl.java:160)
                at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor$HeadersProcessor.process(ReadHeadersInterceptor.java:371)
                at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:208)
                at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:72)
                at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
                at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
                at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:277)
                at com.ibm.ws.jaxws.endpoint.AbstractJaxWsWebEndpoint$1.run(AbstractJaxWsWebEndpoint.java:236)
                at com.ibm.ws.jaxws.endpoint.AbstractJaxWsWebEndpoint$1.run(AbstractJaxWsWebEndpoint.java:233)

And that’s where I’ve hit a wall, it seems totally valid that a request could come in with no prefix so long as the SOAP Envelope uses the proper default namespace: http://schemas.xmlsoap.org/soap/envelope/ I’ve not been able to track down any already known issues for this, and so I’m reaching out to see if anyone has any advice or knows why not Prefixing the SOAP Envelope should generate this error.

Cheers!

Thomas