Configuration

Cette rubrique présente des détails sur la compatibilité, les configurations avancées et les modules complémentaires pour la trousse SDK Oracle Cloud Infrastructure pour Java.

Cette rubrique présente des détails sur la compatibilité, les configurations avancées et les modules complémentaires pour la trousse SDK Oracle Cloud Infrastructure pour Java.

Autorisations du gestionnaire de sécurité

Si votre application doit être exécutée dans le gestionnaire de sécurité de Java, vous devez accorder des autorisations supplémentaires en mettant à jour un fichier de politique ou en indiquant un fichier supplémentaire ou différent au moment de l'exécution.

La trousse SDK nécessite les autorisations suivantes :

  • Requises par Jersey :

    
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.util.PropertyPermission "*", "read,write";
    permission java.lang.RuntimePermission "setFactory";
  • Requise par la trousse SDK pour remplacer les en-têtes réservés :

    permission java.util.PropertyPermission "sun.net.http.allowRestrictedHeaders", "write";
  • Requise par la trousse SDK pour ouvrir les connexions de connecteur logiciel :

    permission java.net.SocketPermission "*", "connect";

Pour inclure un autre fichier de politique, en plus du fichier de politique par défaut de l'environnement d'exécution Java, lancez la machine virtuelle Java avec :

java -Djava.security.manager -Djava.security.policy=</path/to/other_policy>

Pour remplacer le fichier de politique par défaut, lancez la machine virtuelle Java avec :

java -Djava.security.manager -Djava.security.policy==</path/to/other_policy>
Note

Utilisez un signe égal unique (=) lorsque vous fournissez un fichier de politique supplémentaire. Utilisez un signe égal double (==) uniquement si vous voulez remplacer le fichier de politique par défaut.

Durée de vie de machine virtuelle Java pour les consultations de nom DNS

La machine virtuelle Java (JVM) met en mémoire cache les réponses DNS à partir des consultations pendant un certain temps, appelé Durée de vie. Cela garantit un temps de réponse plus rapide pour le code qui nécessite une résolution fréquente des noms.

La JVM utilise la propriété networkaddress.cache.ttl pour spécifier la politique de mise en mémoire cache des consultations de nom DNS. La valeur est un nombre entier qui représente le nombre de secondes pour mettre en mémoire cache la consultation réussie. La valeur par défaut pour de nombreuses machines virtuelles Java, -1, indique que la consultation doit toujours être mise en mémoire cache.

Étant donné que les ressources dans Oracle Cloud Infrastructure utilisent des noms de DNS pouvant être modifiés, nous vous recommandons de remplacer la valeur de durée de vie par 60 secondes. Cela garantit que la nouvelle adresse IP de la ressource est retournée lors de la prochaine interrogation de DNS. Vous pouvez modifier cette valeur de façon globale ou précise pour votre application :

  • Pour définir la durée de vie globalement pour toutes les applications utilisant la JVM, ajoutez la valeur suivante dans le fichier $JAVA_HOME/jre/lib/security/java.security :

    networkaddress.cache.ttl=60
  • Pour définir la durée de vie uniquement pour votre application, définissez les éléments suivants dans le code d'initialisation de votre application :

    java.security.Security.setProperty("networkaddress.cache.ttl" , "60");

Utilisation du connecteur Jersey par défaut HttpUrlConnectorProvider

À partir de la version 2.0.0, la trousse SDK pour Java prend en charge l'utilisation du connecteur Jersey ApacheConnectorProvider au lieu du connecteur Jersey par défaut HttpUrlConnectorProvider pour permettre au client HTTP Apache d'effectuer des appels de service OCI.

Pour passer au connecteur Jersey par défaut au niveau du client

Au niveau du client, la trousse SDK offre le moyen suivant pour revenir à l'ancien connecteur Jersey par défaut :

ObjectStorageClient nonBufferingObjectStorageClient = ObjectStorageClient
        .builder()
        .clientConfigurator(builder -> {
            builder.property(JerseyClientProperties.USE_APACHE_CONNECTOR, false);
        })
        // ...
        .build(provider);
Note

Le remplacement de la propriété clientConfigurator du client rétablit les valeurs Jersey par défaut. Pour configurer clientConfigurator avec le connecteur Apache, utilisez additionalClientConfigurator ou additionalClientConfigurators.

Pour passer au connecteur Jersey par défaut au niveau global

Vous pouvez exclure les dépendances du client HTTP Apache ou utiliser une variable d'environnement. Exclusion des dépendances HttpClient

Si vous gérez vous-même les dépendances :

  • Supprimez les fichiers JAR org.apache.httpcomponents.httpclient et org.glassfish.jersey.connectors.jersey-apache-connector de la variable classpath.

Si vous utilisez Maven pour gérer vos dépendances :

  • Ajoutez des exclusions pour les dépendances org.apache.httpcomponents.httpclient et org.glassfish.jersey.connectors.jersey-apache-connector .
    • Pour ajouter une exclusion si vous utilisez Jersey 2 :

      <dependencies>
          ...
          <dependency>
              <groupId>com.oracle.oci.sdk</groupId>
              <artifactId>oci-java-sdk-common-httpclient-jersey</artifactId>
              <version>...</version>
              <exclusions>
                  <exclusion>
                      <groupId>org.glassfish.jersey.connectors</groupId>
                      <artifactId>jersey-apache-connector</artifactId>
                  </exclusion>
                  <exclusion>
                      <groupId>org.apache.httpcomponents</groupId>
                      <artifactId>httpclient</artifactId>
                  </exclusion>
              </exclusions>
          </dependency>
          ...
      <dependencies> 
    • Pour ajouter une exclusion si vous utilisez Jersey 3 :

      <dependencies>
          ...
          <dependency>
              <groupId>com.oracle.oci.sdk</groupId>
              <artifactId>oci-java-sdk-common-httpclient-jersey3</artifactId>
              <version>...</version>
              <exclusions>
                  <exclusion>
                      <groupId>org.glassfish.jersey.connectors</groupId>
                      <artifactId>jersey-apache-connector</artifactId>
                  </exclusion>
                  <exclusion>
                      <groupId>org.apache.httpcomponents</groupId>
                      <artifactId>httpclient</artifactId>
                  </exclusion>
              </exclusions>
          </dependency>
          ...
      <dependencies>
Revenir en arrière à l'aide d'une variable d'environnement

La trousse SDK pour Java fournit une variable d'environnement permettant de revenir à l'ancien connecteur Jersey par défaut au niveau global. Réglez la valeur de la variable d'environnement OCI_JAVASDK_JERSEY_CLIENT_DEFAULT_CONNECTOR_ENABLED à true. Par défaut, cette valeur est réglée à false.

Désactivation de la fermeture automatique des flux

Pour les appels d'API qui retournent une réponse binaire/un flux, la trousse SDK ferme automatiquement le flux une fois celui-ci entièrement lu. En effet, la trousse SDK pour Java prend en charge le connecteur Apache pour l'envoi des demandes et la gestion des connexions au service. Par défaut, le connecteur Apache prend en charge les réserves de connexions. Si le flux de la réponse n'est pas fermé, les connexions ne sont pas libérées de la réserve.

Pour désactiver le comportement de fermeture automatique, appelez ResponseHelper.shouldAutoCloseResponseInputStream(false).

Choix de la stratégie de fermeture de connexion du connecteur Apache pour optimiser la performance

Le connecteur Apache prend en charge deux stratégies de fermeture de connexion : ApacheConnectionClosingStrategy.GracefulClosingStrategy et ApacheConnectionClosingStrategy.ImmediateClosingStrategy.

Lorsque vous utilisez ApacheConnectionClosingStrategy.GracefulClosingStrategy, les flux retournés à partir d'une réponse sont lus jusqu'à la fin du flux lors de la fermeture de celui-ci. Cela peut entraîner un délai supplémentaire lors de la fermeture du flux avec une lecture partielle, selon la taille du flux restant. Pour éviter ce délai, envisagez d'utiliser ApacheConnectionClosingStrategy.ImmediateClosingStrategy pour les fichiers volumineux avec des lectures partielles. Notez que ApacheConnectionClosingStrategy.ImmediateClosingStrategy prend plus de temps lors de l'utilisation de la lecture partielle pour les flux dont la taille est inférieure à 1 Mo.

Note

Si ces stratégies de fermeture de connexion Apache ne donnent pas des résultats optimaux pour vos cas d'utilisation, vous pouvez revenir au connecteur Jersey par défaut HttpUrlConnectorProvider à l'aide de la méthode indiquée ci-dessus.

Pour plus d'informations, voir : https://github.com/oracle/oci-java-sdk/blob/master/ApacheConnector-README.md.

Utilisation de BC-FIPS au lieu de Bouncy Castle

Si vous avez besoin d'une conformité FIPS, vous devez télécharger et utiliser une version certifiée FIPS. La trousse SDK prend en charge bc-fips 1.0.2 et bcpkix-fips 1.0.3. Vous pouvez les télécharger à l'adresse : https://www.bouncycastle.org/fips-java/

Pour obtenir de l'aide pour installer et configurer Bouncy Castle FIPS, voir "Documentation sur BC FIPS" dans les Guides d'utilisateur et la politique de sécurité de la documentation sur Bouncy Castle.

Dépendances autogérées

Si vous gérez vous-même les dépendances :

  1. Supprimez les fichiers jar Bouncy Castle non FIPS du chemin de classe :
    1. bcprov-jdk15on-1.60.jar
    2. bcpkix-jdk15on-1.60.jar
  2. Ajoutez plutôt les fichiers jar Bouncy Castle FIPS au chemin de classe :
    1. bc-fips-1.0.2.jar
    2. bcpkix-fips-1.0.3.jar

Dépendances gérées par Maven

Si vous utilisez Maven pour gérer vos dépendances :

  1. Ajoutez les versions correctes de bc-fips et bcpkix-fips à vos dépendances :
    <dependencies>
      . . .
      <dependency>
        <groupId>bc-fips</groupId>
        <artifactId>bc-fips</artifactId>
        <version>1.0.2</version>
      </dependency>
      <dependency>
        <groupId>bcpkix-fips</groupId>
        <artifactId>bcpkix-fips</artifactId>
        <version>1.0.3</version>
      </dependency>
      . . .
    </dependencies>
  2. Étant donné que vous dépendez d'un ensemble oci-java-sdk*, vous devez supprimer les dépendances Bouncy Castle non FIPS :
    <dependencies>
      . . .
      <dependency>
        <groupId>com.oracle.oci.sdk</groupId>
        <artifactId>oci-java-sdk-common</artifactId>
        <version> . . . </version>
        <exclusions>
          <exclusion>
            <groupId>org.bouncycastle</groupId>
            <artifactId>bcprov-jdk15on</artifactId>
          </exclusion>
          <exclusion>
            <groupId>org.bouncycastle</groupId>
            <artifactId>bcpkix-jdk15on</artifactId>
          </exclusion>
        </exclusions>
      </dependency>
      . . .
    </dependencies>

Utilisation de votre propre mise en oeuvre JAX-RS

La trousse SDK pour Java est groupée avec Jersey, mais vous pouvez également utiliser votre propre mise en oeuvre JAX-RS.

Module complémentaire RESTEasy Client Configurator

La valeur oci-java-sdk-addons-resteasy-client-configurator est fournie pour montrer comment configurer une mise en oeuvre JAX-RS de remplacement. Le module complémentaire est disponible dans le répertoire bmc-addons de la trousse SDK.

Pour plus de détails sur l'installation et la configuration, consultez le fichier Lisez-moi du module complémentaire.

Pour des exemples de code expliquant comment configurer le client, voir :

Utilisation de SLF4J pour la journalisation

La connexion à la trousse SDK s'effectue au moyen de SLF4J. SLF4J est une abstraction de journalisation qui permet l'utilisation d'une bibliothèque de journalisation fournie par l'utilisateur (par exemple, log4j). Pour plus d'informations, voir le manuel SLF4J.

Voici un exemple qui permet une journalisation de base. D'autres options de journalisation avancées peuvent être configurées à l'aide de la liaison log4j.

  1. Téléchargez le fichier JAR de liaison simple SLF4J : SLF4J Simple Binding
  2. Ajoutez le fichier JAR à la variable classpath (par exemple, ajoutez-le au répertoire /third-party/lib du téléchargement de la trousse SDK)
  3. Ajoutez l'argument de machine virtuelle suivant pour permettre la journalisation du niveau de débogage (par défaut, le niveau d'information est utilisé) : -Dorg.slf4j.simpleLogger.defaultLogLevel=debug