ბოლო ხაზი მნიშვნელოვანია: მიიღეთ ფაილური სისტემის კლიენტი კონფიგურირებული სერვისიდან და არ დაიწყოთ კიდევ ერთი ნაგულისხმევი 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 პროქსების სიიდან; საცავისა და იდენტობის პარამეტრები ადგილზე დატოვეთ.

დაკავშირებული სტატიები