Azure Data Lake Java : garder les clients dérivés sur le pipeline du proxy

La dernière ligne compte : dérivez le client du système de fichiers à partir du service configuré, au lieu de lancer un autre builder par défaut :

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) transmet au client enfant le pipeline HTTP du parent, le point de terminaison du compte et la configuration de stockage applicable.

L'exemple fournit le même http au builder d'informations d'identification, car l'obtention du jeton est un autre chemin de requête. Un client de système de fichiers construit séparément doit aussi recevoir son transport prévu ; aucun builder antérieur ne crée de valeur par défaut globale du SDK.

Utilisez l'URL du compte, le nom du système de fichiers et les valeurs d'identité de votre application. ProxyOptions et les types de transport Netty proviennent d'Azure Core, le builder d'informations d'identification d'Azure Identity et le builder de service d'Azure Storage Data Lake ; InetSocketAddress provient de java.net.

accountUrl reste le point de terminaison de stockage, et le nom du système de fichiers sélectionne l'enfant. Ni l'un ni l'autre n'est l'adresse du proxy. Avec un point de terminaison de stockage accessible publiquement et l'autorisation d'utiliser un intermédiaire public, choisissez l'hôte et le port de ProxyOptions dans la liste de proxies HTTP ; conservez les paramètres de stockage et d'identité.