[
https://issues.apache.org/jira/browse/CXF-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034223#comment-15034223
]
Thierry RAMANAMPANOHARANA commented on CXF-5738:
------------------------------------------------
Thank you very [~ay]. That's exactly what I am looking for. It turned out that
we are using 5.7.6. One minor version prior to the introduction of the property.
I am pretty sure you intended to say CXF-5387 for the ticket where
allowNonMatchingToDefault was introduced. ;-) as CXF-5738 is self-referencing.
What a coincidence.
> given soap action does not match any operation
> ----------------------------------------------
>
> Key: CXF-5738
> URL: https://issues.apache.org/jira/browse/CXF-5738
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.7.11
> Reporter: Nicola
>
> I'm generating a service from an existing wsdl
> (http://195.250.34.59/temp/original.wsdl), after creating the service the cxf
> generated wsdl has some small difference from the original one
> (http://195.250.34.59/temp/cxf_generated.wsdl), if I create client methods,
> using for example soapui, from the cxf generated wsdl all is fine but if I
> use the original wsdl the requests fail with the error:
> "the given soapaction does not match an operation"
> the problem is the SOAPAction http header:
> cxf expects no SOAPAction header or an empty one, if you look at the wsdl
> generated by cxf you can see a section not present in the original wsdl that
> define an empty soap action:
> <soap:operation soapAction="" style="document"/>
> after this section there is also the original one that define:
> <soap:operation soapAction="http://test.example.com//updateList"/>
> I defined an interceptor that remove the SOAPAction http header if present
> and this workaround the problem
> cxf should not modify the original wsdl or however should accept calls
> generated using the provided wsdl
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
