Azure Data Lake Java: задръжте производните клиенти в прокси конвейера

Последният ред е важен: извличайте клиента за файловата система от конфигурираната услуга, вместо да стартирате още един 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 прокси; запазете настройките за съхранение и идентичност.