Metu la prokseajn flagojn de Java antaŭ la ĉefklaso
Transdonu prokseajn sistempropraĵojn al la Ĝava lanĉilo anstataŭ hazarde liveri ilin kiel aplikaĵajn argumentojn.
Ĉi tiuj du komandoj ne donas al la Ĝava lanĉilo la saman agordon. Uzu la gastiganton kaj pordon de via HTTP-prokseo; la listo de HTTP-prokseoj proponas kandidatojn por permesitaj publikaj vojoj:
java -Dhttp.proxyHost=proxy.example.net -Dhttp.proxyPort=8080 -jar app.jar
java -jar app.jar -Dhttp.proxyHost=proxy.example.net -Dhttp.proxyPort=8080En la unua, la lanĉilo ricevas opciojn de sistempropraĵoj. En la dua, la ĵetonoj post app.jar fariĝas aplikaĵaj argumentoj. Se la aplikaĵo ne intence analizas ilin, ili ne agordas la prokseajn propraĵojn de la JVM.
La sama limo validas kiam oni nomas ĉefklason anstataŭ uzi -jar. Metu JVM-opciojn antaŭ la klasnomon kaj aplikaĵspecifajn argumentojn poste.
Ekzamenu la realan startkomandon generitan de IDE, servaĵa envolvilo aŭ lanĉa skripto. Ĝia kampo etikedita “program arguments” povas malsami de ĝia kampo por VM-opcioj.
Ĝusta meto nur provizas la propraĵon. La HTTP-kliento ankoraŭ devas uzi tiun Ĝavan retagordon. Por Apache HttpClient 5, ebligu al la kliento uzi sistempropraĵojn. Proksea aŭtentigo bezonas sian propran subtenatan interfacon.