Apache CXF Configuration and Troubleshooting

How do I properly identify the conduit in cxf.xml?

I’ve had problems with this in the past, as you really do have to go to the WSDL and not the generated code to get the correct values you need. The client configuration for consumers of web services can be found here.

The cxf.xml file looks something like:

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
    xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <http-conf:conduit name="{http://apache.org/hello_world_soap_http}SoapPort.http-conduit">
        <http-conf:client Connection="Keep-Alive" />
    </http-conf:conduit>
</beans>

It’s the conduit name value that can be tricky. If you have the following in your WSDL:

<?xml version="1.0" encoding="utf-8"?>
<definitions name="SomeSOAP"
             targetNamespace="http://project.intelliware.ca/"
             xmlns:lio="http://project.intelliware.ca/"
             xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"
             xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns="http://schemas.xmlsoap.org/wsdl/">

    <types>
        <xsd:schema targetNamespace="http://project.intelliware.ca/" elementFormDefault="qualified" />
    </types>

	<message name="SomeRequest">
		<part name="request" element="lio:Request" />
	</message>

	<message name="SomeResponse">
		<part name="response" element="lio:Response" />
	</message>

	<portType name="SomePort">
		<operation name="Operation">
			<input name="request" message="lio:SomeRequest" />
			<output name="response" message="lio:SomeResponse" />
		</operation>
	</portType>

	<binding name="SomeSOAP" type="lio:SomePort">
		<soapbind:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
		<operation name="Operation">
			<soapbind:operation style="document" soapAction="http://project.intelliware.ca/somews?method=SomeSOAP" />
			<input name="request">
				<soapbind:body use="literal" />
			</input>
			<output name="response">
				<soapbind:body use="literal" />
			</output>
		</operation>
	</binding>

	<service name="SomeRequest">
		<port name="SomeSOAPPort" binding="lio:SomeSOAP">
			<soapbind:address location="http://project.intelliware.ca/somews?method=SomeSOAP" />
		</port>
	</service>

</definitions>

then your conduit name becomes:

<http-conf:conduit name="{http://project.intelliware.ca/}SomeSOAPPort.http-conduit">

where the part in the curly braces comes from the targetNamespace, and the part between the right curly brace and .http-conduit is the name attribute from the port within the service you are using.

I can send a request, but the response always times out!

This one was a little trickier to find out, despite the solution being easy.

We seemed to be connecting to the web service, but could not get a response. Ever.

Jul 23, 2008 12:27:02 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
	at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:170)
	at $Proxy45.geocode(Unknown Source)
	< ... snip ... >
Caused by: java.net.SocketTimeoutException: Read timed out
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:129)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
	at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:659)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:604)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:961)
	at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1896)
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1824)
	at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
	at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:583)
	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
	... 27 more

Once we had our conduit properly identified, we needed to set the AllowChunking to false in the client configuration:

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
    xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <http-conf:conduit name="{http://project.intelliware.ca/}SomeSOAPPort.http-conduit">
        <http-conf:client Connection="Keep-Alive"
                          AllowChunking="false" />
    </http-conf:conduit>
</beans>

We had actually found that several of the SOAP services to which we tried to connect would not respond if chunking was enabled. I don’t know if it is a specific technology on the other side that barfs or not on the chunked request, but this certainly fixed the behaviour we observed with the timing out of the response.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply