იპოვეთ HTTP დამმუშავებელი WebLogic პროქსის პარამეტრის მიღმა
კონფიგურირეთ JVM, რომელიც ასრულებს WebLogic აპლიკაციის გამავალ გამოძახებას, და დაადგინეთ, იყენებს ის WebLogic-ის დამმუშავებელს თუ JDK-ისას.
WebLogic პროქსის პარამეტრების რედაქტირებამდე იპოვეთ სერვერის JVM, რომელიც ასრულებს გამოძახებას. ადმინისტრირების სერვერსა და მართულ სერვერებს შეიძლება ჰქონდეთ განსხვავებული გაშვების არგუმენტები.
შემდეგ დაადგინეთ მისი HTTP იმპლემენტაცია. JDK დამმუშავებლებისთვის საბოლოო წერტილის თვისებებია:
-Dhttp.proxyHost=proxy.example
-Dhttp.proxyPort=8080
-Dhttps.proxyHost=proxy.example
-Dhttps.proxyPort=8080მიაწოდეთ ისინი ამ სერვერის ფაქტობრივი გაშვების კონფიგურაციის მეშვეობით. დამოუკიდებლად ნებადართული საჯარო HTTP ტესტისთვის, პროქსის მონაცემების გარეშე, HTTP პროქსების სია შეიძლება მოგვცეს ჰოსტისა და პორტის კანდიდატური მნიშვნელობები. დომენის სკრიპტი გავლენას ახდენს გაშვებებზე, რომლებიც მას კითხულობენ; სერვისის ან Node Manager-ის გაშვება მოითხოვს საკუთარი ეფექტური შეყვანის შემოწმებას.
Oracle ადასტურებს -DUseSunHttpHandler=true-ს, რომ აირჩიოთ JDK-ის დამმუშავებელი WebLogic-ის საკუთარი დამმუშავებლის ნაცვლად. აირჩიეთ ის როგორც იმპლემენტაციის გადაწყვეტილება და არა როგორც დაკარგული მონაცემის თვისება. კერძო HTTP კლიენტს შეიძლება სამაგიეროდ დასჭირდეს საკუთარი ბილდერი ან მარშრუტის დამგეგმავი.
შეინარჩუნეთ არსებული პარამეტრები, გამოიყენეთ საჭირო გადატვირთვა განლაგების პროცედურის მეშვეობით და შეამოწმეთ ეფექტური მნიშვნელობები წარუმატებელ JVM-ში. სხვა მართული სერვერის შეცვლამ შეიძლება დატოვოს დამაჯერებელი კონფიგურაცია დისკზე ამ მოთხოვნაზე გავლენის გარეშე.