Azure Data Lake Java: tartsuk a származtatott klienseket a proxy-folyamatban

Az utolsó sor fontos: a fájlrendszer-klienst a konfigurált szolgáltatásból származtassa, ne indítson újabb alapértelmezett buildert:

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) átviszi a gyermekbe a szülő HTTP-folyamatát, a fiók végpontját és az alkalmazandó tárkonfigurációt.

A példa ugyanazt a http-t adja a hitelesítőadat-buildernek, mert a token beszerzése egy másik kérési útvonal. A külön felépített fájlrendszer-kliensnek is meg kell kapnia a szánt átvitelt; egyetlen korábbi builder sem hoz létre globális SDK-alapértelmezést.

Használja az alkalmazás fiók-URL-jét, a fájlrendszer nevét és az identitásértékeket. A ProxyOptions és a Netty átviteltípusok az Azure Core-ból, a hitelesítőadat-builder az Azure Identityból, a szolgáltatásbuilder pedig az Azure Storage Data Lake-ből származik; a InetSocketAddress a java.net-ból származik.

A accountUrl a tár végpontja marad, a fájlrendszer neve pedig a gyermeket választja ki. Egyik sem a proxy címe. Nyilvánosan elérhető tárvégpont és nyilvános közvetítő használatára vonatkozó engedély esetén a ProxyOptions gazdagépét és portját az HTTP-proxylistáról válassza; a tár- és identitásbeállításokat hagyja a helyén.