Trovu la HTTP-traktilon malantaŭ WebLogic-proksea agordo

Agordi la JVM-on, kiu faras la elan vokon de WebLogic-a aplikaĵo, kaj konstati, ĉu ĝi uzas la traktilon de WebLogic aŭ tiun de JDK.

Trovu la servilan JVM-on, kiu faras la vokon, antaŭ ol redakti la prokseajn opciojn de WebLogic. La administra servilo kaj la administrataj serviloj povas havi malsamajn startajn argumentojn.

Poste identigu ĝian HTTP-realigon. Por JDK-traktiloj, la finpunktaĵoj estas:

-Dhttp.proxyHost=proxy.example
-Dhttp.proxyPort=8080
-Dhttps.proxyHost=proxy.example
-Dhttps.proxyPort=8080

Provizu ilin per la reala lanĉa agordo de tiu servilo. Por sendepende permesita publika HTTP-testo sen agorditaj prokseaj legitimiloj, la HTTP-proksea listo povas provizi kandidatajn hostajn kaj pordajn valorojn. Domajna skripto influas lanĉojn, kiuj legas ĝin; servo aŭ Node Manager-lanĉo bezonas kontrolon de siaj propraj efikaj enigoj.

Oracle dokumentas -DUseSunHttpHandler=true por elekti la JDK-traktilon anstataŭ la propra traktilo de WebLogic. Elektu ĝin kiel realigan decidon, ne kiel mankantan legitimilan econ. Privata HTTP-kliento povas anstataŭe postuli sian konstruanton aŭ itineran plananton.

Konservu ekzistantajn opciojn, apliku ajnan bezonatan restartigon laŭ la disfaldiga proceduro kaj ekzamenu la efikajn valorojn en la JVM, kiu malsukcesis. Ŝanĝi alian administrata servanton povas lasi konvinkan agordon sur la disko sen influi ĉi tiun peton.

Rilataj artikoloj