the given soapaction does not match an operation, cxf bug?

Discussion:

Mailing List SVR

2014-05-08 08:31:46 UTC

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

Mailing List SVR

2014-05-08 10:45:38 UTC

Permalink

Hi,

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: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 the same wsdl is used to generate
the client methods ...

What do you think about? Why cxf modify the original wsdl used to
generate java code? Is this a cxf bug or am I missing something?

thanks
Nicola

P.S. tested with both cxf 2.7.8 and 2.7.11

Andrei Shakirin

2014-05-13 10:30:35 UTC

Permalink

Hi,

I see that generated WSDL contains two bindings and two services(WSTEST, WSTESTService) using different bindings.
Do you see any reason of that? Could you post your code configuration and used to create a service?

Regards,
Andrei.

-----Original Message-----
Sent: Donnerstag, 8. Mai 2014 12:46
Subject: the given soapaction does not match an operation, cxf bug?
Hi,
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
"the given soapaction does not match an operation"
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
<soap:operationsoapAction=""style="document"/>
<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 the same wsdl is used to generate the
client methods ...
What do you think about? Why cxf modify the original wsdl used to generate
java code? Is this a cxf bug or am I missing something?
thanks
Nicola
P.S. tested with both cxf 2.7.8 and 2.7.11

Mailing List SVR

2014-05-13 12:03:44 UTC

Permalink

Hi,
No generated code is not interesting, but I would like to see how you create the service: did you use spring configuration (jaxws:endpoint) or did it programmatically?
Could you post this code or configuration?

I'm running cxf inside dropwizrad using dropwizard-jaxws
(https://github.com/roskart/dropwizard-jaxws),

I think the code you are asking for is here:

https://github.com/roskart/dropwizard-jaxws/blob/master/dropwizard-jaxws/src/main/java/com/roskart/dropwizard/jaxws/JAXWSEnvironment.java#L95

on my side I create an EndpointBuilder and then call publishEndpoint,

are these infos enough?

thanks
Nicola

Regards,
Andrei.

-----Original Message-----
Sent: Dienstag, 13. Mai 2014 12:55
Cc: Andrei Shakirin
Subject: Re: the given soapaction does not match an operation, cxf bug?

Post by Andrei Shakirin
Hi,
I see that generated WSDL contains two bindings and two services(WSTEST,

WSTESTService) using different bindings.

Post by Andrei Shakirin
Do you see any reason of that?

maybe the location, WSTEST define the location in original wsdl,
WSTESTService the one actually used in my service

Post by Andrei Shakirin
Could you post your code configuration and used to create a service?

the code was generated using using cxf-codegen-plugin which is configured in
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${cxf.version}</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>wsdl2java</goal>
</goals>
<configuration>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/main/resources/original.wsdl</wsdl>
</wsdlOption>
</wsdlOptions>
</configuration>
</execution>
</executions>
</plugin>
do you want to take a look at the generated code? do you see any errors in my
pom.xml?
thanks
Nicola

Post by Andrei Shakirin
Regards,
Andrei.

-----Original Message-----
Sent: Donnerstag, 8. Mai 2014 12:46
Subject: the given soapaction does not match an operation, cxf bug?
Hi,
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
"the given soapaction does not match an operation"
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
<soap:operationsoapAction=""style="document"/>
<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 the same wsdl is used to
generate the client methods ...
What do you think about? Why cxf modify the original wsdl used to
generate java code? Is this a cxf bug or am I missing something?
thanks
Nicola
P.S. tested with both cxf 2.7.8 and 2.7.11

Andrei Shakirin

2014-05-13 13:11:03 UTC

Permalink

Hi,

Likely your implementation somehow creates and publishes multiple services (WSTESTService is created additionally to WSTEST).

I would recommend to create a simple test case:
- generate a code based on original WSDL
- make a dummy implemention of generated service interface and publish it using
Endpoint.publish(address, implementor);
- access the endpoint with address?wsdl and check generated wsdl.

If WSDL in test is correct, debug your framework and try to find the difference.

Regards,
Andrei.

-----Original Message-----
Sent: Dienstag, 13. Mai 2014 14:04
To: Andrei Shakirin
Subject: Re: the given soapaction does not match an operation, cxf bug?

Hi,
No generated code is not interesting, but I would like to see how you create

the service: did you use spring configuration (jaxws:endpoint) or did it
programmatically?

Could you post this code or configuration?

I'm running cxf inside dropwizrad using dropwizard-jaxws
(https://github.com/roskart/dropwizard-jaxws),
https://github.com/roskart/dropwizard-jaxws/blob/master/dropwizard-
jaxws/src/main/java/com/roskart/dropwizard/jaxws/JAXWSEnvironment.java#L
95
on my side I create an EndpointBuilder and then call publishEndpoint,
are these infos enough?
thanks
Nicola

Regards,
Andrei.

-----Original Message-----
Sent: Dienstag, 13. Mai 2014 12:55
Cc: Andrei Shakirin
Subject: Re: the given soapaction does not match an operation, cxf bug?

Post by Andrei Shakirin
Hi,
I see that generated WSDL contains two bindings and two
services(WSTEST,

WSTESTService) using different bindings.

Post by Andrei Shakirin
Do you see any reason of that?

maybe the location, WSTEST define the location in original wsdl,
WSTESTService the one actually used in my service

Post by Andrei Shakirin
Could you post your code configuration and used to create a service?

Post by Andrei Shakirin
Regards,
Andrei.

-----Original Message-----
Subject: the given soapaction does not match an operation, cxf bug?
Hi,
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
"the given soapaction does not match an operation"
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
<soap:operationsoapAction=""style="document"/>
<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 the same wsdl is used to
generate the client methods ...
What do you think about? Why cxf modify the original wsdl used to
generate java code? Is this a cxf bug or am I missing something?
thanks
Nicola
P.S. tested with both cxf 2.7.8 and 2.7.11

Mailing List SVR

2014-05-13 15:45:49 UTC

Permalink

Issue solved removing wsdlLocation from WebService annotation and
putting it in pom.xml, now there is only one service in the generated
wsdl, and the interceptor that remove soapaction http header is not
needed anymore,

thanks
Nicola

Post by Andrei Shakirin
Hi,
Likely your implementation somehow creates and publishes multiple services (WSTESTService is created additionally to WSTEST).
- generate a code based on original WSDL
- make a dummy implemention of generated service interface and publish it using
Endpoint.publish(address, implementor);
- access the endpoint with address?wsdl and check generated wsdl.
If WSDL in test is correct, debug your framework and try to find the difference.
Regards,
Andrei.

-----Original Message-----
Sent: Dienstag, 13. Mai 2014 14:04
To: Andrei Shakirin
Subject: Re: the given soapaction does not match an operation, cxf bug?

Hi,
No generated code is not interesting, but I would like to see how you create

the service: did you use spring configuration (jaxws:endpoint) or did it
programmatically?

Could you post this code or configuration?

Regards,
Andrei.

-----Original Message-----
Sent: Dienstag, 13. Mai 2014 12:55
Cc: Andrei Shakirin
Subject: Re: the given soapaction does not match an operation, cxf bug?

Post by Andrei Shakirin
Hi,
I see that generated WSDL contains two bindings and two
services(WSTEST,

WSTESTService) using different bindings.

Post by Andrei Shakirin
Do you see any reason of that?

maybe the location, WSTEST define the location in original wsdl,
WSTESTService the one actually used in my service

Post by Andrei Shakirin
Could you post your code configuration and used to create a service?

Post by Andrei Shakirin
Regards,
Andrei.

b han

2015-03-19 22:34:40 UTC

Permalink

what do you mean by moving wsdlLocation to pom.xml?

Mailing List SVR

2014-05-13 10:55:02 UTC

Permalink

Post by Andrei Shakirin
Hi,
I see that generated WSDL contains two bindings and two services(WSTEST, WSTESTService) using different bindings.
Do you see any reason of that?

maybe the location, WSTEST define the location in original wsdl,
WSTESTService the one actually used in my service

Post by Andrei Shakirin
Could you post your code configuration and used to create a service?

the code was generated using using cxf-codegen-plugin which is
configured in pom.xml:

<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${cxf.version}</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>wsdl2java</goal>
</goals>
<configuration>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/main/resources/original.wsdl</wsdl>
</wsdlOption>
</wsdlOptions>
</configuration>
</execution>
</executions>
</plugin>

do you want to take a look at the generated code? do you see any errors
in my pom.xml?

thanks
Nicola

Post by Andrei Shakirin
Regards,
Andrei.

Andrei Shakirin

2014-05-13 11:40:09 UTC

Permalink

Hi,

No generated code is not interesting, but I would like to see how you create the service: did you use spring configuration (jaxws:endpoint) or did it programmatically?
Could you post this code or configuration?

Regards,
Andrei.

-----Original Message-----
Sent: Dienstag, 13. Mai 2014 12:55
Cc: Andrei Shakirin
Subject: Re: the given soapaction does not match an operation, cxf bug?

Post by Andrei Shakirin
Hi,
I see that generated WSDL contains two bindings and two services(WSTEST,

WSTESTService) using different bindings.

Post by Andrei Shakirin
Do you see any reason of that?

maybe the location, WSTEST define the location in original wsdl,
WSTESTService the one actually used in my service

Post by Andrei Shakirin
Could you post your code configuration and used to create a service?

Post by Andrei Shakirin
Regards,
Andrei.

-----Original Message-----
Sent: Donnerstag, 8. Mai 2014 12:46
Subject: the given soapaction does not match an operation, cxf bug?
Hi,
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
"the given soapaction does not match an operation"
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
<soap:operationsoapAction=""style="document"/>
<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 the same wsdl is used to
generate the client methods ...
What do you think about? Why cxf modify the original wsdl used to
generate java code? Is this a cxf bug or am I missing something?
thanks
Nicola
P.S. tested with both cxf 2.7.8 and 2.7.11

Mailing List SVR

2014-05-13 10:43:30 UTC

Permalink

Post by Andrei Shakirin
Hi,
I see that generated WSDL contains two bindings and two services(WSTEST, WSTESTService) using different bindings.
Do you see any reason of that?

no I see no apparent reason for that

Post by Andrei Shakirin
Could you post your code configuration and used to create a service?

Post by Andrei Shakirin
Regards,
Andrei.

Mailing List SVR

2014-05-09 07:21:07 UTC

Permalink

Hi,

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 what seems a cxf bug to me.

Obviously if someone give you a wsdl the same wsdl is used to generate the
client methods ...

What do you think about? Why cxf modify the original wsdl used to generate
java code? Is this a cxf bug or am I missing something?

thanks
Nicola

P.S. tested with both cxf 2.7.8 and 2.7.11

--
View this message in context: http://cxf.547215.n5.nabble.com/the-given-soapaction-does-not-match-an-operation-cxf-bug-tp5743826.html
Sent from the cxf-user mailing list archive at Nabble.com.

Daniel Kulp

2014-05-13 14:57:33 UTC

Permalink

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 its either a code generation issue or possibly a runtime issue if its not finding it. Would like to see a test case.

Dan

Post by Mailing List SVR
Hi,
"the given soapaction does not match an operation"
<soap:operation soapAction="" style="document"/>
<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-1oDqGaOF3Lkdnm+***@public.gmane.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Mailing List SVR

2014-05-13 15:28:23 UTC

Permalink

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

Post by Daniel Kulp
If you have the WSDL, why are you not deploying the service using the
has an appropriate wsdlLocation attribute. If the WSDL is
available, it should use it directly and not have to generate a new
annotation.
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

Post by Mailing List SVR
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
"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
<soap:operationsoapAction=""style="document"/>
<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
Talend Community Coder - http://coders.talend.com
<http://coders.talend.com/>