Azure Data Lake Java: utrzymaj klienty pochodne w potoku proxy

Ostatni wiersz ma znaczenie: wyprowadź klienta systemu plików ze skonfigurowanej usługi, zamiast uruchamiać kolejny domyślny 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) przenosi do obiektu podrzędnego potok HTTP rodzica, punkt końcowy konta i obowiązującą konfigurację magazynu.

Przykład przekazuje ten sam http do buildera poświadczeń, ponieważ uzyskanie tokenu to kolejna ścieżka żądania. Osobno zbudowany klient systemu plików również musi otrzymać zamierzony transport; żaden wcześniejszy builder nie tworzy globalnej wartości domyślnej SDK.

Użyj adresu URL konta, nazwy systemu plików i wartości tożsamości aplikacji. ProxyOptions i typy transportu Netty pochodzą z Azure Core, builder poświadczeń z Azure Identity, a builder usługi z Azure Storage Data Lake; InetSocketAddress pochodzi z java.net.

accountUrl pozostaje punktem końcowym magazynu, a nazwa systemu plików wybiera obiekt podrzędny. Żadne z nich nie jest adresem proxy. Przy publicznie dostępnym punkcie końcowym magazynu i pozwoleniu na korzystanie z publicznego pośrednika wybierz hosta i port ProxyOptions z listy proxy HTTP; pozostaw ustawienia magazynu i tożsamości.