Azure Data Lake Java: mantieni i client derivati sulla pipeline del proxy

L'ultima riga conta: deriva il client del file system dal servizio configurato, invece di avviare un altro builder predefinito:

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) trasporta nel figlio la pipeline HTTP del padre, l'endpoint dell'account e la configurazione di archiviazione applicabile.

L'esempio fornisce lo stesso http al builder delle credenziali perché l'ottenimento del token è un altro percorso di richiesta. Un client del file system costruito separatamente deve ricevere anch'esso il trasporto previsto; nessun builder precedente crea un valore predefinito globale dell'SDK.

Usa l'URL dell'account, il nome del file system e i valori di identità dell'applicazione. ProxyOptions e i tipi di trasporto Netty provengono da Azure Core, il builder delle credenziali da Azure Identity e il builder del servizio da Azure Storage Data Lake; InetSocketAddress proviene da java.net.

accountUrl resta l'endpoint di archiviazione e il nome del file system seleziona il figlio. Nessuno dei due è l'indirizzo del proxy. Con un endpoint di archiviazione raggiungibile pubblicamente e l'autorizzazione a usare un intermediario pubblico, scegli host e porta di ProxyOptions dal elenco dei proxy HTTP; mantieni le impostazioni di archiviazione e identità.