Azure Data Lake Java: păstrați clienții derivați pe pipeline-ul proxy

Ultima linie contează: derivați clientul sistemului de fișiere din serviciul configurat, în loc să porniți un alt builder implicit:

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) transportă în clientul copil pipeline-ul HTTP al părintelui, endpoint-ul contului și configurația de stocare aplicabilă.

Exemplul furnizează același http builder-ului de credențiale, deoarece obținerea tokenului este o altă cale de cerere. Un client de sistem de fișiere construit separat trebuie să primească și el transportul prevăzut; niciun builder anterior nu creează o valoare implicită globală a SDK-ului.

Folosiți URL-ul contului, numele sistemului de fișiere și valorile de identitate ale aplicației. ProxyOptions și tipurile de transport Netty provin din Azure Core, builder-ul de credențiale din Azure Identity, iar builder-ul serviciului din Azure Storage Data Lake; InetSocketAddress provine din java.net.

accountUrl rămâne endpoint-ul de stocare, iar numele sistemului de fișiere selectează clientul copil. Niciunul nu este adresa proxy. Cu un endpoint de stocare accesibil public și permisiunea de a folosi un intermediar public, alegeți gazda și portul ProxyOptions din lista de proxy HTTP; păstrați setările de stocare și identitate.