תנו למופע האפליקציה של GlassFish את ה-proxy היוצא שלו

בחרו את יעד GlassFish שמריץ את האפליקציה לפני יצירת אפשרויות proxy. create-jvm-options מכוון כברירת מחדל לשרת ניהול התחום; הוא מקבל גם מופע, אשכול או תצורה בעלת שם. לכן ברירת המחדל עלולה לשנות את ה-JVM הלא נכון.

עבור תצורה בעלת שם להמחשה app-config:

asadmin create-jvm-options --target app-config "-Dhttp.proxyHost=proxy.example:-Dhttp.proxyPort=8080:-Dhttps.proxyHost=proxy.example:-Dhttps.proxyPort=8080"

החליפו את היעד ואת נקודת הקצה; רשימת ה-proxy של HTTP מספקת מועמדים ל-HTTP עבור בקשות מורשות ליעדים ציבוריים. הארגומנט המופרד בנקודתיים מכיל ארבע אפשרויות. ערכי מארח הם שמות מארח ללא קידומות URL. מאפייני HTTP/HTTPS הנפרדים של Java מתארים פרוטוקולי יעד; יעד HTTPS עדיין יכול להשתמש ב-proxy רגיל של HTTP CONNECT.

בדקו את הערכים השמורים עם list-jvm-options עבור אותו יעד. עיינו תחילה ברשומות קיימות: create אינו יוצר מחדש אפשרות זהה, ולכן פקודה מוצלחת אינה פותרת בעצמה ערכים סותרים.

לאחר מכן בדקו את המאפיינים האפקטיביים של המופע הפועל ואת לקוח ה-HTTP בפועל. GlassFish מבדיל בין אפשרויות הדורשות הפעלה מחדש לבין מאפייני מערכת שהוא יכול לעדכן מיד. עקבו אחר הגרסה שנפרסה ולא אחר מתכון הפעלה מחדש בלתי מותנה; לקוח קיים עשוי לשמור על המסלול שלו.

שיטה זו חלה על לקוחות שמכבדים את מאפייני הרשת של JVM. proxy מפורש של ספרייה או תעבורה נפרדת זקוק להגדרה הנתמכת שלו, בעוד שמאזינים נכנסים אינם קשורים. שמרו יעדים ישירים נדרשים במדיניות העקיפה של Java. הוספת מאפייני JVM שרירותיים של שם משתמש/סיסמה אינה מספקת אימות proxy לכל לקוח.