За 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 настройки да се смятат за локални за клиента.

Подобни статии