Guide d'administration et de configuration

Procédure 2.1. Démarrer le service de plate-forme comme serveur autonome.

1. Dans Red Hat Enterprise Linux.

   Exécuter la commande suivante : EAP_HOME/bin/standalone.sh

2. Dans Microsoft Windows Server

   Exécuter la commande suivante : EAP_HOME\bin\standalone.bat

3. Option : indiquer les paramètres supplémentaires.

   Pour imprimer une liste de paramètres supplémentaires à passer aux scripts de démarrage, utiliser le paramètre -h.

Procédure 2.2. Démarrer le service de plate-forme comme serveur géré

1. Dans Red Hat Enterprise Linux.

   Exécutez la commande : EAP_HOME/bin/domain.sh

2. Dans Microsoft Windows Server

   Exécutez la commande : EAP_HOME\bin\domain.bat

3. En option : passez des paramètres supplémentaires au script de démarrage.

   Pour obtenir une liste de paramètres que vous pourrez passer au script de démarrage, utilisez le paramètre -h.

Procédure 2.3. Configuration d'un nom d'hôte avec une propriété système

1. Ouvrir le fichier de configuration de l'hôte host.xml pour le modifier.
2. Chercher l'élément host dans le fichier, comme par exemple :

   <host name="master" xmlns="urn:jboss:domain:1.6">

3. S'il est présent, retirer la déclaration d'attribut name="HOST_NAME". L'élément host devra ressembler à l'exemple suivant :

   <host xmlns="urn:jboss:domain:1.6">

4. Démarrer le serveur en saisissant -Djboss.host.name comme argument de ligne de commande, comme par exemple :

   -Djboss.host.name=HOST_NAME

Procédure 2.4. Configuration d'un nom d'hôte avec un nom spécifique

1. Démarrer l'hôte esclave JBoss EAP à l'aide de la syntaxe suivante :

   bin/domain.sh --host-config=HOST_FILE_NAME

   Par exemple :

   bin/domain.sh --host-config=host-slave01.xml

2. Lancer l'interface CLI.
3. Utiliser la syntaxe suivante pour remplacer le nom d'hôte :

   /host=EXISTING_HOST_NAME:write-attribute(name="name",value=UNIQUE_HOST_NAME)

   Par exemple :

   /host=master:write-attribute(name="name",value="host-slave01")

   Vous devriez voir apparaître le résultat suivant.

    "outcome" => "success"

   Cela modifie l'attribut name de l'hôte dans le fichier host-slave01.xml comme suit :

   <host name="host-slave01" xmlns="urn:jboss:domain:1.6">

4. Vous devez charger à nouveau la configuration du serveur avec l'ancien nom d'hôte pour terminer le processus.

   reload --host=EXISTING_HOST_NAME

   Par exemple :

   reload --host=master

Procédure 2.5. Créer un domaine géré sur deux machines

1. Sur la machine 1

   1. Utiliser le script add-user.sh pour ajouter l'utilisateur de management. Par exemple, slave01, pour que l'hôte puisse authentifier le contrôleur de domaines. Notez la valeur SECRET_VALUE de la sortie add-user.
   2. Démarrer le domaine par le fichier de configuration host-master.xml, qui est préconfiguré pour un contrôleur de domaines exclusif.
   3. Utiliser -bmanagement=$IP1 pour rendre le contrôleur de domaine visible auprès des autres machines.

      [$JBOSS_HOME/bin]$ ./domain.sh --host-config=host-master.xml -bmanagement=$IP1

2. Sur la machine 2

   1. Mettre à jour le fichier $JBOSS_HOME/domain/configuration/host-slave.xml avec les identifiants.

      	<?xml version='1.0' encoding='UTF-8'?>
              <host xmlns="urn:jboss:domain:1.6" name="slave01">   
              <!-- add user name here -->
               <management>
                  <security-realms>
                     <security-realm name="ManagementRealm">
                        <server-identities>
                          <secret value="$SECRET_VALUE" />   
                          <!-- use secret value from add-user.sh output-->
                        </server-identities> 
                        ...

   2. Démarrer l'hôte.

      [$JBOSS_HOME/bin]$ ./domain.sh --host-config=host-slave.xml  -Djboss.domain.master.address=$IP1 -b=$IP2

3. Nous pouvons maintenant gérer le domaine.

   via le CLI :

   [$JBOSS_HOME/bin]$ ./jboss-cli.sh -c --controller=$IP1
   

   via la console web :

   http://$IP1:9990
   

   Accéder à la page d'index du serveur :

   http://$IP2:8080/
   http://$IP2:8230/
   

Procédure 2.6. Démarrage de l'instance par une configuration différente

1. Serveur autonome

   Pour un domaine autonome, fournir le nom du fichier de configuration comme option du paramètre --server-config. Le fichier de configuration doit se trouver dans le répertoire EAP_HOME/standalone/configuration/, et vous devez indiquer le chemin d'accès du fichier de ce répertoire.

   Exemple 2.1. Utiliser un fichier de configuration alternatif pour un serveur autonome Red Hat Enterprise Linux.

   [user@host bin]$ ./standalone.sh --server-config=standalone-alternate.xml

   Cet exemple utilise le fichier de configuration EAP_HOME/standalone/configuration/standalone-alternate.xml.

   Exemple 2.2. Utiliser un fichier de configuration alternatif pour un serveur autonome Microsoft Windows.

   C:\EAP_HOME\bin> standalone.bat --server-config=standalone-alternate.xml

   Cet exemple utilise le fichier de configuration EAP_HOME/standalone/configuration/standalone-alternate.xml.

2. Domaine géré

   Pour un domaine géré, fournir le nom du fichier de configuration comme option du paramètre --domain-config. Le fichier de configuration se trouve dans le répertoire EAP_HOME/domain/configuration/, et vous devez indiquer le chemin d'accès de ce répertoire.

   Exemple 2.3. Utilisation d'un fichier de configuration alternatif pour un domaine géré dans Red Hat Enterprise Linux

   [user@host bin]$ ./domain.sh --domain-config=domain-alternate.xml

   Cet exemple utilise le fichier de configuration EAP_HOME/domain/configuration/domain-alternate.xml.

   Exemple 2.4. Utilisation d'un fichier de configuration alternatif pour un domaine géré dans un serveur Microsoft Windows

   C:\EAP_HOME\bin> domain.bat --domain-config=domain-alternate.xml
   
   

   Cet exemple utilise le fichier de configuration EAP_HOME\domain\configuration\domain-alternate.xml.

Procédure 2.10. Démarrer le serveur d'un domaine géré

1. Sélectionner l'onglet Runtime qui se trouve en haut de la console. Étendre le menu Server et sélectionner Overview.
2. À partir de la liste Server Instances, sélectionner le serveur que vous souhaitez démarrer. Les serveurs qui sont en cours d'exécution sont indiqués.
   Placez le curseur sur une instance de cette liste pour afficher les options en bleu dans le texte sous les informations sur le serveur.
3. Pour démarrer une instance, cliquer sur Start Server quand vous verrez ce texte. Une boîte de dialogue de confirmation va s'ouvrir. Cliquer sur le bouton Confirm pour démarrer le serveur.

Procédure 2.11. Stopper un serveur qui utilise une console de gestion dans un domaine géré

1. Sélectionner l'onglet Runtime qui se trouve en haut de la console. Étendre le menu Domain et sélectionner Overview.
2. Une liste d'instances Server Instances s'affiche dans le tableau Hosts, groups and server instances. Les serveurs en cours sont cochés.
3. Placer le curseur sur le serveur choisi. Cliquer sur le bouton Stop Server qui apparaît. Une fenêtre de dialogue de confirmation s'affichera.
4. Cliquer sur le bouton Confirm pour arrêter le serveur.

Procédure 2.12. jboss-descriptor-property-replacement

1. À l'aide de l'interface CLI, exécuter la commande suivante pour déterminer la valeur de jboss-descriptor-property-replacement:

   /subsystem=ee:read-attribute(name="jboss-descriptor-property-replacement")

2. Exécuter la commande suivante pour configurer le comportement :

   /subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

Procédure 2.13. spec-descriptor-property-replacement

1. À l'aide de l'interface CLI, exécuter la commande suivante pour confirmer la valeur de spec-descriptor-property-replacement:

   /subsystem=ee:read-attribute(name="spec-descriptor-property-replacement")

2. Exécuter la commande suivante pour configurer le comportement :

   /subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)

Procédure 2.14. Télécharger un snapshot de configuration et sauvegardez-le

• Sauvegarde d'un snapshot

  Exécuter l'opération take-snapshot pour acquérir une copie de la configuration du serveur.

  [standalone@localhost:9999 /] :take-snapshot
  {
      "outcome" => "success",
      "result" => "/home/User/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-172258657standalone.xml"
  

Procédure 2.15. Télécharger un snapshot de configuration

1. Identifier le snapshot à télécharger. Cet exemple va rappeler le fichier suivant du répertoire de snapshots. Le chemin par défaut des fichiers de snapshot est le suivant.

   EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110812-191301472standalone.xml

   Les snapshots sont exprimés par leurs chemins relatifs, selon lesquels l'exemple ci-dessus peut être écrit ainsi.

   jboss.server.config.dir/standalone_xml_history/snapshot/20110812-191301472standalone.xml

2. Démarrer le serveur par le snapshot de configuration sélectionné en passant le nom du fichier.

   EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20110913-164449522standalone.xml

Procédure 2.16. Supprimer un snapshot particulier

1. Identifier le snapshot à effacer. Cet exemple va effacer le fichier suivant du répertoire de snapshots.

   EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-165714239standalone.xml

2. Exécuter la commande :delete-snapshot pour supprimer un snapshot particulier, en spécifiant le nom du snapshot comme dans l'exemple ci-dessous.

   [standalone@localhost:9999 /] :delete-snapshot(name="20110630-165714239standalone.xml")
   {"outcome" => "success"}
   

Procédure 2.17. Supprimer tous les snapshots

• Exécuter la commande :delete-snapshot(name="all") pour supprimer tous les snapshots comme dans l'exemple ci-dessous.

  [standalone@localhost:9999 /] :delete-snapshot(name="all")
  {"outcome" => "success"}
  

Procédure 2.18. Lister tous les snapshots de configuration

• Lister tous les snapshots

  Lister tous les snapshots sauvegardés en exécutant la commande :list-snapshots.

  [standalone@localhost:9999 /] :list-snapshots
  {
      "outcome" => "success",
      "result" => {
          "directory" => "/home/hostname/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
          "names" => [
              "20110818-133719699standalone.xml",
              "20110809-141225039standalone.xml",
              "20110802-152010683standalone.xml",
              "20110808-161118457standalone.xml",
              "20110912-151949212standalone.xml",
              "20110804-162951670standalone.xml"
          ]
      }
  }
  

1. Naviguer vers la page de démarrage de la console de gestion

   Lancez votre navigateur web et accédez à la Console de gestion dans votre navigateur web dans http://localhost:9990/console/App.html

   Note

   Port 9990 est prédéfini en tant que liaison de socket de Console de gestion.
2. Saisir le nom d'utilisateur et le mot de passe du compte que vous avez déjà créés pour vous connecter à l'écran de connexion de la console de gestion.
   

   Figure 3.1. Écran de connexion de la console de gestion

Procédure 3.1. Changer la langue de la console de management basée-web

1. Connectez-vous à la console de gestion.

   Connectez-vous à la console de management basée web.

2. Ouvrir le dialogue de configuration.

   Dans le coin gauche de l'écran, il y a une étiquette Settings de configuration. Cliquer sur cette étiquette pour ouvrir les paramètres de configuration de la console de management.

3. Sélectionner la langue désirée.

   Sélectionner la langue désirée à partir de la case Locale. Puis sélectionner Save. Une autre case explicative vous demande de charger à nouveau l'application. Cliquer sur Confirm. Le système réactualise votre navigateur automatiquement pour pouvoir utiliser les nouveaux paramètres régionaux (Locale).

Procédure 3.2. Configurer le serveur

1. Sélectionner l'onglet Domain en haut de la console. Les instances de serveur disponibles s'afficheront sur un tableau.
2. Sélectionner l'instance de serveur à partir du tableau Available Server Configurations.
3. Cliquer sur Edit au dessus des informations sur le serveur choisi.
4. Procédez avec les changements des attributs de configuration.
5. Cliquer sur le bouton Save pour terminer.

1. Sélectionner l'onglet Runtime en haut de la console.
2. Pour un serveur autonome, il vous faudra étendre l'élément de menu Server et sélectionner Manage Deployments. Pour un domaine géré, étendre l'élément de menu Domain et sélectionner Manage Deployments. Le panneau Manage Deployments apparaîtra.
3. Sélectionner Add dans l'onglet Content Repository. Une boîte de dialogue Create Deployment apparaîtra.
4. Dans la boîte de dialogue, cliquer sur Browse. Cherchez le fichier que vous souhaitez déployer, et sélectionnez-le en vue de son chargement. Cliquer sur Next pour continuer.
5. Vérifier le nom du déploiement et le nom du runtime qui apparaît dans la boîte de dialogue Create Deployments. Sélectionner Save pour charger le fichier une fois que les noms auront été vérifiés.

Procédure 3.3. Créer une nouvelle configuration de serveur

1. Naviguer sur la page Server Configuration qui se trouve dans la console de management

   Sélectionner l'onglet Domain en haut de la console.

2. Créer une nouvelle configuration

   1. Sélectionner le bouton Add qui se trouve en haut du tableau Available Server Configuration.
   2. Saisir les paramètres de base du serveur dans la boîte de dialogue Create Server Configuration.
   3. Cliquer sur le bouton Save pour enregistrer la nouvelle configuration de votre serveur.

Procédure 3.4. Modifier les niveaux de journalisation

1. Naviguer dans le panneau Logging de la console de gestion.

   1. Si vous travaillez dans un domaine géré, sélectionner l'onglet Configuration en haut de la console, puis, sélectionner le profil qui convient dans la liste déroulante à gauche de la console.
   2. Pour un domaine géré ou un serveur autonome, étendre le menu Core qui se trouve à gauche de la console et cliquer sur Logging.
   3. Cliquer sur l'onglet Log Categories en haut de la console.

2. Modifier les informations du créateur du journal

   Modifer les informations des entrées du tableau Log Categories.
   1. Sélectionner une entrée dans le tableau Log Categories, puis cliquer sur Edit dans la section Details ci-dessous.
   2. Définir le niveau de journalisation de la catégorie dans la zône déroulante Log Level. Cliquer sur le bouton Save quand c'est fait.

Procédure 3.5. Configurer et ajouter un groupe de serveurs

1. Se rendre dans la vue Server Groups

   Sélectionner l'onglet Domain au haut de la console.
2. Étendre l'étiquette Server dans le menu qui se trouve en haut de la colonne. Sélectionner Server Groups.

3. Ajouter un groupe de serveurs

   Cliquer sur le bouton Add pour ajouter un nouveau groupe de serveurs.

4. Configurer le groupe de serveurs

   1. Saisir un nom pour le groupe de serveurs
   2. Sélectionner le profil d'un groupe de serveurs.
   3. Sélectionner la liaison de socket du groupe de serveurs.
   4. Cliquer sur le bouton Save pour sauvegarder le nouveau groupe.

Procédure 3.6. Visualiser les journaux de JBoss EAP 6 dans la console de gestion

1. Sélectionner l'onglet Runtime en haut de la console de gestion.
   1. Si vous utilisez un domaine géré, utilisez le bouton Change Server dans le menu de gauche pour sélectionner le serveur JBoss EAP 6 dont vous souhaitez afficher les journaux.
2. Étendre le menu Platform sur la gauche, et sélectionnner le Log Viewer.
3. Sélectionner le fichier de journalisation de la liste, et cliquer sur le bouton View.
   Vous pouvez également cliquer sur le bouton Download pour télécharger le fichier de journalisation de la machine locale.

   Note

   Le Log Viewer de la console de gestion affiche une confirmation si vous tentez d'ouvrir un fichier de journalisation plus grand que 15 Mo.

   Le Log Viewer de la console de gestion n'est pas destiné à être un éditeur de texte de remplacement pour l'affichage des fichiers de journalisation très volumineux (> 100Mo). L'ouverture de fichiers journaux très volumineux dans le Log Viewer de la console de gestion peut bloquer votre navigateur web, donc il faut toujours mieux télécharger les gros fichiers de journalisation séparément et les ouvrir dans un éditeur de texte.
4. Le journal sélectionné ouvrira un nouvel onglet dans la console de gestion, Vous pouvez ouvrir plusieurs fichiers de journalisation dans d'autres onglets en retournant à l'onglet LOG FILES et en répétant l'étape précédente.

Procédure 3.7. Lancement du CLI dans un serveur Linux ou Windows

• • Lancement du CLI dans Linux

    Exécutez le fichier EAP_HOME/bin/jboss-cli.sh en saisissant ce qui suit dans la ligne de commande :

    $ EAP_HOME/bin/jboss-cli.sh

  • Lancement du CLI dans un serveur Microsoft Windows

    Exécutez le fichier EAP_HOME/bin/jboss-cli.bat en cliquant deux fois, ou en saisissant ce qui suit dans la ligne de commande :

    C:\>EAP_HOME\bin\jboss-cli.bat

Procédure 3.8. Se connecter à une instance de serveur gérée

• Exécutez la commande connect

  À l'aide de l'interface CLI, saisir la commande connect :

  [disconnected /] connect
  Connected to domain controller at localhost:9999

  • Sinon, pour vous connecter à un serveur géré quand vous démarrez une interface CLI sur un système Linux, utiliser le paramètre --connect :

    $ EAP_HOME/bin/jboss-cli.sh --connect

  • Le paramètre --connect peut être utilisé pour indiquer l'hôte et le port du serveur. Pour connecter l'adresse 192.168.0.1 à la valeur du port 9999 ce qui suit s'applique :

    $ EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.1:9999

1. Obtenir de l'aide générale

   Avec le CLI, saisir la commande help :

   [standalone@localhost:9999 /] help

2. Obtenir de l'aide par rapport au contexte

   Avec le CLI, saisir la commande étendue help -commands :

   [standalone@localhost:9999 /] help --commands

3. Pour plus d'informations sur une commande particulière, exécuter la commande suivie de --help.

   [standalone@localhost:9999 /] deploy --help

Procédure 3.9. Commandes et opérations en mode par lot

1. Saisir un mode par lot

   Saisir le mode par lot par la commande batch.

   [standalone@localhost:9999 /] batch
   [standalone@localhost:9999 / #]

   Le mode par lot est indiqué par le signe (#) dans l'invite.

2. Ajouter les demandes opérationnelles au lot

   Une fois que vous serez en mode par lot, saisir les demandes opérationnelles comme d'habitude. Les demandes opérationnelles sont ajoutées au lot dans l'ordre de saisie.
   Voir Section 3.5.8, « Utiliser les opérations et les commandes de l'interface CLI » pour obtenir des informations sur la façon de formater les demandes opérationnelles.

3. Exécuter le lot

   Une fois que toute la séquence de demandes opérationnelles est saisie, exécuter le lot avec la commande run-batch.

   [standalone@localhost:9999 / #] run-batch
   The batch executed successfully.

   Voir Section 3.5.7, « Commandes CLI Mode Lot » pour obtenir une liste complète des commandes disponibles pour pouvoir travailler avec des lots.

4. Les commandes de lots sont stockées dans des fichiers externes

   Les commandes fréquemment exécutées peuvent être stockées dans un fichier texte externe et être chargées en passant le chemin d'accès complet au fichier comme argument à la commande batch ou exécutées directement en étant un argument à la commande run-batch.
   Vous pouvez créer un fichier de commande lot avec l'éditeur de texte. Chaque commande doit figurer sur une ligne par elle-même et l'interface CLI doit être en mesure d'y accéder.
   La commande suivante chargera un fichier myscript.txt en mode lot. Toutes les commandes de ce fichier seront alors être prêtes à la modification ou à la suppression. De nouvelles commandes pourront être ajoutées. Les modifications effectuées au cours de cette session de lot ne persistera pas dans le fichier myscript.txt.

   [standalone@localhost:9999 /] batch --file=myscript.txt

   Ce qui suit exécutera instantanément les commandes de lot stockées dans le fichier myscript.txt

   [standalone@localhost:9999 /] run-batch --file=myscript.txt

Procédure 3.10. Créer, configurer et exécuter les requêtes

1. Construire la demande opérationnelle

   Les demandes opérationnelles facilitent une interaction de bas niveau dans le modèle de gestion. Il s'agit d'une façon contrôlée de modifier les configurations du serveur. Une demande opérationnelle se présente en trois parties :
   • une adresse, avec une barre oblique devant (/).
   • un nom d'opération, avec deux points (:).
   • un groupe optionnel de paramètres, entre parenthèses (()).

   1. Déterminer l'adresse

      La configuration est présentée sous forme de ressources auxquelles s'adresser et de façon hiérarchique. Chaque noeud de ressources procure un groupe différent d'opérations. Une adresse utilise la syntaxe suivante :

      /node-type=node-name

      • node-type correspond au type de noeud de ressource. Cela correspond à un nom d'élément dans la configuration XML.
      • node-name correspond au nom du nœud. Cela correspond à l'attribut nom de l'élément dans la configuration XML.
      • Séparer chaque niveau de l'arborescence de ressources par une barre oblique (/).
      Voir les fichiers de configuration XML pour déterminer l'adresse qui convient. Le fichier EAP_HOME/standalone/configuration/standalone.xml contient la configuration d'un serveur autonome et les fichiers EAP_HOME/domain/configuration/domain.xml et EAP_HOME/domain/configuration/host.xml contiennent la configuration d'un domaine géré.

      Note

      Exécuter les commandes CLI en mode de domaine requiert que l'hôte et le serveur soient indiqués. Par exemple, /host=master/server=server-one/subsystem=logging

      Exemple 3.3. Exemple d'adresses d'opérations

      Pour procéder à une opération dans le sous-système de journalisation, utiliser l'adresse suivante dans la demande opérationnelle :

      /subsystem=logging

      Pour effectuer une opération sur la source de données Java, utiliser l'adresse suivante dans la demande opérationnelle :

      /subsystem=datasources/data-source=java

   2. Déterminer l'opération

      Les opérations diffèrent avec chaque type de nœud de ressource. Une opération utilise la syntaxe suivante :

      :operation-name

      • operation-name correspond au nom de l'opération à demander.
      Utiliser l'opération read-operation-names sur une adresse de ressources d'un serveur autonome pour lister les opérations disponibles.

      Exemple 3.4. Opérations disponibles

      Pour énumérer toutes les opérations disponibles du sous-système de journalisation, saisir la requête suivante dans un serveur autonome :

      [standalone@localhost:9999 /] /subsystem=logging:read-operation-names
      {
          "outcome" => "success",
          "result" => [
              "add",
              "read-attribute",
              "read-children-names",
              "read-children-resources",
              "read-children-types",
              "read-operation-description",
              "read-operation-names",
              "read-resource",
              "read-resource-description",
              "remove",
              "undefine-attribute",
              "whoami",
              "write-attribute"
          ]
      }

   3. Déterminer un paramètre

      Chaque opération a sans doute besoin de paramètres différents.
      Les paramètres utilisent la syntaxe suivante :

      (parameter-name=parameter-value)

      • parameter-name correspond au nom du paramètre.
      • parameter-value correspond à la valeur du paramètre.
      • Les différents paramètres sont séparés par des virgules (,).
      Afin de déterminer les paramètres qui conviennent, exécutez la commande read-operation-description sur un nœud de ressource, en faisant passer le nom de l'opération en tant que paramètre. Voir Exemple 3.5, « Déterminer les paramètres des opérations » pour plus de détails.

      Exemple 3.5. Déterminer les paramètres des opérations

      Afin de déterminer les paramètres qui conviennent pour l'opération read-children-types sur le sous-système de journalisation, saisir la commande read-operation-description comme suit :

      [standalone@localhost:9999 /] /subsystem=logging:read-operation-description(name=read-children-types)
      {
          "outcome" => "success",
          "result" => {
              "operation-name" => "read-children-types",
              "description" => "Gets the type names of all the children under the selected resource",
              "reply-properties" => {
                  "type" => LIST,
                  "description" => "The children types",
                  "value-type" => STRING
              },
              "read-only" => true
          }
      }

2. Saisir toute la demande opérationnelle

   Une fois que l'adresse, l'opération et tous les paramètres auront été sélectionnés, saisir la demande opérationnelle complète.

   Exemple 3.6. Exemple de demande opérationnelle

   [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)

Procédure 3.11. Activer la substition de propriété dans l'interface CLI

1. Ouvrir le fichier EAP_HOME/bin/jboss-cli.xml.
2. Trouver l'emplacement du paramètre resolve-parameter-values et changez-en la valeur à true (la valeur par défaut est false).

   <!-- whether to resolve system properties specified as command argument or operation parameter values in the Management CLI VM before sending the operation requests to the controller -->
       <resolve-parameter-values>true</resolve-parameter-values>
   

Procédure 3.12. Affiche la valeur de runtime en cours pour un attribut sélectionné.

• Exécuter l'opération read-attribute

  À l'aide de l'interface CLI, utiliser l'opération read-attribute pour afficher la valeur d'un attribut de ressource. Pour plus d'informations sur les requêtes d'informations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes de l'interface CLI ».

  [standalone@localhost:9999 /]:read-attribute(name=name-of-attribute)

Procédure 3.13. Affiche l'utilisateur qui est actif dans l'interface CLI par l'opération whoami

• Exécuter l'opération whoami

  À partir de l'interface CLI, utiliser l'opération whoami pour afficher le compte utilisateur actif.

  [standalone@localhost:9999 /] :whoami

  L'exemple suivant utilise la commande whoami dans une instance de serveur autonome pour montrer que l'utilisateur actif est le username, et que l'utilisateur est assigné au domaine ManagementRealm.

  Exemple 3.9. Utiliser la commande whoami dans une instance autonome

  [standalone@localhost:9999 /]:whoami
  {
      "outcome" => "success",
      "result" => {"identity" => {
          "username" => "username",
          "realm" => "ManagementRealm"
      }}
  }
  

Procédure 3.14. Affiche les informations système et serveur dans l'interface CLI

• Exécuter la commande version

  À partir de l'interface CLI, saisir la commande version :

  [domain@localhost:9999 /] version

Procédure 3.15. Éxécuter la commande CLI suivante

• Exécuter l'opération read-operation-description

  À partir de l'interface CLI, utiliser read-operation-description pour afficher des informations sur l'opération. L'opération requiert des paramètres supplémentaires dans le format d'une paire clé-valeur pour indiquer quelle opération afficher. Pour plus d'informations sur les requêtes d'informations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes de l'interface CLI ».

  [standalone@localhost:9999 /]:read-operation-description(name=name-of-operation)

Procédure 3.16. Éxécuter la commande CLI suivante

• Exécuter l'opération read-operation-names

  À partir de l'interface CLI, utiliser l'opération read-operation-names pour afficher les noms des opérations disponibles. Pour plus d'informations sur les requêtes d'informations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes de l'interface CLI ».

  [standalone@localhost:9999 /]:read-operation-names

Procédure 3.17. Éxécuter la commande CLI suivante

1. Exécuter l'opération read-resource

   Avec l'interface CLI, faites l'opération read-resource pour afficher les ressources disponibles.

   [standalone@localhost:9999 /]:read-resource

   L'exemple suivant vous montre comment il est possible d'utiliser l'opération read-resource dans une instance de serveur autonome pour exposer les informations de ressources générales. Les résultats ressemblent au fichier de configuration standalone.xml, qui affiche les ressources de système, les extensions, les interfaces et les sous-systèmes installés ou configurés pour l'instance du serveur. Ces résultats peuvent être interrogés directement.

   Exemple 3.12. Exécuter l'opération read-resource niveau racine

   [standalone@localhost:9999 /]:read-resource
   {
       "outcome" => "success",
       "result" => {
           "management-major-version" => 1,
           "management-micro-version" => 0,
           "management-minor-version" => 7,
           "name" => "localhost",
           "namespaces" => [],
           "product-name" => "EAP",
           "product-version" => "6.4.0.GA",
           "profile-name" => undefined,
           "release-codename" => "Janus",
           "release-version" => "7.5.0.Final-redhat-17",
           "schema-locations" => [],
           "core-service" => {
               "service-container" => undefined,
               "server-environment" => undefined,
               "module-loading" => undefined,
               "platform-mbean" => undefined,
               "management" => undefined,
               "patching" => undefined
           },
           "deployment" => undefined,
           "deployment-overlay" => undefined,
           "extension" => {
               "org.jboss.as.clustering.infinispan" => undefined,
               "org.jboss.as.connector" => undefined,
               "org.jboss.as.deployment-scanner" => undefined,
               "org.jboss.as.ee" => undefined,
               "org.jboss.as.ejb3" => undefined,
               "org.jboss.as.jaxrs" => undefined,
               "org.jboss.as.jdr" => undefined,
               "org.jboss.as.jmx" => undefined,
               "org.jboss.as.jpa" => undefined,
               "org.jboss.as.jsf" => undefined,
               "org.jboss.as.logging" => undefined,
               "org.jboss.as.mail" => undefined,
               "org.jboss.as.naming" => undefined,
               "org.jboss.as.pojo" => undefined,
               "org.jboss.as.remoting" => undefined,
               "org.jboss.as.sar" => undefined,
               "org.jboss.as.security" => undefined,
               "org.jboss.as.threads" => undefined,
               "org.jboss.as.transactions" => undefined,
               "org.jboss.as.web" => undefined,
               "org.jboss.as.webservices" => undefined,
               "org.jboss.as.weld" => undefined
           },
           "interface" => {
               "management" => undefined,
               "public" => undefined,
               "unsecure" => undefined
           },
           "path" => {
               "jboss.server.temp.dir" => undefined,
               "user.home" => undefined,
               "jboss.server.base.dir" => undefined,
               "java.home" => undefined,
               "user.dir" => undefined,
               "jboss.server.data.dir" => undefined,
               "jboss.home.dir" => undefined,
               "jboss.server.log.dir" => undefined,
               "jboss.server.config.dir" => undefined,
               "jboss.controller.temp.dir" => undefined
           },
           "socket-binding-group" => {"standard-sockets" => undefined},
           "subsystem" => {
               "jaxrs" => undefined,
               "jsf" => undefined,
               "jca" => undefined,
               "jmx" => undefined,
               "threads" => undefined,
               "webservices" => undefined,
               "sar" => undefined,
               "remoting" => undefined,
               "infinispan" => undefined,
               "weld" => undefined,
               "ejb3" => undefined,
               "transactions" => undefined,
               "datasources" => undefined,
               "deployment-scanner" => undefined,
               "logging" => undefined,
               "jdr" => undefined,
               "pojo" => undefined,
               "jpa" => undefined,
               "naming" => undefined,
               "ee" => undefined,
               "mail" => undefined,
               "web" => undefined,
               "resource-adapters" => undefined,
               "security" => undefined
           },
           "system-property" => undefined
       }
   }
   

2. Exécuter l'opération read-resource pour un nœud enfant

   L'opération read-resource peut être exécutée pour chercher les nœuds enfants à partir de la racine. La structure de l'opération commence par définir le nœud à exposer, puis s'ajoute à l'opération pour exécuter à ses côtés.

   [standalone@localhost:9999 /]/subsystem=web/connector=http:read-resource

   Dans l'exemple suivant, on peut exposer des informations de ressources spécifiques sur un composant de sous-système en redirigeant l'opération read-resource vers un nœud de sous-système web particulier.

   Exemple 3.13. Exposer les ressources de nœud enfant à partir d'un nœud racine

   [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource                      
   {
       "outcome" => "success",
       "result" => {
           "configuration" => undefined,
           "enable-lookups" => false,
           "enabled" => true,
           "executor" => undefined,
           "max-connections" => undefined,
           "max-post-size" => 2097152,
           "max-save-post-size" => 4096,
           "name" => "http",
           "protocol" => "HTTP/1.1",
           "proxy-name" => undefined,
           "proxy-port" => undefined,
           "redirect-port" => 443,
           "scheme" => "http",
           "secure" => false,
           "socket-binding" => "http",
           "ssl" => undefined,
           "virtual-server" => undefined
       }
   }
   

   Les mêmes résultats sont possibles en utilisant la commande cd pour naviguer dans les nœuds enfants et en exécutant l'opération read-resource directement.

   Exemple 3.14. Exposer les ressources de nœud enfant en changeant de répertoire

   [standalone@localhost:9999 /] cd subsystem=web

   [standalone@localhost:9999 subsystem=web] cd connector=http

   [standalone@localhost:9999 connector=http] :read-resource
   {
       "outcome" => "success",
       "result" => {
           "configuration" => undefined,
           "enable-lookups" => false,
           "enabled" => true,
           "executor" => undefined,
           "max-connections" => undefined,
           "max-post-size" => 2097152,
           "max-save-post-size" => 4096,
           "name" => "http",
           "protocol" => "HTTP/1.1",
           "proxy-name" => undefined,
           "proxy-port" => undefined,
           "redirect-port" => 443,
           "scheme" => "http",
           "secure" => false,
           "socket-binding" => "http",
           "ssl" => undefined,
           "virtual-server" => undefined
       }
   }
   

3. Utiliser le paramètre récursif pour inclure des valeurs actives dans les résultats

   Le paramètre récursif peut être utilisé pour exposer les valeurs de tous les attributs, y compris les valeurs non persistantes, celles qui sont passées au démarrage, ou les autres attributs normalement actifs du modèle d'exécution.

   [standalone@localhost:9999 /]/interface=public:read-resource(include-runtime=true)

   Par rapport à l'exemple précédent, l'inclusion de la propriété de requête include-runtime expose des attributs actifs supplémentaires, comme des octets envoyés ou des octets reçus par le connecteur HTTP.

   Exemple 3.15. Exposer des valeurs actives et supplémentaires par le paramètre include-runtime

   [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true)
   {
       "outcome" => "success",
       "result" => {
           "any" => undefined,
           "any-address" => undefined,
           "any-ipv4-address" => undefined,
           "any-ipv6-address" => undefined,
           "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
           "link-local-address" => undefined,
           "loopback" => undefined,
           "loopback-address" => undefined,
           "multicast" => undefined,
           "name" => "public",
           "nic" => undefined,
           "nic-match" => undefined,
           "not" => undefined,
           "point-to-point" => undefined,
           "public-address" => undefined,
           "resolved-address" => "127.0.0.1",
           "site-local-address" => undefined,
           "subnet-match" => undefined,
           "up" => undefined,
           "virtual" => undefined
       }
   }
   

Procédure 3.18. Éxécuter la commande CLI suivante

1. Exécuter l'opération read-resource-description

   À partir du CLI, utiliser l'opération read-resource-description pour lire et afficher les noms des ressources disponibles. Pour plus d'informations sur les requêtes d'opérations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes de l'interface CLI ».

   [standalone@localhost:9999 /]:read-resource-description

2. Utiliser les paramètres en option

   L'opération read-resource-description autorise l'utilisation de paramètres supplémentaires.
   1. Utiliser le paramètre operations pour inclure les descriptions des opérations de la ressource.

      [standalone@localhost:9999 /]:read-resource-description(operations=true)

   2. Utiliser le paramètre inherited pour inclure ou pour exclure des descriptions des opérations héritées de ressource. L'état par défaut est true.

      [standalone@localhost:9999 /]:read-resource-description(inherited=false)

   3. Utiliser le paramètre recursive pour inclure les descriptions récursives des ressources dépendantes.

      [standalone@localhost:9999 /]:read-resource-description(recursive=true)

   4. Utiliser le paramètre locale pour obtenir la description des ressources. Si « null », la locale régionale par défaut sera utilisée.

      [standalone@localhost:9999 /]:read-resource-description(locale=true)

Procédure 3.19. Fermer le serveur d'applications

• Exécuter l'opération shutdown

  • À partir du CLI, utiliser l'opération shutdown pour fermer le serveur via l'appel de système System.exit(0). Pour plus d'informations sur les requêtes d'opérations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes de l'interface CLI ».
    • En mode autonome, utiliser la commande suivante :

      [standalone@localhost:9999 /]:shutdown

    • En mode domaine, utiliser la commande suivante avec le nom d'hôte qui convient :

      [domain@localhost:9999 /]/host=master:shutdown

  • Pour vous connecter à une instance CLI détachée et pour fermer le serveur, exécuter la commande suivante :

    jboss-cli.sh --connect command=:shutdown
    

  • Pour vous connecter à une instance CLI éloignée et pour fermer le serveur, exécuter la commande suivante :

    [disconnected /] connect IP_ADDRESS
    [standalone@IP_ADDRESS:9999 /] :shutdown

    Remplacer l'IP_ADDRESS par l'adresse IP de votre instance.

Procédure 3.20. Configurer un attribut de ressource par l'interface CLI

• Exécuter l'opérationwrite-attribute

  À partir de l'interface CLI, utiliser l'opération write-attribute pour modifier la valeur d'un attribut de ressource. L'opération peut être exécutée dans le nœud dépendant de la ressource, ou bien dans le nœud root du CLI où le chemin de ressource complet est spécifié.

Procédure 3.21. Configurer les propriétés système par l'interface CLI

1. Démarrer le serveur JBoss EAP.
2. Lancer l'interface CLI par la commande pour votre système d'exploitation.
   Dans Linux :

   EAP_HOME/bin/jboss-cli.sh --connect

   Dans Windows :

   EAP_HOME\bin\jboss-cli.bat --connect

3. Ajouter une propriété système.
   La commande que vous utilisez dépend de savoir si vous utilisez un serveur autonome ou un domaine géré. Si vous utilisez un domaine géré, vous pouvez ajouter des propriétés système à un ou à plusieurs serveurs exécutant sur ce domaine.
   • Ajouter une propriété système sur un serveur autonome en utilisant la syntaxe suivante :

     /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

     Exemple 3.18. Ajouter une propriété système sur un serveur autonome

     [standalone@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
     {"outcome" => "success"}

   • Ajouter une propriété système sur tous les hôtes et serveurs d'un domaine géré en utilisant la syntaxe suivante :

     /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

     Exemple 3.19. Ajouter une propriété système à tous les serveurs d'un domaine géré

     [domain@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {
             "server-one" => {"response" => {"outcome" => "success"}},
             "server-two" => {"response" => {"outcome" => "success"}}
         }}}}
     }

   • Ajouter une propriété système à un hôte et à ses instances de serveur d'un domaine géré en utilisant la syntaxe suivante :

     /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

     Exemple 3.20. Ajouter une propriété système à un hôte et à ses serveurs dans un domaine

     [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {
             "server-one" => {"response" => {"outcome" => "success"}},
             "server-two" => {"response" => {"outcome" => "success"}}
         }}}}
     }

   • Ajouter une propriété système à une instance de serveur d'un domaine géré en utilisant la syntaxe suivante :

     /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

     Exemple 3.21. Ajouter une propriété système à une instance de serveur d'un domaine géré

     [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}}
     }
     

4. Lire une propriété système.
   La commande que vous utilisez dépend de savoir si vous exécutez sur un serveur autonome ou un domaine géré.
   • Lire une propriété système sur un serveur autonome en utilisant la syntaxe suivante :

     /system-property=PROPERTY_NAME:read-resource

     Exemple 3.22. Lire une propriété système sur un serveur autonome

     [standalone@localhost:9999 /] /system-property=property.mybean.queue:read-resource
     {
         "outcome" => "success",
         "result" => {"value" => "java:/queue/MyBeanQueue"}
     }
     

   • Lire une propriété système sur tous les hôtes et serveurs d'un domaine géré en utilisant la syntaxe suivante :

     /system-property=PROPERTY_NAME:read-resource

     Exemple 3.23. Lire une propriété système de tous les serveurs dans un domaine géré

     [domain@localhost:9999 /] /system-property=property.mybean.queue:read-resource
     {
         "outcome" => "success",
         "result" => {
             "boot-time" => true,
             "value" => "java:/queue/MyBeanQueue"
         }
     }

   • Lire une propriété système d'un hôte et de ses instances de serveur d'un domaine géré en utilisant la syntaxe suivante :

     /host=master/system-property=PROPERTY_NAME:read-resource

     Exemple 3.24. Lire une propriété système d'un hôte et de ses serveurs dans un domaine

     [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:read-resource
     {
         "outcome" => "success",
         "result" => {
             "boot-time" => true,
             "value" => "java:/queue/MyBeanQueue"
         }
     }
     

   • Lire une propriété système d'une instance de serveur d'un domaine géré en utilisant la syntaxe suivante :

     /host=master/server-config=server-one/system-property=PROPERTY_NAME:read-resource

     Exemple 3.25. Lire une propriété système d'une instance de serveur dans un domaine géré

     [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:read-resource
     {
         "outcome" => "success",
         "result" => {
             "boot-time" => true,
             "value" => "java:/queue/MyBeanQueue"
         }
     }

5. Supprimer une propriété système.
   La commande que vous utilisez dépend de savoir si vous exécutez sur un serveur autonome ou un domaine géré.
   • Supprimer une propriété système sur un serveur autonome en utilisant la syntaxe suivante :

     /system-property=PROPERTY_NAME:remove

     Exemple 3.26. Supprimer une propriété système sur un serveur autonome

     [standalone@localhost:9999 /] /system-property=property.mybean.queue:remove
     {"outcome" => "success"}

   • Supprimer une propriété système de tous les hôtes et serveurs d'un domaine géré en utilisant la syntaxe suivante :

     /system-property=PROPERTY_NAME:remove

     Exemple 3.27. Supprimer une propriété système de tous les hôtes et de ses serveurs dans un domaine.

     [domain@localhost:9999 /] /system-property=property.mybean.queue:remove
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {
             "server-one" => {"response" => {"outcome" => "success"}},
             "server-two" => {"response" => {"outcome" => "success"}}
         }}}}
     }
     

   • Supprimer une propriété système d'un hôte et de ses instances de serveur dans un domaine géré en utilisant la syntaxe suivante :

     /host=master/system-property=PROPERTY_NAME:read-resource

     Exemple 3.28. Supprimer une propriété système d'un hôte et de ses serveurs dans un domaine

     [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:remove
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {
             "server-one" => {"response" => {"outcome" => "success"}},
             "server-two" => {"response" => {"outcome" => "success"}}
         }}}}
     }
     

   • Supprimer une propriété système d'une instance de serveur d'un domaine géré en utilisant la syntaxe suivante :

     /host=master/server-config=server-one/system-property=PROPERTY_NAME:remove

     Exemple 3.29. Supprimer une propriété système d'un serveur dans un domaine géré

     [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:remove
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}}
     }
     

Procédure 3.22. Afficher l'historique de commandes par l'interface CLI.

• Exécuter la commande history

  À partir de l'interface CLI, saisir la commande history :

  [standalone@localhost:9999 /] history

Procédure 3.23. Effacer l'historique de commandes par interface CLI.

• Exécuter la commande history --clear

  À partir de l'interface CLI, saisir la commande history--clear :

  [standalone@localhost:9999 /] history --clear

Procédure 3.24. Désactiver l'historique de commandes par l'interface CLI.

• Exécuter la commande history --disable

  À partir de l'interface CLI, saisir la commande history --disable :

  [standalone@localhost:9999 /] history --disable

Procédure 3.25. Activer l'historique des commandes de l'interface CLI

• Exécuter la commande history --enable

  À partir de l'interface CLI, saisir la commande history --enable :

  [standalone@localhost:9999 /] history --enable

Procédure 3.26. Activer la journalisation d'auditing sur un serveur syslog

1. Activer la journalisation d'auditing

   Exécutez la commande suivante :

   [.. /]/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

2. Créer un gestionnaire syslog

   Dans cet exemple, le serveur syslog exécute sur le même serveur en tant qu'instance JBoss EAP, sur le port 514. Remplacer les valeurs de l'attribut host par des valeurs appropriées à votre environnement.

   Exemple 3.30. Exemple de gestionnaire syslog

   [.. /]batch
   [.. / #]/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
   [.. / #]/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
   [.. /]run-batch

3. Ajouter une référence au gestionnaire syslog

   Exécuter ce qui suit :

   [.. /]/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add

Procédure 4.1. Créer l'utilisateur administratif d'origine pour les interfaces de gestion distantes

1. Éxécuter le script add-user.sh ou add-user.bat.

   Passez au répertoire EAP_HOME/bin/. Invoquer le script qui convient à votre système d'exploitation.

   Red Hat Enterprise Linux

   [user@host bin]$ ./add-user.sh

   Microsoft Windows Server

   C:\bin>  add-user.bat

2. Choisissez d'utiliser un utilisateur Management.

   Appuyer sur ENTER pour sélectionner l'option a pour ajouter un utilisateur Management.
   Cet utilisateur sera ajouté au domaine ManagementRealm et il sera autorisé à effectuer des opérations de gestion par la Management Console basée web ou par l'interface CLI basé sur la ligne de commande. Autre alternative, b, ajoutera l'utilisateur au domaine ApplicationRealm, et ne fournit aucune permission particulière. Ce domaine est fourni pour être utilisé avec des applications.

3. Saisir le nom d'utilisateur et le mot de passe que vous souhaitez.

   Quand on vous y invite, saisir le nom d'utilisateur et le nom de passe. On vous demandera de saisir le mot de passe une seconde fois pour confirmer.

4. Saisissez les informations sur votre groupe.

   Ajouter le groupe ou les groupes auxquels l'utilisateur appartient. Si l'utilisateur appartient à plusieurs groupes, saisir une liste séparée par des virgules. Laisser vide si vous ne souhaitez pas que l'utilisateur appartienne à un groupe.

5. Vérifier les informations et confirmer.

   On vous invitera à confirmer les informations. Quand vous serez satisfait, saisir yes.

6. Décidez si l'utilisateur représente une instance de serveur de JBoss EAP 6 à distance.

   En plus des administrateurs, un autre type d'utilisateur qui a parfois besoin d'être ajouté à JBoss EAP 6 dans le domaine ManagementRealm est un utilisateur qui représente une autre instance de JBoss EAP 6, et qui a besoin d'être authentifié pour rejoindre un groupement en tant que membre. L'invite suivante vous permet de désigner votre utilisateur supplémentaire dans ce but. Si vous sélectionnez yes, on vous donnera une valeur secret de hachage, qui représentera le mot de passe de l'utilisateur, que vous aurez besoin d'ajouter dans un fichier de configuration différent. Dans le but de cette tâche, répondre no à cette question.

7. Saisir des utilisateurs supplémentaires.

   Vous pouvez saisir des utilisateurs supplémentaires si vous le souhaitez, en répétant la procédure. Vous pouvez également les ajouter à tout moment sur un système en cours d'exécution. Au lieu de choisir le domaine de sécurité par défaut, vous pouvez ajouter des utilisateurs d'autres domaines afin d'ajuster leurs autorisations.

8. Créer des utilisateurs en mode non interactif.

   Vous pouvez créer des utilisateurs en mode non interactif, en l'indiquant dans chaque paramètre de ligne de commande. Cette approche n'est pas recommandée sur les systèmes partagés, parce que les mots de passe seront visibles dans les fichiers de journalisation (log) et dans les fichiers d'historique. La syntaxe de la commande, pour le domaine de gestion, est la suivante :

   [user@host bin]$ ./add-user.sh username password

   Pour utiliser le domaine d'application, utiliser le paramètre -a.

   [user@host bin]$ ./add-user.sh -a username password

9. Vous pouvez supprimer la sortie normale du script d'ajout d'utilisateur en passant le paramètre --silent. Cela s'applique uniquement si un minimum de paramètres, nom d'utilisateur et mot de passe, ont été indiqués. Le message d'erreur apparaîtra toujours.

Procédure 4.2. Spécifier des fichiers de propriétés alternatifs

• • Pour spécifier un autre répertoire pour la configuration du serveur, utilisez l'argument -sc. Cet argument spécifie un autre répertoire qui contiendra les fichiers de propriétés de configuration de serveur.
  • Pour spécifier un répertoire alternatif de configuration de domaine, utiliser l'argument -dc. Cet argument spécifie un répertoire alternatif qui contient les fichiers de propriétés de configuration de domaines.
  • Pour spécifier un fichier de configuration utilisateur différent, utiliser l'argument -up ou --user-properties. Peut correspondre à un chemin complet ou à un nom de fichier utilisé en conjonction avec -sc ou -dc spécifiant le répertoire de configuration alternatif.
  • Pour spécifier un fichier de configuration de groupe différent, utiliser l'argument -up ou --group-properties. Peut correspondre à un chemin complet ou à un nom de fichier utilisé en conjonction avec -sc ou -dc indiquant le répertoire de configuration alternatif.

• Configuration des attributs d'une interface

  Vous pouvez utiliser la fonction de saisie semie-automatique pour saisir la commande au fur et à mesure que vous saisissez, et afin d'exposer les attributs disponibles.

  • Configurer les attributs d'interface par l'interface CLI

    Utiliser l'interface CLI pour ajouter de nouvelles interfaces et pour écrire des nouvelles valeurs dans dans les attributs de l'interface.

    1. Ajouter une nouvelle interface

       L'opération add (ajouter) crée de nouvelles interfaces selon les besoins. Vous pouvez exécuter cette commande add à partir de la racine de la session CLI, qui, dans l'exemple suivant, crée un nouveau titre de nom d'interface interfacename, avec une inet-address déclarée 12.0.0.2.

       /interface=interfacename/:add(inet-address=12.0.0.2)

    2. Modifier les attributs d'une interface

       L'opération write-attribute écrit de nouvelles valeurs sur un attribut. L'exemple suivant met à jour la valeur de inet-address à 12.0.0.8.

       /interface=interfacename/:write-attribute(name=inet-address, value=12.0.0.8)

    3. Vérifier les attributs d'interface.

       Confirmer que les valeurs d'attribut ont changé en exécutant l'opération read-resource accompagnée du paramètre include-runtime=true pour exposer toutes les valeurs actives en cours du modèle de serveur. Par exemple :

       [standalone@localhost:9999 interface=public] :read-resource(include-runtime=true)

  • Configurer les attributs d'interface par la console de gestion

    1. Connectez-vous à la console de management.

       Connectez-vous à la console de gestion de votre instance de serveur autonome ou de domaine géré.

    2. Naviguer dans l'écran d'interfaces

       1. Naviguer dans l'onglet de configuration.

          Sélectionner Configuration qui se trouve en haut de l'écran.

       2. Mode domaine uniquement

          Sélectionner un profil à partir du menu déroulant Profile qui se situe en haut et à gauche de l'écran.

    3. Sélectionner Interfaces à partir du menu de navigation.

       Étendre le menu General Configuration. Sélectionner l'élément de menu Interfaces à partir du menu de navigation.

    4. Ajouter une nouvelle interface

       1. Cliquer sur Ajouter.
       2. Saisir les valeurs qui conviennent pour les Name (Nom), Inet Address (Adresse Inet) et Address Wildcard (Adresse générique).
       3. Cliquer sur le bouton Save.

    5. Modifier les attributs d'une interface

       1. Sélectionner l'interface que vous souhaitez modifier dans la liste Available Interfaces et cliquer sur le bouton Edit.
       2. Saisir les valeurs qui conviennent pour les Name (Nom), Inet Address (Adresse Inet) et Address Wildcard (Adresse générique).
       3. Cliquer sur le bouton Save.

• Configurer des liaisons de sockets dans des groupes de liaisons de sockets

  Sélectionner le CLI ou la console de gestion pour configurer vos liaisons de sockets selon les besoins.

  • Configurer les liaisons de sockets par l'interface CLI

    Utiliser l'interface CLI pour configurer les liaisons de sockets.

    1. Ajouter une nouvelle liaison de sockets

       Utiliser l'opération add (ajouter) pour créer une nouvelle configuration d'adresse si nécessaire. Vous pouvez exécuter cette commande à partir de la racine de la session de CLI, qui, dans l'exemple suivant, crée une nouvelle liaison de sockets intitulée newsocket, avec un attribut port déclaré comme 1234. Les exemples s'appliquent à la fois pour la modification des serveurs autonomes et des serveurs gérés sur la liaison de sockets standard-sockets comme montré ci-dessous.

       [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:add(port=1234)

    2. Modifier les attributs de modèle

       Utiliser l'opération write-attribute pour écrire une nouvelle valeur dans un attribut. Vous pouvez utiliser l'onglet de complétion pour aider à compléter la chaîne de commande que vous saisissez, et pour exposer les attributs disponibles. L'exemple suivant met à jour la valeur port à 2020

       [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:write-attribute(name=port,value=2020)

    3. Confirmer les attributs de modèle

       Confirmer que les valeurs ont changé en exécutant read-resource accompagné du paramètre include-runtime=true pour exposer toutes les valeurs actives en cours du modèle de serveur.

       [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:read-resource

  • Configurer les liaisons de sockets par la console de gestion

    Utiliser la console de gestion pour configurer les liaisons de sockets.

    1. Connectez-vous à la console de management.

       Connectez-vous à la console de gestion de votre domaine géré ou de votre serveur autonome.

    2. Naviguer dans Configuration.

       Sélectionner Configuration qui se trouve en haut de l'écran.

    3. Sélectionner l'élément Socket Binding à partir du menu de navigation.

       Étendre le menu General Configuration. Sélectionner Socket Binding. Si vous utilisez un domaine géré, sélectionner le groupe désiré dans la liste Socket Binding Groups.

    4. Ajouter une nouvelle liaison de sockets

       1. Cliquer sur le bouton Add (ajouter).
       2. Saisir les valeurs qui conviennent pour les Name (Nom), Port (Port) et Binding Group (Groupe de liaisons).
       3. Cliquer sur le bouton Save pour terminer.

    5. Modifier la liaison de socket

       1. Sélectionner la liaison de sockets de la liste et cliquer sur le bouton Edit.
       2. Saisir les valeurs qui conviennent pour les Name (Nom), Interface (Interface) ou Port (Port).
       3. Cliquer sur le bouton Save pour terminer.

• Configurer Port Offset (valeurs de décalage de ports)

  Sélectionner l'interface CLI ou la console de gestion pour configurer vos valeurs de décalage de ports.

  • Configurer Port Offsets par l'interface CLI

    Sélectionner l'interface CLI pour configurer vos ports offsets.

    1. Modifier les Ports Offsets

       Utiliser l'opération write-attribut pour écrire une nouvelle valeur référence de port. L'exemple suivant met à jour la valeur du socket-binding-port-offset de server-two à 250. Ce serveur est membre du groupe hôte local par défaut. Un redémarrage est nécessaire pour que les modifications puissent prendre effet.

       [domain@localhost:9999 /] /host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)

    2. Confirmer les attributs d'un Port Offset

       Confirmer que les valeurs ont changé en exécutant read-resource accompagné du paramètre include-runtime=true pour exposer toutes les valeurs actives en cours du modèle de serveur.

       [domain@localhost:9999 /] /host=master/server-config=server-two/:read-resource(include-runtime=true)

  • Configurer les valeurs de décalage de ports par la console de gestion

    Sélectionner la console de gestion pour configurer vos valeurs de décalage de ports.

    1. Connectez-vous à la console de gestion.

       Connectez-vous à la console de gestion de votre domaine géré.

    2. Sélectionner l'onglet Domain

       Sélectionner l'onglet Domain en haut de l'écran.

    3. Modifier les attributs de Port Offset

       1. Sélectionner le serveur dans la liste Available Server Configurations et cliquer sur Edit en haut de la liste des attributs en dessous.
       2. Saisir les valeurs que vous désirez dans le champ Port Offset.
       3. Cliquer sur le bouton Save pour terminer.

Procédure 5.1. Désactiver la propriété IPv4 Stack Java

1. Ouvrir le fichier qui convient à l'installation :

   • Pour le serveur autonome :

     Ouvrir EAP_HOME/bin/standalone.conf.

   • Pour un domaine géré :

     Ouvrir EAP_HOME/bin/domain.conf.
2. Modifier la propriété IPv4 Stack Java à false :

   -Djava.net.preferIPv4Stack=false

   Par exemple :

   Exemple 5.8. Options JVM

   # Specify options to pass to the Java VM.
   #
   if [ "x$JAVA_OPTS" = "x" ]; then
      JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
      -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
      -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
   fi
   

Procédure 5.2. Configurer l'interface du réseautage IPv6

1. Sélectionner Configuration qui se trouve en haut de l'écran.
2. Étendre le menu General Configuration et sélectionnez Interfaces.
3. Sélectionner l'interface dans la liste Available Interfaces.
4. Cliquer sur Edit dans la liste d'informations.
5. Définir l'adresse inet à :

   ${jboss.bind.address.management:[ADDRESS]}

6. Cliquer sur le bouton Save pour terminer.
7. Démarrer le serveur à nouveau pour implémenter les changements.

Procédure 5.3. Configuration de l'installation JBoss EAP 6 pour qu'elle préfère les adresses IPv6

1. Ouvrir le fichier qui convient à l'installation :

   • Pour le serveur autonome :

     Ouvrir EAP_HOME/bin/standalone.conf.

   • Pour un domaine géré :

     Ouvrir EAP_HOME/bin/domain.conf.
2. Ajouter la propriété Java suivante aux options de la Java VM

   -Djava.net.preferIPv6Addresses=true

   Par exemple :

   Exemple 5.9. Options JVM

   # Specify options to pass to the Java VM.
   #
   if [ "x$JAVA_OPTS" = "x" ]; then
      JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
      -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
      -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
   fi
   

Procédure 6.1. Modifier le JAR du pilote JDBC

1. Modifier ou créer un répertoire temporaire vide.
2. Créer un sous-répertoire META-INF.
3. Créer un sous-répertoire META-INF/services.
4. Créer un fichier META-INF/services/java.sql.Driver qui contienne une ligne indiquant le nom de classe complet du pilote JDBC.
5. Utiliser l'outil de ligne de commande du JAR pour mettre à jour le JAR ainsi :

   jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver

6. Section 3.4.2, « Se connecter à la console de gestion »
7. Si vous utilisez un domaine géré, déployez le fichier JAR dans un groupe de serveurs. Sinon, déployez-le sur votre serveur. Voir Section 10.2.2, « Activer une application déployée à l'aide de la console de gestion ».

Procédure 6.2. Installer un pilote JDBC comme core module

1. Créer une structure de chemin d'accès de fichier sous le répertoire EAP_HOME/modules/. Ainsi, pour un pilote MySQL JDBC, créer une structure de répertoire comme suit : EAP_HOME/modules/com/mysql/main/.
2. Copier le pilote JDBC dans le sous-répertoire main/.
3. Dans le sous-répertoire main/, créer un fichier module.xml ressemblant à l'exemple qui se trouve Section 7.1.1, « Modules ». Le module XSD est défini dans le fichier EAP_HOME/docs/schema/module-1_2.xsd.
4. Démarrer le serveur.
5. Démarrer l'interface CLI.
6. Exécuter la commande CLI pour ajouter le module de pilote JDBC à la configuration du serveur.
   La commande que vous avez choisie dépend du nombre de classe listées dans le fichier /META-INF/services/java.sql.Driver qui se situe dans le JAR du pilote JDBC. Par exemple, le fichier /META-INF/services/java.sql.Driver du JAR JDBC MySQL 5.1.20 liste deux classes  :

   • com.mysql.jdbc.Driver
   • com.mysql.fabric.jdbc.FabricMySQLDriver

   Quand il n'y a plus d'une entrée, vous devez également spécifier le nom de la classe de pilote. Sinon, vous provoquerez une erreur semblable à ce qui suit :

   Exemple 6.1. Erreur de classe de pilote

   JBAS014749: Operation handler failed: Service jboss.jdbc-driver.mysql is already registered

   • Exécuter la commande CLI pour les JAR JDBC qui contiennent une entrée de classe.

     /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME)

     Exemple 6.2. Commande CLI en mode autonome pour les JAR JDBC ayant une classe de pilote.

     /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)

     Exemple 6.3. Commande CLI en mode de domaine pour les JAR JDBC ayant une classe de pilote.

     /profile=ha/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)

   • Exécuter la commande CLI pour les JAR JDBC qui contiennent plusieurs entrées de classe.

     /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME, driver-class-name=DRIVER_CLASS_NAME)

     Exemple 6.4. Commande CLI en mode autonome pour les JAR JDBC ayant plusieurs classes de pilote.

     /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)

     Exemple 6.5. Commande CLI en mode de domaine pour les JAR JDBC ayant plusieurs classes de pilote.

     /profile=ha/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)

Procédure 6.3. Ajouter une dépendance à l'application

• • Configurer le fichier MANIFEST.MF

    1. Ouvrir le fichier META-INF/MANIFEST.MF de l'application dans un éditeur de texte.
    2. Ajouter une dépendance au module JDBC et sauvegarder le fichier.

       Dépendences : MODULE_NAME

       Exemple 6.6. Fichier MANIFEST.MF avec com.mysql déclaré comme dépendance.

       Dépendences : com.mysql

  • 1. Créer un fichier jboss-deployment-structure.xml

       Créer un fichier jboss-deployment-structure.xml dans le dossier META-INF/ ou WEB-INF de l'application.

       Exemple 6.7. Fichier jboss-deployment-structure.xml avec com.mysql déclaré comme dépendance.

       <jboss-deployment-structure>
         <deployment>
           <dependencies>
             <module name="com.mysql" />
           </dependencies>
         </deployment>
       </jboss-deployment-structure>

Procédure 6.4. Créer une source de données en utilisant l'interface CLI ou la console de gestion

• • Interface CLI

    1. Lancer le CLI et connectez-vous à votre serveur.
    2. Exécuter la commande d'interface de gestion CLI suivante pour créer une source de données non-XA, et configurer les variables comme il se doit :

       Note

       La valeur de DRIVER_NAME (nom de pilote) dépend du nombre de classes répertoriées dans le fichier /META-INF/services/java.sql.Driver situé dans le JAR du pilote JDBC. S'il n'y a qu'une seule classe, la valeur correspondra au nom du JAR. S'il y a plusieurs classes, la valeur correspondra au nom du JAR + driverClassName + « _ » + majorVersion + « _ » + minorVersion. Toute erreur provoquera l'erreur suivante dans le journal :

       JBAS014775:    New missing/unsatisfied dependencies

       Par exemple, la valeur de DRIVER_NAME qu'il nous faut pour le pilote MySQL 5.1.31 est mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1.

       data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME  --connection-url=CONNECTION_URL

    3. Activer la source de données :

       data-source enable --name=DATASOURCE_NAME

  • Console de gestion

    1. Connectez-vous à la console de gestion.

    2. Naviguer dans le panneau Datasources qui se trouve dans la console de gestion

       1. Sélectionner Configuration qui se trouve en haut de la console.
       2. En mode de domaine uniquement, sélectionner un profil à partir du menu déroulant qui se trouve en haut et à gauche.
       3. Étendre le menu Subsystems qui se trouve à gauche de la console, puis étendre le menu Connector.
       4. Sélectionner Datasources à partir du menu à gauche de la console.

    3. Créer une nouvelle source de données

       1. Cliquer sur Add qui se trouve en haut du panneau Datasources.
       2. Saisir les attributs de la nouvelle source de données de l'assistant Create Datasource et appuyez sur Next.
       3. Saisir les informations sur le pilote JDBC dans l'assistant Create Datasource et cliquer sur Next pour continuer.
       4. Saisir les paramètres de connexion dans l'assistant Create Datasource.
       5. Cliquer sur le bouton Test Connection pour tester la connexion à la ressource de données et vérifier que les paramètres de configuration sont corrects.
       6. Cliquer sur Done pour terminer.

Procédure 6.5. Modifier une source de données non-XA

• • Interface CLI

    1. Section 3.5.2, « Lancement de l'interface CLI ».
    2. Utiliser la commande write-attribute pour configurer un attribut de source de données :

       /subsystem=datasources/data-source=DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)

    3. Charger à nouveau le serveur pour confirmer les changements :

       :reload

  • Console de gestion

    1. Section 3.4.2, « Se connecter à la console de gestion ».

    2. Naviguer dans le panneau Datasources qui se trouve dans la console de gestion

       1. Sélectionner Configuration qui se trouve en haut de la console.
       2. En mode de domaine uniquement, sélectionner un profil à partir du menu déroulant qui se trouve en haut et à gauche.
       3. Étendre le menu Subsystems qui se trouve à gauche de la console, puis étendre le menu Connector.
       4. Sélectionner Datasources à partir du menu déroulant.

    3. Modifier la source de données

       1. Sélectionner une source de données dans la liste Available Datasources. Les attributs de source de données sont affichés ci-dessous.
       2. Cliquer sur Edit pour modifier les attributs de la source de données.
       3. Cliquer sur le bouton Save pour terminer.

Procédure 6.6. Supprimer une source de données non-XA

• • Interface CLI

    1. Section 3.5.2, « Lancement de l'interface CLI ».
    2. Exécuter la commande suivante pour supprimer une source de données non-XA :

       data-source remove --name=DATASOURCE_NAME

  • Console de gestion

    1. Section 3.4.2, « Se connecter à la console de gestion ».

    2. Naviguer dans le panneau Datasources qui se trouve dans la console de gestion

       1. Sélectionner Configuration qui se trouve en haut de la console.
       2. En mode de domaine uniquement, sélectionner un profil à partir du menu déroulant qui se trouve en haut et à gauche.
       3. Étendre le menu Subsystems qui se trouve à gauche de la console, puis étendre le menu Connector.
       4. Sélectionner Datasources.
    3. Sélectionner la source de données enregistrée à supprimer, et cliquer sur Remove.

Procédure 6.7. Créer une source de données XA en utilisant l'interface CLI ou la console de gestion

• • Interface CLI

    1. Section 3.5.2, « Lancement de l'interface CLI ».
    2. Exécuter la commande d'interface de gestion CLI suivante pour créer une source de données XA, et configurer les variables comme il se doit :

       Note

       La valeur de DRIVER_NAME (nom de pilote) dépend du nombre de classes répertoriées dans le fichier /META-INF/services/java.sql.Driver situé dans le JAR du pilote JDBC. S'il n'y a qu'une seule classe, la valeur correspondra au nom du JAR. S'il y a plusieurs classes, la valeur correspondra au nom du JAR + driverClassName + « _ » + majorVersion + « _ » + minorVersion. Toute erreur provoquera l'erreur suivante dans le journal :

       JBAS014775:    New missing/unsatisfied dependencies

       Par exemple, la valeur de DRIVER_NAME qu'il nous faut pour le pilote MySQL 5.1.31 est mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1.

       xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS

    3. Configurer les propriétés de la source de données XA

       1. Définir le nom du serveur

          Exécuter la commande suivante pour configurer le nom du serveur de l'hôte :

          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOSTNAME)

       2. Définir le nom de la base de données

          Exécuter la commande suivante pour configurer le nom de la base de données :

          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)

    4. Activer la source de données :

       xa-data-source enable --name=XA_DATASOURCE_NAME

  • Console de gestion

    1. Section 3.4.2, « Se connecter à la console de gestion ».

    2. Naviguer dans le panneau Datasources qui se trouve dans la console de gestion

       1. Sélectionner Configuration qui se trouve en haut de la console.
       2. En mode de domaine uniquement, sélectionner un profil à partir du menu déroulant qui se trouve en haut et à gauche.
       3. Étendre le menu Subsystems qui se trouve à gauche de la console, puis étendre le menu Connector.
       4. Sélectionner Datasources.
    3. Sélectionner l'onglet XA Datasource.

    4. Créer une nouvelle source de données XA

       1. Cliquer sur Add.
       2. Saisir les attributs de la nouvelle source de données XA de l'assistant Create XA Datasource et cliquer sur Next.
       3. Saisir les informations sur le pilote JDBC dans l'assistant Create XA Datasource et cliquer sur Next.
       4. Saisir les propriétés XA et cliquer sur Next.
       5. Saisir les paramètres de connexion dans l'assistant Create XA Datasource.
       6. Cliquer sur le bouton Test Connection pour tester la connexion à la ressource de données XA et vérifier que les paramètres de configuration soient corrects.
       7. Cliquer sur Done pour terminer.

Procédure 6.8. Modifier une source de données XA en utilisant l'interface CLI ou la console de gestion

• • L'interface CLI

    1. Section 3.5.2, « Lancement de l'interface CLI ».

    2. Configurer les attributs de source de données XA

       Utiliser la commande write-attribute pour configurer un attribut de source de données :

       /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)

    3. Configurer les propriétés de la source de données XA

       Exécuter la commande suivante pour configurer une sous-ressource de source de données XA :

       /subsystem=datasources/xa-data-source=DATASOURCE_NAME/xa-datasource-properties=PROPERTY_NAME:add(value=PROPERTY_VALUE)

    4. Charger à nouveau le serveur pour confirmer les changements :

       :reload

  • Console de gestion

    1. Section 3.4.2, « Se connecter à la console de gestion ».

    2. Naviguer dans le panneau Datasources qui se trouve dans la console de gestion

       1. Sélectionner Configuration qui se trouve en haut de la console.
       2. En mode de domaine uniquement, sélectionner un profil à partir du menu déroulant qui se trouve en haut et à gauche.
       3. Étendre le menu Subsystems qui se trouve à gauche de la console, puis étendre le menu Connector .
       4. Sélectionner Datasources.
    3. Sélectionner l'onglet XA Datasource.

    4. Modifier la source de données

       1. Sélectionner la source de données XA qui convient à partir de la liste Available XA Datasources. Les attributs de la source de données XA sont affichés dans le panneau Attributes ci-dessous.
       2. Sélectionner le bouton Edit pour modifier les attributs de la source de données.
       3. Modifier les attributs de la source de données XA et sélectionner le bouton Save quand c'est fait.

Procédure 6.9. Supprimer une source de données XA en utilisant l'interface CLI ou la console de gestion

• • Management CLI

    1. Section 3.5.2, « Lancement de l'interface CLI ».
    2. Exécuter la commande suivante pour supprimer une source de données :

       xa-data-source remove --name=XA_DATASOURCE_NAME

  • Console de gestion

    1. Section 3.4.2, « Se connecter à la console de gestion ».

    2. Naviguer dans le panneau Datasources qui se trouve dans la console de gestion

       1. Sélectionner Configuration qui se trouve en haut de la console.
       2. En mode de domaine uniquement, sélectionner un profil à partir du menu déroulant qui se trouve en haut et à gauche.
       3. Étendre le menu Subsystems qui se trouve à gauche de la console, puis étendre le menu Connector.
       4. Sélectionner Datasources.
    3. Sélectionner l'onglet XA Datasource.
    4. Sélectionner la source de données XA enregistrée à supprimer, et cliquer sur le bouton Remove pour supprimer la source de données XA de façon permanente.

Procédure 6.10. Configuration des paramètres de validation de connexion de la base de données

1. Choisissez une méthode de validation

   Veuillez sélectionner une des méthodes de validation suivantes.

   • <validate-on-match>true</validate-on-match>

     Lorsque l'option < validate-on-match > a comme valeur true, la connexion à la base de données est validée à chaque retrait du pool de connexions en utilisant le mécanisme de validation spécifié à l'étape suivante.
     Si une connexion n'est pas valide, un avertissement sera inscrit dans le journal et la prochaine connexion sera extraite du pool. Ce processus se poursuit jusqu'à ce qu'une connexion valide soit enfin trouvée. Si vous préférez ne pas faire défiler chaque connexion du pool, vous pouvez utiliser l'option <use-fast-fail>. Si on ne trouve pas de connexion valide dans le pool, une nouvelle connexion sera créée. Si la création de la connexion échoue, une exception sera retournée à l'application qui en a fait la demande.
     Ce paramètre entraîne une récupération plus rapide, mais crée une charge plus élevée sur la base de données. Cependant, c'est la sélection la plus sûre si une baisse de performance minimale n'est pas un sujet de préoccupation.

   • <background-validation>true</background-validation>

     Lorsque l'option < >background-validation a comme valeur true, il est utilisé en combinaison à la valeur <background-validation-millis> pour déterminer la fréquence d'exécution de l'information en d'arrière-plan. La valeur par défaut du paramètre <background-validation-millis> est de 0 millisecondes, ce qui signifie que c'est désactivé par défaut. Cette valeur ne doit pas être à la même valeur que celle du paramètre < idle-timeout-minutes >.
     Il est délicat de déterminer la valeur optimale de <background-validation-millis> pour un système particulier. Plus la valeur est faible, le plus fréquemment le pool sera validé et le plus rapidement les connexions plus tôt non valides sont supprimées de la piscine. Cependant, des valeurs les plus faibles prennent davantage de ressources de base de données. En outre, les valeurs élevées ont des contrôles de validation de connexion plus fréquents et utilisent moins de ressources de base de données, mais les liens morts demeurent indétectables pendant de plus longues périodes.

   Note

   Si l'option <validate-on-match> est définie à true, l'option <background-validation> devra être définie à false. Le contraire est vrai également. Si l'option <background-validation> est définie à true, l'option <validate-on-match> devra être définie à false.

2. Choisir un mécanisme de validation

   Veuillez sélectionner un des mécanismes de validation suivants.

   • Spécifier un Nom de classe <valid-connection-checker>

     Il s'agit du mécanisme préféré car il est optimisé pour un RBMS particulier. JBoss EAP 6 fournit les vérificateurs de connexions suivants :

     • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker

   • Indiqué l'énoncé SQL pour <check-valid-connection-sql>

     Vous fournissez l'énoncé SQL utilisé pour valider la connexion.
     Ce qui suit est un exemple qui vous montre comment spécifier un énoncé SQL pour valider une connexion dans Oracle :

     <check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>

     Dans MySQL ou PostgreSQL, vous pouvez spécifier l'énoncé SQL suivant :

     <check-valid-connection-sql>select 1</check-valid-connection-sql>

3. Définir le Nom de classe <exception-sorter>

   Lorsqu'une exception est marquée comme étant fatale, la connexion est fermée immédiatement, même si la connexion participe à une transaction. Utilisez l'option de classe de triage d'exception trieuse pour détecter correctement et ensuite nettoyer les exceptions de connexion fatales. JBoss EAP 6 fournit les trieurs d'exception suivants :

   • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.informix.InformixExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter

• /subsystem=datasources/data-source=ExampleDS/statistics=pool:write-attribute(name=statistics-enabled,value=true)
  

  /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:write-attribute(name=statistics-enabled,value=true)