Azure Data Lake Java: abgeleitete Clients in der Proxy-Pipeline halten

Die letzte Zeile ist entscheidend: Leiten Sie den Dateisystem-Client vom konfigurierten Dienst ab, statt einen weiteren Standard-Builder zu 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) überträgt die HTTP-Pipeline des übergeordneten Objekts, den Kontoendpunkt und die geltende Speicherkonfiguration auf das untergeordnete Objekt.

Das Beispiel übergibt denselben http an den Anmeldeinformations-Builder, weil der Tokenabruf ein weiterer Anforderungspfad ist. Ein separat erstellter Dateisystem-Client muss ebenfalls seinen vorgesehenen Transport erhalten; kein früherer Builder erzeugt einen globalen SDK-Standard.

Verwenden Sie die Konto-URL, den Dateisystemnamen und die Identitätswerte Ihrer Anwendung. ProxyOptions und die Netty-Transporttypen stammen aus Azure Core, der Anmeldeinformations-Builder aus Azure Identity und der Dienst-Builder aus Azure Storage Data Lake; InetSocketAddress stammt aus java.net.

accountUrl bleibt der Speicherendpunkt, und der Dateisystemname wählt das untergeordnete Objekt. Keines von beiden ist die Proxyadresse. Bei einem öffentlich erreichbaren Speicherendpunkt und der Berechtigung, einen öffentlichen Vermittler zu nutzen, wählen Sie Host und Port von ProxyOptions aus der HTTP-Proxy-Liste; die Speicher- und Identitätseinstellungen bleiben bestehen.