Azure Data Lake Java- တွင် ဆင်းသက်လာသော client များကို proxy လမ်းကြောင်းပေါ် ထားရှိပါ
Proxy ဖြင့် ပြင်ဆင်ထားသော DataLakeServiceClient မှ ဖိုင်စနစ် client ကို ဆင်းသက်ယူပြီး အထောက်အထား token ပို့ဆောင်မှုကို တူညီသော ဆက်တင်တွင် ပြင်ဆင်ပါ။
နောက်ဆုံးလိုင်းသည် အရေးကြီးသည်- အခြား default builder ကို စတင်မည့်အစား ပြင်ဆင်ထားသော service မှ ဖိုင်စနစ် client ကို ဆင်းသက်ယူပါ-
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 သို့ ပေးသည်၊ အကြောင်းမှာ token ရယူခြင်းသည် အခြား တောင်းဆိုမှုလမ်းကြောင်း ဖြစ်သောကြောင့်။ သီးခြား တည်ဆောက်ထားသော ဖိုင်စနစ် client သည်လည်း ၎င်း၏ ရည်ရွယ်ထားသော ပို့ဆောင်မှုကို ရရှိရမည်၊ မည်သည့် ယခင် builder မျှ ကမ္ဘာလုံးဆိုင်ရာ SDK default ကို မဖန်တီးပါ။
သင့် application ၏ အကောင့် URL၊ ဖိုင်စနစ်အမည်နှင့် အထောက်အထား တန်ဖိုးများကို အသုံးပြုပါ။ ProxyOptions နှင့် Netty ပို့ဆောင်မှု အမျိုးအစားများသည် Azure Core မှ၊ အထောက်အထား builder သည် Azure Identity မှ၊ service builder သည် Azure Storage Data Lake မှ လာပါသည်၊ InetSocketAddress သည် java.net မှ လာပါသည်။
accountUrl သည် သိုလှောင်မှု ဆုံးမှတ်အဖြစ် ဆက်ရှိပြီး ဖိုင်စနစ်အမည်က သားသမီးကို ရွေးချယ်သည်။ နှစ်ခုစလုံးသည် proxy လိပ်စာ မဟုတ်ပါ။ အများသူငှာ ဝင်ရောက်နိုင်သော သိုလှောင်မှု ဆုံးမှတ်နှင့် အများသူငှာ ကြားခံကို အသုံးပြုခွင့်ရှိပါက HTTP proxy စာရင်း မှ ProxyOptions host နှင့် port ကို ရွေးပါ၊ သိုလှောင်မှုနှင့် အထောက်အထား ဆက်တင်များကို မူလအတိုင်း ထားပါ။