Azure Data Lake Java: håll härledda klienter på proxy-pipelinen

Den sista raden är viktig: härled filsystemsklienten från den konfigurerade tjänsten i stället för att starta ännu en standardbuilder:

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) för över förälderns HTTP-pipeline, kontots slutpunkt och tillämplig lagringskonfiguration till barnet.

Exemplet ger samma http till autentiseringsbuilderaren eftersom hämtning av token är en annan begärandeväg. En filsystemsklient som byggs separat måste också få sin avsedda transport; ingen tidigare builder skapar en global SDK-standard.

Använd programmets konto-URL, filsystemsnamn och identitetsvärden. ProxyOptions och Netty-transporttyperna kommer från Azure Core, autentiseringsbuilderaren från Azure Identity och tjänstebuilderaren från Azure Storage Data Lake; InetSocketAddress kommer från java.net.

accountUrl förblir lagringens slutpunkt och filsystemsnamnet väljer barnet. Ingen av dem är proxyadressen. Med en offentligt nåbar lagringsslutpunkt och tillstånd att använda en offentlig mellanhand väljer du ProxyOptions värd och port från HTTP-proxylistan; behåll lagrings- och identitetsinställningarna.