אותו מאגר עובד עם git clone במסוף ונכשל באפליקציה שמשתמשת ב-JGit. זו השוואה בין שני מימושים, לא בהכרח בין עותק עובד לעותק שבור של אותו לקוח.

תיעוד התצורה של JGit אומר שתצורת ה-proxy משתמשת במנגנונים הסטנדרטיים של Java דרך java.net.ProxySelector. אל תניחו שכל אפשרות HTTP של Git מקורי ממומשת רק מפני ששני הלקוחות מבינים קובץ תצורה של Git.

זהו את האפליקציה שמטמיעה את JGit, את הגרסה שלה ואת תעבורת ה-HTTP שנבחרה. אפליקציית המארח יכולה לספק הגדרות או התנהגות מעבר לברירות המחדל העצמאיות של JGit.

לאחר מכן בדקו את תצורת ה-proxy של Java הנראית לתהליך הזה. בתעבורת HTTP מבוססת URLConnection, בדקו את מאפייני המארח והפורט של ה-JVM שהיא צורכת. מאפיין שהוזן במסוף לא קשור לאחר שהאפליקציה עלתה אינו יכול להגדיר מחדש את ה-JVM הפועל. גם פעולת Git מקורית ב-IDE ופעולת ה-JGit שלה יכולות להשתמש בנתיבים שונים.

הפרידו בין אימות ה-proxy לבין בחירת המסלול. מאפייני proxy של Java שמזהים מארח ופורט אינם מיישמים אוטומטית סכימת סיסמה ל-proxy. השתמשו במנגנון האימות הנתמך של אפליקציית המארח.

השאלה המועילה היא ״איזה proxy בחרה בקשת ה-JGit הזו?״ ולא ״האם תצורת ה-Git שלי מכילה שורת proxy?״. הצלחה עם Git מקורי היא השוואה ערכית, אך היא אינה עונה על השאלה הזו הספציפית למימוש.

מאמרים קשורים