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