Varför misslyckas webbtjänstrapporteringsservern som anropar C# med att känna igen värdet på http-headern SOAPAction och låter alltid C# ändra det, bara för att C# bara behöver lägga till en tagg, varför kan inte JAVA specificera en åtgärdsförfrågan?
Att publicera och anropa webbtjänsten är mycket enkelt, men det finns fortfarande mindre problem, som sammanfattas enligt följande:
Java anropar .nets webService med felet "Server failed to recognize the value of HTTP header SOAPAction".
Lösning:
När webbtjänsten anropas anges ingen SoapAction, ingen RequestNameSpace specificeras, så "Servern misslyckades med att känna igen värdet av HTTP-headern SOAPAction" visas alltid vid begäran.
Om du använder axelkall, kalla dem enligt följande:
public static void main(String[] args) kastar Exception { Inte ta med det? WSDL-suffix Strängändpunkt = "http://webservice.webxml.com.cn/webservices/qqOnlineWebService.asmx"; Skapa ett serviceanrop Servicetjänst = ny Service(); Skapa ett anropsobjekt via tjänst Call call = (Call) service.createCall(); Ställ in URL:en där tjänsten är placerad call.setTargetEndpointAddress(new java.net.URL(endpoint)); qqCheckOnline är metoden "http://WebXml.com.cn/" på nätsidan, som också uppmärksammar adressen till namnrymden och även rapporterar ett fel om du inte tar med det call.setOperationName(nya QName("http://WebXml.com.cn/","qqCheckOnline")); qqCode är också parameternamnet för .NET-metoden, vilket är parameternamnet för qqCheckOnline call.addParameter(nya QName("http://WebXml.com.cn/","qqCode"), org.apache.axis.encoding.XMLType.XSD_STRING, javax.xml.rpc.ParameterMode.IN); Undvik att Java anropar .nets webService med felmeddelandet "Servern misslyckades med att känna igen värdet på HTTP-headern SOAPAction" call.setUseSOAPAction(true); call.setReturnType(org.apache.axis.encoding.XMLType.SOAP_STRING); Typen av parameter som returneras call.setSOAPActionURI("http://WebXml.com.cn/qqCheckOnline"); Det bör också noteras att du behöver lägga till metoden som ska anropas, annars rapporteras även ett fel Objektarrayer kapslar in parametrarna String ret = (String) call.invoke(new Object[] {"aaaaa"}); System.out.println("--------"+ret); } Notera kommentarsfältet.
Inloggningen med hyperlänken är synlig.? WSDL står för Public Web Service (Public Web Service)
Följande undantag uppstår när wsdl2java.bat som använder CXF genererar en klient för att publicera en .net-webbtjänst baserad på en wsdl-fil
( odefinierad elementdeklaration 's:schema') Lösning:
Öppna wsdl.xml och använd
<s:any minOccurs="2" maxOccurs="2"/>Alternate <s:element ref="s:schema" /><s:any /> Detta wsdl2java-genereringsfel bör vara relaterat till att JAXB inte stöder xml-referenser, eftersom <s:any minOccurs="2" maxOccurs="2"/> och <s:element ref="s:schema" /><s:any/> faktiskt är ekvivalenta. <s:element ref="s:schema" /> betyder faktiskt att du kan använda vilken elementtyp som helst specificerad av s:schema här, <s:any /> spelar denna roll, <s:any minOccurs="2" maxOccurs="2"/> är bara två <s:any /> Det stod bara i en mening.
hänvisningInloggningen med hyperlänken är synlig.
Med CXF:s wsdl2java.bat genereras ett klientkompileringssuperfel baserat på wsdl-filen
Lösning:
Den kompileras inte korrekt eftersom jax-ws2.2-specifikationen krockar med java6.
Programmet kan dock inte kompileras enbart i java5, så det är nödvändigt att sänka jax-ws-specifikationsversionen, som kan hanteras så här: Utför kommandot
wsdl2java -frontend jaxws21 -client *.xml På detta sätt kan koden som genereras med jax-ws2.1 kompileras och köras i java6.
Jag jämförde klientkoden som genererades av verktyget med textjämförelse och upptäckte att den senare genererade 3 fler klientkod, så att ta bort de 3 konstruktörer som rapporterade fel kan också lösa ovanstående problem.
Återutgiven från:Inloggningen med hyperlänken är synlig.
|