wsimport er ferdig. SOAP-kallet trenger fortsatt en proxy.
Skill WSDL-generering, WSDL-henting ved kjøretid og SOAP-kall når JAX-WS-proxytilgang settes opp.
WSDL-en ble lastet ned, Java-klassene ble generert, og det første SOAP-kallet kommer fortsatt ikke ut av nettverket. Proxyvalget generatoren bruker, hører til generatorens egen kjøring.
Oracles JDK 8-referanse for wsimport dokumenterer et HTTP-proxyvalg for det verktøyet. Det er ikke en flyttbar instruksjon som bakes inn i tjenesteklassene som genereres. En senere applikasjon kan kjøre i en annen JVM, under en annen konto og med en annen JAX-WS-implementasjon.
Finn ut hvilken forespørsel som feilet
| Trinn | Prosess eller komponent som skal undersøkes |
|---|---|
| Generer klasser fra WSDL og importer | Byggeverktøyet eller wsimport-kallet |
| Les WSDL mens tjenesten bygges | Applikasjonens WSDL-plassering og kjøretidsklienten |
| Kall SOAP-endepunktet | Den valgte kjøretidstransporten og proxyoppsettet dens |
Det midterste trinnet er lett å overse. En generert tjeneste kan fortsatt vise til en ekstern WSDL. Hvis kjøretiden må hente den under bygging, er det for sent å sette opp en port bare etterpå for den tidligere nedlastingen. Å pakke den tiltenkte beskrivelsen som en applikasjonsressurs kan fjerne den henteavhengigheten der implementasjonen støtter det.
En klasse kalt ClientProxyFeature fra én implementasjon er ikke automatisk en del av hver JAX-WS-leverandør.
Hold proxy-legitimasjonen atskilt fra legitimasjonen til SOAP-tjenesten. En vellykket WSDL-nedlasting kan til og med være anonym mens endepunktet for operasjonen krever innlogging, eller omvendt.
Noter den feilende URL-en og punktet der byggingen eller kallet stoppet. Det viser vanligvis hvor den manglende innstillingen hører hjemme, uten et nytt forsøk på å generere nøyaktig de samme klassene.