You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mailing List SVR <li...@svrinformatica.it> on 2014/05/08 10:31:46 UTC
the given soapaction does not match an operation, cxf bug?
Hi,
I'm generating a service from an existing wsdl (original.wsdl attached),
after creating the service the generated wsdl has some small difference
from the original one (cxf_generated.wsdl attached), 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 they 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:operationsoapAction=""style="document"/>
after this section there is also the original one that define:
<soap:operationsoapAction="http://test.example.com//updateList"/>
I defined an interceptor that remove the SOAPAction http header if
present and this workaround what seems a cxf bug to me.
Obviously if someone give you a wsdl it use that wsdl to generate client
methods and not redownload the wsdl from your service.
What do you think about? Is this a cxf bug? Why cxf modify the original
wsdl used to generate java code?
thanks
Nicola
P.S. tested with both cxf 2.7.8 and 2.7.11
Re: the given soapaction does not match an operation, cxf bug?
Posted by Mailing List SVR <li...@svrinformatica.it>.
Thanks for the suggestion, issue solved, some details:
1) WebMethod annotations has the proper action parameter
2) in my implementation wsdlLocation is set to "classpath:original.wsdl"
step to solve:
1) I removed the wsdlLocation from @WebService annotation in my
implementation
2) I added wsdlLocation in my pom.xml pointing to the same path
previously defined in WebService annotation,
thanks
Nicola
Il 13/05/2014 16:57, Daniel Kulp ha scritto:
>
> If you have the WSDL, why are you not deploying the service using the
> WSDL. I think for your case, make sure the @WebService annotation
> has an appropriate wsdlLocation attribute. If the WSDL is
> available, it should use it directly and not have to generate a new
> annotation.
>
> Can you check the generated code to make sure the @WebMethod
> annotations have the appropriate action parameter? It should be
> pulling the action from there so it's either a code generation issue
> or possibly a runtime issue if it's not finding it. Would like to
> see a test case.
>
> Dan
>
>
>
> On May 8, 2014, at 4:31 AM, Mailing List SVR <lists@svrinformatica.it
> <ma...@svrinformatica.it>> wrote:
>
>> Hi,
>>
>> I'm generating a service from an existing wsdl (original.wsdl
>> attached), after creating the service the generated wsdl has some
>> small difference from the original one (cxf_generated.wsdl attached),
>> 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 they 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:operationsoapAction=""style="document"/>
>>
>> after this section there is also the original one that define:
>>
>> <soap:operationsoapAction="http://test.example.com//updateList"/>
>>
>> I defined an interceptor that remove the SOAPAction http header if
>> present and this workaround what seems a cxf bug to me.
>>
>> Obviously if someone give you a wsdl it use that wsdl to generate
>> client methods and not redownload the wsdl from your service.
>>
>> What do you think about? Is this a cxf bug? Why cxf modify the
>> original wsdl used to generate java code?
>>
>>
>> thanks
>> Nicola
>>
>> P.S. tested with both cxf 2.7.8 and 2.7.11
>> <cxf_generated.wsdl><original.wsdl>
>
> --
> Daniel Kulp
> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> <http://coders.talend.com/>
>
Re: the given soapaction does not match an operation, cxf bug?
Posted by Daniel Kulp <dk...@apache.org>.
If you have the WSDL, why are you not deploying the service using the WSDL. I think for your case, make sure the @WebService annotation has an appropriate wsdlLocation attribute. If the WSDL is available, it should use it directly and not have to generate a new annotation.
Can you check the generated code to make sure the @WebMethod annotations have the appropriate action parameter? It should be pulling the action from there so it’s either a code generation issue or possibly a runtime issue if it’s not finding it. Would like to see a test case.
Dan
On May 8, 2014, at 4:31 AM, Mailing List SVR <li...@svrinformatica.it> wrote:
> Hi,
>
> I'm generating a service from an existing wsdl (original.wsdl attached), after creating the service the generated wsdl has some small difference from the original one (cxf_generated.wsdl attached), 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 they 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 what seems a cxf bug to me.
>
> Obviously if someone give you a wsdl it use that wsdl to generate client methods and not redownload the wsdl from your service.
>
> What do you think about? Is this a cxf bug? Why cxf modify the original wsdl used to generate java code?
>
>
> thanks
> Nicola
>
> P.S. tested with both cxf 2.7.8 and 2.7.11
> <cxf_generated.wsdl><original.wsdl>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com