Azure Data Lake Java: panatilihin ang mga hinangong kliyente sa pipeline ng proxy
Kunin ang kliyente ng filesystem mula sa DataLakeServiceClient na na-configure sa proxy, at i-configure ang transport ng identity token sa parehong setup.
Mahalaga ang huling linya: kunin ang kliyente ng filesystem mula sa naka-configure na serbisyo sa halip na magsimula ng isa pang default na 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) dinadala sa anak ang HTTP pipeline ng magulang, ang endpoint ng account at ang naaangkop na configuration ng storage.
Ibinibigay ng halimbawa ang parehong http sa builder ng kredensyal dahil ang pagkuha ng token ay isa pang landas ng kahilingan. Ang hiwalay na itinayong kliyente ng filesystem ay dapat ding tumanggap ng nilalayong transport; walang naunang builder na gumagawa ng pandaigdigang default ng SDK.
Gamitin ang URL ng account, pangalan ng filesystem at mga halaga ng identity ng iyong application. Ang ProxyOptions at mga uri ng transport ng Netty ay nagmumula sa Azure Core, ang builder ng kredensyal sa Azure Identity, at ang builder ng serbisyo sa Azure Storage Data Lake; ang InetSocketAddress ay nagmumula sa java.net.
Ang accountUrl ay nananatiling endpoint ng storage, at pinipili ng pangalan ng filesystem ang anak. Wala sa dalawa ang address ng proxy. Sa isang endpoint ng storage na naa-access ng publiko at pahintulot na gumamit ng pampublikong tagapamagitan, piliin ang host at port ng ProxyOptions mula sa listahan ng HTTP proxy; iwanan ang mga setting ng storage at identity.