Błąd podczas generowania klienta z użyciem WSDL apache cxf

Question

Próbowałem wygenerować odcinki i klienta z użyciem WSDL CXF (wersje 2.2.3 i 2.7.0) 2.2.6 dając poniższej komendy

> wsdl2java.bat -p com.easynet.eordering.client -client http://expediter.staging.gis.easynet.com:7001/cds/services/eordering?wsdl 

ale otrzymuję błąd jak

WSDLToJava Error: Non unique body parts! In a port, operations must have unique operation signaure on the wire for successful dispatch. In port {http://eordering.uk.easynet.net}eorderingPortSOAP, Operations "{http://eordering.uk.easynet.net}getAMList" and "{http://eordering.uk.easynet.net}getDCList" have the same request body block {http://eordering.uk.easynet.net}userListRequest

wiem, dlaczego ten błąd został wyrzucony w moich operacji WSDL są zapisywane jako

<operation name="getDCList"><input message="tns:userListRequest"/><output message="tns:userListResponse"/></operation> 
<operation name="getAMList"><input message="tns:userListRequest"/><output message="tns:userListResponse"/></operation> 

Po prostu ponownie użyłem parametru userListRequest dla obu operacji, uważam, że błąd został zgłoszony jako ten sam parametr (userListRequest) określony w obu operacjach.

Czy istnieje sposób na uniknięcie tego błędu bez wprowadzania zmian we wsdl? (ponieważ wiem, że przeciążanie operacji jest niedozwolone w pliku wsdl 1.2, ale przeciążanie parametrów wejściowych?).

Answer 1

Taki WSDL nie byłby zgodny z WSI-BasicProfile. Zobacz:

http://www.ws-i.org/profiles/basicprofile-1.1.html#Operation_Signatures

Profil definiuje podpis pracy jako nazwy elementu, który pojawia się w soap: body. Zatem, jeśli dwie operacje użyć tego samego elementu z dzieckiem (lub wiadomość w danym przypadku), są one uważane za nieunikatowa i łamanie:

R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another. 

Answer 2

Jak wspomniano w pytaniu:

Is there any way to avoid this error without making changes to the wsdl ?

Jeśli możesz „t naprawić WSDL, można wyłączyć jego potwierdzenie:

-validate = brak

lub jeśli używasz maven:

Nie jestem pewien, czy nie spowoduje to problemów w czasie pracy. Znajdę to wkrótce i zaktualizuję ten post.

Answer 3

Jeśli jest możliwa zmiana WSDL i WS-I Basic Profile 2.0 jest używany, można dodać wsa:Action z unique value do elementu wsdl:input (wewnątrz elementu wsdl:operation):

Np

<wsdl:operation name="update"> 
    <wsdl:input message="tns:myMessage" wsam:Action="namespace/port/operation" /> 
</wsdl:operation> 

W WS-I Basic Profil 2.0 Definicja „podpisu operacja”: „Profil definiuje«podpis operacja», aby być w pełni kwalifikowana nazwa elementu potomnego organizmu SOAP komunikatu wejściowego SOAP opisane przez operację w powiązaniu WSDL i wartość URI bloku nagłówka SOA Action: Action, jeśli jest obecny. "

Answer 4

Inną pracą jest próba pobrania pliku schematu z pliku WSDL. a poniżej wtyczki w Maven generować klasy Javy

<plugin> 
<groupId>org.jvnet.jax-ws-commons</groupId> 
<artifactId>jaxws-maven-plugin</artifactId> 
<version>2.3</version> 
<executions> 
<execution> 
<id>schema1-generate</id> 
<goals><goal>wsimport</goal></goals> 
<configuration> 
<extension>true</extension> 
<bindingFiles> 
<bindingFile>${basedir}/src/main/resources/wsdl/service-bindings.xjc 
</bindingFile> 
</bindingFiles> 
<wsdlDirectory>src/main/resources/wsdl</wsdlDirectory> 
<wsdlFiles> 
<wsdlFile>Service.wsdl</wsdlFile> 
</wsdlFiles> 
<keep>true</keep> 
<sourceDestDir>target/generated-code/src</sourceDestDir> 
<vmArgs> 
<vmArg>-Djavax.xml.accessExternalSchema=all</vmArg> 
</vmArgs> 
</configuration> 
<phase>generate-sources</phase> 
</execution> 
</executions> 
</plugin>