Pentru WebSphere Application Server 8.5.5 JAX-WS, verificați două controale din jur înainte de a vă baza pe o adresă din contextul cererii clientului. Proprietatea IBM la nivel de JVM com.ibm.ws.websvcs.transport.enableProxyTunnel este false în mod implicit; o adresă pentru fiecare client nu activează tunelarea. Valorile de transport HTTP ale unui set de politici suprascriu și ele valorile programatice, iar acestea suprascriu proprietățile de sistem ale JVM.

Pentru portul existent selectat, IBM documentează această configurare pentru fiecare client înainte de apel:

import javax.xml.ws.BindingProvider;

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

Cheile HTTPS se aplică punctelor finale HTTPS; pentru HTTP folosiți cheile IBM HTTP corespunzătoare. Un punct final SOAP public permis poate folosi o adresă HTTP din lista de proxy HTTP numai după ce politica aplicabilă și controalele de tunel permit acest lucru și nu este configurat niciun cont de proxy la acele niveluri. Autentificarea proxy are proprietăți HTTP/HTTPS proxyUser și proxyPassword separate, independente de acreditările serviciului SOAP.

Acestea sunt extensii WebSphere. O hartă BindingProvider în Metro, CXF sau altă implementare nu face acele șiruri portabile.

Păstrați rutele simultane diferite pe obiecte client configurate corespunzător, în loc să rescrieți un context de port partajat în timp ce apelurile rulează. Astfel adresa este limitată la clientul real, fără a trata toate controalele JVM din jur ca fiind locale clientului.

Articole similare