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
Il 13/05/2014 15:11, Andrei Shakirin ha scritto:
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-----
From: Mailing List SVR [mailto:[email protected]]
Sent: Dienstag, 13. Mai 2014 14:04
To: Andrei Shakirin
Cc: [email protected]
Subject: Re: the given soapaction does not match an operation, cxf bug?
Il 13/05/2014 13:40, Andrei Shakirin ha scritto:
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#L
95
on my side I create an EndpointBuilder and then call publishEndpoint,
are these infos enough?
thanks
Nicola
Regards,
Andrei.
-----Original Message-----
From: Mailing List SVR [mailto:[email protected]]
Sent: Dienstag, 13. Mai 2014 12:55
To: [email protected]
Cc: Andrei Shakirin
Subject: Re: the given soapaction does not match an operation, cxf bug?
Il 13/05/2014 12:30, Andrei Shakirin ha scritto:
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
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
Regards,
Andrei.
-----Original Message-----
From: Mailing List SVR [mailto:[email protected]]
Sent: Donnerstag, 8. Mai 2014 12:46 To:[email protected]
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
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
