wsimport è finito. La chiamata SOAP ha ancora bisogno di un proxy.
Separare generazione del WSDL, recupero del WSDL a runtime e invocazione SOAP quando si configura l'accesso JAX-WS tramite proxy.
Il WSDL è stato scaricato, le classi Java sono state generate e la prima chiamata SOAP continua a non uscire dalla rete. L'opzione proxy usata dal generatore appartiene all'esecuzione del generatore stesso.
Il riferimento a wsimport di Oracle JDK 8 documenta un'opzione proxy HTTP per quello strumento. Non è un'istruzione trasferibile incorporata nelle classi di servizio risultanti. Un'applicazione successiva può girare in un'altra JVM, con un altro account e con un'altra implementazione JAX-WS.
Individuare la richiesta fallita
| Fase | Processo o componente da ispezionare |
|---|---|
| Generare le classi da WSDL e import | Lo strumento di build o l'invocazione di wsimport |
| Leggere il WSDL durante la costruzione del servizio | La posizione del WSDL dell'applicazione e il client a runtime |
| Invocare l'endpoint SOAP | Il trasporto runtime scelto e la sua configurazione proxy |
La fase intermedia sfugge facilmente. Un servizio generato può ancora rimandare a un WSDL remoto. Se il runtime deve recuperarlo durante la costruzione, configurare una porta solo dopo arriva troppo tardi per quel download precedente. Impacchettare la descrizione prevista come risorsa dell'applicazione può rimuovere quella dipendenza dal recupero dove l'implementazione lo consente.
Una classe chiamata ClientProxyFeature di un'implementazione non fa automaticamente parte di ogni provider JAX-WS.
Tenere le credenziali del proxy separate da quelle del servizio SOAP. Un download WSDL riuscito può persino essere anonimo mentre l'endpoint dell'operazione richiede un accesso, o viceversa.
Annotare l'URL fallito e il punto in cui la costruzione o l'invocazione si sono fermate. Di solito questo indica dove va l'impostazione mancante, senza un altro tentativo di rigenerare esattamente le stesse classi.