Azure Data Lake Java: השארו לקוחות נגזרים בצינור ה-proxy

השורה האחרונה חשובה: גזרו את לקוח מערכת הקבצים מהשירות המוגדר במקום להתחיל builder ברירת מחדל נוסף:

var proxy = new ProxyOptions(
    ProxyOptions.Type.HTTP,
    new InetSocketAddress("proxy.example.net", 8080));

var http = new NettyAsyncHttpClientBuilder()
    .proxy(proxy)
    .build();

var credential = new ClientSecretCredentialBuilder()
    .tenantId(tenantId)
    .clientId(clientId)
    .clientSecret(clientSecret)
    .httpClient(http)
    .build();

var service = new DataLakeServiceClientBuilder()
    .endpoint(accountUrl)
    .credential(credential)
    .httpClient(http)
    .buildClient();

var filesystem = service.getFileSystemClient(fileSystemName);

service.getFileSystemClient(fileSystemName) מעביר לילד את צינור ה-HTTP של האב, את נקודת הקצה של החשבון ואת תצורת האחסון הרלוונטית.

הדוגמה מספקת את אותו http ל-builder של פרטי הזיהוי מפני שקבלת אסימון היא נתיב בקשה נוסף. לקוח מערכת קבצים שנבנה בנפרד חייב לקבל גם הוא את התעבורה המיועדת לו; אף builder קודם אינו יוצר ברירת מחדל גלובלית של ה-SDK.

השתמשו בכתובת ה-URL של החשבון, בשם מערכת הקבצים ובערכי הזהות של היישום. ProxyOptions וסוגי התעבורה של Netty מגיעים מ-Azure Core, ה-builder של פרטי הזיהוי מ-Azure Identity, וה-builder של השירות מ-Azure Storage Data Lake; InetSocketAddress מגיע מ-java.net.

accountUrl נשאר נקודת הקצה של האחסון, ושם מערכת הקבצים בוחר את הילד. אף אחד מהם אינו כתובת ה-proxy. עם נקודת קצה של אחסון נגישה לציבור והרשאה להשתמש במתווך ציבורי, בחרו את המארח והפורט של ProxyOptions מתוך רשימת ה-proxy של HTTP; השאירו את הגדרות האחסון והזהות במקומן.