Azure Data Lake Java: houd afgeleide clients op de proxypijplijn

De laatste regel is belangrijk: leid de bestandssysteemclient af van de geconfigureerde service in plaats van nog een standaard-builder te starten:

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) draagt de HTTP-pijplijn van de ouder, het accounteindpunt en de toepasselijke opslagconfiguratie over aan het kind.

Het voorbeeld geeft dezelfde http aan de aanmeldingsgegevens-builder, omdat het ophalen van een token een ander aanvraagpad is. Een apart gebouwde bestandssysteemclient moet ook zijn bedoelde transport krijgen; geen enkele eerdere builder maakt een globale SDK-standaard.

Gebruik de account-URL, de bestandssysteemnaam en de identiteitswaarden van de toepassing. ProxyOptions en de Netty-transporttypen komen uit Azure Core, de aanmeldingsgegevens-builder uit Azure Identity en de service-builder uit Azure Storage Data Lake; InetSocketAddress komt uit java.net.

accountUrl blijft het opslageindpunt en de bestandssysteemnaam kiest het kind. Geen van beide is het proxyadres. Met een openbaar bereikbaar opslageindpunt en toestemming om een openbare tussenpersoon te gebruiken, kiest u de host en poort van ProxyOptions uit de HTTP-proxylijst; laat de opslag- en identiteitsinstellingen staan.