Для WebSphere Application Server 8.5.5 JAX-WS проверьте два окружающих механизма, прежде чем полагаться на адрес в контексте запроса клиента. Свойство IBM на уровне JVM com.ibm.ws.websvcs.transport.enableProxyTunnel по умолчанию равно false; адрес для отдельного клиента не включает туннелирование. Значения HTTP-транспорта набора политик также переопределяют программные значения, а те переопределяют системные свойства JVM.

Для выбранного существующего порта IBM документирует эту настройку для отдельного клиента перед вызовом:

import javax.xml.ws.BindingProvider;

BindingProvider binding = (BindingProvider) servicePort;
binding.getRequestContext().put("https.proxyHost", "proxy.example");
binding.getRequestContext().put("https.proxyPort", "8080");

Ключи HTTPS действуют для конечных точек HTTPS; для HTTP используйте соответствующие ключи IBM HTTP. Разрешённая публичная конечная точка SOAP может использовать HTTP-адрес из списка HTTP-прокси только после того, как применимая политика и средства управления туннелем это разрешат и на этих уровнях не настроена учётная запись прокси. Аутентификация прокси имеет отдельные свойства HTTP/HTTPS proxyUser и proxyPassword, независимые от учётных данных службы SOAP.

Это расширения WebSphere. Карта BindingProvider в Metro, CXF или другой реализации не делает эти строки переносимыми.

Держите разные одновременные маршруты на правильно настроенных клиентских объектах, а не переписывайте общий контекст порта во время выполнения вызовов. Так адрес ограничивается реальным клиентом, а окружающие механизмы JVM не считаются локальными для клиента.

Похожие статьи