Configuration

Cette rubrique fournit des détails sur la compatibilité, les configurations avancées et les extensions relatives au kit SDK Oracle Cloud Infrastructure pour Java.

Cette rubrique fournit des détails sur la compatibilité, les configurations avancées et les extensions relatives au kit SDK Oracle Cloud Infrastructure pour Java.

Droits d'accès du gestionnaire de sécurité

Si votre application doit être exécutée dans le gestionnaire de sécurité Java, vous devez accorder des droits d'accès supplémentaires en mettant à jour un fichier de stratégie, ou en indiquant un fichier de stratégie supplémentaire ou différent lors de l'exécution.

Le kit SDK exige les droits d'accès suivants :

  • Requis 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";
  • Requis par le kit SDK pour écraser les en-têtes réservés :

    permission java.util.PropertyPermission "sun.net.http.allowRestrictedHeaders", "write";
  • Requis par le kit SDK pour ouvrir les connexions de socket :

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

Pour inclure un autre fichier de stratégie, en plus du fichier de stratégie par défaut de l'environnement JRE, lancez la Java Virtual Machine avec ce qui suit :

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

Pour remplacer le fichier de stratégie par défaut, lancez la Java Virtual Machine avec ce qui suit :

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

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

Durée de vie de la Java Virtual Machine pour les recherches de noms DNS

La JVM (Java Virtual Machine) met en mémoire cache les réponses DNS des recherches pendant une durée définie, appelée durée de vie. Cela permet de garantir un temps de réponse plus rapide dans le code nécessitant une résolution fréquente des noms.

La JVM utilise la propriété networkaddress.cache.ttl pour définir la stratégie de mise en mémoire cache des recherches de noms DNS. La valeur est un entier qui représente le nombre de secondes nécessaires à la mise en mémoire cache de la recherche effectuée. La valeur par défaut pour de nombreuses JVM, -1, indique que la recherche doit être mise en mémoire cache de manière permanente.

Dans la mesure où les ressources dans Oracle Cloud Infrastructure utilisent des noms DNS qui peuvent changer, nous vous recommandons de définir la valeur de la durée de vie sur 60 secondes. Cela garantit que la nouvelle adresse IP pour la ressource soit renvoyée lors de la prochaine requête DNS. Vous pouvez modifier cette valeur de manière globale ou spécifiquement pour votre application :

  • Afin de définir la durée de vie de manière globale pour toutes les applications utilisant la JVM, ajoutez ce qui suit au fichier $JAVA_HOME/jre/lib/security/java.security :

    networkaddress.cache.ttl=60
  • Afin de définir la durée de vie uniquement pour votre application, définissez ce qui suit dans le code d'initialisation de votre application :

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

Utilisation du connecteur par défaut Jersey HttpUrlConnectorProvider

A partir de la version 2.0.0, le kit 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 Apache HttpClient d'effectuer des appels de service OCI.

Procédure de passage au connecteur par défaut Jersey au niveau du client

Au niveau du client, le kit SDK permet de rétablir l'ancien connecteur Jersey par défaut :

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

Le remplacement de la propriété clientConfigurator du client rétablit les valeurs par défaut Jersey. Pour configurer clientConfigurator avec l'utilisation d'Apache Connector, employez additionalClientConfigurator ou additionalClientConfigurators.

Procédure de passage au connecteur par défaut Jersey au niveau global

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

Si vous gérez vous-même les dépendances, procédez comme suit :

  • Enlevez les fichiers JAR org.apache.httpcomponents.httpclient et org.glassfish.jersey.connectors.jersey-apache-connector de la variable d'environnement CLASSPATH.

Si vous utilisez Maven pour gérer vos dépendances, procédez comme suit :

  • 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, servez-vous de ce qui suit :

      <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, servez-vous de ce qui suit :

      <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>
Rétablissement à l'aide d'une variable d'environnement

Le kit SDK pour Java fournit une variable d'environnement permettant de rétablir l'ancien connecteur par défaut Jersey au niveau global. Définissez la valeur de la variable d'environnement OCI_JAVASDK_JERSEY_CLIENT_DEFAULT_CONNECTOR_ENABLED sur true. Par défaut, cette valeur est définie sur false.

Désactivation de la fermeture automatique des flux de données

Pour les appels d'API renvoyant une réponse binaire/de flux de données, le kit SDK ferme automatiquement le flux une fois que celui-ci a été complètement lu. En effet, le kit 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 le regroupement de connexions en pool. Dans les cas où le flux de données de la réponse n'est pas fermé, les connexions ne sont pas libérées du pool de connexions.

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

Choix des stratégies de fermeture de connexion avec le connecteur Apache pour optimiser les performances

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

Avec ApacheConnectionClosingStrategy.GracefulClosingStrategy, les flux de données renvoyés à partir d'une réponse sont lus jusqu'à la fin du flux lors de sa fermeture. Cela peut entraîner un délai supplémentaire lors de la fermeture du flux de données avec une lecture partielle, en fonction de la taille du flux restant. Pour éviter ce délai, envisagez d'utiliser ApacheConnectionClosingStrategy.ImmediateClosingStrategy pour les fichiers volumineux avec des lectures partielles. ApacheConnectionClosingStrategy.ImmediateClosingStrategy prend plus de temps lors de l'utilisation de la lecture partielle pour des flux de données de plus petite taille (inférieurs à 1 Mo).

Remarque

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

Pour plus d'informations, reportez-vous à : 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 de la conformité FIPS, vous devez télécharger et utiliser une version certifiée FIPS. Le kit SDK prend en charge bc-fips 1.0.2 et bcpkix-fips 1.0.3. Vous pouvez les télécharger à l'adresse suivante : https://www.bouncycastle.org/fips-java/

Pour obtenir de l'aide concernant l'installation et la configuration de Bouncy Castle FIPS, reportez-vous à la documentation BC FIPS dans les guides de l'utilisateur et dans la stratégie de sécurité de la documentation Bouncy Castle.

Dépendances auto-gérées

Si vous gérez vous-même les dépendances, procédez comme suit :

  1. Enlevez les fichiers JAR Bouncy Castle non FIPS de la variable d'environnement CLASSPATH :
    1. bcprov-jdk15on-1.60.jar
    2. bcpkix-jdk15on-1.60.jar
  2. A la place, ajoutez les fichiers JAR Bouncy Castle FIPS à la variable d'environnement CLASSPATH :
    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, procédez comme suit :

  1. Ajoutez les versions correctes de bc-fips et de 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. Etant donné que vous dépendez d'un package oci-java-sdk*, vous devez enlever 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 implémentation JAX-RS

Le kit SDK pour Java est fourni avec Jersey, mais vous pouvez également utiliser votre propre implémentation JAX-RS.

Extension du configurateur client RESTEasy

L'extension oci-java-sdk-addons-resteasy-client-configurator est fournie pour présenter la configuration d'une autre implémentation JAX-RS. L'extension se trouve dans le répertoire bmc-addons du kit SDK.

Pour plus de détails sur l'installation et la configuration, reportez-vous au fichier README de l'extension.

Pour obtenir des exemples de code qui illustrent la configuration du client, reportez-vous aux éléments ci-dessous :

Utilisation de SLF4J pour la journalisation

La journalisation dans le kit SDK est effectuée via SLF4J. SLF4J est une abstraction de journalisation qui permet d'utiliser une bibliothèque de journalisation fournie par l'utilisateur (par exemple, log4j). Pour plus d'informations, reportez-vous au manuel de SLF4J.

Voici un exemple permettant une journalisation de base vers une sortie standard. Vous pouvez configurer des options de journalisation plus avancées à l'aide de la liaison log4j.

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