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

Den siste linjen er viktig: utled filsystemklienten fra den konfigurerte tjenesten i stedet for å starte nok 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 overordnets HTTP-pipeline, kontoens endepunkt og gjeldende lagringskonfigurasjon videre til barnet.

Eksempelet gir den samme http til legitimasjonsbyggeren fordi henting av token er en annen forespørselsvei. En filsystemklient som bygges separat, må også få den tiltenkte transporten; ingen tidligere bygger oppretter en global SDK-standard.

Bruk applikasjonens konto-URL, filsystemnavn og identitetsverdier. ProxyOptions og Netty-transporttypene kommer fra Azure Core, legitimasjonsbyggeren fra Azure Identity og tjenestebyggeren fra Azure Storage Data Lake; InetSocketAddress kommer fra java.net.

accountUrl forblir lagringsendepunktet, og filsystemnavnet velger barnet. Ingen av dem er proxyadressen. Med et offentlig tilgjengelig lagringsendepunkt og tillatelse til å bruke en offentlig mellommann, velg ProxyOptions vert og port fra HTTP-proxylisten; behold lagrings- og identitetsinnstillingene.