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 прокси; оставете ги поставките за складирање и идентитет.