Azure Data Lake Java: mantén los clientes derivados en la canalización del proxy

La última línea importa: deriva el cliente del sistema de archivos desde el servicio configurado, en lugar de iniciar otro 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) traslada al hijo la canalización HTTP del padre, el punto de conexión de la cuenta y la configuración de almacenamiento aplicable.

El ejemplo entrega el mismo http al builder de credenciales porque la obtención del token es otra ruta de solicitud. Un cliente del sistema de archivos construido por separado también debe recibir su transporte previsto; ningún builder anterior crea un valor predeterminado global del SDK.

Utiliza la URL de la cuenta, el nombre del sistema de archivos y los valores de identidad de la aplicación. ProxyOptions y los tipos de transporte de Netty proceden de Azure Core, el builder de credenciales de Azure Identity y el builder del servicio de Azure Storage Data Lake; InetSocketAddress procede de java.net.

accountUrl sigue siendo el punto de conexión de almacenamiento y el nombre del sistema de archivos selecciona al hijo. Ninguno de los dos es la dirección del proxy. Con un punto de conexión de almacenamiento accesible públicamente y permiso para usar un intermediario público, elige el host y el puerto de ProxyOptions de la lista de proxies HTTP; mantén la configuración de almacenamiento e identidad.