Azure Data Lake Java: mantén os clientes derivados na canalización do proxy

A última liña importa: deriva o cliente do sistema de ficheiros desde o servizo configurado, en vez de iniciar outro builder predeterminado:

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) leva ao fillo a canalización HTTP do pai, o punto de conexión da conta e a configuración de almacenamento aplicable.

O exemplo fornece o mesmo http ao builder de credenciais porque a obtención do token é outra ruta de solicitude. Un cliente do sistema de ficheiros construído por separado tamén debe recibir o transporte previsto; ningún builder anterior crea un valor predeterminado global do SDK.

Usa o URL da conta, o nome do sistema de ficheiros e os valores de identidade da aplicación. ProxyOptions e os tipos de transporte Netty veñen de Azure Core, o builder de credenciais de Azure Identity e o builder do servizo de Azure Storage Data Lake; InetSocketAddress vén de java.net.

accountUrl segue a ser o punto de conexión de almacenamento, e o nome do sistema de ficheiros selecciona o fillo. Ningún dos dous é o enderezo do proxy. Cun punto de conexión de almacenamento accesible publicamente e permiso para usar un intermediario público, escolle o host e o porto de ProxyOptions da lista de proxies HTTP; mantén a configuración de almacenamento e identidade.