Azure Data Lake Java: mbani klientët e derivuar në tubacionin e proxy

Rreshti i fundit ka rëndësi: derivoni klientin e sistemit të skedarëve nga shërbimi i konfiguruar në vend që të nisni një builder tjetër të parazgjedhur:

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) transferon te fëmija tubacionin HTTP të prindit, pikën fundore të llogarisë dhe konfigurimin e zbatueshëm të ruajtjes.

Shembulli i jep të njëjtin http builderit të kredencialeve, sepse marrja e tokenit është një rrugë tjetër kërkese. Një klient sistemi skedarësh i ndërtuar veçmas duhet të marrë gjithashtu transportin e synuar; asnjë builder i mëparshëm nuk krijon një parazgjedhje globale të SDK-së.

Përdorni URL-në e llogarisë, emrin e sistemit të skedarëve dhe vlerat e identitetit të aplikacionit. ProxyOptions dhe llojet e transportit Netty vijnë nga Azure Core, builderi i kredencialeve nga Azure Identity dhe builderi i shërbimit nga Azure Storage Data Lake; InetSocketAddress vjen nga java.net.

accountUrl mbetet pika fundore e ruajtjes dhe emri i sistemit të skedarëve zgjedh fëmijën. Asnjëri prej tyre nuk është adresa e proxy-t. Me një pikë fundore ruajtjeje të aksesueshme publikisht dhe leje për të përdorur një ndërmjetës publik, zgjidhni hostin dhe portin e ProxyOptions nga lista e proxy-ve HTTP; lërini cilësimet e ruajtjes dhe identitetit në vend.