Using CXF as a raw XML broker. Workaround for incorrect WSDL on server side

[chrisxaustin <ch...@gmail.com>]

I am consuming a soap web service that has the response message defined as:

  <s0:message name="receiveResponse">
  </s0:message>
  <s0:portType name="taservicePort">
    <s0:operation name="receive">
      <s0:input message="s1:receive">
    </s0:input>
      <s0:output message="s1:receiveResponse">
    </s0:output>
    </s0:operation>
  </s0:portType>

But the service actually returns:

<NS1:receiveResponse
xmlns:NS1="..."><NS1:receiveReturn>0</NS1:receiveReturn></NS1:receiveResponse>

This causes my client to fail with:
org.apache.cxf.interceptor.Fault: Message part
{java:com.verizon.webservices.adapter.clecclient}receiveResponse was not
recognized.  (Does it exist in service WSDL?)
	at
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:186)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
	at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:671)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2177)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2057)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1982)
	at
org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
	at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
	at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
	at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:637)
	at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)


In axis-1.4 I was able to work around this by changing OperationDesc.style
to org.apache.axis.constants.Style.MESSAGE, which caused the client to act
as a broker for xml payloads instead of attempting to unmarshal the
response.

What is the recommended way to solve this problem with CXF?
A few options that occurred to me:
1) Ask the service provider to update the wsdl
2) Download the wsdl from the server, modify it to include the receiveReturn
element, regenerate my stub
3) Add an interceptor to replace the soap body
4) Give up, and just catch the exception, ignoring it if it matches
"receiveResponse was not recognized"

Thanks for your time,
--Chris
-- 
View this message in context: http://cxf.547215.n5.nabble.com/Using-CXF-as-a-raw-XML-broker-Workaround-for-incorrect-WSDL-on-server-side-tp3351438p3351438.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Using CXF as a raw XML broker. Workaround for incorrect WSDL on server side

[Daniel Kulp <dk...@apache.org>]

On Friday 21 January 2011 8:52:49 am chrisxaustin wrote:
> What is the recommended way to solve this problem with CXF?
> A few options that occurred to me:
> 1) Ask the service provider to update the wsdl

That is difinitely the preferred option.   People shouldn't publish WSDL's 
that are wrong.

> 2) Download the wsdl from the server, modify it to include the
> receiveReturn element, regenerate my stub

That would be the next best option I think.   Fairly simple.   Would still 
allow things like schema validation and such to work.

> 3) Add an interceptor to replace the soap body
> 4) Give up, and just catch the exception, ignoring it if it matches
> "receiveResponse was not recognized"

Both of these smell like "hack".  They would work, but I think the  
modified/fixed  wsdl is the better option.

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog