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-проксі; налаштування сховища та ідентичності залиште на місці.

Схожі статті