wsimport는 끝났다. 그래도 SOAP 호출에는 프록시가 필요하다.
JAX-WS 프록시 접근을 구성할 때 WSDL 생성, 런타임 WSDL 조회, SOAP 호출을 구분한다.
WSDL을 내려받고 Java 클래스를 생성했는데도 첫 SOAP 호출은 여전히 네트워크를 빠져나가지 못한다. 생성기가 쓰는 프록시 옵션은 생성기 자신의 실행에 속한다.
Oracle JDK 8의 wsimport 참조 문서는 그 도구를 위한 HTTP 프록시 옵션을 설명한다. 그것은 생성된 서비스 클래스에 새겨지는 이식 가능한 지시가 아니다. 나중에 실행되는 애플리케이션은 다른 JVM, 다른 계정, 다른 JAX-WS 구현에서 돌 수 있다.
어느 요청이 실패했는지 찾아내기
| 단계 | 확인할 프로세스 또는 구성 요소 |
|---|---|
| WSDL과 import에서 클래스 생성 | 빌드 도구 또는 wsimport 호출 |
| 서비스 생성 중 WSDL 읽기 | 애플리케이션의 WSDL 위치와 런타임 클라이언트 |
| SOAP 엔드포인트 호출 | 선택한 런타임 전송과 그 프록시 설정 |
가운데 단계는 놓치기 쉽다. 생성된 서비스가 여전히 원격 WSDL을 가리킬 수 있다. 런타임이 구성 중에 그것을 가져와야 한다면, 그 뒤에 포트를 설정하는 것은 앞선 내려받기에 너무 늦다. 의도한 설명을 애플리케이션 리소스로 패키징하면 구현이 지원하는 곳에서는 그 조회 의존성을 없앨 수 있다.
한 구현의 ClientProxyFeature 라는 클래스가 모든 JAX-WS 제공자에 자동으로 포함되는 것은 아니다.
프록시 자격 증명은 SOAP 서비스 자격 증명과 분리해 둔다. WSDL 내려받기는 익명으로 성공해도 작업 엔드포인트는 로그인을 요구할 수 있고, 그 반대일 수도 있다.
실패한 URL과 구성 또는 호출이 멈춘 지점을 기록한다. 그러면 보통 빠진 설정이 어디에 속하는지 드러난다. 똑같은 클래스를 다시 생성할 필요는 없다.