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