För WebSphere Application Server 8.5.5 JAX-WS, kontrollera två omgivande styrningar innan du förlitar dig på en adress i klientens förfrågningskontext. IBMs egenskap på JVM-nivå com.ibm.ws.websvcs.transport.enableProxyTunnel är false som standard; en adress per klient aktiverar inte tunnling. HTTP-transportvärdena i en policymängd åsidosätter också programmatiska värden, och de åsidosätter JVM:ens systemegenskaper.

För den valda befintliga porten dokumenterar IBM denna inställning per klient före anropet:

import javax.xml.ws.BindingProvider;

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

HTTPS-nycklarna gäller för HTTPS-slutpunkter; för HTTP använder du motsvarande IBM HTTP-nycklar. En tillåten offentlig SOAP-slutpunkt kan använda en HTTP-adress från HTTP-proxylistan först när den tillämpliga policyn och tunnlingsstyrningarna tillåter det och ingen proxykontot är konfigurerat på dessa nivåer. Proxyautentisering har separata HTTP/HTTPS-egenskaper proxyUser och proxyPassword, oberoende av SOAP-tjänstens autentiseringsuppgifter.

Detta är WebSphere-utökningar. En BindingProvider-karta i Metro, CXF eller en annan implementering gör inte dessa strängar portabla.

Håll olika samtidiga rutter på korrekt konfigurerade klientobjekt i stället för att skriva om en delad portkontext medan anrop körs. Då begränsas adressen till den faktiska klienten utan att alla omgivande JVM-styrningar behandlas som klientlokala.

Relaterade artiklar