Azure Data Lake Java: hold afledte klienter på proxy-pipelinen

Den sidste linje er vigtig: udled filsystemklienten fra den konfigurerede tjeneste i stedet for at starte endnu en standard-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) fører forælderens HTTP-pipeline, kontoens slutpunkt og den relevante lagerkonfiguration videre til barnet.

Eksemplet giver den samme http til legitimationsbuilder'en, fordi hentning af token er en anden anmodningsvej. En filsystemklient, der bygges separat, skal også have sin tilsigtede transport; ingen tidligere builder opretter en global SDK-standard.

Brug applikationens konto-URL, filsystemnavn og identitetsværdier. ProxyOptions og Netty-transporttyper kommer fra Azure Core, legitimationsbuilder'en fra Azure Identity og tjenestebuilder'en fra Azure Storage Data Lake; InetSocketAddress kommer fra java.net.

accountUrl forbliver lagerets slutpunkt, og filsystemnavnet vælger barnet. Ingen af dem er proxyadressen. Med et offentligt tilgængeligt lagerslutpunkt og tilladelse til at bruge en offentlig mellemmand vælges ProxyOptions-vært og -port fra HTTP-proxylisten; behold lager- og identitetsindstillingerne.