Azure Data Lake Java: трымайце вытворныя кліенты на праксі-канвееры

Апошні радок важны: атрымлівайце кліент файлавай сістэмы з наладжанай службы, а не запускайце чарговы 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) перадае бацькоўскі HTTP-канвеер, канчатковы пункт уліковага запісу і адпаведную канфігурацыю сховішча даччынаму кліенту.

Прыклад перадае той жа http у builder уліковых даных, бо атрыманне токена — гэта яшчэ адзін шлях запыту. Асобна створаны кліент файлавай сістэмы таксама павінен атрымаць сваю прызначаную транспартную частку; ніводзін папярэдні builder не стварае глабальнай прадвызначанай налады SDK.

Выкарыстоўвайце URL уліковага запісу, назву файлавай сістэмы і значэнні ідэнтычнасці з вашага праграмнага забеспячэння. ProxyOptions і тыпы транспарту Netty паходзяць з Azure Core, builder уліковых даных — з Azure Identity, а builder службы — з Azure Storage Data Lake; InetSocketAddress — з java.net.

accountUrl застаецца канчатковым пунктам сховішча, а назва файлавай сістэмы выбірае даччыны кліент. Ні адно з іх не з'яўляецца адрасам праксі. Калі канчатковы пункт сховішча публічна даступны і ёсць дазвол на выкарыстанне публічнага пасярэдніка, выбераце хост і порт ProxyOptions з спісу HTTP-праксі; пакіньце налады сховішча і ідэнтычнасці без змен.