Azure Data Lake Java: hald avleidde klientar på proxy-pipelinen

Den siste linja er viktig: lei filsystemklienten ut frå den konfigurerte tenesta i staden for å starte ein ny 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 HTTP-pipelinen til forelderen, endepunktet til kontoen og gjeldande lagringskonfigurasjon vidare til barnet.

Dømet gjev den same http til legitimasjonsbyggjaren fordi henting av token er ein annan førespurnadsveg. Ein filsystemklient som blir bygd separat, må òg få den tiltenkte transporten; ingen tidlegare byggjar opprettar ein global SDK-standard.

Bruk konto-URL-en, filsystemnamnet og identitetsverdiane til applikasjonen. ProxyOptions og Netty-transporttypane kjem frå Azure Core, legitimasjonsbyggjaren frå Azure Identity og tenestebyggjaren frå Azure Storage Data Lake; InetSocketAddress kjem frå java.net.

accountUrl blir verande lagringsendepunktet, og filsystemnamnet vel barnet. Ingen av dei er proxyadressa. Med eit offentleg tilgjengeleg lagringsendepunkt og løyve til å bruke ein offentleg mellommann, vel ProxyOptions vert og port frå HTTP-proxylista; lat lagrings- og identitetsinnstillingane stå.