Azure Data Lake Java: Keep Derived Clients on the Proxy Pipeline

The final line matters: derive the filesystem client from the configured service, rather than starting another default 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) carries the parent's HTTP pipeline, account endpoint and applicable storage configuration into the child.

The example supplies the same http to the credential builder because token acquisition is another request path. A separately constructed filesystem client must receive its intended transport too; no earlier builder creates a global SDK default.

Use the application's account URL, filesystem name and identity values. ProxyOptions and Netty transport types come from Azure Core, the credential builder from Azure Identity, and the service builder from Azure Storage Data Lake; InetSocketAddress is from java.net.

accountUrl stays the storage endpoint, and the filesystem name selects the child. Neither is the proxy address. With a publicly reachable storage endpoint and permission to use a public intermediary, choose the ProxyOptions host and port from the HTTP proxy list; keep the storage and identity settings in place.