Azure Data Lake Java: کلاینتهای مشتقشده را روی خط لوله پراکسی نگه دارید
کلاینت فایلسیستم را از DataLakeServiceClient پیکربندیشده با پراکسی مشتق کنید و انتقال توکن هویت را در همان تنظیمات پیکربندی کنید.
خط آخر مهم است: کلاینت فایلسیستم را از سرویس پیکربندیشده مشتق کنید، نه اینکه یک 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 همان نقطه پایانی ذخیرهسازی میماند و نام فایلسیستم فرزند را انتخاب میکند. هیچکدام نشانی پراکسی نیستند. با نقطه پایانی ذخیرهسازی قابل دسترسی عمومی و اجازه استفاده از واسطه عمومی، میزبان و پورت ProxyOptions را از فهرست پراکسی HTTP انتخاب کنید؛ تنظیمات ذخیرهسازی و هویت را سر جای خود نگه دارید.