Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

Guide d'administration et de configuration

JBoss Enterprise Application Platform 6.4

À utiliser dans Red Hat JBoss Enterprise Application Platform 6

Red Hat Customer Content Services

Résumé

Cet ouvrage est un guide d'administration et de configuration de Red Hat JBoss Enterprise Application Platform 6, qui inclut des correctifs publiés.

Chapitre 1. Introduction

1.1. Red Hat JBoss Enterprise Application Platform 6

Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6) est une plate-forme middleware générée sur la base de standards ouverts et compatibles avec Java Enterprise Edition 6. Elle intègre JBoss Application Server 7 avec un clustering de haute disponibilité, une messagerie, une mise en cache distribuée et autres technologies.
JBoss EAP 6 comprend une nouvelle structure modulaire qui permet aux services d'être activés seulement si nécessaire, améliorant ainsi la vitesse de démarrage.
La console de gestion et l'interface en ligne de commmandes (CLI) rendent la modification des fichiers de configuration XML inutile et rajoutent la capacité d'encoder et d'automatiser des tâches.
En plus, JBoss EAP 6 comprend des frameworks de développement et des API pour développer rapidement des applications de Java EE sécurisées et évolutives.

1.2. Les fonctionnalités de JBoss EAP 6

Tableau 1.1. Fonctionnalités de JBoss EAP 6

Fonctionnalité Description
Certification Java JBoss Enterprise Application Platform 6 Full Profil et Web Profile certifiés.
Domaine géré
  • Un domaine géré procure une gestion centralisée d'instances de serveurs multiples et d'hôtes physiques, tandis qu'un serveur autonome autorise une instance de serveur unique.
  • Gestion de groupe de configuration par-serveur, déploiement, liaisons de socket, modules, extensions et propriétés système.
  • Gestion centralisée et simplifiée de la sécurité des applications (y compris les domaines de sécurité).
Console de gestion et interface CLI Interfaces de gestion de serveur autonome ou nouveaux domaines. L'édition des fichiers de configuration XML n'est plus nécessaire. L'interface CLI comprend également un mode batch qui peut encoder et automatiser les tâches de gestion.
La disposition du répertoire est simplifiée Le répertoire modules contient maintenant les modules du serveur d'applications. Les répertoires communs et spécifiques au serveur lib sont obsolètes. Les répertoires domain et standalone contiennent les artefacts et les fichiers de configuration pour les déploiements autonomes et de domaine respectivement.
Mécanisme de chargement de classes modulaire Les modules sont chargés et déchargés à la demande. Cela améliore la performance et la sécurité, et permet des démarrages et redémarrages plus rapides.
Gestion des sources de données simplifiée Les pilotes de base de données peuvent être déployés comme tout autre service. En plus, les sources de données sont créées et gérées directement dans la console de gestion ou l'interface CLI.
Utilisation réduite et plus efficace des ressources JBoss EAP 6 utilise moins de ressources système et les utilise plus efficacement que dans les versions précédentes. Entre autres avantages, JBoss EAP 6 démarre et s'arrête plus rapidement que JBoss EAP 5.

1.3. JBoss EAP 6 Operating Modes

JBoss EAP 6 fournit deux modes d'opération pour les instances de JBoss EAP 6 : serveur autonome ou domaine géré.
Les deux modes diffèrent dans la façon dont les serveurs sont gérés, pas dans leur capacité à traiter les demandes de l'utilisateur final. Il est important de noter que la fonctionnalité de cluster de haute disponibilité (HA) est disponible avec les deux modes de fonctionnement. Un groupe de serveurs autonomes peut être configuré pour former un cluster HA.

1.4. Les serveurs autonomes

Un mode de serveur autonome est un processus indépendant qui ressemble au mode d'exécution unique des anciennes versions de JBoss EAP.
L'instance de JBoss EAP 6 qui exécute en tant que serveur autonome est une instance unique, qui peut exécuter optionnellement dans une configuration clusterisée.

1.5. Les domaines gérés

Le mode d'opération d'un domaine géré permet la gestion de multiples instances de JBoss EAP 6 à partir d'un seul point de contrôle.
Les collections de serveur JBoss EAP 6 centralement gérées sont connues comme membres d'un domaine. Toutes les instances JBoss EAP 6 d'un domaine partagent une stratégie de gestion en commun.
Un domaine consite en un contrôleur de domaine, un ou plusieurs controleur(s) hôte(s), et zéro ou plusieurs groupes de serveurs par hôte.
Un contrôleur de domaine est un point central à partir duquel le domaine est contrôlé. Il s'assure que chaque serveur est configuré suivant la stratégie de gestion du domaine. Le contrôleur du domaine est également un contrôleur hôte.
Un contrôleur hôte est un hôte physique ou virtuel sur lequel le script domain.sh ou domain.bat exécute. Les contrôleurs hôtes sont configurés pour déléguer les tâches de gestion de domaine au contrôleur de domaine.
Le contrôleur hôte de chaque hôte interagit avec le contrôleur de domaine pour contrôler le cycle de vie des instances de serveur de l'application exécutant sur son hôte et pour aider le contrôleur de domaine à les gérer. Chaque hôte peut contenir plusieurs groupes de serveurs.
Un groupe de serveurs est un ensemble d'instances de serveurs avec JBoss EAP 6 installé dessus, et qui sont gérées et configurées comme une entité unique. Le contrôleur de domaine gère la configuration et les applications déployées sur les groupes de serveurs. Ainsi, chaque serveur dans un groupe de serveurs partage les mêmes configurations et déploiements.
Il est possible qu'un contrôleur de domaine, un contrôleur hôte unique et plusieurs serveurs s'exécutent dans la même instance de JBoss EAP 6, sur le même système physique.
Les contrôleurs hôtes sont liés à des hôtes physiques (ou virtuels) spécifiques. Vous pouvez exécuter plusieurs contrôleurs hôtes sur le même matériel si vous utilisez différentes configurations, afin d'éviter que les ports et autres ressources n'entrent en conflit.
A managed domain with one domain controller, three host controllers, and three server groups. Servers are members of server groups, and may be located on any of the host controllers in the domain.

Figure 1.1. Représentation graphique d'un domaine géré

1.6. Contrôleur de domaine

Un contrôleur de domaine est une instance de serveur de JBoss EAP 6 qui agit en tant que point central de gestion pour un domaine. Une instance de contrôleur hôte est configurée pour agir en tant que contrôleur de domaine.
Les responsabilités principales d'un contrôleur de domaine sont les suivantes :
  • Maintenir la politique centrale de gestion du domaine.
  • S'assurer que tous les contrôleurs soient mis au courant de son contenu actuel.
  • Assister tous les contrôleurs pour que toutes les instances en cours de JBoss EAP 6 soient configurées suivant cette stratégie.
La stratégie de gestion centrale est stockée par défaut dans le fichier domain/configuration/domain.xml. Ce fichier est le fichier d'installation JBoss EAP 6 non compressé, qui se trouve sur le système de fichiers de l'hôte du contrôleur de domaines.
Une fichier domain.xml doit se trouver dans le répertoire domain/configuration/ du contrôleur hôte défini pour exécuter en tant que contrôleur de domaine. Ce fichier n'est pas obligatoire pour les installations sur les contrôleurs hôtes qui ne sont pas sensés exécuter en tant que contrôleurs de domaines. Cependant, la présence d'un fichier domain.xml sur un tel serveur n'a aucun effet néfaste.
Le fichier domain.xml contient les configurations de profil qui peuvent être exécutées sur les instances de serveur dans un domaine. Une configuration de profil inclut les paramètres détaillés des différents sous-systèmes qui composent un profil. La configuration de domaine inclut également la définition des groupes de sockets et les définitions de groupes de serveurs.

1.7. Domain Controller Discovery et Failover

Lorsque vous configurez un domaine géré, chaque contrôleur hôte doit être configuré avec les informations nécessaires pour communiquer avec le contrôleur de domaine. Dans JBoss EAP 6, chaque contrôleur hôte peut être configuré avec de multiples options pour trouver le contrôleur de domaine. Les contrôleurs hôtes peuvent parcourir la liste des options jusqu'à ce qu'une d'entre elle réussisse.
Cela permet aux contrôleurs hôtes d'être pré configurés avec des informations de contact d'un contrôleur de domaine secondaire. Un contrôleur hôte de sauvegarde peut être promu pour maîtriser s'il y a un problème avec le contrôleur de domaine principal, permettant aux contrôleurs hôtes de basculer automatiquement vers le nouveau master une fois qu'il a été promu.
Ce qui suit est un exemple sur la façon de configurer un contrôleur hôte avec des options multiples pour trouver le contrôleur de domaine.

Exemple 1.1. Contrôleur d'hôte configuré avec de nombreuses options de contrôleur de domaine

<domain-controller>  
    <remote security-realm="ManagementRealm">  
          <discovery-options>  
              <static-discovery name="primary" host="172.16.81.100" port="9999"/>  
              <static-discovery name="backup" host="172.16.81.101" port="9999"/>  
          </discovery-options>  
    </remote>  
</domain-controller>
Une option discovery statique inclut les attributs obligatoires suivants :

name
Le nom de cette option discovery de contrôleur de domaine
host
Le nom d'hôte du contrôleur de domaine distant.
Important
Le port du contrôleur de domaine distant.
Dans l'exemple suivant, la première option discovery est celle avec laquelle on attent un résultat positif. La seconde peut être utilisée pour les situations d'échec.
Si un problème survient avec le contrôleur principal de domaine, un contrôleur hôte qui a été démarré avec l'option --backup pourra être promu pour agir comme contrôleur de domaine.

Note

À partir d'un contrôleur hôte avec l'option --backup qui entraînera ce contrôleur à conserver une copie locale de la configuration du domaine. Cette configuration servira si le contrôleur hôte est reconfiguré pour pouvoir agir comme contrôleur de domaine.

Procédure 1.1. Promouvoir un contrôleur hôte comme contrôleur de domaine

  1. Assurez-vous que le contrôleur de domaine d'origine a, ou est, arrêté.
  2. Utiliser l'interface CLI pour vous connecter au contrôleur hôte qui deviendra le nouveau contrôleur de domaine.
  3. Exécutez la commande suivante pour configurer le contrôleur hôte pour qu'il agisse comme nouveau contrôleur de domaine.
    /host=HOST_NAME:write-local-domain-controller
  4. Exécutez la commande suivante pour rechercher le contrôleur hôte.
    reload --host=HOST_NAME
Le contrôleur hôte choisi à l'étape 2 agira maintenant en tant que contrôleur de domaine.

1.8. Contrôleur hôte

Un contrôleur hôte est lancé quand le script domain.sh ou domain.bat exécute. sur un hôte.
Le principale responsabilité d'un contrôleur hôte est la gestion de serveurs. Il délègue les tâches de gestion de domaines et est chargé de démarrer ou stopper les processus de serveurs d'application individuels qui exécutent sur son hôte.
Il entre en interaction avec le contrôleur de domaines pour gérer la communication entre les serveurs et le contrôleur de domaines. Plusieurs contrôleurs hôtes d'un domaine peuvent interagir avec un contrôleur de domaine unique. Par conséquent, tous les contrôleurs hôtes et les instances de serveurs exécutant en mode de domaine unique ont un contrôleur de domaine unique et doivent appartenir au même domaine.
Chaque contrôleur hôte lit par défaut sa configuration à partir du fichier domain/configuration/host.xml situé dans le fichier d'installation de JBoss EAP 6 décompressé sur le système de fichiers de son hôte. Le fichier host.xml contient les informations de configuration suivantes spécifiques à l'hôte particulier :
  • Les noms des instances de JBoss EAP 6 censées être exécutées à partir de l'installation.
  • Une des configurations suivantes :
    • La façon dont le contrôleur contacte le contrôleur de domaines pour s'enregistrer lui-même et pour accéder à la configuration de domaine.
    • La façon de rechercher et contacter un contrôleur de domaines éloigné.
    • Comment le contrôleur hôtes doit se persuader lui-même d'agir en tant que contrôleur de domaines
  • Les configuration spécifiques à l'installation physique locale. Ainsi, les définitions d'interfaces nommées déclarées dans domain.xml peuvent être mappées vers une adresse IP particulière appartenant à une machine dans host.xml. Les noms de chemins d'accès abstraits de domain.xml peuvent être mappés vers les chemins d'accès du système de fichiers dans host.xml.

1.9. Les groupes de serveurs

Un groupe de serveurs est un regroupement d'instances des serveurs qui sont gérés et configurés en un. Dans un domaine géré, chaque instance de serveur d'application appartient à un groupe de serveurs, même s'il en est le seul membre. Les instances de serveur d'un groupe partagent la même configuration de profil et le même contenu déployé.
Un contrôleur de domaines et un contrôleur hôte font appliquer la configuration standard sur toutes les instances de serveur de chaque groupe de serveurs sur son domaine.
Un domaine peut se composer de plusieurs groupes de serveurs. Différents groupes de serveurs peuvent être configurés avec des déploiements et des profils différents. Un domaine peut être configuré avec des niveaux de serveurs différents offrant des services différents.
Différents groupes de serveurs peuvent également avoir les mêmes profils et déploiements. Cela permet, par exemple, le cumul des mises à niveau de l'application quand l'application est mise à jour sur un groupe de serveurs, puis mise à jour sur un deuxième groupe de serveurs, évitant ainsi une interruption complète du service.
Voici un exemple de définition de groupe de serveurs :

Exemple 1.2. Définition de groupe de serveurs

<server-group name="main-server-group" profile="default">
 <socket-binding-group ref="standard-sockets"/>
  <deployments>
   <deployment name="foo.war_v1" runtime-name="foo.war"/>
   <deployment name="bar.ear" runtime-name="bar.ear"/>
  </deployments>
</server-group>
Un groupe de serveurs inclut les attributs obligatoires suivants :
  • nom : le nom du groupe de serveurs
  • profil : le nom du profil du groupe de serveurs
  • socket-binding-group : le nom du groupe de liaisons de sockets par défaut à utiliser pour les serveurs dans le groupe. Ce nom peut être remplacé sur la base d'un serveur dans host.xml. Cependant, c'est un élément obligatoire pour chaque groupe de serveurs et le domaine ne peut pas démarrer s'il n'est pas présent.
Un groupe de serveurs inclut les attributs optionnels suivants :
  • deployments : le contenu de déploiement à déployer sur les serveurs du groupe.
  • system-properties : les propriétés système à définir sur les serveurs du groupe
  • jvm : les paramètres de configuration JMV par défaut de tous les serveurs du groupe. Le contrôleur hôte fait fusionner ces paramètres dans n'importe quelle configuration fournie par host.xml pour établir les paramètres utilisés dans la JVM du serveur.
  • socket-binding-port-offset: le décallage par défaut à ajouter aux valeurs de port données par le groupe de liaisons de sockets.
  • management-subsystem-endpoint: défini à true pour que les serveurs qui appartiennent au groupe de serveurs puissent se connecter à nouveau au contrôleur de l'hôte en utilisant le point de terminaison du sous-système distant (le sous-système distant doit être présent pour que cela fonctionne).

1.10. Profils JBoss EAP 6

Le concept des profils qui ont été utilisés dans les versions précédentes de JBoss EAP n'est plus utilisé. JBoss EAP 6 utilise maintenant un petit nombre de fichiers de configuration simples pour contenir toutes les informations de configuration.
Les modules et les pilotes sont chargés en fonction des besoins, donc le concept du profil par défaut utilisé dans les anciennes versions de JBoss EAP 6 où les profils étaient utilisés pour rendre le démarrage du serveur plus performant n'est pas très utile.
Au moment du déploiement, les dépendances du module sont définies, ordonnancées, et résolues par le serveur ou le contrôleur du domaine, et chargées dans le bon ordre. Les modules sont retirés du chargement quand ils ne sont plus utiles à aucun déploiement.
Il est possible de désactiver les modules ou de décharger les pilotes ou autres services manuellement en retirant les sous-systèmes de la configuration. Cependant, dans la plupart des cas, cela n'est pas utile. Si aucune de vos applications utilisent un module, il ne sera pas chargé.

Chapitre 2. Gestion de serveurs d'applications

2.1. Conventions pour la documentation JBoss EAP

Toutes les instances d' EAP_HOME de ce guide se rapportent au répertoire d'installation root de JBoss EAP, suivant la méthode que vous utilisez.

Méthode d'installation en téléchargement compressé
EAP_HOME est le répertoire à partir duquel le fichier JBoss EAP Zip est extrait.
Méthode d'installation par interface de commandes CLI ou par le GUI
EAP_HOME est le répertoire dans lequel vous décidez d'installer JBoss EAP.
Méthode d'installation RPM
EAP_HOME se rapporte au répertoire /usr/share/jbossas.

Note

L'annotation EWS_HOME est utilisée en référence aux emplacements d'installation de JBoss EWS, en suivant les mêmes conventions définies ci-dessus pour JBoss EAP.

2.2. Démarrer et stopper JBoss EAP 6

2.2.2. Démarrez JBoss EAP 6 comme un serveur autonome

Résumé

Cette rubrique couvre toutes les étapes à couvrir pour démarrer JBoss EAP 6 en tant que serveur autonome.

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.
Résultat

L'instance de serveur autonome JBoss EAP 6 démarre.

2.2.3. Démarrez JBoss EAP 6 comme domaine géré

Ordre des opérations

Le contrôleur de domaines doit être démarré avant qu'un serveur esclave ne démarre dans des groupes de serveurs du domaine. Utiliser cette procédure sur le contrôleur de domaine pour commencer, puis, sur chaque contrôleur hôte associé et sur chaque hôte associé.

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.
Résultat

L'instance de domaine géré de JBoss EAP 6 démarre.

2.2.4. Configuration d'un nom d'hôte dans un domaine géré

Résumé

Chaque hôte exécutant dans un domaine géré doit avoir un nom d'hôte unique. Pour faciliter l'administration et permettre l'utilisation de mêmes fichiers de configuration hôte sur plusieurs hôtes, le serveur utilise la priorité suivante pour déterminer le nom d'hôte.

  1. Si défini, l'attribut de nom de l'élément hôte qui se trouve dans le fichier de configuration host.xml.
  2. La valeur de la propriété système jboss.host.name.
  3. La valeur qui suit le caractère (".") dans la propriété système jboss.qualified.host.name, ou toute la valeur s'il n'y a pas de point final (".").
  4. La valeur qui suit le caractère (".") dans la variable d'environnement HOSTNAME pour les systèmes d'exploitation basés POSIX, la variable d'environnement COMPUTERNAME dans Microsoft Windows, ou toute la valeur s'il n'y a pas de point final (".")

Pour obtenir des informations sur la façon de définir les variables d'environnement, voir la documentation de votre système d'exploitation. Pour plus d'informations sur la façon de définir les propriétés système, voir Section 3.6.11, « Configurer les propriétés système par l'interface CLI ».
Cette section décrit comment fixer le nom de l'hôte dans le fichier de configuration, à l'aide d'une propriété système ou d'un nom codé en dur.

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

2.2.5. Créer un domaine géré sur deux machines

Note

Vous devrez sans doute configurer votre pare-feu pour qu'il puisse exécuter cet exemple.
Vous pouvez créer un domaine géré sur deux machines, avec une machine en tant que contrôleur de domaine, et l'autre en tant qu'hôte. Pour plus d'informations, voir Section 1.6, « Contrôleur de domaine ».
  • IP1 = adresse IP du contrôleur de domaine (Machine 1)
  • IP2 = adresse IP de l'hôte (Machine 2)

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/
    

2.2.6. Démarrer JBoss EAP 6 avec une configuration différente

Si vous n'indiquez pas de fichier de configuration, le serveur démarrera avec le fichier par défaut. Cependant, quand vous démarrez le serveur, vous pouvez spécifier Configuration manuelle. Le processus varie légèrement, suivant que vous utilisez un Domaine géré ou un Serveur autonome, et suivant le système d'exploitation que vous utilisez.

Conditions préalables

  • Avant d'utiliser un fichier de configuration alternatif, préparez-le à l'aide de la configuration par défaut comme modèle. Pour un domaine géré, le fichier de configuration doit être placé dans EAP_HOME/domain/configuration/. Pour les serveurs autonomes, le fichier de configuration devra être mis dans le répertoire EAP_HOME/standalone/configuration/.

Note

Plusieurs exemples de configurations sont inclus dans les répertoires de configuration EAP_HOME/docs/examples/configs/. Utiliser ces exemples pour activer des fonctionnalités supplémentaires, comme clustering ou l'API XTS de Transactions.
Certains des exemples de configurations doivent être modifiés avant d'être utilisés. Les fichiers de configuration suivants produisent des erreurs s'ils sont utilisées sans être modifiés : standalone-picketlink.xml, standalone-genericjms.xml et standalone-hornetq-colocated.xml.

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.
Résultat

La plateforme JBoss Enterprise Application Platform est maintenant en cours d'exécution, avec votre fichier de configuration alternatif.

2.2.7. Stopper le serveur JBoss EAP 6

La façon dont vous arrêtez la plate-forme JBoss EAP 6 dépend de la façon dont elle a été lancée. Cette tâche couvre l'arrêt d'une instance qui a démarré de manière interactive, comment faire cesser une instance qui a été démarrée par un service et comment faire cesser une instance qui a été mise en arrière-plan par un script.

Note

Pour obtenir des informations sur la façon de stopper un serveur ou un groupe de serveurs dans un domaine géré, voir Section 2.3.3, « Stopper un serveur qui utilise une console de gestion ». Pour obtenir des informations sur la façon de stopper un serveur par le CLI, voir Section 2.3.1, « Démarrer et arrêter les serveurs par l'interface CLI ».
  • Procédure 2.7. Stopper une instance de JBoss EAP 6

    • Stopper une instance qui a été démarrée de façon interactive à partir d'une invite de commande.

      Appuyez sur Ctrl-C dans le terminal où JBoss EAP 6 exécute.
  • Procédure 2.8. Stopper une instance qui a démarré en tant que service de système d'exploitation.

    Suivant votre système d'exploitation, utiliser une des procédures suivantes :
      • Red Hat Enterprise Linux

        Dans Red Hat Enterprise Linux, si vous avez écrit un script de service, utiliser sa fonction stop. Cela devra être inscrit dans le script. Ensuite, vous pourrez utiliser service scriptname stop, avec scriptname comme nom de script.
      • Microsoft Windows Server

        Dans Microsoft Windows, utiliser la commande net service, ou bien faites cesser le service à partir de l'applet Services qui se trouve dans le panneau de contrôle.
  • Procédure 2.9. Stopper une instance qui exécute en arrière-plan (Red Hat Enterprise Linux)

    1. Chercher l'ID de processus (PID) du processus :
      • Si une seule instance est en cours d'exécution (mode autonome)

        N'importe laquelle des commandes suivantes renverront le PID d'une simple instance de JBoss EAP 6 :
        • pidof java
        • jps
          (La commande jps retournera un ID des deux processus ; un pour jboss-modules.jar et un pour jps lui-même. Utiliser l'ID de jboss-modules.jar pour stopper l'instance EAP)
      • Si plusieurs instances EAP sont en cours d'exécution (mode de domaine)

        Identifier le process qui convient pour y mettre un terme si plus d'une instance d'EAP en cours d'exécution nécessitent l'utilisation de commandes plus élaborées.
        • La commande jps peut être utilisée en mode détaillé (verbose) pour qu'elle puisse fournir davantage d'informations sur les processus java qu'elle trouve.
          Vous trouverez ci-dessous sous une sortie abrégée d'une commande détaillée jps qui identifie les différents processus d'EAP en cours par PID et rôle :
          $ jps -v
          12155 jboss-modules.jar -D[Server:server-one] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1303m 
          ...
          
          12196 jboss-modules.jar -D[Server:server-two] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1303m 
          ...
          
          12096 jboss-modules.jar -D[Host Controller] -Xms64m -Xmx512m -XX:MaxPermSize=256m 
          ...
          
          11872 Main -Xms128m -Xmx750m -XX:MaxPermSize=350m -XX:ReservedCodeCacheSize=96m -XX:+UseCodeCacheFlushing 
          ...
          
          11248 jboss-modules.jar -D[Standalone] -XX:+UseCompressedOops -verbose:gc 
          ...
          
          12892 Jps 
          ...
          
          12080 jboss-modules.jar -D[Process Controller] -Xms64m -Xmx512m -XX:MaxPermSize=256m 
          ...
          
        • La commande ps aux peut également être utilisée pour renvoyer des informations sur les instances multiples EAP.
          Vous trouverez ci-dessous sous une sortie abrégée d'une commande détaillée ps aux qui identifie les différents processus d'EAP en cours par PID et rôle :
          $ ps aux | grep java
          username 12080  0.1  0.9 3606588 36772 pts/0   Sl+  10:09   0:01 /path/to/java -D[Process Controller] -server -Xms128m -Xmx128m -XX:MaxPermSize=256m 
          ...
          
          username 12096  1.0  4.1 3741304 158452 pts/0  Sl+  10:09   0:13 /path/to/java -D[Host Controller] -Xms128m -Xmx128m -XX:MaxPermSize=256m 
          ...
          
          username 12155  1.7  8.9 4741800 344224 pts/0  Sl+  10:09   0:22 /path/to/java -D[Server:server-one] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1000m -Xmx1000m -server -
          ...
          
          username 12196  1.8  9.4 4739612 364436 pts/0  Sl+  10:09   0:22 /path/to/java -D[Server:server-two] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1000m -Xmx1000m -server 
          ...
          
        Dans les exemples ci-dessus, les processus Process Controller sont des processus à stopper pour stopper tout le domaine.
        L'utilitaire grep peut être utilisé avec une de ces commandes pour identifier le Process Controller :
        jps -v | grep "Process Controller"
        ps aux | grep "Process Controller"
    2. Envoyer le signal TERM au processus en exécutant kill PID, quand PID est l'ID de processus identifié par une des commandes ci-dessus.
Résultat

Chacune de ces solutions ferme la plate-forme JBoss EAP 6 nettement, ce qui fait qu'aucune donnée n'est perdue.

2.2.8. Référence aux variables et arguments à passer à l'exécution du serveur

Le script de démarrage du serveur d'applications accepte l'ajout d'arguments et de variables en cours d'exécution. L'utilisation de ces paramètres permet au serveur d'être démarré sous d'autres configurations que celles qui sont définies dans les fichiers de configuration standalone.xml, domain.xml et host.xml. Cela peut comprendre le démarrage du serveur par un ensemble de liaisons de sockets différentes ou une configuration secondaire. Vous pourrez accéder à une liste des paramètres disponibles en passant la variable d'assistance au démarrage.
L'exemple suivant ressemble au démarrage de serveur expliqué dans Section 2.2.2, « Démarrez JBoss EAP 6 comme un serveur autonome » et Section 2.2.3, « Démarrez JBoss EAP 6 comme domaine géré », avec en plus les variables -h ou --help>. Les résultats de cette variable d'assistance sont expliqués dans le tableau ci-dessous.

Exemple 2.5. Variable d'assistance « help »

Mode autonome :
[localhost bin]$ standalone.sh -h
Mode de domaine :
[localhost bin]$ domain.sh -h

Tableau 2.1. Tableau des arguments et variables du temps d'exécution

Argument ou Option Mode Description
--admin-only Autonome Définir le type d'exécution du serveur à ADMIN_ONLY. Cela le fera ouvrir les interfaces administratives et il pourra ainsi accepter les ordres de gestion, mais il ne pourra pas démarrer d'autres services de runtime ou accepter les demandes de l'utilisateur final.
--admin-only Domaine Définir le type d'exécution du contrôleur hôte à ADMIN_ONLY, ce qui le fera ouvrir les interfaces administratives et il pourra ainsi accepter les ordres de gestion, mais il ne pourra pas démarrer d'autres serveurs ou, si ce contrôleur hôte est le master du domaine, il pourra accepter les demandes des contrôleurs hôte esclaves.
-b <value>, -b=<value> Autonome, Serveur Définir la propriété système jboss.bind.address à la valeur donnée.
-b<interface>=<value> Autonome, Serveur Définir la propriété système jboss.bind.address.<interface> à la valeur donnée.
--backup Domaine Conserver une copie de la configuration de domaine persistante même si cet hôte n'est pas le contrôleur de domaines.
-c <config>, -c=<config> Autonome Nommer le fichier de configuration du serveur à utiliser. La valeur par défaut est standalone.xml.
-c <config>, -c=<config> Domaine Nom du fichier de configuration de serveur à utiliser. La valeur par défaut est domain.xml.
--cached-dc Domaine Si l'hôte n'est pas le contrôleur de domaine et ne peut pas contacter le contrôleur de domaine au démarrage, puisque le processus de démarrage (booting) utilise une copie de la configuration de domaine mise en cache localement.
--debug [<port>] Autonome Active le mode de débogage par un argument en option qui indique le port. Ne fonctionne que si le script de lancement le supporte.
-D<name>[=<value>] Autonome, Serveur Définit une propriété système.
--domain-config=<config> Domaine Nom du fichier de configuration de serveur à utiliser. La valeur par défaut est domain.xml.
-h, --help Autonome, Serveur Affiche le message d'assistance et sortir.
--host-config=<config> Domaine Nom du fichier de configuration hôte à utiliser. La valeur par défaut est host.xml.
--interprocess-hc-address=<address> Domaine Adresse à laquelle le contrôleur hôte doit écouter la communication en provenance du contrôleur de processus.
--interprocess-hc-port=<port> Domaine Port sur lequel le contrôleur hôte doit écouter la communication en provenance du contrôleur de processus.
--master-address=<address> Domaine Définit la propriété système jboss.domain.master.address à la valeur donnée. Dans une configuration de contrôleur hôte esclave par défaut, c'est utilisé pour configurer l'adresse du contrôleur hôte maître.
--master-port=<port> Domaine Définit la propriété système jboss.domain.master.port à la valeur donnée. Dans une configuration de contrôleur hôte esclave par défaut, c'est utilisé pour configurer le port utilisé pour la communication de gestion native du contrôleur hôte maître.
--read-only-server-config=<config> Autonome Nom du fichier de configuration du serveur à utiliser. Cela diffère de --server-config et -c en ce que le fichier d'origine n'est jamais écrasé.
--read-only-domain-config=<config> Domaine Nom du fichier de configuration du domaine à utiliser. Cela diffère de --domain-config et de -c en ce que le fichier de départ n'est jamais écrasé.
--read-only-host-config=<config> Domaine Nom du fichier de configuration de l'hôte à utiliser. Cela diffère de --host-config en ce que le fichier de départ n'est jamais écrasé.
-P <url>, -P=<url>, --properties=<url> Autonome, Serveur Télécharge les propriétés système de l'URL donné.
--pc-address=<address> Domaine Adresse à laquelle le contrôleur de processus doit écouter les communications en provenance des processus qu'il contrôle.
--pc-port=<port> Domaine Port sur lequel le contrôleur de processus doit écouter les communications en provenance des processus qu'il contrôle.
-S<name>[=<value>] Autonome Définit une propriété de sécurité.
--server-config=<config> Autonome Nommer le fichier de configuration du serveur à utiliser. La valeur par défaut est standalone.xml.
-u <value>, -u=<value> Autonome, Serveur Définit la propriété système jboss.default.multicast.address à la valeur donnée.
-v, -V, --version Autonome, Serveur Affiche la version du serveur d'applications et sortie.

2.3. Démarrer et arrêter les serveurs

2.3.1. Démarrer et arrêter les serveurs par l'interface CLI

Vous pouvez démarrer et arrêter les serveurs avec l'interface CLI (en mode autonome) ou par la console de gestion. En mode de domaine, vous ne pouvez que démarrer les instances de serveur. Les deux outils de gestion vous permettent de contrôler une seule instance de serveur autonome, ou de gérer sélectivement un ou plusieurs serveurs dans un déploiement de domaine géré. Si vous utilisez la console de gestion en mode de domaine, veuillez consulter Section 2.3.2, « Démarrer un serveur par la console de gestion » pour obtenir des instructions. Si vous utilisez l'interface CLI, le processus varie entre des instances de serveur autonome et de domaine géré.
Démarrer et arrêter un serveur autonome par l'interface CLI

Vous pouvez démarrer une instance de serveur autonome par les scripts de ligne de commande, et le fermer par l'interface CLI par la commande shutdown. Si vous avez besoin de l'instance par la suite, exécuter le processus de démarrage à nouveau selon les instructions dans Section 2.2.2, « Démarrez JBoss EAP 6 comme un serveur autonome ».

Exemple 2.6. Démarrer et arrêter une instance de serveur autonome par l'interface CLI

[standalone@localhost:9999 /] shutdown
Démarrer et arrêter un domaine géré par l'interface CLI

Si vous exécutez un domaine géré, la console de gestion va vous permettre de démarrer ou de stopper sélectivement des serveurs spécifiques pour ce domaine. Cela inclut les groupes de serveurs dans tout le domaine, ainsi que les instances de serveur spécifiques sur un hôte.

Exemple 2.7. Stopper un hôte de serveur dans un domaine géré par l'interface CLI

Semblable à une instance de serveur autonome, la commande shutdown est utilisée pour fermer un hôte de domaine géré déclaré. Cet exemple stoppe un hôte de serveur nommé master en déclarant le nom d'instance avant d'appeler l'opération de fermeture. Utiliser la touche tab pour aider à la complétion de chaînes et pour exposer des variables visibles comme les valeurs hôtes disponibles.
[domain@localhost:9999 /] /host=master:shutdown

Exemple 2.8. Stopper un hôte de serveur dans un domaine géré par l'interface CLI

Cet exemple montre comment démarrer un groupe de serveurs par défaut nommé main-server-group en déclarant le groupe avant les opérations start et stop. Utilisez la touche tab pour aider à la complétion de chaînes et pour exposer des variables visibles comme les valeurs de nom de groupes de serveurs disponibles.
[domain@localhost:9999 /] /server-group=main-server-group:start-servers
[domain@localhost:9999 /] /server-group=main-server-group:stop-servers

Exemple 2.9. Démarrer et stopper une instance de serveur dans un domaine géré par l'interface CLI

Cet exemple montre comment démarrer et stopper une instance de serveur nommée server-one sur l'hôte master en déclarant la configuration de l'hôte et du serveur avant d'invoquer les opérations start et stop. Utilisez la touche tab pour aider à la complétion de chaînes et pour exposer des variables visibles comme les valeurs de configuration de l'hôte et du serveur.
[domain@localhost:9999 /] /host=master/server-config=server-one:start
[domain@localhost:9999 /] /host=master/server-config=server-one:stop

2.3.2. Démarrer un serveur par la console de gestion

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.
Résultat

Le serveur sélectionné démarre et exécute.

2.3.3. Stopper un serveur qui utilise une console de gestion

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.
Résultat

Le serveur sélectionné est stoppé.

2.4. Chemins d'accès aux systèmes de fichiers

2.4.1. Chemins d'accès aux systèmes de fichiers

JBoss EAP 6 utilise des noms logiques pour les chemins de systèmes de fichiers. Les fichiers de configuration domain.xml, host.xml et standalone.xml incluent tous une section où les chemins d'accès peuvent être déclarés. D'autres sections de la configuration peuvent ensuite référencer ces chemins par leur nom logique, évitant la déclaration du chemin d'accès absolu pour chaque instance. Cela bénéficie aux efforts de configuration et d'administration car cela permet à des configurations hôtes spécifiques de résoudre des noms logiques universels.
Par exemple, la configuration du sous-système de logging comprend une référence au chemin jboss.server.log.dir qui pointe vers le répertoire log du serveur.

Exemple 2.10. Exemple de chemin d'accès relatif du répertoire de logging

<file relative-to="jboss.server.log.dir" path="server.log"/>
JBoss EAP 6 fournit un nombre de chemins d'accès standards automatiquement sans que l'utilisateur n'ait besoin de les configurer dans un fichier de configuration.

Tableau 2.2. Chemins d'accès standard

Valeur Description
java.ext.dirs Chemins de répertoires d'extension de JDK.
jboss.home.dir Le répertoire root de la distribution JBoss EAP 6.
user.home Le répertoire d'accueil de l'utilisateur.
user.dir Le répertoire de travail actuel de l'utilisateur
java.home Le répertoire d'installation de Java
jboss.server.base.dir Le répertoire root d'une instance de serveur individuel.
jboss.server.data.dir Le répertoire que le serveur va utiliser pour le stockage de fichiers de données persistantes.
jboss.server.config.dir Le répertoire qui contient la configuration du serveur.
jboss.server.log.dir Le répertoire que le serveur va utiliser pour le stockage de fichier journal.
jboss.server.temp.dir Le répertoire que le serveur va utiliser pour le stockage de fichiers temporaires.
jboss.server.deploy.dir Le répertoire que le serveur utilisera pour stocker le contenu déployé.
jboss.controller.temp.dir Le répertoire que le contrôleur hôte va utiliser pour le stockage de fichiers temporaires.
jboss.domain.base.dir Le répertoire de base de contenu de domaine.
jboss.domain.config.dir Le répertoire qui contient la configuration de domaine.
jboss.domain.data.dir Le répertoire que le domaine utilisera pour le stockage de fichiers de données persistantes.
jboss.domain.log.dir Le répertoire que le domaine va utiliser pour le stockage de fichier de journalisation persistant.
jboss.domain.temp.dir Le répertoire que le domaine va utiliser pour le stockage de fichier temporaire.
jboss.domain.deployment.dir Le répertoire que le serveur utilisera pour stocker le contenu déployé.
jboss.domain.servers.dir Le répertoire que le domaine va utiliser pour stocker les sorties d'instances de domaines gérés.
Substituer un chemin par un autre

Si vous exécutez en serveur autonome, vous pourrez substituer les chemins jboss.server.base.dir, jboss.server.log.dir, ou jboss.server.config.dir d'une ou de deux manières.

  1. Vous pouvez passer des arguments par ligne de commande quand vous démarrez le serveur. Ainsi :
    bin/standalone.sh -Djboss.server.log.dir=/var/log
  2. Vous pouvez modifier la variable JAVA_OPTS dans le fichier de configuration du serveur. Ouvrir le fichier EAP_HOME/bin/standalone.conf et ajouter la ligne suivante à la fin du fichier :
    JAVA_OPTS="$JAVA_OPTS Djboss.server.log.dir=/var/log"
La substitution de fichiers n'est pas prise en charge pour les serveurs exécutant dans un domaine géré.

Ajouter un chemin personnalisé

Vous pouvez également créer votre propre chemin personnalisé. Par exemple, vous pouvez définir un chemin relatif à utiliser pour la journalisation. Vous pouvez alors changer le gestionnaire de journal pour utiliser my.relative.path,

Exemple 2.11. Un chemin de journalisation personnalisé

my.relative.path=/var/log

2.5. Fichiers de configuration

2.5.1. Fichiers de configuration de JBoss EAP 6

La configuration de JBoss EAP 6 a considérablement changé depuis les dernières versions. Une des différences principale est l'utilisation d'une structure de fichier de configuration simplifiée, qui comprend un ou plusieurs des fichiers répertoriés ci-dessous :

Tableau 2.3. Emplacements des fichiers de configuration

Mode du serveur Emplacement But
domain.xml EAP_HOME/domain/configuration/domain.xml Il s'agit du fichier de configuration principal d'un domaine géré. Seul le master du domaine lit ce fichier. Il peut être supprimé pour les autres membres du domaine.
host.xml EAP_HOME/domain/configuration/host.xml Ce fichier contient les détails de configuration spécifiques à un hôte physique dans un domaine géré, tels que les interfaces réseau, les liaisons de sockets, le nom de l'hôte et d'autres détails spécifiques à l'hôte. Le fichier host.xml contient toutes les fonctionnalités de hôte-master.xml et hôte-slave.xml qui sont décrites ci-dessous. Ce fichier n'est pas présent pour les serveurs autonomes.
host-master.xml EAP_HOME/domain/configuration/host-master.xml Ce fichier inclut tous les détails de configuration nécessaires pour exécuter un serveur en tant que serveur maître de domaine géré. Ce fichier n'est pas présent dans les serveurs autonomes.
host-slave.xml EAP_HOME/domain/configuration/host-slave.xml Ce fichier inclut tous les détails de configuration nécessaires pour exécuter un serveur en tant que serveur esclave de domaine géré. Ce fichier n'est pas présent dans les serveurs autonomes.
standalone.xml EAP_HOME/standalone/configuration/standalone.xml C'est le fichier de configuration par défaut pour un serveur autonome. Il contient toutes les informations sur le serveur autonome, y compris les sous-systèmes, réseautage, déploiements, les liaisons de sockets et autres détails configurables. Cette configuration est utilisée automatiquement lorsque vous démarrez votre serveur autonome.
standalone-full.xml EAP_HOME/standalone/configuration/standalone-full.xml Il s'agit d'un exemple de configuration pour un serveur autonome. Il prend en charge chaque sous-système possible à l'exception de ceux destinés à la haute disponibilité. Pour l'utiliser, arrêtez votre serveur et redémarrez à l'aide de la commande suivante : EAP_HOME/bin/standalone.sh -c standalone-full.xml
standalone-ha.xml EAP_HOME/standalone/configuration/standalone-ha.xml Cet exemple de fichier de configuration active tous les sous-systèmes par défaut et ajoute les mod_cluster et les sous-systèmes JGroups pour un serveur autonome, afin qu'il puisse participer à un cluster de haute disponibilité ou d'équilibrage de la charge. Ce fichier n'est pas applicable à un domaine géré. Pour utiliser cette configuration, arrêtez votre serveur et redémarrez le à l'aide de la commande suivante : EAP_HOME/bin/standalone.sh -c standalone-ha.xml
standalone-full-ha.xml EAP_HOME/standalone/configuration/standalone-full-ha.xml Il s'agit d'un exemple de configuration pour un serveur autonome. Il prend en charge chaque sous-système possible incluant ceux destinés à la haute disponibilité. Pour l'utiliser, arrêtez votre serveur et redémarrez à l'aide de la commande suivante : EAP_HOME/bin/standalone.sh -c standalone-full-ha.xml
Ce sont les emplacements par défaut uniquement. Vous pouvez indiquer un fichier de configuration différent en cours d'exécution.

2.5.2. Remplacement de propriété basée descripteur

La configuration d'application - par exemple, les paramètres de connexion de la source de données - varient normalement entre le développement, les tests, et les déploiements de production. Cette variation est parfois accommodée par les build system scripts, car la spécification Java EE ne contient pas de méthode pour externaliser ces configurations. Dans JBoss EAP 6, vous pouvez utiliser le remplacement de propriété basée descripteur pour gérer la configuration en externe.
Le remplacement de propriété basée descripteur remplace les propriétés basées sur des descripteurs, ce qui vous permet de supprimer les hypothèses concernant l'environnement de l'application et la chaîne de construction. Les configurations spécifiques à l'environnement peuvent être spécifiées dans les descripteurs de déploiement à la place des annotations ou des build system scripts. Vous pouvez fournir la configuration dans les fichiers ou en tant que paramètres en ligne de commande.
Le remplacement de propriétés basées descripteur est activé globalement par standalone.xml ou domain.xml :

Exemple 2.12. Remplacement de propriété basée descripteur

<subsystem xmlns="urn:jboss:domain:ee:1.1">
  <spec-descriptor-property-replacement>
    true
  </spec-descriptor-property-replacement>
  <jboss-descriptor-property-replacement>
    true
  </jboss-descriptor-property-replacement>
</subsystem>
Le remplacement de descripteur spécifique à Java EE est désactivé par défaut. Si activés, les descripteurs peuvent être remplacés dans le fichiers de configuration suivants : ejb-jar.xml et persistence.xml.
Le remplacement de descripteur spécifique à Java est activé par défaut. Si activés, les descripteurs peuvent être remplacés dans les fichiers de configuration suivants :
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
Par exemple, avec un bean ayant l'annotation suivante :

Exemple 2.13. Exemple d'annotation

@ActivationConfigProperty(propertyName = "connectionParameters", propertyValue = "host=192.168.1.1;port=5445")
Avec le remplacement de propriété basée descripteur, connectionParameters peut être spécifié en ligne de commande par :
./standalone.sh -DconnectionParameters='host=10.10.64.1;port=5445'
Pour accomplir cela par les propriétés système, vous pouvez utiliser une expression à la place de la valeur litérale. Les expressions prennent le format ${parameter:default}. Quand une expression est utilisée dans une configuration, la valeur de ce paramètre prend sa place. Si le paramétre n'existe pas, alors la valeur par défaut indiquée sera utilisée à la place.

Exemple 2.14. Utiliser une expression dans un descripteur

<activation-config>
  <activation-config-property>
    <activation-config-property-name>
      connectionParameters
      </activation-config-property-name>
    <activation-config-property-value>
      ${jms.connection.parameters:'host=10.10.64.1;port=5445'}
    </activation-config-property-value>
  </activation-config-property>
</activation-config>
L'expression ${jms.connection.parameters:'host=10.10.64.1;port=5445'} permet aux paramètres de connexion d'être remplacés par un paramètre fourni en ligne de commande, tout en donnant une valeur par défaut.

2.5.3. Activer/Désactiver un remplacement de propriété basé descripteur

Résumé

Le contrôle précis du remplacement de propriété de descripteur a été introduit dans jboss-as-ee_1_1.xsd. Cette tâche couvre les étapes requises pour configurer le remplacement de propriété basé descripteur.

Les indicateurs de remplacement de propriété basé descripteur ont les valeurs booléennes suivantes :
  • Si défini à true, les remplacements de propriété sont activés.
  • Si défini à false, les remplacements de propriété sont désactivés.

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

jboss-descriptor-property-replacement est utilisé pour activer ou désactiver le remplacement de propriété dans les descripteurs suivants :
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
La valeur par défaut de jboss-descriptor-property-replacement est true.
  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

spec-descriptor-property-replacement est utilisé pour activer ou désactiver le remplacement de propriété dans les descripteurs suivants :
  • ejb-jar.xml
  • persistence.xml
  • application.xml
  • web.xml
La valeur par défaut de spec-descriptor-property-replacement est false.
  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)
Résultat

Les indicateurs de remplacement de propriété basé descripteur ont bien été configurés.

2.5.4. Expressions imbriquées

Les expressions peuvent être imbriquées, ce qui permet une utilisation plus avancée des expressions au lieu de valeurs fixes. Le format d'une expression imbriquée ressemble à celui d'une expression normale, mais une expression est imbriquée dans l'autre, comme par exemple :

Exemple 2.15. Transactions imbriquées

${system_value_1${system_value_2}}
Les expressions imbriquées sont évaluées de façon récursive, donc l'expression inner est d'abord évaluée, puis outer. Les expressions imbriquées sont autorisées partout où elles sont autorisées, à l'exception des commandes CLI de gestion.
En ce qui concerne les expressions normales, les sources prises en charge pour résoudre les expressions imbriquées sont : propriétés système, variables d'environnement et de l'archivage sécurisé. Pour les déploiements uniquement, la source peut correspondre à des propriétés qui sont listées dans un fichier META-INF/jboss.properties qui se trouve dans l'archive de déploiement. Dans un EAR ou dans un autre type de déploiement qui prenne en charge les sous-déploiements, la résolution est scoped à tous les sous-déploiements si META-INF/jboss.properties se trouve dans le déploiement externe (par ex. EAR) et est scoped à un sous-déploiement si META-INF/jboss.properties est dans l'archive d'un sous-déploiement (par ex. un WAR à l'intérieur d'une EAR).

Exemple 2.16. Utiliser une expression imbriquée dans un fichier de configuration

Une application real-life d'une expression imbriquée se trouve dans une définition de source de données. Si le mot de passe utilisé dans une définition de source de données est masqué, voici la ligne de texte qui en résulte dans la définition de la source de données :
<password>${VAULT::ds_ExampleDS::password::1}</password>
Pour une expression imbriquée, la valeur de ds_ExampleDS peut être remplacée par une propriété système. Si une propriété système datasource_name reçoit comme valeur ds_ExampleDS, la ligne de texte de la définition de source de données pourra ressembler à ceci :
<password>${VAULT::${datasource_name}::password::1}</password>
JBoss EAP doit tout d'abord évaluer l'expression ${datasource_name}, puis l'ajouter à une plus grande expression et évaluer l'expression qui en résulte. L'avantage de cette configuration est que le nom de la source de données se soustrait de la configuration fixe
Les expressions peuvent également être récursives quand une expression est résolue en expression qui est résolue à son tour. Les expressions imbriquées et récursives représentent une forme d'indirection. Notez que les expressions récursives ne sont pas permises dans les commandes d'interface CLI.

Exemple 2.17. Expression récursive

Pour l'exemple ci-dessus, vous pouvez utiliser l'expression ${foo} qui résolue en expression ${VAULT::ds_ExampleDS::password::1}, elle-même résolue par une valeur contenue dans l'archivage sécurisé : secret.

2.5.5. Historique du fichier de configuration

Les fichiers de configuration du serveur d'applications incluent standalone.xml, ainsi que les fichiers domain.xml et host.xml. Alors que ces fichiers sont modifiables directement, la méthode recommandée consiste à configurer le modèle de serveur d'applications par les opérations de gestion disponibles, y compris l'interface CLI et la console de gestion.
Pour aider à la maintenance et à la gestion de l'instance de serveur, le serveur d'applications crée une version horodatée du fichier de configuration original au moment du démarrage. Toutes les modifications de configuration supplémentaires suite aux opérations de gestion résultent à la sauvegarde automatique du fichier d'origine, et une copie de travail de l'instance est alors conservée en tant que référence et pour la restauration. Cette fonctionnalité d'archivage s'étend à l'enregistrement, au chargement et à la suppression des snapshots de configuration du serveur pour autoriser les scénarios de rappel et de restauration.

2.5.6. Démarrer le serveur par une ancienne configuration

L'exemple suivant vous montre comment démarrer le serveur d'applications par une ancienne configuration dans un serveur autonome par standalone.xml. Le même concept s'applique à un domaine géré par domain.xml et host.xml respectivement.
Cet exemple nous remémore une ancienne configuration sauvegardée automatiquement par le serveur d'applications tandis que les opérations de gestion modifient le modèle de serveur.

Exemple 2.18. Démarrer le serveur avec une configuration sauvegardée

  1. Identifier la version de sauvegarde que vous souhaitez démarrer. Cet exemple va rappeler l'instance de modèle de serveur qui précédait la première modification qui a lieu suite à un démarrage réussi.
    EAP_HOME/standalone/configuration/standalone_xml_history/current/standalone.v1.xml
  2. Démarrer le serveur par cette configuration du modèle de sauvegarde en passant le nom de fichier relatif sous jboss.server.config.dir.
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/current/standalone.v1.xml
Résultat

Le serveur d'applications démarre par la configuration sélectionnée.

Note

L'historique de la configuration du domaine se trouve dans EAP_HOME/domain/configuration/domain_xml_history/current/domain.v1.xml
Démarrer le serveur par cette configuration du modèle de sauvegarde en passant le nom de fichier relatif sous jboss.domain.config.dir.
Pour démarrer le domaine par cette configuration :
EAP_HOME/bin/domain.sh --domain-config=domain_xml_history/current/domain.v1.xml

2.5.7. Sauvegarder un snapshot de configuration par l'interface CLI

Résumé

Les snapshots représentent une copie d'un moment précis d'une configuration de serveur en cours. Ces copies peuvent être sauvegardées et chargées par l'administrateur.

L'exemple suivant utilise le fichier de configuration standalone.xml, mais le même processus s'applique aux fichiers de configuration domain.xml et host.xml.

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"
    
Résultat

Un snapshot de la configuration du serveur en cours a été sauvegardé.

2.5.8. Charger un snapshot de configuration par l'interface CLI.

Les snapshots de configuration représentent une copie d'un moment précis d'une configuration de serveur en cours. Ces copies peuvent être sauvegardées et chargées par l'administrateur. Le processus de chargement des snapshots ressemble à celui de la méthode pour Section 2.5.6, « Démarrer le serveur par une ancienne configuration », à partir de la ligne de commande et non pas l'interface CLI utilisée pour créer, lister et supprimer les snapshots.
L'exemple suivant utilise le fichier standalone.xml, mais le même processus s'applique aux fichiers domain.xml et host.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
Résultat

Le serveur démarre à nouveau avec la configuration sélectionnée dans le snapshot téléchargé.

2.5.9. Supprimer un snapshot de configuration par l'interface CLI

Les snapshots représentent une copie d'un moment précis d'une configuration de serveur en cours. Ces copies peuvent être sauvegardées et chargées par l'administrateur.
Les exemples suivants utilisent le fichier standalone.xml, mais le même processus s'applique aux fichiers domain.xml et host.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"}
    
Résultat

Le snapshot a été supprimé.

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"}
    
Résultat

Tous les snapshots ont été supprimés.

2.5.10. Lister tous les snapshots de configuration par l'interface CLI

Les snapshots représentent une copie d'un moment précis d'une configuration de serveur en cours. Ces copies peuvent être sauvegardées et chargées par l'administrateur.
L'exemple suivant utilise le fichier standalone.xml, mais le même processus s'applique aux fichiers domain.xml et host.xml.

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"
            ]
        }
    }
    
Résultat

Les snapshots sont listés.

Chapitre 3. Interfaces de gestion

3.1. Gestion du serveur d'applications

JBoss EAP 6 vous propose des outils de gestion multiples pour configurer et administrer votre implémentation suivant les besoins. Ces outils comprennent la nouvelle console de gestion et l'interface CLI, comme exemples d'API de gestion pour permettre aux utilisateurs experts de développer leurs propres outils s'ils le désirent.

3.2. Les API (de l'anglais Application Programming Interfaces) de gestion

Clients de gestion

JBoss EAP 6 offre trois approches différentes pour configurer et gérer des serveurs, une interface web, un client de ligne de commande et un ensemble de fichiers de configuration XML. Tandis que les méthodes recommandées pour la modification du fichier de configuration incluent la console de gestion et l'interface CLI, les modifications de configuration de la part des trois sont toujours synchronisées à travers les différentes vues et sont conservées dans les fichiers XML. Notez que les modifications apportées aux fichiers de configuration XML pendant l'exécution d'une instance de serveur seront remplacées par le modèle de serveur.

HTTP API

Le point de terminaison de l'API HTTP est le point d'entrée pour les clients de gestion, comme par exemple la Console de gestion, qui dépend du protocole HTTP pour s'intégrer à la couche de gestion. Ce point de terminaison utilise un protocole JSON encodé et un API de style RPC de-typed, pour décrire et exécuter des opérations de gestion dans un domaine géré ou un serveur autonome. Il est utilisé par la console web, mais offre aussi des possibilités d'intégration pour un large éventail d'autres clients.

Le point de terminaison HTTP API est situé près du contrôleur de domaine ou d'une instance de serveur autonome. Il sert deux contextes différents; un pour l'exécution des opérations de gestion et de l'autre pour accéder à l'interface web. Par défaut, il s'exécute sur le port 9990.

Exemple 3.1. Exemple de fichier de configuration HTTP API

<management-interfaces>
  [...]
  <http-interface security-realm="ManagementRealm">
     <socket-binding http="management-http"/>
  </http-interface>
</management-interfaces>
La console web est desservie par le même port que l'API de gestion HTTP. Il est important de distinguer la façon dont on accède à la Console de gestion ou à l'API HTTP : la Console de gestion comme localhost par défaut, la Console de gestion à distance par un hôte spécifique et une combinaison de ports, et l'API HTTP exposé du domaine.

Tableau 3.1. Les URL d'accès à la Console de gestion ou à l'API HTTP exposé

URL Description
http://localhost:9990/console La console de gestion à laquelle accéde l'hôte local, et qui contrôle la configuration du domaine géré.
http://hostname:9990/console La console de gestion accédée à distance, qui nomme l'hôte et qui contrôle la configuration du domaine géré.
http://hostname:9990/management L'API de gestion HTTP exécute sur le même port que la console de gestion, affiche les mêmes valeurs et attributs bruts exposés à l'API.
API Natif

Le CLI de gestion est un exemple d'outil d'API Natif. Cet outil de gestion est disponible à une instance de serveur autonome ou à un domaine, permettant ainsi à un utilisateur de se connecter à une instance du serveur autonome ou au contrôleur du domaine, et d'exécuter des opérations de gestion rendues disponibles par le modèle de gestion de-types.

Le point de terminaison de l'API natif est le point d'entrée pour les clients de gestion qui s'appuient sur le protocole natif pour intégrer la couche de gestion. Il utilise un protocole binaire ouvert et une API style-RPC basée sur un très petit nombre de types Java pour décrire et exécuter des opérations de gestion. Il est utilisé par l'outil de gestion Interface CLI, mais offre des capacités d'intégration pour un large éventail d'autres clients également.
Le point de terminaison d'API natif est co-localisé avec un contrôleur hôte ou un serveur autonome. Il doit être activé pour utiliser l'interface CLI. Par défaut, il s'exécute sur le port 9999.

Exemple 3.2. Exemple de fichier de configuration d'API natif

<management-interfaces>
  <native-interface security-realm="ManagementRealm">
    <socket-binding native="management-native"/>
  </native-interface>
  [...]
</management-interfaces>

3.3. console de gestion et interface CLI

Dans JBoss EAP 6, toutes les instances de serveurs et toutes les configurations sont gérées par les interfaces de gestion, et non pas par modification de fichiers XML. Malgré que les fichiers de configuration XML puissent toujours être édités, la gestion par les interfaces de gestion fournit une validation supplémentaire et des fonctionnalités avancées pour la gestion persistante des instances de serveurs. Les modifications apportées aux fichiers de configuration XML, tandis que l'instance de serveur est en cours d'exécution, seront remplacées par le modèle de serveur, et des commentaires XML ajoutés disparaîtront ainsi. Seules les interfaces de gestion doivent être utilisées pour modifier les fichiers de configuration pendant l'exécution d'une instance de serveur
Pour gérer les serveurs par une interface utilisateur graphique d'un navigateur web, utiliser la console de gestion.
Pour gérer les serveurs par l'interface de ligne de commande, utiliser l'interface CLI.

3.4. La console de gestion

3.4.1. Console de management

La console de management est un outil administratif basé web pour la plateforme JBoss EAP 6.
Utilisez la console de management pour démarrer et arrêter des serveurs, déployer et annuler le déploiement des applications, régler les paramètres du système et apporter des modifications persistantes à la configuration du serveur. La console de management a également la capacité d'effectuer des tâches administratives, avec des notifications directes lorsque les modifications exigent que l'instance du serveur soit redémarrée ou rechargée.
Dans un domaine géré, les instances de serveur et les groupes de serveurs d'un même domaine peuvent être gérés de façon centralisée à partir de la console de management du contrôleur de domaine.

3.4.2. Se connecter à la console de gestion

Conditions préalables

  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.
    The login screen for the Management console.

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

Résultat

Une fois connecté, vous serez redirigé à l'adresse suivante et la page d'accueil de la Console de gestion apparaîtra : http://localhost:9990/console/App.html#home 

3.4.3. Changer la langue de la console de management

Les paramètres de configuration de la console de management basée web utilisent l'anglais par défaut. Vous pouvez décider d'utiliser une des langues suivantes à la place.

Langues prises en charge

  • Allemand (de)
  • Chinois simplifié (zn-Hans)
  • Portugais brézilien (pt-BR)
  • Français (fr)
  • Espagnol (es)
  • Japonais (ja)

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).

3.4.4. Données analytiques dans la console EAP

Google Analytics

Google Analytics est un service analytique web gratuit qui fournit des statistiques complètes sur un site Web. Il fournit des données essentielles relatives aux visiteurs d'un site comme leurs visites, pages vues, pages par visite et moyenne de temps passé sur le site. Google Analytics fournit une meilleure visibilité sur la présence d'un site Web et ses utilisateurs.

Google Analytics dans la console d'administration EAP

JBoss EAP 6 fournit aux utilisateurs l'option d'activer/de désactiver Google Analytics dans la console de gestion. La fonctionnalité Google Analytics vise à aider les équipes de Red Hat EAP à comprendre comment les clients utilisent la console et quelles parties de la console est particulièrement d'importance aux clients. Cette information aidera l'équipe à adapter l'apparence de la console, ses fonctionnalités et le contenu aux besoins immédiats des clients.

3.4.5. Activer/désactiver Google Analytics dans la console EAP

Pour activer Google Analytics dans la console d'administration EAP :
  • Connectez-vous à la console d'administration
  • Cliquer sur le bouton Settings en bas et à droite de la console
    Description

    Figure 3.2. Connectez-vous à l'écran de console d'administration

  • Sélectionner la case Enable Usage Data Collection sur la fenêtre Settings et cliquer sur le bouton Save. Confirmer le rechargement de l'application pour activer les nouveaux paramètres de configuration.
    Description

    Figure 3.3. Configurer Window (Activer Usage Data Collection)

Pour désactiver Google Analytics dans la console d'administration après l'avoir activé, cliquer sur Enable Usage Data Collection dans la fenêtre de paramétrage Settings pour supprimer la sélection, puis cliquer sur le bouton Save. Confirmer le rechargement de l'application pour activer les nouveaux paramètres de configuration.
Description

Figure 3.4. Configurer Window (Désactiver Usage Data Collection)

Note

Google Analytics est désativé par défaut dans la console d'administration EAP 6 et son utilisation est optionnelle

3.4.6. Configurer un serveur par la console de management

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.
Résultat

La configuration du serveur a changé, et prendra effet la prochaine fois que le serveur démarrera.

3.4.7. Ajouter un déploiement dans une console de management

  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.
Résultat

Le contenu sélectionné est téléchargé dans le serveur et est maintenant prêt à être déployé.

3.4.8. Créer un nouveau serveur dans la console de management

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.
Résultat

Le nouveau serveur créé est listé dans Server Configurations.

3.4.9. Modifier les niveaux de journalisation par défaut en utilisant la console de management

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.
Résultat

Les niveaux de journalisation des catégories qui conviennent sont maintenant mis à jour.

3.4.10. Créer un nouveau groupe de service dans la console de gestion

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.
Résultat

Le nouveau groupe de serveurs est visible dans la console de gestion.

3.4.11. Visualisation des journaux dans la console de gestion

Vous pouvez afficher des journaux de serveur et d'application dans la console de gestion JBoss EAP 6 pour aider à diagnostiquer des erreurs, des problèmes de performance et d'autres questions. Pour être visible dans la visionneuse du journal de console de gestion d'un journal, elle doit se situer dans le répertoire du serveur jboss.server.log.dir. La visionneuse du journal JBoss EAP 6 respecte également les attributions de rôles d'utilisateur RBAC, donc un utilisateur connecté à la console de gestion ne peut voir que des journaux pour lesquels il a l'autorisation d'accès.

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.

3.4.12. Intégration du Portail clients dans la Console de gestion

Vous pouvez utiliser l'interface access.redhat.com pour naviguer dans les sections du Portail clients de Red Hat sans quitter la console de gestion de votre installation JBoss EAP.
La barre de navigation supérieure de la console de gestion contient un menu déroulant : Red Hat Access. En cliquant sur ce menu, vous apercevrez trois liens de tâches spécifiques au portail client :
  • Search Customer Portal
  • Open Case
  • Modify Case
Les fonctionnalités de ces liens seront discutées en détails ci-dessous.

Note

Si vous n'êtes pas déjà connecté au portail clients lorsque vous cliquer sur un de ces liens, une boîte de dialogue s'affichera, vous invitant à vous connecter. Vous devez être connecté au portail clients dans la session du navigateur que vous utilisez pour accéder à la console de gestion. Si vous êtes connecté au portail client dans un navigateur, mais utilisez un autre navigateur pour accéder à la console de gestion, on vous demandera d'ouvrir une session.

Search Customer Portal

Cliquer sur Search Customer Portal vous mène à une page contenant une case de recherche. Vous pourrez y saisir des termes ou des phrases pour chercher des articles de base de connaissance.
Une fois que vous aurez effectué votre recherche, vous pourrez sélectionner un élément d'une liste de résultats et apercevoir l'article complet dans un panneau séparé.

Open Case

La page Open Case vous permet d'ouvrir un nouveau dossier de prise en charge.
On vous présentera un formulaire à remplir afin d'ouvrir un nouveau dossier de prise en charge. Une liste d'articles de Base de connaissances recommandés est fournie à côté du formulaire. Cette liste reflète les actualisations sur la base des détails fournis dans le cas de la prise en charge.

Modifier un cas

La page Modify Case vous permet de visualiser et de modifier des dossiers de prise en charge existants.
Vous pouvez raffiner les résultats en limitant votre recherche aux cas groupés ou non-groupés, en par statut de cas (ouvert, fermé, ou autre).
Après avoir sélectionné un cas de prise en charge spécifique, vous pourrez voir ou mettre à jour les détails du cas de prise en charge, ainsi qu'ajouter des commentaires.

3.5. L'interface CLI

3.5.1. Gestion par interface en ligne de commande (CLI)

La gestion par interface en ligne de commande (CLI) est un outil d'administration en ligne de commande pour JBoss EAP 6.
Utiliser l'interface CLI pour démarrer et stopper les serveurs, déployer et retirer les déploiements d'applications, configurer les paramètres du système, ou encore, effectuer d'autre tâches administratives. Les opérations peuvent être effectuées par mode de lots, ce qui permet à plusieurs tâches d'ëtre exécutées en groupe.

3.5.2. Lancement de l'interface CLI

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

3.5.3. Quitter l'interface CLI

Avec le Management CLI, saisir la commande quit :
[domain@localhost:9999 /] quit

3.5.4. Se connecter à une instance de serveur géré par l'interface CLI

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

3.5.5. Comment obtenir de l'aide par l'interface CLI

Résumé

Vous aurez parfois besoin d'aide pour mémoriser une commande d'interface ou pour vous rassurez que vous ne vous trompez pas. L'interface de gestion CLI dispose d'une boîte de dialogue d'assistance avec des options générales et des options sensibles au contexte. (notez que les commandes d'assistance dépendant du contexte de l'opération nécessitent une connexion à un contrôleur de domaine ou à un serveur autonome. Ces commandes ne seront pas affichées dans la liste, sauf si la connexion a été établie.)

  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
Résultat

L'information d'assistance du CLI s'affichera.

3.5.6. Utiliser l'interface CLI en mode par lot

Résumé

Le traitement par lot permet à un certain nombre de requêtes d'être groupées par séquences et exécutées ensemble par unité. Si une des demandes opérationnelles d'une séquence échoue, tout le groupe d'opérations sera annulé.

Note

Le mode en lot ne prend pas en charge les énoncés conditionnels.

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
Résultat

La séquence de demandes opérationnelles saisies est effectuée sous forme de lot.

3.5.7. Commandes CLI Mode Lot

Ce tableau vous fournit une liste de commandes en mode lot valides pouvant être utilisées dans JBoss EAP 6 CLI. Ces commandes ne peuvent être utilisées que pour travailler en lots.

Tableau 3.2. Commandes CLI Mode Lot

Command Name Description
list-batch Liste des commandes et des opérations du lot en cours.
edit-batch-line line-number edited-command Modifier une ligne du lot en cours en donnant un numéro de ligne à modifier et la commande éditée. Exemple: edit-batch-line 2 data-source disable --name=ExampleDS.
move-batch-line fromline toline Réorganiser les lignes dans le lot en spécifiant le numéro de ligne à déplacer comme premier argument et sa nouvelle position comme deuxième argument. Exemple : move-batch-line 3 1.
remove-batch-line linenumber Supprimer la commande de lot à la ligne indiquée. Exemple: remove-batch-line 3.
holdback-batch [batchname]
Vous pouvez reporter à plus tard ou stocker un lot en cours à l'aide de cette commande. Utiliser cette option si vous voulez soudainement exécuter quelque chose dans la CLI en dehors du lot. Pour revenir à ce lot en attente, tapez simplement batch à nouveau à la ligne de commande CLI.
Si vous fournissez un nom de lot en utilisant la commande holdback-batch, le lot sera stocké sous ce nom. Pour retourner au lot nommé, utilisez la commande batch batchname. L'appel de la commande batch sans un nom de lot va commencer un nouveau lot (sans nom). Il peut y avoir qu'un seul lot suspendu sans nom.
Pour voir une liste de tous les lots suspendus, utiliser la commande batch -l.
discard-batch Rejète le lot actif en cours.

3.5.8. Utiliser les opérations et les commandes de l'interface CLI

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)
Résultat

L'interface de gestion effectue la demande opérationnelle sur la configuration du serveur.

3.5.9. Options de configuration de l'interface CLI

Le fichier de configuration de l'interface CLI - jboss-cli.xml - est chargé à chaque fois que le CLI démarre. Il doit se situer dans le répertoire $EAP_HOME/bin ou dans un système spécifié dans la propriété système jboss.cli.config.
default-controller
Configuration du contrôleur auquel il faut vous connecter si la commande connect est exécutée sans paramètre.

Paramètres de contrôleur par défaut

host
Nom d'hôte du contrôleur. La valeur par défaut est : localhost.
port
Numéro de port sur lequel il faut se connecter au contrôleur. La valeur par défaut est 9999.
validate-operation-requests
Indique si la liste des paramètres des demandes d'opération doit être validée avant que les demandes ne soient envoyées au contrôleur pour être exécutées. Type : Booléen. Valeur par défaut : true.
history
Cet élément contient la configuration pour les commandes et pour le journal de l'historique des opérations.

Paramètres history

enabled
Indique si history est activé ou non. Type : booléen. Valeur par défaut : true.
file-name
Nom du fichier dans lequel l'historique doit être stocké. La valeur par défaut est .jboss-cli-history.
file-dir
Répertoire dans lequel l'historique doit être stocké. La valeur par défaut est = $USER_HOME
max-size
Taille maximum du fichier d'historique. La valeur par défaut : 500.
resolve-parameter-values
Indique si l'on doit résoudre les propriétés système qui sont spécifiées comme argument de commande (ou paramètres d'opérations) avant d'envoyer la demande d'opération au contrôleur ou laisser la résolution avoir lieu côté serveur. Type : Booléen. Valeur par défaut : true.
connection-timeout
Durée autorisée pour établir une connexion avec le contrôleur. Type : entier relatif. Valeur par défaut : 5000 secondes.
ssl
Cet élément contient la configuration pour les stores Trust et Key utilisés par SSL.

Avertissement

Red Hat recommande que vous désactiviez SSL explicitement en faveur de TLSv1.1 ou TLSv1.2 dans tous les packages affectés.

Paramètres ssl

archivage sécurisé
Type : vaultType
key-store
Type : string.
key-store-password
Type : string.
alias
Type : string
key-password
Type : string
trust-store
Type : string.
trust-store-password
Type : string.
modify-trust-store
Si défini à true, le CLI invitera l'utilisateur quand des certificats non reconnus auront été reçus et les autorisera à les stocker dans le truststore. Type : Booléen. Valeur par défaut : true.

vaultType

Quand ni code ou module ne sont précisés. l'implémentation par défaut sera utilisée. Si le code est spécifié, mais pas le module il cherchera la classe spécifique dans le module de Picketbox. Si le module et le code sont spécifiés, il cherchera la classe spécifiée par le code dans le module spécifié par le 'module'.
code
Type : String.
module
Type : string
silent
Indique si les messages d'erreur et d'information doivent sortir dans le terminal. Même si la valeur false est indiquée, les messages continueront d'être enregistrés par le logger si sa configuration le permet et/ou si la cible de sortie est spécifiée dans la ligne de commande par >. La valeur par défaut est : False.

3.5.10. Références de commandes d'interface CLI

Résumé

La section Section 3.5.5, « Comment obtenir de l'aide par l'interface CLI » décrit comment accéder aux fonctionnalités d'assistance de l'interface CLI. L'interface de gestion dispose d'une boîte de dialogue d'assistance avec des options générales et des options sensibles au contexte. Les commandes d'assistance dépendant du contexte de l'opération nécessitent une connexion à un contrôleur de domaine ou à un serveur autonome. Ces commandes ne seront pas affichées dans la liste, sauf si la connexion a été établie.

Tableau 3.3. 

Commande Description
batch Démarrer le mode par lot en créant un nouveau lot ou, selon les lots existants retenus, réactiver l'un d'entre eux. Si il n'y a pas de lot existant retenu, cette commande, quand elle est invoquée sans argument, va commencer un nouveau lot . S'il y a un lot sans nom existant retenu, cette commande le réactivera. S'il y a des lots existants retenus, mais avec nom, il peuvent être activées en exécutant cette commande avec ce nom comme argument.
cd Change le chemin du nœud en cours à l'argument. Le chemin du nœud en cours est utilisé comme adresse pour les requêtes opérationnelles qui ne contiennent pas la partie adresse. Si une opération n'inclut pas d'adresse, l'adresse incluse sera considérée comme relative au chemin du nœud en cours. Le chemin du nœud en cours peut finir en type de nœud. Dans ce cas, exécuter une opération en spécifiant un nom de nœud est suffisant, comme logging:read-resource.
clear Efface l'écran
command Vous permet d'ajouter, de supprimer ou de lister des commandes existantes de type standard. Une commande de type standard est une commande qui est assignée à un type de nœud spécifique et qui vous permet d'effectuer une opération disponible à une instance de ce type. Elle vous permet de modifier n'importe quelle propriété exposée par le type de n'importe quelle instance existante.
connect Connecte le contrôleur à l'hôte et au port spécifiés.
connection-factory Définit une usine de connexions
data-source Gère les configurations de sources de données JDBC dans le sous-système de la source de données.
deploy Déploie l'application désignée par le chemin d'accès au fichier ou bien, active une application qui est pré-existante, mais désactivée dans le référentiel. Si elle est exécutée sans argument, cette commande énumérera tous les déploiements existants.
echo
Disponible à partir de JBoss EAP 6.4, la commande echo produit le texte spécifié dans la console. Le texte est une sortie verbatim donc l'utilisation de variables n'est pas possible.
Exemple :
echo Phase one complete
help Affiche le message d'asistance. Peut être utilisé avec l'argument --commands pour fournir aux commandes données des résultats sensibles au contexte.
history Affiche l'historique en mémoire de la commande CLI et affiche un statut pour savoir si l'expansion de l'historique est activée ou non. Peut être utilisé avec des arguments pour effacer, désactiver, ou activer l'expansion de l'historique selon les besoins.
jms-queue Définit une file d'attente JMS dans le sous-système de messagerie.
jms-topic Définit un topic dans le sous-système de messagerie.
ls Lister les contenus du chemin d'accès au nœud. Par défaut, le résultat est imprimé dans des colonnes qui utilisent toute la largeur du terminal. Utiliser -l affichera les résultats sur la base d'un nom par ligne.
pwd Affiche le chemin d'accès du nœud pour le nœud en cours
quit Termine l'interface de ligne de commande.
read-attribute Affiche la valeur et, suivant les arguments, la description de l'attribut d'une ressource gérée.
read-operation Affiche la description d'une opération particulière, ou bien liste toutes les opérations si aucune n'est spécifiée.
undeploy Annule une demande lorsque celle-ci est exécutée avec le nom de l'application prévue. Peut être exécuté avec des arguments pour supprimer également l'application du référentiel. Imprime la liste de tous les déploiements existants si exécutée sans application spécifiée.
version Affiche la version de serveur d'applications et les informations d'environnement.
xa-data-source Gére la configuration de la source de données JDBC XA du sous-système de la source de données.

3.5.11. Référence aux opérations d'interface CLI

Exposer les opérations d'interface CLI

Les opérations d'interface CLI peuvent être exposées par l'opération read-operation-names décrite dans la rubrique Section 3.6.5, « Afficher les noms de l'opération en utilisant l'interface CLI ». Les descriptions des opérations peuvent être exposées par l'opération read-operation-descriptions décrite dans la rubrique Section 3.6.4, « Affiche une description d'opération en utilisant l'interface CLI ».

Tableau 3.4. Les opérations d'interface CLI

Nom de l'opération Description
add-namespace Ajoute un mappage de préfixe d'espace-nom à la mappe d'attribut d'espace-nom.
add-schema-location Ajoute un schéma de mappage d'emplacement à la mappe d'attribut schema-locations.
delete-snapshot Efface un snapshot de la configuration serveur dans le répertoire de snapshots.
full-replace-deployment Ajoute le contenu précédemment téléchargé de déploiement à la liste de contenu disponible, remplace le contenu existant du même nom dans le runtime et supprime le contenu remplacé dans la liste de contenu disponible. Voir lien pour plus de renseignements.
list-snapshots Liste les snapshots de la configuration du serveur sauvegardée dans le répertoire des snapshots.
read-attribute Affiche la valeur d'un attribut d'une ressource sélectionnée.
read-children-names Affiche le nom de tous les enfants d'une ressource donnée ayant le type donné.
read-children-resources Affiche des informations sur tous les enfants d'une ressource d'un type donné.
read-children-types Affiche les noms de types de tous les enfants pour la ressource sélectionnée.
read-config-as-xml Lit la configuration actuelle et l'affiche en format XML.
read-operation-description Affiche les détails d'une opération de la ressource donnée.
read-operation-names Affiche les noms de toutes les opérations de la ressource donnée.
read-resource Affiche les valeurs des attributs d'un modèle de ressource avec des informations complètes ou de base sur n'importe quelle ressource enfant.
read-resource-description Indique la description des attributs d'une ressource, les types de dépendants et les opérations.
reload Charge le serveur à nouveau en fermant tous les services et en redémarrant.
remove-namespace Supprime un mappage de préfixe d'espace-nom à la mappe d'attribut d'espace-nom.
remove-schema-location Supprime un schéma de mappage d'emplacement à la mappe d'attribut schema-locations.
replace-deployment Remplace le contenu existant du runtime par un contenu nouveau. Le nouveau contenu doit avoir été chargé auparavant dans le référentiel du contenu de déploiement.
resolve-expression Opération qui accepte une expression comme entrée ou un string pouvant être compris comme une expression, et résolu en fonction du système local de propriétés et des variables d'environnement.
resolve-internet-address Prend un ensemble de critères de résolution d'interface et trouve une adresse IP sur une machine locale qui correspond au critère, ou échoue si aucune adresse IP correspondante n'est trouvée.
server-set-restart-required Met le serveur en mode «restart-required»
shutdown Ferme le serveur via un appel à System.exit(0).
start-servers Démarre tous les serveurs configurés dans un domaine géré qui n'est pas actuellement en cours d'exécution.
stop-servers Arrête tous les serveurs actuellement en cours d'exécution dans un domaine géré.
take-snapshot Prend un snapshot de la configuration du serveur et la sauvegarde dans le répertoire des snapshots.
upload-deployment-bytes Indique si le contenu de déploiement du tableau d'octets inclus doit être ajouté au référentiel du contenu de déploiement. Notez que cette opération n'indique pas que le contenu doive être déployé au runtime.
upload-deployment-stream Indique si le contenu de déploiement disponible dans l'index des flux entrants doit être ajouté au référentiel du contenu de déploiement. Notez que cette opération n'indique pas que le contenu doive être déployé au runtime.
upload-deployment-url Indique si le contenu de déploiement disponible dans l'URL doit être ajouté au référentiel du contenu de déploiement. Notez que cette opération n'indique pas que le contenu doive être déployé au runtime.
validate-address Valide l'adresse de l'opération
write-attribute Indique la valeur d'un attribut d'une ressource sélectionnée.

3.5.12. Substitution dans l'interface de commandes CLI

JBoss EAP 6 prend en charge l'utilisation des expressions de propriétés et d'élément prédéfinis dans l'interface de commandes CLI. Ces expressions seront résolues à leurs valeurs définies lors de l'exécution de la commande.
Les propriétés suivantes peuvent être substituées par des expressions :
  • la partie adresse d'opération de la demande d'opération (types de nodes et/ou les noms) ;
  • nom d'opération ;
  • noms de paramètres d'opérations ;
  • noms d'en-têtes et valeurs ;
  • noms de commandes :
  • noms d'arguments de commandes.
Par défaut, l'interface CLI effectue la substitution de propriétés à chaque ligne sauf pour les valeurs de paramètres ou d'arguments. Les valeurs de paramètres ou d'arguments sont résolues dans le serveur en cours d'exécution. Si vous avez besoin d'une substitution de propriété pour des valeurs de paramètre ou d'argument dans l'interface CLI client, et de lui faire envoyer les valeurs résolues au serveur, compléter la procédure suivante :

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>
    
Cet élément n'affecte que les valeurs de paramètres de la demande d'opération et les valeurs d'arguments de commandes. Il n'a aucun effet sur le reste de la ligne de commande. Ce signifie que les propriétés système présentes dans la ligne de commande seront résolues lors du traitement de la ligne quelle que soit la valeur de l'élément resolve-parameter-values, sauf s'il si celui-ci correspond à une valeur de paramètre/argument.
Voir Section 3.5.9, « Options de configuration de l'interface CLI » pour obtenir d'autres options de configuration d'interface CLI.
Sachez que les valeurs de système utilisées dans les commandes d'interface CLI doivent être déjà définies. Vous devez inclure l'argument --properties=/path/to/file.properties ou bien, un ou plusieurs paramètres -Dkey=VALUE, quand vous commencez votre instance d'interface CLI. Le fichier de propriétés utilise une syntaxe standard key=value.
Les clés de propriétés son dénotées dans vos commandes d'interface CLI en utilisant la syntaxe ${MY_VAR}.

Exemple 3.7. Exemple : utilisation de propriétés dans les commandes d'interface CLI

/subsystem=datasources/data-source=${datasourcename}:add(connection-url=jdbc:oracle:thin:@server:1521:ora1, jndi-name=java:/jboss/${name}, driver-name=${drivername})

3.6. Opérations de l'interface CLI

3.6.1. Afficher les attributs d'une ressource par l'interface CLI

Résumé

L'opération read-attribute est une opération globale utilisée pour lire la valeur d'exécution d'un attribut sélectionné. Peut être utilisée pour exposer uniquement les valeurs qui ont été définies par l'utilisateur, en ignorant toute valeur par défaut ou non définie. Les propriétés de la requête incluent les paramètres suivants.

Propriétés de requêtes

name
Le nom de l'attribut pour obtenir la valeur sous la ressource sélectionnée.
include-defaults
Un paramètre booléen qui peut être défini à false pour limiter les résultats de l'opération aux attributs qui ont été définis par l'utilisateur uniquement, et ignorer les valeurs par défaut.

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

Un avantage de l'opération read-attribute est la possibilité d'exposer la valeur d'exécution actuelle d'un attribut spécifique. Des résultats similaires peuvent être obtenus avec l'opération read-attribute, mais seulement avec l'addition de la propriété de requête include-runtime, et uniquement dans le cadre d'une liste de toutes les ressources disponibles pour ce nœud. L'opération read-attribute est destinée aux requêtes d'attribut précises, comme le montre l'exemple suivant.

Exemple 3.8. Exécuter l'opération read-attribute pour exposer l'IP d'interface publique.

Si vous connaissez le nom de l'attribut que vous souhaitez exposer, vous pouvez utiliser la commande read-attribute pour renvoyer la valeur exacte dans le runtime en cours.
[standalone@localhost:9999 /] /interface=public:read-attribute(name=resolved-address)
{
    "outcome" => "success",
    "result" => "127.0.0.1"
}
L'attribut resolved-address est une valeur de runtime, donc ne s'affiche pas dans les résultats de l'opération read-resource standard.
[standalone@localhost:9999 /] /interface=public:read-resource                        
{
    "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,
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}
Pour afficher resolved-address ou des autres valeurs de runtime, vous devrez utiliser la propriété de requête include-runtime.
[standalone@localhost:9999 /] /interface=public: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
    }
}
Résultat

La valeur de l'attribut du runtime en cours est affichée.

3.6.2. Afficher l'utilisateur qui est actif dans l'interface CLI

Résumé

L'opération whoami est une opération globale utilisée pour identifier les attributs de l'utilisateur actif. L'opération expose l'identité de nom d'utilisateur et le domaine qui leur est attribué. L'opération whoami est utile pour les administrateurs qui gèrent plusieurs comptes d'utilisateurs dans plusieurs domaines, ou pour aider à assurer le suivi des utilisateurs actifs à travers les instances de domaine avec plusieurs sessions de terminal et les comptes utilisateurs.

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"
        }}
    }
    
Résultat

Votre compte d'utilisateur actif en cours est affiché

3.6.3. Affiche les informations système et serveur dans l'interface CLI

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
Résultat

Les informations sur la version de votre serveur d'applications et sur votre environnement s'afficheront.

3.6.4. Affiche une description d'opération en utilisant l'interface CLI

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)

Exemple 3.10. Afficher la description de l'opération «list-snapshots»

L'exemple suivant vous montre la méthode utilisée pour décrire l'opération list-snapshots.
[standalone@localhost:9999 /] :read-operation-description(name=list-snapshots)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "list-snapshots",
        "description" => "Lists the snapshots",
        "request-properties" => {},
        "reply-properties" => {
            "type" => OBJECT,
            "value-type" => {
                "directory" => {
                    "type" => STRING,
                    "description" => "The directory where the snapshots are stored",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "min-length" => 1L,
                    "max-length" => 2147483647L
                },
                "names" => {
                    "type" => LIST,
                    "description" => "The names of the snapshots within the snapshots directory",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "value-type" => STRING
                }
            }
        },
        "access-constraints" => {"sensitive" => {"snapshots" => {"type" => "core"}}},
        "read-only" => false
    }
}
Résultat

La description est affichée pour l'opération choisie.

3.6.5. Afficher les noms de l'opération en utilisant l'interface CLI

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

Exemple 3.11. Afficher les noms de l'opération en utilisant l'interface CLI

L'exemple suivant vous montre la méthode utilisée pour décrire l'opération read-operation-names.
[standalone@localhost:9999 /]:read-operation-names
{
    "outcome" => "success",
    "result" => [
        "add-namespace",
        "add-schema-location",
        "delete-snapshot",
        "full-replace-deployment",
        "list-snapshots",
        "read-attribute",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-config-as-xml",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "reload",
        "remove-namespace",
        "remove-schema-location",
        "replace-deployment",
        "resolve-expression",
        "resolve-internet-address",
        "server-set-restart-required",
        "shutdown",
        "take-snapshot",
        "undefine-attribute",
        "upload-deployment-bytes",
        "upload-deployment-stream",
        "upload-deployment-url",
        "validate-address",
        "validate-operation",
        "whoami",
        "write-attribute"
    ]
}
Résultat

Les noms d'opérations disponibles sont affichés.

3.6.6. Afficher les ressources disponibles en utilisant l'interface CLI

Résumé

L'opération read-resource est une opération globale utilisée pour lire la valeur des ressources. Peut être utilisée pour exposer des informations complètes ou de base sur les ressources des nœuds en cours ou des nœuds enfants, ainsi qu'un ensemble de propriétés de requêtes qui peuvent étendre ou limiter l'étendue des résultats de l'opération. Les propriétés de la requête incluent les paramètres suivants.

Propriétés de requêtes

recursive
Pour savoir si on doit inclure récursivement des informations complètes sur les ressources enfant.
recursive-depth
La précision des informations de ressources enfant incluses
proxies
Si on doit inclure des ressources éloignées pour une recherche récursive. Par exemple, si on doit inclure les ressources niveau hôte à partir des contrôleurs hôtes esclave pour une demande de contrôleur de domaines.
include-runtime
Si on doit inclure des attributs de runtime dans la réponse, comme des valeurs d'attributs qui ne proviennent pas de la configuration persistante. Cette propriété de requête est définie sur false par défaut.
include-defaults
Une propriété de demande booléenne qui sert à activer ou à désactiver la lecture des attributs par défaut. Si définie sur false, seuls les attributs définis par l'utilisateur seront renvoyés, ignorant ainsi ceux qui sont non définis.

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
        }
    }
    

3.6.7. Afficher les descriptions de ressources disponibles en utilisant l'interface CLI

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)
Résultat

Les descriptions des ressources disponibles sont affichées.

3.6.8. Charger à nouveau le serveur d'applications à l'aide du CLI

Avec l'interface CLI, utiliser l'opération reload pour fermer tous les services et démarrer le runtime à nouveau. Une fois que la commande reload sera complétée, l'interface CLI se reconnectera automatiquement.
Pour obtenir plus d'informations sur les demandes d'opérations, voir Section 3.5.8, « Utiliser les opérations et les commandes de l'interface CLI ».

Exemple 3.16. Charger à nouveau le serveur d'applications

[standalone@localhost:9999 /]:reload
{"outcome" => "success"}

3.6.9. Fermer le serveur d'applications par l'interface CLI

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.

Note

Ajouter l'argument (restart=true) à la commande :shutdown (comme indiqué ci-dessous) entraînera le redémarrage du serveur.
[standalone@localhost:9999 /]:shutdown(restart=true)
Résultat

Le serveur d'applications se ferme. Le CLI sera déconnecté car le runtime n'est pas disponible.

3.6.10. Configurer un attribut à l'aide du CLI

Résumé

L'opération write-attribute est une opération globale utilisée pour écrire ou modifier un attribut de la ressource sélectionnée. Vous pouvez utiliser l'opération pour rendre les modifications persistantes ou pour modifier les paramètres de configuration de vos instances de serveur géré. Les propriétés de la requête incluent les paramètres suivants.

Propriétés de requêtes

name
Le nom de l'attribut pour définir la valeur sous la ressource sélectionnée.
value
La valeur désirée de l'attribut sous la ressource sélectionnée. Peut être « null » si le modèle sous-jacent supporte des valeurs « null ».

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é.

Exemple 3.17. Désactiver le scanner de déploiement par l'opération write-attribute

L'exemple suivant utilise l'opération write-attribute pour désactiver le scanner de déploiement. L'opération est exécutée à partir d'un nœud root, en utilisant l'onglet de complétion de tâche pour pouvoir peupler le chemin de ressources qui convient.
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)
{"outcome" => "success"}
Le résultat de l'opération peut être confirmé directement par l'opération read-attribute.
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled)
{
    "outcome" => "success",
    "result" => false
}
Les résultats peuvent également être confirmés en listant tous les attributs de ressources du nœud disponibles par l'opération read-resource. Dans l'exemple suivant, cette configuration particulière vous montre que l'attribut scan-enabled est maintenant défini à false.
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-resource                                 
{
    "outcome" => "success",
    "result" => {
        "auto-deploy-exploded" => false,
        "auto-deploy-xml" => true,
        "auto-deploy-zipped" => true,
        "deployment-timeout" => 600,
        "path" => "deployments",
        "relative-to" => "jboss.server.base.dir",
        "scan-enabled" => false,
        "scan-interval" => 5000
    }
}
Résultat

L'attribut de ressource est mis à jour.

3.6.11. Configurer les propriétés système par l'interface CLI

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"}}}}}}
      }
      

3.7. Historique des commandes de l'interface CLI

3.7.1. Utiliser l'historique de commandes à l'aide de l'interface CLI.

L'interface CLI contient une fonctionnalité d'historique de commandes qui est activée par défaut dans l'installation du serveur d'applications. L'historique est conservé en tant qu'archive dans la mémoire volatile de la session CLI active, et est ajouté le fichier journal qui sauvegarde automatiquement dans le répertoire d'accueil de l'utilisateur sous le nom .jboss-cli-history. Le fichier de l'historique est configuré par défaut pour enregistrer un maximum de 500 commandes CLI.
La commande history elle-même renverra l'historique de la session en cours, ou si accompagnée d'arguments, elle pourra désactiver, activer ou supprimer l'historique de la mémoire de session. L'interface CLI vous donne également la possibilité d'utiliser les flèches de votre clavier pour naviguer dans l'historique des commandes et des opérations.

3.7.2. Afficher l'historique de commandes par interface CLI.

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
Résultat

L'historique de la commande CLI stocké en mémoire depuis le démarrage du CLI ou la commande de suppression de l'historique est affiché.

3.7.3. Effacer l'historique de commandes par interface CLI.

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
Résultat

L'historique des commandes enregistré depuis le démarrage du CLI est supprimé de la mémoire de session. L'historique de la commande est toujours présent dans le fichier .jboss-cli-history qui est sauvegardé dans le répertoire d'accueil de l'utilisateur.

3.7.4. Désactiver l'historique de commandes par l'interface CLI.

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
Résultat

Les commandes passées dans le CLI ne seront pas enregistrées dans la mémoire ou dans un fichier .jboss-cli-history sauvegardé dans le répertoire d'accueil de l'utilisateur.

3.7.5. Activer l'historique des commandes de l'interface CLI

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
Résultat

Les commandes passées dans le CLI seront enregistrées dans la mémoire ou dans un fichier .jboss-cli-history sauvegardé dans le répertoire d'accueil de l'utilisateur.

3.8. La journalisation d'auditing de l'interface de gestion

3.8.1. La journalisation d'auditing de l'interface de gestion

Quand la journalisation de l'auditing est activée, toutes les opérations effectuées par la console de gestion, l'interface CLI, ou l'application de gestion personnalisée manuellement sont assujetties à la journalisation d'auditing.
Les entrées de journalisation d'auditing sont stockées en format JSON et, basées sur votre configuration, elles peuvent être stockées dans des fichiers, elles peuvent être envoyées dans un serveur syslog ou les deux à la fois. Les journalisation d'auditing ne peut être configurée qu'à l'aide de l'interface CLI et est désactivée par défaut.
Les événements de connexion et de déconnexion ne peuvent pas être audités car il n'y a pas de session d'authentification dans EAP. Au lieu de cela, les messages d'auditing sont journalisés quand l'utilisateur reçoit une opération.

Note

Par défaut, la journalisation d'auditing n'est pas active. La journalisation d'auditing ne peut être configurée que par l'interface CLI.
Pour lister toutes les options disponibles de configuration de journalisation d'auditing de l'interface de gestion et leurs valeurs courantes, saisir la commande de ligne suivante :

Note

Ajouter le préfixe /host=HOST_NAME à la commande si vous devez appliquer les changements à un domaine géré.
[... /] /core-service=management/access=audit:read-resource(recursive=true)

3.8.2. Activer la Journalisation d'auditing de l'interface de gestion par l'intermédiaire d'un fichier.

Pour activer les sorties de journalisation dans un fichier, saisir la commande d'interface CLI suivante.

Note

Si la modification s'applique à un domaine géré, ajouter le préfixe /host=HOST_NAME à la commande suivante.
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
Les opérations de gestion sont maintenant journalisées dans un fichier :
  • En mode autonome : EAP_HOME/standalone/data/audit-log.log
  • En mode de domaine : EAP_HOME/domain/data/audit-log.log
Pour obtenir des informations sur les attributs du gestionnaire de tous les fichiers, consulter Section A.3, « Référence de Journalisation d'auditing de l'interface de gestion ».

3.8.3. Activer la journalisation d'auditing de l'interface de gestion par le serveur syslog.

Par défaut, la journalisation d'auditing est préconfigurée pour pouvoir être déversée dans un fichier une fois activée. Cette procédure configure la sortie dans un serveur syslog et active la journalisation d'auding dans un fichier. Pour obtenir plus d'informations sur les attributs de gestionnaire syslog, consulter Section A.3, « Référence de Journalisation d'auditing de l'interface de gestion ».

Note

Si la modification s'applique à un domaine géré, ajouter le préfixe /host=HOST_NAME à la commande /core-service.

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
Résultat

Les entrées de journalisation de l'auditing de l'interface de gestion sont alors enregistrées sur le serveur syslog.

3.8.4. Lire une Journalisation d'auditing de l'interface de gestion

Les sorties de journalisation d'auditing en fichier(s) peuvent être lues grace à visionneur, tandis que les mêmes sorties dans un serveur syslog devront être visionnées à l'aide d'une application de visionneur de syslog.

Note

Utiliser un éditeur de texte pour visionner les fichiers de journalisation n'est pas conseillé car il est possible que cela empêche la journalisation ultérieure.
Les journaux d'auditing de l'interface de gestion sont présentés sous un format JSON. Chaque entrée de journalisation commence par une date de dernière modification suivie des champs listés dans le tableauManagement Interface Audit Log Fields.

Tableau 3.5. Champs de journalisation d'auditing de l'interface de gestion

Nom de champ Description
type Peut avoir pour valeur core, indiquant ainsi qu'il s'agit d'une opération de gestion, ou jmx indiquant une provenance de sous-système JMX (voir le sous-système JMX pour la configuration de la journalisation de l'auditing du sous-système JMX).
r/o Sur true si l'opération ne modifie pas le modèle de gestion, sinon false.
booting Sur true si l'opération a été exécutée à l'amorçage, false si elle a été exécutée une fois que le serveur était en route.
version Le numéro de version de l'instance JBoss EAP.
user Le nom d'utilisateur de l'utilisateur authentifié. Si l'opération a été journalisée par l'interface CLI sur le même ordinateur que le serveur en cours d'exécution, l'utilisateur spécial $local sera utilisé.
domainUUID Un identifiant pour relier toutes les opérations tandis qu'elles sont propagées du contrôleur de domaines vers ses serveurs, ses contrôleurs hôtes, et ses serveurs de contrôleurs hôtes esclaves.
access Peut avoir une des valeurs suivantes :
  • NATIVE - L'opération est venue par le biais de l'interface de gestion native, comme l'interface CLI.
  • HTTP - L'opération est venue par le biais de l'interface HTTP de domaine, comme la console de gestion.
  • JMX - L'opération est venue par le biais du sous-système JMX. Voir JMX pour voir la façon de configurer la journalisation d'auditing de JMX.
remote-address L'adresse du client qui exécute l'opération.
success Sur true si l'opération a réussi, false si non.
ops Les opérations en cours. Liste des opérations sérialisées dans JSON. Au démarrage, cela correspond à toutes les opérations résultant du traitement XML. Une fois démarré, la liste contient normalement une seule entrée.

Chapitre 4. Gestion des utilisateurs

4.1. Création d'utilisateur

4.1.1. Ajouter un utilisateur pour les interfaces de gestion

Aperçu

Les instances de gestion de JBoss EAP 6 sont sécurisés par défaut car il n'y a aucun compte d'utilisateur disponible au départ, (sauf si vous avez installé la plateforme à l'aide de l'installateur graphique.) Il s'agit d'une mesure de précaution visant à éviter les failles de sécurité qui peuvent découler de simples erreurs de configuration.

La communication HTTP avec la plate-forme JBoss EAP 6 est considérée « communication à distance », même si le trafic prend sa source sur l'hôte local. Par conséquent, vous devez créer au moins un utilisateur afin de pouvoir utiliser la console de gestion. Si vous essayiez d'accéder à la console de gestion avant d'ajouter un utilisateur, vous receviez une erreur parce qu'il n'y a pas de déploiement tant que l'utilisateur n'a pas été créé.
Suivez ces étapes pour créer l'utilisateur d'administration d'origine, qui peut utiliser la console de gestion basée web et les instances éloignées de l'interface CLI pour configurer et administrer la plate-forme JBoss EAP 6 à partir de systèmes distants.

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.
Résultat

Tout utilisateur que vous ajoutez est activé dans les domaines de sécurité que vous avez indiqués. Les utilisateurs actifs dans le domaine ManagementRealm sont en mesure de gérer la plateforme JBoss EAP 6 à partir de systèmes éloignés.

4.1.2. Passer des arguments au script add-user de la gestion utilisateur

Vous pouvez exécuter la commande add-user.sh ou add-user.bat interactivement ou vous pouvez passer des arguments par la ligne de commande. Cette section décrit les options qui se présentent pour passer des arguments en ligne de commande au script add-user.
Pour obtenir une liste d'arguments en ligne de commandes disponibles pour add-user.sh ou add-user.bat, consulter Section 4.1.3, « Arguments pour la commande Add-user » .
Pour plus d'informations sur la façon d'indiquer un autre fichier de propriétés et son emplacement, consulter Section 4.1.4, « Spécifier des fichiers de propriétés alternatifs pour les informations de gestion des utilisateurs » .
Pour obtenir des exemples qui montrent comment passer des arguments sur la commande add-user.sh ou add-user.bat, consulter Section 4.1.5, « Exemples de lignes de commande de script Add-user » .

4.1.3. Arguments pour la commande Add-user

Le tableau suivant décrit les arguments disponibles pour la commande add-user.sh ou add-user.bat.

Tableau 4.1. Arguments pour la commande Add-user

Argument de ligne de commande Valeur d'argument Description
-a
S/O
Cet argument demande de créer un utilisateur dans le domaine de l'application. S'il est omis, un utilisateur sera créé par défaut dans le domaine de gestion.
-dc
DOMAIN_CONFIGURATION_DIRECTORY
Cet argument spécifie le répertoire de configuration de domaine qui contient les fichiers de propriétés. S'il est omis, le répertoire par défaut sera EAP_HOME/domain/configuration/.
-sc
SERVER_CONFIGURATION_DIRECTORY
Cet argument spécifie un répertoire de configuration de serveur autonome différent qui contient les fichiers de propriétés. S'il est omis, le répertoire par défaut sera EAP_HOME/standalone/configuration/.
-up
--user-properties
USER_PROPERTIES_FILE
Cet argument spécifie le nom d'un autre fichier de propriétés utilisateur. Il peut correspondre à un chemin absolu ou il peut correspondre à un nom de fichier utilisé en conjonction avec l'argument -sc ou -dc qui spécifie le répertoire de configuration alternatif.
-g
--group
GROUP_LIST
Une liste séparée par des virgules de groupes à assigner à cet utilisateur.
-gp
--group-properties
GROUP_PROPERTIES_FILE
Cet argument spécifie le nom d'un autre fichier de propriétés de groupe. Il peut correspondre à un chemin absolu ou il peut correspondre à un nom de fichier utilisé en conjonction avec l'argument -sc ou -dc qui spécifie le répertoire de configuration alternatif.
-p
--password
PASSWORD
Le mot de passe utilisateur. Le mot de passe doit remplir les critères suivants :
  • Il doit contenir 8 caractères au moins.
  • Il doit contenir au moins un caractère de l'alphabet.
  • Il doit contenir un chiffre au moins.
  • Il doit contenir au moins un symbole non alphanumérique
-u
--user
USER_NAME
Le nom de l'utilisateur. Seuls les caractères alphanumériques et les symboles suivants sont valides : ,./=@\.
-r
--realm
REALM_NAME
Le nom du domaine utilisé pour sécuriser les interfaces de gestion. S'il est omis, la valeur par défaut sera ManagementRealm.
-s
--silent
S/O
Exécuter le script add-user sans sortie vers la console.
-h
--help
S/O
Afficher les informations d'utilisation du script add--user.

4.1.4. Spécifier des fichiers de propriétés alternatifs pour les informations de gestion des utilisateurs

Aperçu

Par défaut, les informations utilisateurs et rôles créés à l'aide du script add-user.sh ou Add-user.bat sont stockées dans des fichiers de propriétés situés dans le répertoire de configuration de serveur. Les informations de configuration du serveur sont stockées dans le répertoire EAP_HOME/standalone/configuration/ et les informations de configuration de domaine sont stockées dans le répertoire EAP_HOME/domaine/configuration/. Cette rubrique décrit comment substituer les noms de fichier et emplacements par défaut.

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.

Note

La commande add-user a pour but d'opérer sur des fichiers de propriétés existants. Tout fichier de propriété alternatif spécifié dans un argument de ligne de commande devra sortir là où vous verrez l'erreur suivante :
JBAS015234: No appusers.properties files found
Pour obtenir plus d'informations sur les arguments de commande, consulter Section 4.1.3, « Arguments pour la commande Add-user » .
Pour obtenir plus d'exemples sur les commandes add-user, consulter Section 4.1.5, « Exemples de lignes de commande de script Add-user » .

4.1.5. Exemples de lignes de commande de script Add-user

Les exemples suivants montrent comment passer des arguments à la commande add-user.sh ou add-user.bat. À moins que cela soit notifié, ces commandes supposent la configuration d'un serveur autonome.

Exemple 4.1. Créer un utilisateur qui appartienne à un groupe unique en utilisant les fichiers de propriétés par défaut.

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest'
La commande ci-dessus produit les résultats suivants.
  • L'utilisateur appuser1 est ajouté aux fichiers de propriétés suivants par défaut qui contiennent les informations utilisateur.
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • L'utilisateur appuser1 ayant pour groupe guest est ajouté aux fichiers de propriétés suivants par défaut qui contiennent les informations utilisateur.
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

Exemple 4.2. Créer un utilisateur qui appartienne à plusieurs groupes en utilisant les fichiers de propriétés par défaut.

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest,app1group,app2group'
La commande ci-dessus produit les résultats suivants.
  • L'utilisateur appuser1 est ajouté aux fichiers de propriétés suivants par défaut qui contiennent les informations utilisateur.
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • L'utilisateur appuser1 ayant pour groupes guest, app1group, et app2group est ajouté aux fichiers de propriétés suivantes par défaut qui contiennent les informations utilisateur.
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

Exemple 4.3. Créer un utilisateur ayant des privilèges admin dans le domaine par défaut en utilisant les fichiers de propriétés par défaut.

EAP_HOME/bin/add-user.sh -u 'adminuser1' -p 'password1!' -g 'admin'
La commande ci-dessus produit les résultats suivants.
  • L'utilisateur adminuser1 est ajouté aux fichiers de propriétés suivantes par défaut qui contiennent les informations utilisateur.
    EAP_HOME/standalone/configuration/mgmt-users.properties
    EAP_HOME/domain/configuration/mgmt-users.properties
  • L'utilisateur adminuser1 ayant pour groupe admin est ajouté aux fichiers de propriétés suivants par défaut qui contiennent les informations utilisateur.
    EAP_HOME/standalone/configuration/mgmt-groups.properties
    EAP_HOME/domain/configuration/mgmt-groups.properties

Exemple 4.4. Créer un utilisateur qui appartienne à un groupe unique en utilisant des fichiers de propriétés alternatifs pour stocker des informations.

EAP_HOME/bin/add-user.sh -a -u appuser1 -p password1! -g app1group -sc /home/someusername/userconfigs/ -up appusers.properties -gp appgroups.properties 
La commande ci-dessus produit les résultats suivants.
  • L'utilisateur appuser1 est ajouté aux fichiers de propriétés suivants et ce fichier est maintenant le fichier par défaut qui contient les informations utilisateur.
    /home/someusername/userconfigs/appusers.properties
  • L'utilisateur appuser1 ayant pour groupe app1group est ajouté aux fichiers de propriétés suivants et ce fichier est maintenant le fichier par défaut qui contient les informations utilisateur.
    /home/someusername/userconfigs/appgroups.properties

Chapitre 5. Réseau et configuration de port

5.1. Interfaces

5.1.1. Les interfaces

Le serveur d'applications utilise des références d'interfaces nommées dans la configuration. Cela permet à la configuration de référencer les déclarations d'interfaces individuelles avec des noms logiques, au lieu de référencer toutes les informations sur l'interface à chaque utilisation. L'utilisation de noms logiques permet également de conserver une homogénéité des références de groupe pour les interfaces nommées, quand les instances de serveur d'un domaine géré peuvent contenir des informations d'interface diverses à travers les machines. En utilisant cette méthodologie, chaque instance de serveur peut correspondre à un groupe de nom logique, ce qui facilite l'administration du groupe d'interfaces dans son ensemble.
Une interface réseau est déclarée en spécifiant un nom logique et un critère de sélection pour l'interface physique. Le serveur d'applications est fourni avec une configuration par défaut pour une gestion et un nom d'interface publique. Dans cette configuration, le groupe de l'interface publique est destiné à être utilisé par toute communication de réseau liée à l'application comme Web ou Messaging. Le groupe interface de gestion est destiné à tous les composants et les services requis par la couche de gestion, y compris HTTP Management Endpoint. Les noms d'interface sont fournis en tant que suggestions uniquement, alors que n'importe quel nom de groupe peut être substitué ou créé selon les besoins.
Les fichiers de configuration domain.xml, host.xml et standalone.xml comprennent tous des déclarations d'interface. Les critères de déclaration peuvent référencer une adresse générique ou spécifier un ensemble de caractéristiques qu'une interface ou une adresse doit avoir pour pouvoir établir une correspondance valide. Les exemples suivants illustrent plusieurs configurations possibles de déclarations d'interface, généralement définies soit dans le fichier de configuration standalone.xml ou host.xml. Cela permet à des groupes d'hôtes distants de maintenir leurs propres attributs d'interfaces spécifiques, tout en permettant une référence aux groupes d'interfaces dans le fichier de configuration domain.xml du contrôleur de domaine.
Le premier exemple montre une valeur d'inet-address indiquée pour le groupe de noms relatifs management et public.

Exemple 5.1. Un groupe d'interfaces créé avec une adresse inet

<interfaces>
  <interface name="management">
   <inet-address value="127.0.0.1"/>
  </interface>
  <interface name="public">
   <inet-address value="127.0.0.1"/>
  </interface>
</interfaces>

Dans l'exemple suivant, un groupe global interface utilise l'élément any-address pour déclarer une adresse générique.

Exemple 5.2. Un groupe global créé avec une déclaration générique

<interface name="global">
   <!-- Use the wild-card address -->
   <any-address/>
</interface>

L'exemple suivant déclare une carte d'interface de réseau sous un groupe relatif avec un nom externe.

Exemple 5.3. Un groupe externe créé avec un NIC

        
<interface name="external">
   <nic name="eth0"/>
</interface>

Dans l'exemple suivant, une déclaration est créée comme groupe par défaut pour un besoin spécifique. Dans ce cas, les caractéristiques des éléments supplémentaires définissent les conditions pour que l'interface soit une correspondance valide. Cela permet la création de groupes de déclaration d'interface très spécifique, avec la possibilité de les référencer de manière prédéfinie, réduisant ainsi le temps de configuration et d'administration sur plusieurs instances de serveur.

Exemple 5.4. Un groupe par défaut créé avec des valeurs conditionnelles spécifiques

<interface name="default">
   <!-- Match any interface/address on the right subnet if it's
        up, supports multicast, and isn't point-to-point -->
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>

Alors que les déclarations d'interface peuvent être faites et modifiées dans les fichiers de configuration des sources, l'interface CLI et la console de gestion fournissent un environnement sécurisé, contrôlé et persistant pour les modifications de configuration.

5.1.2. Configurer les interfaces

Les configurations de l'interface par défaut des fichiers de configuration standalone.xml et host.xml offrent trois interfaces nommées avec jetons d'interfaces relatives pour chacune. Vous pouvez utiliser la console de gestion ou l'interface CLI pour configurer des attributs et valeurs supplémentaires indiquées dans le tableau ci-dessous. Vous pouvez également remplacer les liaisons d'interfaces relatives par des valeurs spécifiques selon les besoins, mais notez que si vous le faites, vous serez incapable de passer une valeur d'interface en cours d'exécution de serveur, car -b> peut seulement substituer une valeur relative.

Exemple 5.5. Configuration d'interface par défaut

        
<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>

Tableau 5.1. Attributs et valeurs d'interface

Élément d'interface Description
any Élément vide de type exclusion d'adresse, utilisé pour forcer le critère de sélection.
any-address Élément vide indiquant que les sockets qui utilisent cette interface doivent être liés à une adresse générique. L'adresse générique IPv6 (::) sera utilisée à moins que la propriété système java.net.preferIpV4Stack soit définie sur true, dans lequel cas, l'adresse générique (0.0.0.0) IPv4 sera utilisée. Si un socket est lié à une adresse anylocal IPv6 sur une machine dual-stack, il pourra accepter le trafic IPv6 et IPv4 ; si lié à l'adresse IPv4 anylocal (mappées IPv4), il ne peut accepter que le trafic IPv4.
any-ipv4-address Élément vide indiquant que les sockets qui utilisent cette interface doivent être liés à une adresse générique (0.0.0.0) IPv4.
any-ipv6-address Élément vide indiquant que les sockets qui utilisent cette interface doivent être liés à une adresse générique (::). IPv6.
inet-address Soit une adresse IP en notation à points IPV6 ou IPV4, ou un nom d'hôte pouvant être résolu.
link-local-address Élément vide indiquant qu'une partie du critère de sélection d'une interface devrait consister à savoir si oui ou non il a une adresse associée local-link.
loopback Élément vide indiquant qu'une partie du critère de sélection d'une interface est de savoir s'il s'agit oui ou non d'une interface de loopback.
loopback-address Une adresse de loopback qui ne peut pas réellement être configurée sur l'interface de loopback de la machine. Diffère d'inet-addressType car la valeur donnée sera utilisée même si aucune carte réseau possédant l'adresse IP associée ne peut être trouvée.
multicast Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être si oui ou non il y a un support multi-diffusion.
nic Le nom d'une interface de réseau (e.g. eth0, eth1, lo).
nic-match Une expression standard à laquelle faire correspondre les noms des interfaces de réseau disponibles sur la machine pour trouver une interface qui convienne.
not Élément vide de type exclusion d'adresse, utilisé pour forcer le critère de sélection.
point-to-point Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être de savoir si elle a oui ou non une interface d'un point à un autre.
public-address Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être de savoir si elle a oui ou non une adresse publiquement routable.
site-local-address Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être ou non une adresse associée à son site-local
subnet-match Une adresse IP réseau et le nombre de bits dans le préfixe de réseau de l'adresse, sous la forme « / » ; par exemple"192.168.0.0/16".
up Élément vide indiquant qu'une partie du critère de sélection d'une interface est active ou non.
virtual Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être ou non une interface virtuelle.
  • 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.

5.2. Groupes de liaisons de sockets

5.2.1. Groupes de liaisons de sockets

Les liaisons de sockets et les groupes de liaisons de sockets vous permettent de définir les ports de réseau et leur relation aux interfaces de réseau requises pour votre configuration JBoss EAP 6.
Une liaison de socket est une configuration nommée pour un socket. Les déclarations pour ces configurations nommées se trouvent dans les deux fichiers de configuration domain.xml et standalone.xml. D'autres sections de la configuration peuvent alors faire référence à ces sockets par leur nom logique, plutôt que d'avoir à inclure tous les détails de la configuration de socket. Cela permet de référencer des configurations de sockets relatives qui peuvent varier sur des machines différentes.
Les liaisons de sockets sont rassemblées sous un groupe de liaisons de sockets. Un groupe de liaisons de sockets est une collection de déclarations de liaisons de sockets qui sont regroupées sous un nom logique. Le groupe peut ensuite être référencé dans l'ensemble de la configuration. Un serveur autonome contient uniquement un de ces groupes, alors qu'une instance managée de domaine peut contenir plusieurs groupes. Vous pouvez créer un groupe de liaison de socket pour chaque groupe de serveurs dans le domaine géré, ou partager un groupe de liaisons de sockets entre plusieurs groupes de serveurs.
Les groupes de noms permettent à des références simplifiées d'être utilisées pour des groupes particuliers de liaisons de sockets lors de la configuration des groupes de serveurs, dans le cas d'un domaine géré. Une autre utilisation courante est pour la configuration et la gestion de plusieurs instances du serveur autonome sur un seul système. Les exemples suivants montrent les groupes de liaison de sockets par défaut dans les fichiers de configuration des instances du domaine et du serveur autonome.

Exemple 5.6. Liaisons de sockets par défaut pour la configuration du serveur autonome.

Les groupes de liaisons de sockets par défaut dans le fichier de configuration standalone.xml sont groupés sous standard-sockets. Ce groupe est aussi référencé dans l'interface publique , en utilisant la même méthodologie de référencement logique.
   
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-native" interface="management" port="${jboss							.management.native.port:9999}"/>
        <socket-binding name="management-http" interface="management" port="${jboss								.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss							.management.https.port:9443}"/>
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
</socket-binding-group>

Exemple 5.7. Liaisons de sockets par défaut pour la configuration du serveur autonome.

Les groupes de liaisons de sockets par défaut dans le fichier de configuration domain.xml contiennent quatre groupes : standard-sockets, ha-sockets, full-sockets et full-ha-sockets. Ces groupes sont également référencés dans une interface appelée public.
<socket-binding-groups>
        <socket-binding-group name="standard-sockets" default-interface="public">
            <!-- Needed for server groups using the 'default' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
                <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
        <socket-binding-group name="ha-sockets" default-interface="public">
            <!-- Needed for server groups using the 'ha' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss									.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
            <socket-binding name="jgroups-tcp" port="7600"/>
            <socket-binding name="jgroups-tcp-fd" port="57600"/>
            <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss								.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
            <socket-binding name="jgroups-udp-fd" port="54200"/>
            <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" 								multicast-port="23364"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
        <socket-binding-group name="full-sockets" default-interface="public">
            <!-- Needed for server groups using the 'full' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="jacorb" interface="unsecure" port="3528"/>
            <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
            <socket-binding name="messaging" port="5445"/>
            <socket-binding name="messaging-group" port="0" multicast-address="${jboss								.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
            <socket-binding name="messaging-throughput" port="5455"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
        <socket-binding-group name="full-ha-sockets" default-interface="public">
            <!-- Needed for server groups using the 'full-ha' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="jacorb" interface="unsecure" port="3528"/>
            <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
            <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss									.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
            <socket-binding name="jgroups-tcp" port="7600"/>
            <socket-binding name="jgroups-tcp-fd" port="57600"/>
            <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss								.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
            <socket-binding name="jgroups-udp-fd" port="54200"/>
            <socket-binding name="messaging" port="5445"/>
            <socket-binding name="messaging-group" port="0" multicast-address="${jboss								.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
            <socket-binding name="messaging-throughput" port="5455"/>
            <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" 								multicast-port="23364"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
    </socket-binding-groups>
Les instances de liaisons de sockets peuvent être créées et modifiées dans les fichiers source standalone.xml et domain.xml du répertoire de l'application. La méthode recommandée pour gérer les liaisons consiste à utiliser la console de gestion ou l'interface CLI. Les avantages à utiliser la console de gestion est l'interface utilisateur graphique avec un écran de groupes de liaisons de sockets dédié dans la section Configuration générale. L'interface CLI propose un API et un flux de travail basés ligne de commande qui permettent le traitement par lots et l'utilisation de scripts aux niveaux supérieurs et inférieurs de la configuration de serveur d'applications. Les deux interfaces permettent la persistance des modifications ou bien leur enregistrement dans la configuration du serveur.

5.2.2. Configurer les liaisons de sockets

Les liaisons de sockets peuvent être définies dans des groupes de liaisons sockets uniques. Le serveur autonome contient un de ces groupes, le groupe standard-sockets, et ne peut pas créer de groupes supplémentaires. À la place, vous pouvez créer des fichiers de configuration de serveur autonome alternatif. Pour le domaine géré cependant, vous pouvez créer des groupes de liaisons de sockets et configurer les liaisons de sockets qu'ils contiennent selon vos besoins. Le tableau suivant montre les attributs disponibles pour chaque liaison de sockets.

Tableau 5.2. Attributs de liaisons de sockets

Attribut Description Rôle
name Nom logique de la configuration de socket qui doit être utilisée ailleurs dans la configuration. Requis
port Port de base auquel un socket basé sur cette configuration doit être lié. Notez que les serveurs peuvent être configurés pour substituer cette valeur de base en appliquant une incrémentation ou décrémentation à toutes les valeurs de port. Requis
interface Nom logique de l'interface à laquelle un socket basé sur cette configuration doit être lié. Si non défini, la valeur de l'attribut default-interface du groupe de liaison de sockets enveloppant servira. Option
multicast-address Si le socket doit être utilisé en multi-diffusion, c'est l'adresse multi-diffusion qu'il vous faut. Option
multicast-port Si le socket doit être utilisé en multi-diffusion, c'est le port multi-diffusion qu'il vous faut. Option
fixed-port Si défini sur true, déclare que la valeur de port doit toujours être utilisée par le socket et ne doit pas être remplacée par l'ajout d'un incrément ou d'un décrément. Option
  • 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.

5.2.3. Ports de réseau utilisés par JBoss EAP 6

Les ports utilisés par la configuration JBoss EAP 6 par défaut sont liés à plusieurs facteurs :
  • Le fait que vos groupes de serveurs utilisent le groupe de liaisons de sockets par défaut, ou un groupe de liaisons de sockets personnalisé.
  • Les exigences de vos déploiements individuels.

Note

Un décalage de port numérique peut être configuré pour atténuer les conflits de ports lorsque vous exécutez plusieurs serveurs sur un même serveur physique. Si votre serveur utilise un décalage de port numérique, ajoutez la valeur de décalage au numéro de port par défaut pour le groupe de liaisons de sockets de son groupe de serveurs. Par exemple, si le port HTTP du groupe de liaisons de socket est 8080 et si votre serveur utilise un décalage de port de 100, son port HTTP sera 8180.
À moins d'instruction particulière, les ports utilisent le protocole TCP.

groupes de liaisons de sockets par défaut

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets
Ces groupes de liaisons de sockets sont disponibles uniquement dans domain.xml. Les profils de serveur autonomes contiennent uniquement le groupe de liaisons de sockets standards. Ce groupe correspond à des-sockets standards dans standalone.xml, ha-sockets pour standalone-ha.xml, full-sockets pour standalone-full.xml, et full-ha-sockets pour standalone-full-ha.xml. Les profils autonomes contiennent certaines liaisons de sockets supplémentaires, comme par exemple, management-{native,http,https}.

Tableau 5.3. Référence aux groupes de liaisons de sockets par défaut

Nom Port Port multi-diffusion Description full-ha-sockets full-sockets ha-socket standard-socket
ajp 8009 Protocole Apache JServ. Utilisé pour le clustering HTTP et pour l'équilibrage des charges. Oui Oui Oui Oui
http 8080 Le port par défaut des applications déployées. Oui Oui Oui Oui
https 8443 Connexion cryptée-SSL entre les applications déployées et les clients. Oui Oui Oui Oui
jacorb 3528 Services CORBA pour les transactions JTS et autres services dépendants-ORB. Oui Oui Non Non
jacorb-ssl 3529 Services CORBA cryptés-SSL. Oui Oui Non Non
jgroups-diagnostics 7500 Multidiffusion. Utilisée pour découvrir des homologues dans les groupements HA. Non configurable par les interfaces de gestion. Oui Non Oui Non
jgroups-mping 45700 Multidiffusion. Utilisée pour découvrir l'appartenance de groupe d'origine dans un cluster HA. Oui Non Oui Non
jgroups-tcp 7600 Découverte d'homoplogues unicastes dans les groupements HA avec TCP. Oui Non Oui Non
jgroups-tcp-fd 57600 Utilisé pour la détection des échecs en TCP. Oui Non Oui Non
jgroups-udp 55200 45688 Découverte de pairs multicast dans les groupements HA avec UDP. Oui Non Oui Non
jgroups-udp-fd 54200 Utilisé pour la détection des échecs par UDP. Oui Non Oui Non
messaging 5445 Service JMS. Oui Oui Non Non
messaging-group Référencé par la diffusion HornetQ JMS et les groupes Discovery Oui Oui Non Non
messaging-throughput 5455 Utilisé par JMS Remoting. Oui Oui Non Non
mod_cluster 23364 Port de multidiffusion pour la communication entre JBoss EAP 6 et l'équilibreur de charges HTTP. Oui Non Oui Non
remoting 4447 Utilisé pour l'invocation EJB. Oui Oui Oui Oui
txn-recovery-environment 4712 Gestionnaire de recouvrement des transactions JTA. Oui Oui Oui Oui
txn-status-manager 4713 Gestionnaire des transactions JTA / JTS. Oui Oui Oui Oui
Ports de gestion

En plus des groupes de liaisons de sockets, chaque contrôleur hôte ouvre deux ports supplémentaires pour la gestion :

  • 9990 - Le port de console de gestion web
  • 9999 - Le port utilisé par la console de gestion et par l'API de gestion.
De plus, si HTTPS est activé pour la console de gestion, 9443 sera également ouvert en tant que valeur de port par défaut.

5.2.4. Valeurs de décalage des ports pour les groupes de liaisons de sockets

Les valeurs de décalage des ports (Port offsets) est un décalage chiffré qui vient s'ajouter aux valeurs de port données par le groupe de liaisons de sockets pour ce serveur. Cela permet à un seul serveur d'hériter les liaisons de sockets du groupe de serveurs auquel il appartient, avec un décalage pour veiller à ce qu'il n'entre pas en conflit avec les autres serveurs du groupe. Par exemple, si le port HTTP du groupe de liaisons de sockets est 8080 et si votre serveur utilise un port offset de 100, son port HTTP sera 8180.

5.2.5. Configurer Port Offset (valeurs de décalage de ports)

  • 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.

5.2.6. Configuration de la taille d'un message à distance

Le sous-système de communication à distance (Remoting) offre la possibilité de limiter la taille des messages pour des protocoles de communication à distance. Vous pouvez définir la taille maximale des messages entrants (MAX_INBOUND_MESSAGE_SIZE) et la taille maximale des messages sortants (MAX_OUTBOUND_MESSAGE_SIZE) pour s'assurer que les messages sont reçus et envoyés dans la limite des tailles appropriées.
La configuration de la taille des messages dans des protocoles de communication à distance contribue à une utilisation efficace de la mémoire système et l'empêche d'atteindre un état « out of memory » pendant l'exécution des opérations importantes.
Si l'expéditeur envoie un message qui dépasse la limite maximale admissible (MAX_OUTBOUND_MESSAGE_SIZE), le serveur lèvera une exception et annulera la transmission des données. Toutefois, la connexion restera ouverte et l'expéditeur pourra choisir de fermer le message si nécessaire.
Si un message reçoit la limite permise maximum (MAX_INBOUND_MESSAGE_SIZE), le message sera fermé de façon asynchrone avec la connexion restée ouverte.

5.3. IPv6

5.3.1. Configurer les préférences de JVM Stack d'IPv6 Networking

Résumé
Cette section couvre l'activation du réseau IPv6 de l'installation JBoss EAP 6

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
    

5.3.2. Configurer les déclarations d'interface du réseautage IPv6

Résumé

Suivre ces étapes de configuration de l'adresse inet d'interface dans IPv6 par défaut:

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.

5.3.3. Configurer les Préférences JVM Stacks des adresses IPv6

Résumé
Cette rubrique couvre la configuration de l'installation de JBoss EAP 6 pour qu'elle préfère les adresses IPv6 dans les fichiers de configuration.

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
    

Chapitre 6. Gestion des sources de données

6.1. Introduction

6.1.1. JDBC

L'API JDBC est la norme qui définit comment les bases de données sont accessibles par les applications Java. Une application configure une source de données qui référence un pilote JDBC. Le code de l'application peut alors s'inscrire au pilote, à la place de la base de données. Le pilote convertit le code dans le langage de base de données. Cela signifie que si le pilote qui convient est installé, une application pourra être utilisée sans base de données supportée.
La norme JDBC 4.0 est définie ici : http://jcp.org/en/jsr/detail?id=221.
Pour débuter dans JDBC et avec les sources de données, voir la section JDBC Driver du Guide d'administration et de configuration de JBoss EAP 6.

6.1.2. Bases de données prises en charge par JBoss EAP 6

Liste des bases de données compatibles JDBC prises en charge par JBoss EAP 6 : https://access.redhat.com/site/articles/111663.

6.1.3. Types de sources de données

Les deux grands types de ressources sont nommés les sources de données et les sources de données XA.
Les sources de données non-XA sont utilisées pour les applications qui n'utilisent pas de transactions, ou les applications qui utilisent des transactions avec une base de données simple.
Les sources de données XA sont utilisées par les applications dont les transactions sont réparties à travers plusieurs bases de données. Les sources de données XA rajoutent un niveau supplémentaire.
Vous n'avez qu'à indiquer le type de source de données quand vous la créez dans la console de gestion ou l'interface CLI.

6.1.4. L'exemple de source de données

JBoss EAP 6 inclut une base de données H2. Il s'agit d'un système de gestion de bases de données relationnelles léger, qui donne aux développeurs la possibilité de construire des applications rapidement, et qui représente la source de données de référence pour la plate forme.

Avertissement

Toutefois, elle ne devrait pas être utilisée dans un environnement de production. C'est une source de données très petite, autonome, qui prend en charge toutes les normes nécessaires pour le test et la création d'applications, mais qui n'est pas fiable ou suffisamment évolutive pour une utilisation en production.
Pour obtenir une liste de sources de données certifiées ou prises en charges, consulter Section 6.1.2, « Bases de données prises en charge par JBoss EAP 6 ».

6.1.5. Déploiement des fichiers -ds.xml

Dans JBoss EAP 6, les sources de données sont définies comme une ressource du sous-système de serveur. Dans les versions précédentes, un fichier de configuration de source de données *-ds.xml était requis dans le répertoire de déploiement de la configuration du serveur. Les fichiers *-ds.xml peuvent toujours être déployés dans JBoss EAP 6, suivant le schéma de sources de données 1.1 disponible sous Schemas : http://www.ironjacamar.org/documentation.html.

Avertissement

Cette fonctionnalité doit être utilisée pour le développement uniquement. Elle n'est pas conseillée en production car non supportée par les outils de gestion et d'admin de JBoss. Cette fonctionnalité est dépréciée dans JBoss EAP 6.4 et ne sera pas prise en charge dans la prochaine version du produit.

Important

Il est obligatoire d'utiliser une référence à une entrée de <driver> (pilote) déjà déployé / défini quand on déploie les fichiers *-ds.xml.

6.2. Pilotes JDBC

6.2.1. Installer un pilote JDBC avec la console de gestion

Résumé

Avant que votre application puisse se connecter à une source de données JDBC, vos pilotes JDBC du fournisseur de votre source de données doivent être installés dans un endroit où JBoss EAP 6 puisse les utiliser. JBoss EAP 6 vous permettra de déployer ces pilotes comme tout autre déploiement. Cela signifie que vous pouvez les déployer sur plusieurs serveurs dans un groupe de serveurs, si vous utilisez un domaine géré.

Conditions préalables

Vous devrez remplir les conditions suivantes avant de pouvoir effectuer cette tâche  :

  • Télécharger le pilote JDBC de votre fournisseur de base de données.

Note

Tout pilote conforme à JDBC 4 est automatiquement reconnu et installé dans le système avec son nom et de sa version. Un JAR JDBC utilisant le mécanisme de fournisseur de service Java est identifié. Ces JAR contiennent un fichier-texte nommé META-INF/services/java.sql.Driver qui indique les nom(s) de classes de pilote de ce JAR.

Procédure 6.1. Modifier le JAR du pilote JDBC

Si le JAR de pilote JDBC n'est pas conforme à JDBC 4, il peut être rendu déployable à l'aide de la commande suivante.
  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. 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 ».
Résultat :

Le pilote JDBC est déployé, et est disponible pour vos applications.

6.2.2. Installer un pilote JDBC comme core module

Conditions préalables

Vous devrez remplir les conditions suivantes avant de pouvoir effectuer cette tâche  :

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)
Résultat

Le pilote JDBC est maintenant installé et configuré comme core module. Il est maintenant prêt à être référencé par les sources de données d'application.

6.2.3. Adresses des téléchargements de pilotes JDBC

Le tableau suivant donne les adresses de téléchargement standard pour les pilotes JDBC de bases de données utilisées avec JBoss EAP 6. Ces liens pointent vers des sites tiers qui ne sont pas contrôlés ou surveillés activement par Red Hat. Pour les pilotes les plus à jour de votre base de données, consultez le site Web et la documentation de votre fournisseur de base de données.

6.2.4. Accès aux classes spécifiques à un fournisseur

Résumé

Cette section couvre les étapes à suivre pour utiliser les classes spécifiques JDBC. Cela est utile quand une application a besoin d'utiliser une fonctionnalité spécifique à un fournisseur ne faisant pas partie de l'API JDBC.

Avertissement

Ceci est une procédure d'utilisation avancée. Seules les applications qui ont besoin d'une fonctionnalité que l'on ne peut pas trouver dans l'API JDBC doivent implémenter cette procédure.

Important

Ce processus est requis pour le mécanisme de ré-authentification et pour accéder aux classes spécifiques au fournisseur.

Important

Suivre les directives de l'API spécifiques au fournisseur de près, car la connexion est contrôlée par le conteneur IronJacamar.

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

Vous pouvez ajouter une dépendance à une application en utilisant la méthode que vous préférez.
    • 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>

Exemple 6.8. Accèder à l'API spécifique du fournisseur

L'exemple ci-dessous accède à l'API MySQL.
import java.sql.Connection;
import org.jboss.jca.adapters.jdbc.WrappedConnection;

  Connection c = ds.getConnection();
  WrappedConnection wc = (WrappedConnection)c;
  com.mysql.jdbc.Connection mc = wc.getUnderlyingConnection();

6.3. Sources de données non-XA

6.3.1. Créer une source de données non-XA avec les interfaces de gestion

Résumé

Cette section explique les étapes à suivre pour créer une source de données non-XA, en utilisant la console de gestion ou l'interface CLI.

Conditions préalables

  • Le serveur JBoss EAP 6 doit être en cours d'exécution.

Note

Avant la version 10.2 de la source de données Oracle, le paramètre <no-tx-separate-pools/> était requis, car le mélange de connexions transactionnelles et non-transactionnelles aurait créé une erreur. Ce paramètre n'est plus requis pour certaines applications.

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.
Résultat

La source de données non-Xa a été ajoutée au serveur. Elle est maintenant visible dans le fichier standalone.xml ou le fichier domain.xml, ainsi que dans les interfaces de gestion.

6.3.2. Modifier une source de données non-XA par les interfaces de gestion

Résumé

Cette section explique les étapes à suivre pour modifier une source de données non-XA, en utilisant la console de gestion ou l'interface CLI.

Note

Les sources de données non-XA peuvent être intégrées dans les transactions JTA. Pour intégrer la source de données dans JTA, veillez à ce que le paramètre jta soit défini à true.

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

    • Interface CLI

      1. 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)
      2. Charger à nouveau le serveur pour confirmer les changements :
        :reload
    • Console de gestion

      1. 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.
      2. 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.
Résultat

La source de données non-Xa a été configurée. Elle est maintenant visible dans le fichier standalone.xml ou le fichier domain.xml, ainsi que dans les interfaces de gestion.

6.3.3. Supprimer une source de données non-XA par les interfaces de gestion

Résumé

Ce sujet couvre les étapes requises pour supprimer une source de données non-XA de JBoss EAP 6, en utilisant la console de gestion ou l'interface CLI.

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

    • Interface CLI

      1. Exécuter la commande suivante pour supprimer une source de données non-XA :
        data-source remove --name=DATASOURCE_NAME
    • Console de gestion

      1. 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.
      2. Sélectionner la source de données enregistrée à supprimer, et cliquer sur Remove.
Résultat

La source de données non-XA a été supprimée dans le serveur.

6.4. Sources de données XA

6.4.1. Créer une source de données XA par les interfaces de gestion

Résumé

Cette section explique les étapes à suivre pour créer une source de données XA, en utilisant la console de gestion ou l'interface CLI.

Note

Avant la version 10.2 de la source de données Oracle, le paramètre <no-tx-separate-pools/> était requis, car le mélange de connexions transactionnelles et non-transactionnelles aurait créé une erreur. Ce paramètre n'est plus requis pour certaines applications.

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. 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
      2. 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)
      3. Activer la source de données :
        xa-data-source enable --name=XA_DATASOURCE_NAME
    • Console de gestion

      1. 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.
      2. Sélectionner l'onglet XA Datasource.
      3. 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.
Résultat

La source de données XA a été ajoutée au serveur. Elle est maintenant visible dans le fichier standalone.xml ou le fichier domain.xml, ainsi que dans les interfaces de gestion.

6.4.2. Modifier une Source de données XA par les Interfaces de gestion

Résumé

Cette section explique les étapes à suivre pour modifier une source de données XA, en utilisant la console de gestion ou l'interface CLI.

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. 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)
      2. 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)
      3. Charger à nouveau le serveur pour confirmer les changements :
        :reload
    • Console de gestion

      1. 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.
      2. Sélectionner l'onglet XA Datasource.
      3. 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.
Résultat

La source de données XA a été configurée. Les changements sont maintenant visibles dans le fichier standalone.xml ou le fichier domain.xml, ainsi que dans les interfaces de gestion.

6.4.3. Supprimer une Source de données XA par les Interfaces de gestion

Résumé

Ce sujet couvre les étapes requises pour supprimer une source de données XA de JBoss EAP 6, en utilisant la console de gestion ou l'interface CLI.

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

    • Management CLI

      1. Exécuter la commande suivante pour supprimer une source de données :
        xa-data-source remove --name=XA_DATASOURCE_NAME
    • Console de gestion

      1. 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.
      2. Sélectionner l'onglet XA Datasource.
      3. 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.
Résultat

La source de données XA a été supprimée dans le serveur.

6.4.4. XA Recovery

6.4.4.1. Les modules de recouvrement XA

Chaque ressource XA a besoin d'un module de recouvrement associé avec sa configuration. Le module de recouvrement doit étendre la classe com.arjuna.ats.jta.recovery.XAResourceRecovery.
JBoss EAP 6 fournit des modules de recouvrement pour les ressources JDBC et JMS XA. Pour ces types de ressources, les modules de recouvrement sont automatiquement enregistrés. Si vous avez besoin d'utiliser un module personnalisé, vous pouvez l'enregistrer dans votre source de données.

6.4.4.2. Configurer les modules de recouvrement

Pour la plupart des ressources JDBC et JMS, le module de recouvrement est automatiquement associé à la ressource. Dans de tels cas, vous aurez uniquement besoin de configurer les options qui permettent au module de recouvrement de se connecter à vos ressources afin de procéder au recouvrement.
Pour les ressources personnalisées qui ne sont ni JDBC, ni JMS, contacter Red Hat Global Services pour obtenir des informations sur les configurations qui sont prises en charge.
Chacun de ces attributs de configuration peut être défini lors de la création de la source de données, ou par la suite. Vous pouvez les définir en utilisant la console de gestion basée web ou l'interface CLI par ligne de commande. Se référer à Section 6.4.1, « Créer une source de données XA par les interfaces de gestion » and Section 6.4.2, « Modifier une Source de données XA par les Interfaces de gestion » pour obtenir des informations sur la façon de configurer des sources de données XA.
Voir les tableaux suivants pour les attributs de configuration de sources de données, et pour obtenir des informations sur la configuration spécifique à certains fournisseurs de bases de données.

Tableau 6.2. Attributs de configuration générale

Attribut Description
recovery-username
Le nom d'utilisateur qui doit être utilisé par le module de recouvrement pour se connecter à la ressource de recouvrement.
recovery-password
Le mot de passe qui doit être utilisé par le module de recouvrement pour se connecter à la ressource de recouvrement.
recovery-security-domain
Le domaine de sécurité qui doit être utilisé par le module de recouvrement pour se connecter à la ressource de recouvrement.
recovery-plugin-class-name
Si vous devez utiliser un module de recouvrement personnalisé, définissez cet attribut au nom complet de classe du module. Le module doit étendre la classe com.arjuna.ats.jta.recovery.XAResourceRecovery.
recovery-plugin-properties
Si vous utilisez un module de récupération personnalisée qui requiert des propriétés à définir, définissez cet attribut à la liste de paires key=value séparée par des virgules pour les propriétés.

Informations de configuration spécifiques au fournisseur

Oracle
Si la source de données Oracle n'est pas configurée correctement, vous apercevrez sans doute les erreurs suivantes dans votre sortie de journalisation :

Exemple 6.9. Erreur de la configuration incorrecte

WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
Pour résoudre cette erreur, veillez à ce que l'utilisateur Oracle configuré dans recovery-username ait bien accès aux tableaux utiles au recouvrement. L'énoncé SQL suivant affiche les attributions d'instances correctes Oracle 11g ou Oracle 10g R2 corrigées pour le bogue 5945463 d'Oracle.

Exemple 6.10. Octroi de privilège pour la configuration

GRANT SELECT ON sys.dba_pending_transactions TO recovery-username;
GRANT SELECT ON sys.pending_trans$ TO recovery-username;
GRANT SELECT ON sys.dba_2pc_pending TO recovery-username;
GRANT EXECUTE ON sys.dbms_xa TO recovery-username;
Si vous utilisez une version Oracle 11g antérieure à 11g, modifier l'énoncé final EXECUTE ainsi:
	GRANT EXECUTE ON sys.dbms_system TO recovery-username;
PostgreSQL
Voir la documentation PostgreSQL pour obtenir des instructions sur la façon d'activer des transactions (ex. XA) préparées. La version 8.4-701 du pilote JDBC de PostgreSQL a un bogue dans org.postgresql.xa.PGXAConnection qui empêche le recouvrement dans certaines situations. Cela a été résolu dans les nouvelles versions.
MySQL
Basé sur http://bugs.mysql.com/bug.php?id=12161, le recouvrement de transactions XA ne fonctionnait pas dans certaines versions de MySQL 5. Cela a été corrigé dans MySQL 6.1. Voir l'URL du bogue ou la documentation MySQL pour obtenir davantage d'informations.
IBM DB2
IBM DB2 s'attend à ce que la méthode XAResource.recover soit appelée uniquement pendant la phase de resynchronisation désignée qui se produit lorsque le serveur d'applications est redémarré après un accident ou une panne. Il s'agit d'une décision de conception pour l'implémentation de DB2, qui est en dehors du dessein de cette documentation.
Sybase
Sybase s'attend à ce que les transactions XA soient activées sur la base de données. Sans configuration correcte de la base de données, les transactions XA ne fonctionneront pas. enable xact coordination active ou désactive les services de coordination de transaction Adaptive Server. Lorsque ce paramètre est activé, Adaptive Server garantit que les mises à jour de données Adaptive Server distantes soient validées ou annulées avec la transaction d'origine. Pour permettre la coordination de transaction, utilisez :
sp_configure 'enable xact coordination', 1
.

6.5. Sécurité des bases de données

6.5.1. Sécurité des bases de données

La notion de sécurité des sources de données se réfère à l'encodage ou au déguisement des mots de passe pour les connexions aux sources de données. Les mots de passe peuvent être stockés au format texte brut dans les fichiers de configuration, mais cela représente un risque de sécurité.
La meilleure solution de sécurité de source de données est soit l'utilisation des domaines de sécurité, soit les mots de passe. Vous trouverez un exemple de chacun ci-dessous. Pour plus d'informations, consulter Security Architecture ou les autres documentations de sécurité JBoss.

Exemple 6.11. Exemple de domaine de sécurité

 <security-domain name="DsRealm" cache-type="default">  
  <authentication>  
    <login-module code="ConfiguredIdentity" flag="required">  
      <module-option name="userName" value="sa"/>  
      <module-option name="principal" value="sa"/>  
      <module-option name="password" value="sa"/>  
    </login-module>  
  </authentication>  
</security-domain>
Le domaine DsRealm est référencé par une source de données comme :
<datasources>
  <datasource jndi-name="java:jboss/datasources/securityDs"
    pool-name="securityDs">
    <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
      <driver>h2</driver>
      <new-connection-sql>select current_user()</new-connection-sql>
      <security>
        <security-domain>DsRealm</security-domain>
      </security>
    </datasource>
</datasources>

Exemple 6.12. Exemple de mots de passe

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>

6.6. Validation de la connexion à la base de données

6.6.1. Configuration des paramètres de validation de connexion de la base de données

Aperçu

En raison de problèmes de maintenance de base de données, de problèmes de réseau ou autres événements peuvent amener JBoss EAP 6 à perdre la connexion à la base de données. Vous activez la validation de la connexion à la base de données par l'élément < validation > dans la section < datasource > du fichier de configuration du serveur. Suivez les étapes ci-dessous pour configurer les paramètres de source de données pour activer la validation de connexion de la base de données dans JBoss EAP 6.

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

6.7. Configuration des sources de données

6.7.1. Paramètres de source de données

Tableau 6.3. Les paramètres de source de données communs aux sources XA ou non-XA

Paramètre Description
jndi-name Le nom JNDI unique pour la source de données.
pool-name Le nom du pool de gestion de la source de données.
enabled Indique si la source de données est activée.
use-java-context
Indique si on doit relier la source de données au JNDI global.
spy
Activer la fonctionnalité spy sur la couche JDBC. Cela journalisera tout le trafic JDBC dans la source de données. Notez que la catégorie de journalisation jboss.jdbc.spy doit également être définie au niveau DEBUG dans le sous-système de journalisation.
use-ccm Activer le gestionnaire de connexion cache.
new-connection-sql Un énoncé SQL qui exécute quand la connexion est ajoutée au pool de connexion.
transaction-isolation
Un parmi :
  • TRANSACTION_READ_UNCOMMITTED
  • TRANSACTION_READ_COMMITTED
  • TRANSACTION_REPEATABLE_READ
  • TRANSACTION_SERIALIZABLE
  • TRANSACTION_NONE
url-selector-strategy-class-name Une classe qui implémente l'interface org.jboss.jca.adapters.jdbc.URLSelectorStrategy.
sécurité
Contient des éléments dépendants en tant que paramètres de sécurité. Voir Tableau 6.8, « Paramètres de sécurité ».
validation
Contient des éléments dépendants en tant que paramètres de validation. Voir Tableau 6.9, « Paramètres de validation ».
timeout
Contient des éléments dépendants en tant que paramètres de timeout. Voir Tableau 6.10, « Paramètres de timeout ».
énoncé
Contient des éléments dépendants en tant que paramètres d'énoncés. Voir Tableau 6.11, « Paramètres d'instruction ».

Tableau 6.4. Paramètres de source de données non-xa

Paramètre Description
jta Active l'intégration JTA pour les sources de données non-XA. Ne s'applique pas aux sources de données XA.
connection-url L'URL de connexion du pilote JDBC.
driver-class Le nom complet de la classe de pilote JDBC.
connection-property
Propriétés de connexions arbitraires passées à la méthode Driver.connect(url,props). Chaque connection-property indique une paire name/value. Le nom de la propriété provient du nom, et la valeur provient du contenu de l'élément.
pool
Contient des éléments dépendants en tant que paramètres de pooling. Voir Tableau 6.6, « Les paramètres de pool communs aux sources XA ou non-XA ».
url-delimiter
Le délimiteur d'URLs d'une connexion url pour les bases de données clusterisées HA (Haute disponibilité).

Tableau 6.5. Paramètres de source de données XA

Paramètre Description
xa-datasource-property
Une propriété pour assigner la classe d'implémentation XADataSource. Spécifiée par name=value. Si une méthode setter existe, dans le format setName, la propriété sera définie en appelant une méthode setter sous le format setName(value).
xa-datasource-class
Le nom complet de la classe d'implémentation de javax.sql.XADataSource.
pilote
Unique référence au module de chargeur de classe qui contient le pilote JDBC. Le format accepté est driverName#majorVersion.minorVersion.
xa-pool
Contient des éléments dépendants en tant que paramètres de pooling. Voir Tableau 6.6, « Les paramètres de pool communs aux sources XA ou non-XA » et Tableau 6.7, « Paramètres du pool XA ».
recouvrement
Contient des éléments dépendants en tant que paramètres de recouvrement. Voir Tableau 6.12, « Paramètres de recouvrement ».

Tableau 6.6. Les paramètres de pool communs aux sources XA ou non-XA

Paramètre Description
min-pool-size Le nombre minimum de connexions contenues par un pool.
max-pool-size Le nombre maximum de connexions qu'un pool peut contenir
Pré-remplissage Indique si l'on doit essayer de pré-remplir un pool de connexion. Un élément vide indique une valeur true. La valeur par défaut est false.
use-strict-min Indique si la taille du pool est stricte. false par défaut.
flush-strategy
Indique si le pool est vidé en cas d'erreur. Les valeurs acceptées sont :
  • FailingConnectionOnly
  • IdleConnections
  • EntirePool
La valeur par défaut est FailingConnectionOnly.
allow-multiple-users Indique si plusieurs utilisateurs pourront avoir accès à la source de données par la méthode getConnection(user, password), et si les types de pools internes ont une influence sur ce comportement.

Tableau 6.7. Paramètres du pool XA

Paramètre Description
is-same-rm-override Indique si la classe javax.transaction.xa.XAResource.isSameRM(XAResource) retourne true ou false.
entrelacement Indique si on doit activer l'entrelacement pour les fabriques de connexion XA.
no-tx-separate-pools
Indique si on doit créer des sous-répertoires distincts pour chaque contexte. Cela est nécessaire pour les sources de données Oracle, qui ne permettent pas aux connexions XA d'être utilisées à la fois à l'intérieur et à l'extérieur d'une transaction de JTA
Utiliser cette option entraînera la multiplication par deux de la taille du pool max-pool-size, car en fait, deux pools seront créés.
pad-xid Indique si on doit remplir le Xid.
wrap-xa-resource
Indique si on doit inclure XAResource dans une instance org.jboss.tm.XAResourceWrapper.

Tableau 6.8. Paramètres de sécurité

Paramètre Description
user-name Le nom d'utilisation pour créer une nouvelle connexion.
password Le mot de passe à utiliser pour créer une nouvelle connexion
security-domain Contient le nom d'un gestionnaire de sécurité JAAS, qui gère l'authentification. Ce nom correspond à l'attribut application-policy/name de la configuration de connexion JAAS.
reauth-plugin Définit un plugin d'authentification à nouveau pour la réauthentification de connexions physiques.

Tableau 6.9. Paramètres de validation

Paramètre Description
valid-connection-checker
Une mise en œuvre d'interface org.jboss.jca.adaptors.jdbc.ValidConnectionChecker qui fournit une méthode SQLException.isValidConnection(Connection e) pour valider une connexion. Une exception signifie que la connexion est détruite. Cela remplace le paramètre check-valid-connection-sql s'il est présent.
check-valid-connection-sql Un énoncé SQL pour vérifier la validité d'un pool de connexion. Peut être appelé quand une connexion gérée est tirée d'un pool.
validate-on-match
Indique si la validation de niveau de connexion est exécutée lorsqu'une fabrique de connexions essaie de correspondre à une connexion gérée pour un ensemble donné.
Indiquer "true" pour validate-on-match n'est pas normalement fait en conjonction avec "true" pour background-validation. Validate-on-match est utile quand un client doit avoir une connexion vallidée avant utilisation. Ce paramètre est à false par défaut.
background-validation
Indique que les connexions sont validées sur un thread d'arrière-plan. La validation de l'arrière-plan (Background validation) est une optimisation de performance lorsque non utilisé avec validate-on-match. Si Validate-on-match est sur true, l'utilisation de background-validation pourrait entraîner des contrôles redondants. La validation de l'arrière-plan pourrait provoquer une mauvaise connexion (une connexion qui irait mal entre le moment de l'analyse de validation et avant d'être donnée au client), l'application cliente doit par conséquent tenir compte de cette possibilité.
background-validation-millis La durée, en millisecondes, pendant laquelle la validation d'arrière-plan exécute.
use-fast-fail
Si défini sur true, échoue une allocation de connexion lors de la première tentative, si la connexion est non valide. La valeur par défaut est false.
stale-connection-checker
Une instance de org.jboss.jca.adapters.jdbc.StaleConnectionChecker qui produit une méthode booléenne isStaleConnection(SQLException e). Si cette méthode renvoie un true, l'exception sera contenue dans org.jboss.jca.adapters.jdbc.StaleConnectionException, qui correspond à une sous-classe de SQLException.
exception-sorter
Une instance de org.jboss.jca.adapters.jdbc.ExceptionSorter qui fournit une méthode booléenne isExceptionFatal(SQLException e). Cette méthode validera si une exception est envoyée à toutes les instances d'un javax.resource.spi.ConnectionEventListener en tant que message connectionErrorOccurred.

Tableau 6.10. Paramètres de timeout

Paramètre Description
use-try-lock Utiliser tryLock() au lieu de lock(). Vous essayerez ainsi d'obtenir un verrou pour le nombre de secondes configurées, avant le timeout, au lieu d'échouer immédiatement quand le verrou n'est pas disponible. La valeur par défaut est de 60 secondes. Par exemple, pour définir un timeout de 5 minutes, définir <use-try-lock>300</use-try-lock>.
blocking-timeout-millis La durée maximale, en millisecondes, de blocage lorsque vous attendez une connexion. Après que ce délai soit dépassé, une exception sera levée. Cela bloque uniquement pendant que vous attendez un permis de connexion et ne lève pas d'exception si la création d'une nouvelle connexion prend beaucoup de temps. Par défaut, 30000, qui correspond à 30 secondes.
idle-timeout-minutes
La durée maximale, en minutes, avant qu'une connexion inactive soit fermée. La durée maximale réelle dépend de la durée d'analyse de l'idleRemover, qui correspond à la moitié du plus petit idle-timeout-minutes de n'importe quel pool.
set-tx-query-timeout
Indique si on doit définir le timeout d'interrogation par rapport au temps qui reste avant le timeout de transaction. Si aucune transaction n'existe, on utilisera le timeout de recherche qui a été configuré. La valeur par défaut est false.
query-timeout Timeout pour les recherches, en secondes. La valeur par défaut est « no timeout ».
allocation-retry Le nombre de tentatives de connexions avant d'envoyer une connexion. La valeur par défaut est 0, pour qu'une exception puisse être envoyée à la première défaillance.
allocation-retry-wait-millis
Le temps, en millisecondes, qu'il faut attendre avant de retenter d'allouer une connexion. La valeur par défaut est 5 000, soit 5 secondes.
xa-resource-timeout
Si la valeur est non nulle, elle passe à la méthode XAResource.setTransactionTimeout.

Tableau 6.11. Paramètres d'instruction

Paramètre Description
track-statements
Indique si l'on doit vérifier les instructions non fermées lorsqu'une connexion est renvoyée à un pool ou qu'une instruction est retournée dans le cache d'instruction préparée. Si false, les instructions ne seront pas suivies.

Valeurs valides

  • true : les instructions et les ensembles de résultats sont suivis, et un avertissement sera émis s'ils ne sont pas fermés.
  • false : ni les instructions, ni les ensembles de résultats ne seront suivis.
  • nowarn : les instructions sont suivies, mais il n'y a aucun avertissement. Valeur par défaut.
prepared-statement-cache-size Le nombre d'instructions préparées par connexion, dans le cache LRU (le moins souvent utilisé récemment).
share-prepared-statements
Indique si le fait de demander la même instruction deux fois sans la fermer utilise la même instruction préparée sous-jacente. La valeur par défaut est false.

Tableau 6.12. Paramètres de recouvrement

Paramètre Description
recover-credential Une paire nom d'utilisateur/mot de passe ou domaine de sécurité pour le recouvrement.
recover-plugin
Une mise en œuvre de la classe org.jboss.jca.core.spi.recoveryRecoveryPlugin à utiliser pour le recouvrement.

6.7.2. Les URL de connexion de sources de données

Tableau 6.13. Les URL de connexion de sources de données

Source de données URL de connexion
PostgreSQL jdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME
MySQL jdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME
Oracle jdbc:oracle:thin:@ORACLE_HOST:PORT:ORACLE_SID
IBM DB2 jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME
Microsoft SQLServer jdbc:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME

Note

Le modèle jdbc:microsoft:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME ne fonctionne pas avec la nouvelle base de données.

6.7.3. Extensions de sources de données

Les déploiements de sources de données peuvent utiliser plusieurs extensions de l'adaptateur de ressources JDBC pour améliorer la validation de la connexion, et vérifier si l'exception doit rétablir la connexion. Ces extensions sont les suivantes :

Tableau 6.14. Extensions de sources de données

Extension de sources de données Paramètre de configuration Description
org.jboss.jca.adapters.jdbc.spi.ExceptionSorter <exception-sorter> Vérifie si SQLException est fatale pour la connexion sur laquelle l'exception a été lancée
org.jboss.jca.adapters.jdbc.spi.StaleConnection <stale-connection-checker> Wraps stale SQLExceptions in a org.jboss.jca.adapters.jdbc.StaleConnectionException
org.jboss.jca.adapters.jdbc.spi.ValidConnection <valid-connection-checker> Vérifie si une connexion est valide pour être utilisée par l'application
JBoss EAP 6 comprend également des implémentations de ces extensions pour plusieurs bases de données prises en charge.

Implémentations des extensions

Générique
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
PostgreSQL
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
MySQL
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
IBM DB2
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
Sybase
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
Microsoft SQLServer
  • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
Oracle
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker

6.7.4. Voir les statistiques de sources de données

Vous pourrez voir des statistiques de sources de données définies dans jdbc et pool qui utilisent des versions modifiées des commandes ci-dessous :

Exemple 6.13. Obtention des statistiques de sources de données

/subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true)
ou
/subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)

Note

Veillez à spécifier l'argument include-runtime=true car tous les statistiques sont en runtime uniquement et la valeur par défaut est false.

6.7.5. Statistiques de bases de données

Statistiques principaux

Le tableau suivant montre une liste des statistiques principaux de sources de données pris en charge :

Tableau 6.15. Statistiques principaux

Nom Description
ActiveCount
Le nombre de connexions actives. Chacune de ces connexions est soit utilisée par une application, ou disponible via pool
AvailableCount
Le nombre de connexions disponibles dans le pool
AverageBlockingTime
Le durée moyenne passée à bloquer l'obtention d'un verrou exclusif sur le pool. La valeur est en millisecondes.
AverageCreationTime
Le durée moyenne passée à créer une connexion. La valeur est en millisecondes.
CreatedCount
Le nombre de connexions créées.
DestroyedCount
Le nombre de connexions détruites.
InUseCount
Le nombre de connexions actuellement utilisées.
MaxCreationTime
La durée maximum pour créer une connexion. La valeur est en millisecondes.
MaxUsedCount
Le nombre maximum de connexions utilisées
MaxWaitCount
Le nombre maximum de requêtes attendant une connexion en même temps.
MaxWaitTime
Le durée maximum à attendre un verrou exclusif sur le pool.
TimedOut
Le nombre de connexions expirées
TotalBlockingTime
Le durée à attendre un verrou exclusif sur le pool. La valeur est en millisecondes.
TotalCreationTime
La durée passée à créer des connexions. La valeur est en millisecondes.
WaitCount
Le nombre de requêtes en attente de connexion.
Statistiques JDBC

Le tableau suivant montre une liste des statistiques JDBC de sources de données pris en charge :

Tableau 6.16. Statistiques JDBC

Nom Description
PreparedStatementCacheAccessCount
Le nombre de fois qu'un cache d'énoncé a été accédé.
PreparedStatementCacheAddCount
Le nombre d'énoncés ajoutés au cache de l'énoncé.
PreparedStatementCacheCurrentSize
Le nombre d'énoncés préparés et que l'on peut appeler, actuellement mis en cache dans un cache d'énoncé.
PreparedStatementCacheDeleteCount
Le nombre d'énoncés rejetés du cache.
PreparedStatementCacheHitCount
Le nombre de fois que des énoncés de cache ont été utilisés.
PreparedStatementCacheMissCount
Le nombre de fois qu'une requête d'énoncé a pu être réglée par un énoncé d'un cache.
Vous pouvez activer les statistiques Core et JDBC en utilisant des versions appropriément modifiées des commandes suivantes :
  • /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)
    

6.8. Exemples de sources de données

6.8.1. L'exemple de source de données PostgreSQL

L'exemple ci-dessous est une configuration de source de données PostgreSQL. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.14. Configuration des sources de données PostSQL

<datasources>
  <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS">
    <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url>
    <driver>postgresql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données PostgreSQL ci-dessus.

Exemple 6.15. module.xml

<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.2. Exemple de source de données PostgreSQL XA

L'exemple ci-dessous est une configuration de source de données PostgreSQL XA. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.16. Source de données PostSQL XA

<datasources>
  <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS">
    <driver>postgresql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">postgresdb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker">
      </valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter">
      </exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données PostgreSQL XA ci-dessus.

Exemple 6.17. module.xml

<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.3. Exemple de source de données MySQL

L'exemple ci-dessous est une configuration de source de données MySQL. La source de données a été activée, un utilisateur a été ajouté, et des options de validation ont été définies.

Exemple 6.18. Configuration de source de données MySQL

<datasources>
  <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS">
    <connection-url>jdbc:mysql://mysql-localhost:3306/jbossdb</connection-url>
    <driver>mysql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données MySQL ci-dessus.

Exemple 6.19. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.4. Exemple de source de données MySQL XA

L'exemple ci-dessous est une configuration de source de données MySQL XA. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.20. Source de données MySQL XA

<datasources>
  <xa-datasource jndi-name="java:jboss/MysqlXADS" pool-name="MysqlXADS">
  <driver>mysql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mysqldb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données MySQL XA ci-dessus.

Exemple 6.21. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.5. L'exemple de source de données Oracle

Note

Avant la version 10.2 de la source de données Oracle, le paramètre <no-tx-separate-pools/> était requis, car le mélange de connexions transactionnelles et non-transactionnelles aurait créé une erreur. Ce paramètre n'est plus requis pour certaines applications.
L'exemple ci-dessous est une configuration de source de données Oracle. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.22. Configuration de source de données Oracle

<datasources>
  <datasource jndi-name="java:/OracleDS" pool-name="OracleDS">
    <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url>
    <driver>oracle</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données Oracle ci-dessus.

Exemple 6.23. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.6. Exemple de source de données d'Oracle XA

Note

Avant la version 10.2 de la source de données Oracle, le paramètre <no-tx-separate-pools/> était requis, car le mélange de connexions transactionnelles et non-transactionnelles aurait créé une erreur. Ce paramètre n'est plus requis pour certaines applications.

Important

Les paramètres de configuration doivent être appliqués pour un utilisateur qui accède à une source de données Oracle XA pour que le recouvrement XA fonctionne correctement. La valeur user est une valeur définie par l'utilisateur pour pouvoir se connecter à partir de JBoss à Oracle :
  • GRANT SELECT ON sys.dba_pending_transactions TO user;
  • GRANT SELECT ON sys.pending_trans$ TO user;
  • GRANT SELECT ON sys.dba_2pc_pending TO user;
  • GRANT EXECUTE ON sys.dbms_xa TO user; (If using Oracle 10g R2 (patched) or Oracle 11g)
    OU
    GRANT EXECUTE ON sys.dbms_system TO user; (If using an unpatched Oracle version prior to 11g)
L'exemple ci-dessous est une configuration de source de données Oracle XA. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.24. Source de données Oracle XA

<datasources>
  <xa-datasource jndi-name="java:/XAOracleDS" pool-name="XAOracleDS">
    <driver>oracle</driver>
    <xa-datasource-property name="URL">jdbc:oracle:oci8:@tc</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
      <no-tx-separate-pools />
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données Oracle XA ci-dessus.

Exemple 6.25. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.7. Exemple de source de données Microsoft SQLServer

L'exemple ci-dessous est une configuration de source de données Microsoft SQLServer. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.26. Configuration de source de données de SQLserver

<datasources>
  <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url>
    <driver>sqlserver</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données Microsoft SQLServer ci-dessus.

Exemple 6.27. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.8. Exemple de source de données Microsoft SQLServer XA

L'exemple ci-dessous est une configuration de source de données Microsoft SQLServer XA. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.28. Source de données SQLserver XA

<datasources>
  <xa-datasource jndi-name="java:/MSSQLXADS" pool-name="MSSQLXADS">
    <driver>sqlserver</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mssqldb</xa-datasource-property>
    <xa-datasource-property name="SelectMethod">cursor</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données Microsoft SQLServer XA ci-dessus.

Exemple 6.29. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.9. Exemple de source de données IBM DB2

L'exemple ci-dessous est une configuration de source de données IBM DB2. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.30. Configuration de source de données IBM DB2

<datasources>
  <datasource jndi-name="java:/DB2DS" pool-name="DB2DS">
    <connection-url>jdbc:db2:ibmdb2db</connection-url>
    <driver>ibmdb2</driver>
    <pool>
      <min-pool-size>0</min-pool-size>
      <max-pool-size>50</max-pool-size>
    </pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jdbc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données IBM DB2 ci-dessus.

Exemple 6.31. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.10. Exemple de source de données IBM DB2 XA

L'exemple ci-dessous est une configuration de source de données IBM DB2 XA. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.32. Configuration de source de données IBM DB2 XA

<datasources>
  <xa-datasource jndi-name="java:/DB2XADS" pool-name="DB2XADS">
    <driver>ibmdb2</driver>
    <xa-datasource-property name="DatabaseName">ibmdb2db</xa-datasource-property>
    <xa-datasource-property name="ServerName">hostname</xa-datasource-property>
    <xa-datasource-property name="PortNumber">port</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
    <recovery>
      <recover-plugin class-name="org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin">
        <config-property name="EnableIsValid">false</config-property>
        <config-property name="IsValidOverride">false</config-property>
        <config-property name="EnableClose">false</config-property>
      </recover-plugin>
    </recovery>
  </xa-datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données IBM DB2 XA ci-dessus.

Exemple 6.33. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
    <resource-root path="db2jcc_license_cisuz.jar"/>
    <resource-root path="db2jcc_license_cu.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.11. L'exemple de source de données Sybase

L'exemple ci-dessous est une configuration de source de données Sybase. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.34. Configuration de la base de données Sybase

<datasources>
  <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB" enabled="true">
    <connection-url>jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6</connection-url>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc4.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données Sybase ci-dessus.

Exemple 6.35. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.8.12. L'exemple de source de données Sybase XA

L'exemple ci-dessous est une configuration de source de données Sybase XA. La source de données a été activée, un utilisateur a été ajouté et les options de validation ont été définies.

Exemple 6.36. Configuration de la base de données Sybase XA

<datasources>
  <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS" enabled="true">
    <xa-datasource-property name="NetworkProtocol">Tds</xa-datasource-property>
    <xa-datasource-property name="ServerName">myserver</xa-datasource-property>
    <xa-datasource-property name="PortNumber">4100</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mydatabase</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc4.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
L'exemple ci-dessous est un fichier module.xml pour la source de données Sybase XA ci-dessus.

Exemple 6.37. module.xml

<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

Chapitre 7. Configuration des modules

7.1. Introduction

7.1.1. Modules

Un module est un regroupement logique des classes utilisées pour le chargement de classes et pour la gestion de dépendances. JBoss EAP 6 identifie deux types de modules, parfois appelés modules statiques et dynamiques. Cependant, la seule différence entre les deux est la façon dont ils sont emballés.
Modules statiques
Les modules statiques sont prédéfinis dans le répertoire EAP_HOME/modules/ du serveur d'applications. Chaque sous-répertoire représente un module et contient un sous-fichier de configuration main/ qui contient un fichier de configuration (module.xml) et tous les fichiers JAR requis. Le nom du module est défini dans le fichier module.xml. Toutes les API fournies par le serveur de l'application sont des modules statiques, y compris les API Java EE, et les autres API comme JBoss Logging.

Exemple 7.1. Exemple de fichier module.xml

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.1.15.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Le nom du module, com.mysql, doit correspondre à la structure du répertoire du module, à l'excepté du nom de sous-répertoire main/.
Les modules fournis dans les distributions JBoss EAP se trouvent dans un répertoire system se trouvant lui-même dans le répertoire JBOSS_HOME/modules. Cela les rend séparés de tout module fourni par une tierce partie.
Tout produit mis en couche de Red Hat, se superposant sur JBoss EAP 6.1 ou version supérieure installera également leurs modules dans le répertoire system.
La création de modules statiques personnalisés peut être utile si plusieurs applications sont déployées sur un même serveur utilisant les mêmes bibliothèques de tierce partie. Au lieu d'un regroupement de ces bibliothèques pour chaque application, un module contenant ces bibliothèques peut être créé et installé par l'administrateur JBoss. Les applications peuvent ensuite déclarer une dépendance explicite sur les modules statiques personnalisés.
Les utilisateurs doivent s'assurer que les modules personnalisés soient installés dans le répertoire JBOSS_HOME/modules, en utilisant un répertoire par couche de modules. Cela garantit que les versions personnalisées de modules qui existent déjà dans le répertoire system soient bien chargées à la place des versions fournies. Ainsi, les modules utilisateur auront la priorité sur les modules fournis par le système.
Si vous utilisez la variable d'environnement JBOSS_MODULE_PATH pour changer les emplacements où JBoss EAP cherche les modules, le produit ira chercher dans une structure de sous-répertoire system dans un des emplacements spécifiés. Une structure de sous-répertoire system doit exister quelquepart dans les emplacements spécifiés dans JBOSS_MODULEPATH.
Modules dynamiques
Les modules dynamiques sont créés et chargés par le serveur d'applications pour chaque déploiement JAR ou WAR (ou sous-déploiement d'un EAR). Le nom d'un module dynamique est dérivé du nom de l'archive déployée. Comme les déploiements sont chargés sous forme de modules, ils peuvent configurer des dépendances et peuvent être utilisés comme dépendances par d'autres déploiements.
Les modules ne sont chargés qu'en fonction des besoins. Cela a généralement lieu quand une application est déployée avec des dépendances implicites ou explicites.

7.1.2. Modules globaux

Un module global est un module que JBoss EAP 6 fournit comme dépendance pour chaque application. Chaque module peut être composé en l'ajoutant à la liste du serveur d'applications des modules globaux. Il n'est nul besoin de faire des changements au module.

7.1.3. Les dépendances de modules

Une dépendance de module est une déclaration qui indique qu'un module a besoin des classes d'un autre module pour pouvoir fonctionner. Les modules peuvent déclarer leurs dépendances sur un certain nombre d'autres modules. Quand le serveur d'applications charge un module, le chargeur de classes de module traite les dépendances de ce module et ajoute les classes de chaque dépendance à son chemin de classe. Si une dépendance particulière est introuvable, le module ne pourra pas charger.
Les applications déployées (JAR et WAR) sont chargées sous forme de modules dynamiques et utilisent des dépendances pour accéder aux API fournies par JBoss EAP 6.
Il y a deux types de dépendances : explicite et implicite.
Les dépendances explicites sont déclarées dans la configuration par le développeur. Les modules statiques peuvent déclarer des dépendances dans le fichier modules.xml. Les modules dynamiques peuvent avoir des dépendances déclarées dans les descripteurs de déploiement MANIFEST.MF ou jboss-deployment-structure.xml.
Les dépendances explicites peuvent être spécifiées comme étant optionnelles. Une erreur de chargement de dépendance optionnelle n'entraînera pas l'annulation d'un chargement de module. Cependant, si la dépendance est rendue disponible par la suite, elle ne sera PAS ajoutée au chemin de classe du module. Les dépendances doivent être rendues disponibles quand le module est chargé.
Des dépendances implicites sont ajoutées automatiquement par le serveur d'applications quand certaines conditions ou meta-données se trouvent dans un déploiement. Les API Java EE 6 fournies avec JBoss EAP 6 sont des exemples de modules ajoutés par détection de dépendances implicites dans les déploiements.
Les déploiements peuvent également être configurés de façon à exclure des dépendances implicites particulières. Il vous faut pour cela le fichier de déploiement jboss-deployment-structure.xml. C'est normalement le cas quand une application empaquète une version spécifique de bibliothèque que le serveur d'applications tentera d'ajouter comme dépendance implicite.
Un chemin de classe de module ne contient que ses propres classes et celles de ses dépendances immédiates. Un module n'est pas en mesure d'accéder aux classes des dépendances. Cependant, un module peut indiquer quand une dépendance explicite est exportée. Une dépendance exportée est fournie à tout module qui dépend du module qui l'exporte.

Exemple 7.2. Les dépendances de module

Le Module A dépend du Module B et le Module B dépend su Module C. Le Module A peut accéder aux classes du Module B, et le Module B peut accéder aux classes du Module C. Le Module C ne peut pas accéder aux classes du Module C à moins que :
  • Le Module A déclare une dépendance explicite sur le Module C, ou bien
  • Le Module B exporte ses dépendances sur le Module C.

7.1.4. Isolement du chargeur de classes d'un sous-déploiement

Chaque sous-déploiement d'EAR (Archive Enterprise) est un module dynamique possédant son propre chargeur de classe. Par défaut, un sous-déploiement peut accéder aux ressources d'autres sous-déploiements.
Si un sous-déploiement ne doit pas accéder aux ressources d'autres sous-déploiements (une isolation de sous-déploiement est alors requise), alors cela pourra être activé.

7.2. Désactiver l'isolement de module de sous-déploiement pour tous les déploiements

Cette tâche montre aux administrateurs du serveur comment désactiver l'isolement du module de sous-déploiement dans le serveur d'applications. Cela affecte tous les déploiements.

Avertissement

Cette tâche requiert que vous éditiez les fichiers de configuration XML du serveur. Le serveur doit être arrêté avant cela. Ce n'est que temporaire car les outils administratifs de version finale supporteront ce type de configuration.
  1. Arrêter le serveur

    Mettre en halte le serveur JBoss EAP 6.
  2. Ouvrir le fichier de configuration du serveur

    Ouvrir le fichier de configuration du serveur dans un éditeur de texte
    Ce fichier sera différent pour un domaine géré ou un serveur autonome. De plus, des emplacements et des noms de fichiers non-défauts peuvent être utilisés. Les fichiers de configuration par défaut sont domain/configuration/domain.xml et standalone/configuration/standalone.xml pour les domaines gérés et les serveurs autonomes respectivement.
  3. Chercher la configuration de sous-système EE

    Chercher la configuration de sous-système EE dans le fichier de configuration. L'élément <profile> du fichier de configuration contient plusieurs éléments du sous-système. L'élément du sous-système EE a comme espace-nom urn:jboss:domain:ee:1.2.
    <profile>
    
       ...
    
       <subsystem xmlns="urn:jboss:domain:ee:1.2" />
    
       ...
    La configuration par défaut a une balise en fermeture automatique unique mais une configuration personnalisée peut avoir des balises d'ouverture ou de fermeture distinctes (éventuellement avec d'autres éléments à l'intérieur) comme ceci :
    <subsystem xmlns="urn:jboss:domain:ee:1.2" ></subsystem>
  4. Remplacer les balises en fermeture automatique si nécessaire

    Si l'élément de sous-système EE est une balise en fermeture automatique unique, remplacez-la par les balises d'ouverture ou de fermeture qui conviennent ainsi :
    <subsystem xmlns="urn:jboss:domain:ee:1.2" ></subsystem>
  5. Ajouter l'élément ear-deployments-isolated

    Ajouter l'élément ear-subdeployments-isolated comme dépendant de l'élément du sous-système EE et ajouter le contenu de false comme suit :
    <subsystem xmlns="urn:jboss:domain:ee:1.2" ><ear-subdeployments-isolated>false</ear-subdeployments-isolated></subsystem>
  6. Démarrer le serveur

    Lancer à nouveau le serveur JBoss EAP 6 pour qu'il commence à exécuter avec la nouvelle configuration.
Résultat :

Le serveur va maintenant exécuter avec l'isolement de module de sous-déploiement désactivé pour tous les déploiements.

7.3. Ajouter un module à tous les déploiements

Cette tâche montre comment les administrateurs JBoss peuvent définir une liste de modules globaux.

Conditions préalables

  1. Vous devez connaître le nom des modules qui ont été ajoutés comme modules globaux. Voir Section 7.6.1, « Les modules inclus » pour obtenir la liste des modules statiques inclus dans JBoss EAP 6. Si le module est dans un autre déploiement, voir Section 7.6.2, « Nommage de modules dynamiques » pour déterminer le nom du module.

Procédure 7.1. Ajouter un module à la liste des modules globaux

  1. Connectez-vous à la console de gestion. Section 3.4.2, « Se connecter à la console de gestion »
  2. Naviguer dans le panneau EE Subsystem.
    1. Sélectionner Configuration qui se trouve en haut de la console.
    2. Mode Domaine uniquement

      1. Sélectionner le profil qui convient à partir du menu déroulant en haut à gauche.
    3. Étendre le menu Subsystems qui se trouve à gauche de la console.
    4. Sélectionner ContainerEE à partir du menu à gauche de la console.
  3. Cliquer sur Add dans la section Subsystem Defaults. La boîte de dialogue Create Module apparaîtra.
  4. Saisir alors le nom du module et le slot de module, en option.
  5. Cliquer sur Enregistrer pour ajouter le nouveau module global, ou bien cliquer sur Annuler pour annuler.
    • Si vous cliquer sur Enregistrer, la boîte de dialogue va se fermer et le module spécifié sera ajouté à la liste des modules globaux.
    • Si vous cliquer sur le bouton Cancel, la boîte de dialogue se fermera et il n'y aura aucun changement.
Résultat

Les modules ajoutés à la liste des modules globaux seront ajoutés en tant que dépendances à chaque déploiement.

7.4. Créer un module personnalisé

La procédure suivante décrit comment créer un module personnalisé pour rendre les fichiers de propriétés et les autres ressources disponibles à toutes les applications qui exécutent sur le serveur JBoss EAP.

Procédure 7.2. Créer un module personnalisé

  1. Créer et compléter la structure de répertoire module/.
    1. Créer une structure de répertoire sous le répertoire EAP_HOME/module qui contienne les fichiers et les JAR.
      $ cd EAP_HOME/modules/ 
      $ mkdir -p myorg-conf/main/properties
    2. Déplacer les fichiers de propriétés dans le répertoire EAP_HOME/modules/myorg-conf/main/properties/ que vous avez créé à l'étape précédente.
    3. Créer un fichier module.xml dans le répertoire EAP_HOME/modules/myorg-conf/main/ qui contienne l'XML suivant :
      <module xmlns="urn:jboss:module:1.1" name="myorg-conf">
          <resources>
              <resource-root path="properties"/>
          </resources>
      </module>
  2. Modifier le sous-système ee du fichier de configuration du serveur. Vous pouvez utiliser l'interface en ligne de commande JBoss CLI, ou bien, vous pouvez éditer le fichier manuellement.
    • Suivez ces étapes pour modifier le fichier de configuration du serveur par l'interface en ligne de commande JBoss CLI.
      1. Démarrez le serveur et connectez-vous à l'interface en ligne de commande.
        • Dans Linux, saisir ce qui suit au niveau de la ligne de commande :
           EAP_HOME/bin/jboss-cli.sh --connect
        • Dans Windows, saisir ce qui suit au niveau de la ligne de commande :
          C:\>EAP_HOME\bin\jboss-cli.bat --connect
        Vous devriez voir apparaître le résultat suivant :
        Connected to standalone controller at localhost:9999
      2. Pour créer l'élément <global-modules> myorg-conf dans le sous-système ee, saisir ce qui suit dans la ligne de commande :
        /subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])
        Vous devriez voir apparaître le résultat suivant :
        {"outcome" => "success"}
    • Suivre ces étapes si vous préférez éditer manuellement le fichier de configuration du serveur.
      1. Arrêter le serveur et ouvrir le fichier de configuration du serveur dans un éditeur de texte. Si vous exécutez sur un serveur autonome, il s'agira du fichier EAP_HOME/standalone/configuration/standalone.xml ou du fichier EAP_HOME/domain/configuration/domain.xml si vous exécutez sur un domaine géré.
      2. Chercher le sous-système ee et ajouter le module global de myorg-conf. Ce qui suit est un exemple d'élément du sous-système ee modifié pour inclure l'élément myorg-conf :

        Exemple 7.3. élément myorg-conf

        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>
  3. Si vous copiez un fichier nommé my.properties dans l'emplacement de module qui convient, vous pourrez alors charger les fichiers de propriétés en utilisant un code qui ressemble à ceci :

    Exemple 7.4. Télécharger le fichier de propriétés

    Thread.currentThread().getContextClassLoader().getResource("my.properties");

7.5. Définir un répertoire de modules JBoss externe

Résumé

Par défaut, JBoss EAP recherche les modules dans le répertoire EAP_HOME/modules/. Vous pouvez demander à JBoss EAP de regarder dans un ou plusieurs modules répertoires externes en définissant une variable d'environnement JBOSS_MODULEPATH ou en définissant la variable dans le fichier de configuration de démarrage. Cette section décrit les deux méthodes.

Procédure 7.3. Définissez la variable d'environnement JBOSS_MODULEPATH

  • Pour sépécifier un ou plusieurs répertoires de module externes, définir la variable d'environnement JBOSS_MODULEPATH.
    Dans Linux, utiliser les deux-points pour délimiter une liste de répertoires. Par exemple :

    Exemple 7.5. variable d'environnement JBOSS_MODULEPATH

    export JBOSS_MODULEPATH=EAP_HOME/modules/:/home/username/external/modules/directory/
    Dans Linux, utiliser un point-virgule pour délimiter une liste de répertoires. Par exemple :

    Exemple 7.6. variable d'environnement JBOSS_MODULEPATH

    SET JBOSS_MODULEPATH=EAP_HOME\modules\;D:\JBoss-Modules\

Procédure 7.4. Définissez la variable JBOSS_MODULEPATH dans le fichier de configuration de démarrage.

  • Si vous choisissez de ne pas définir une variable d'environnement globale, vous pouvez définir la variable JBOSS_MODULEPATH dans le fichier de configuration de démarrage de JBoss EAP. Si vous exécutez dans un serveur autonome, il s'agira du fichier EAP_HOME/bin/standalone.conf. Si le serveur exécute dans dans un domaine géré, il s'agira du fichier EAP_HOME/bin/domain.conf.
    Vous trouverez ci-dessous un exemple de la commande qui définit la variable JBOSS_MODULEPATH dans le fichier standalone.conf :

    Exemple 7.7. entrée standalone.conf

    JBOSS_MODULEPATH="EAP_HOME/modules/:/home/username/external/modules/directory/"

7.6. Référence

7.6.1. Les modules inclus

Un tableau énumérant les modules JBoss EAP 6 inclus et indiquant s'ils sont pris en charge se trouve dans le portail clients à https://access.redhat.com/articles/1122333.

7.6.2. Nommage de modules dynamiques

Tous les déploiements sont chargés en tant que modules par JBoss EAP 6 et sont nommés en fonction des conventions suivantes :
  1. Les déploiements des fichiers WAR et JAR sont nommés selon le format suivant :
     deployment.DEPLOYMENT_NAME 
    Par exemple, inventory.war et store.jar auront les mêmes noms de module que deployment.inventory.war et deployment.store.jar respectivement.
  2. Les sous-déploiements des archives Enterprise sont nommés selon le format suivant :
     deployment.EAR_NAME.SUBDEPLOYMENT_NAME 
    Ainsi, le sous-déploiement reports.war, qui se trouve dans l'archive Enterprise accounts.ear, aura le nom de module du deployment.accounts.ear.reports.war.

Chapitre 8. Jsvc

8.1. Introduction

8.1.1. Jsvc

Jsvc est un ensemble de bibliothèques et d'applications qui permettent aux applications Java exécutées sur UNIX ou sur des plateforme style UNIX en arrière-plan. Jsvc permet à une application d'effectuer des opérations en tant qu'utilisateur privilégié, puis de changer identité en tant qu'utilisateur non privilégié.
Jsvc utilise trois processus : un processus de lanceur, un processus de contrôleur et un processus contrôlé. Le processus contrôlé est également le principal thread Java. Si la JVM plante le processus du contrôleur, il redémarrera dans les 60 secondes. Jsvc est un processus de démon et pour JBoss EAP 6, il doit être lancé par un utilisateur privilégié.

Note

Jsvc est peut être utilisé sur Red Hat Enterprise Linux, Solaris et HP-UX. Pour une fonctionnalité similaire dans Microsoft Windows, voir prunsrv.exe dans Native Utilities for Windows Server disponibles depuis le portail clients de Red Hat.

8.1.2. Démarrer et arrêter JBoss EAP par Jsvc

Les instruction de démarrage et d'arrêt de JBoss EAP par Jsvc varient, selon le mode opérationnel : autonome ou domaine. Sachez que si JBoss EAP est exécuté en mode de domaine, Jsvc ne gérera que le processus de contrôleur de domaine. Quelle que soit la commande que vous utilisez pour démarrer JBoss EAP par Jsvc, elle doit être gérée par un utilisateur privilégié.

Conditions préalables

  • Si JBoss EAP était installé par la méthode Zip :
    • Installez le package Native Utilities de votre système d'exploitation, disponible à partir du portail clients de Red Hat Install Native Components and Native Utilities (Zip, Installer) dans Installation Guide.
    • Créez le compte d'utilisateur sous lequel s'exécute l'instance de JBoss EAP 6. Le compte utilisé pour démarrer et arrêter le serveur doit posséder un accès lecture et écriture dans le répertoire où JBoss EAP a été installé.
  • Si JBoss EAP était installé par la méthode RPM, installez le package apache-commons-daemon-jsvc-eap6. Voir Install Native Components and Native Utilities (RPM Installation) dans le guide Installation Guide.
Les commandes suivantes sont utilisées pour démarrer et arrêter JBoss EAP en mode autonome ou domaine. Notez que les emplacements de fichiers sont différents selon la méthode utilisée pour installer Jsvc dans JBoss EAP 6. Utilisez les tableaux ci-dessous pour déterminer les fichiers à utiliser pour résoudre les variables des commandes.
Mode autonome

Les instructions suivantes sont utilisées pour démarrer ou pour stopper JBoss EAP en mode autonome.

Tableau 8.1. Emplacements des fichiers Jsvc pour les installations zip - Mode autonome

Référence Fichier en Instructions Emplacement fichier
EAP-HOME
${eap-installation-location}/jboss-eap-${version}
JSVC-BIN
EAP_HOME/modules/system/layers/base/native/sbin/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
EAP_HOME/standalone/configuration
LOG-DIR
EAP_HOME/standalone/log

Tableau 8.2. Emplacements des fichiers Jsvc pour les installations RPM - Mode autonome

Référence Fichier en Instructions Emplacement fichier
EAP-HOME
/usr/share/jbossas
JSVC-BIN
/usr/bin/jsvc-eap6/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
/etc/jbossas/standalone
LOG-DIR
/var/log/jbossas/standalone

Démarrez JBoss en serveur autonome

  • JSVC_BIN \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -D[Standalone] -XX:+UseCompressedOops -Xms1303m \
     -Xmx1303m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true 
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true \
     -Dorg.jboss.boot.log.file=LOG_DIR/server.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp EAP_HOME/jboss-modules.jar:JSVC_JAR \
     -Djboss.home.dir=EAP_HOME \
     -Djboss.server.base.dir=EAP_HOME/standalone   \
     @org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules \
     -jaxpmodule javax.xml.jaxp-provider \
     org.jboss.as.standalone

Stopper JBoss en serveur autonome

  • JSVC_BIN \
     -stop \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -D[Standalone] -XX:+UseCompressedOops -Xms1303m \
     -Xmx1303m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true \
     -Dorg.jboss.boot.log.file=LOG_DIR/server.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp EAP_HOME/jboss-modules.jar:JSVC_JAR \
     -Djboss.home.dir=EAP_HOME \
     -Djboss.server.base.dir=EAP_HOME/standalone   \
     @org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules \
     -jaxpmodule javax.xml.jaxp-provider \
     org.jboss.as.standalone
Mode Domaine

Les instructions suivantes sont utilisées pour démarrer ou pour stopper JBoss EAP en mode autonome. Notez qu'en mode de domaine, vous devrez remplacer la variable JAVA_HOME par le répertoire d'accueil de Java.

Tableau 8.3. Emplacements des fichiers Jsvc pour les installations zip - Mode de domaine

Référence Fichier en Instructions Emplacement fichier
EAP-HOME
${eap-installation-location}/jboss-eap-${version}
JSVC-BIN
EAP_HOME/modules/system/layers/base/native/sbin/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
EAP_HOME/domain/configuration
LOG-DIR
EAP_HOME/domain/log

Tableau 8.4. Emplacements des fichiers Jsvc pour les installations RPM - Mode de domaine

Référence Fichier en Instructions Emplacement fichier
EAP-HOME
/usr/share/jbossas
JSVC-BIN
/usr/bin/jsvc-eap6/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
/etc/jbossas/domain
LOG-DIR
/var/log/jbossas/domain

Démarrez JBoss EAP en mode de domaine

  • JSVC_BIN \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -nodetach -D"[Process Controller]" -server -Xms64m \
     -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true  \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true  \
     -Dorg.jboss.boot.log.file=LOG_DIR/process-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp "EAP_HOME/jboss-modules.jar:JSVC_JAR" \
     org.apache.commons.daemon.support.DaemonWrapper \
     -start org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules org.jboss.as.process-controller \
     -jboss-home EAP_HOME -jvm $JAVA_HOME/bin/java \
     -mp EAP_HOME/modules -- \
     -Dorg.jboss.boot.log.file=LOG_DIR/host-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -server -Xms64m -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true -- -default-jvm $JAVA_HOME/bin/java

Stopper JBoss EAP en mode de domaine

  • JSVC_BIN \
     -stop \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -nodetach -D"[Process Controller]" -server -Xms64m \
     -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true  \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true  \
     -Dorg.jboss.boot.log.file=LOG_DIR/process-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp "EAP_HOME/jboss-modules.jar:JSVC_JAR" \
     org.apache.commons.daemon.support.DaemonWrapper \
     -start org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules org.jboss.as.process-controller \
     -jboss-home EAP_HOME -jvm $JAVA_HOME/bin/java \
     -mp EAP_HOME/modules -- \
     -Dorg.jboss.boot.log.file=LOG_DIR/host-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -server -Xms64m -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true -- -default-jvm $JAVA_HOME/bin/java

Note

Si JBoss EAP 6 est arrêté de façon anormale, comme un crash de la JVM, Jsvc le démarrera à nouveau automatiquement. Si JBoss EAP 6 s'arrête normalement, Jsvc s'arrêtera également.

Chapitre 9. Valves globales

9.1. Valves

Une valve est une classe Java insérée dans le pipeline de traitement de demande d'une application. Elle est insérée dans le pipeline avant les filtres servlet. Les valves peuvent apporter des modifications à la demande avant de les passer ou d'effectuer tout autre traitement comme l'authentification ou annuler la demande.
Les valves peuvent être configurées au niveau du serveur ou au niveau de l'application. La seule différence est la façon dont elles sont configurées ou empaquetées.
  • Les valves globales sont configurées au niveau serveur et s'appliquent à toutes les applications déployées dans le serveur. Les instructions sur la façon de configurer les valves globales se trouvent dans le guide Administration and Configuration Guide de JBoss EAP.
  • Les valves configurées au niveau de l'application sont empaquetées dans le déploiement de l'application et n'affectent que l'application en question. Des instructions sur la façon de configurer des valves au niveau de l'application se trouvent dans le guide Development Guide de JBoss EAP.
Les versions 6.1.0 et supérieures prennent en charge les valves globales.

9.2. Valves globales

Une valve globale est une valve insérée dans le pipeline de traitement de requête de toutes les applications déployées. Une valve est rendue globale lorsqu'elle est mise en paquetage et qu'elle est installée comme module static dans JBoss EAP 6. Les valves globales sont configurées dans le sous-système web.
Seules les versions 6.1.0 et supérieures prennent en charge les valves globales.
Pour obtenir plus d'informations sur la façon de configurer Global Valves, voir Section 9.5, « Configuration d'une valve globale ».

9.3. Les valves d'authentification

Une valve d'authentification est une valve qui authentifie les informations d'identification d'une requête. Cette valve est une sous-classe de org.apache.catalina.authenticator.AuthenticatorBase et elle remplace la méthode authenticate(Request request, Response response, LoginConfig config).
Elle peut être utilisée pour implémenter des schémas d'authentification supplémentaires.

9.4. Installation d'une valve globale

Les valves globales doivent être empaquetées et installées sous forme de modules statics dans JBoss EAP 6. Cette tâche vous montre comment installer le module.

Conditions préalables :

  • La valve doit déjà avoir été créée et empaquetée dans un fichier JAR.
  • Un fichier module.xml doit déjà avoir été créé pour le module.
    Voir Section 7.1.1, « Modules » pour un exemple de fichier module.xml.

Procédure 9.1. Installer un module global

  1. Créer un répertoire d'installation de module

    Vous devrez créer un répertoire pour le module à installer dans le répertoire de modules du serveur d'applications.
    EAP_HOME/modules/system/layers/base/MODULENAME/main
    $ mkdir -P EAP_HOME/modules/system/layers/base/MODULENAME/main
  2. Copier les fichiers

    Copier le JAR et les fichiers module.xml dans le répertoire créé dans l'étape 1.
    $ cp MyValves.jar module.xml EAP_HOME/modules/system/layers/base/MODULENAME/main
Les classes de valve déclarées dans le module sont maintenant disponibles et peuvent être configurées dans le sous-système web.

9.5. Configuration d'une valve globale

Les valves globales sont activées et configurées dans le sous-système web par l'intermédiaire de l'interface CLI de JBoss.

Procédure 9.2. Configuration d'une valve globale

  1. Activer la valve

    Utiliser l'opération add pour ajouter une nouvelle saisie de valve.
    /subsystem=web/valve=VALVENAME:add(module="MODULENAME",class-name="CLASSNAME")
    Vous devrez indiquer les valeurs suivantes :
    • VALVENAME, le nom utilisé pour cette valve dans la configuration de l'application.
    • MODULENAME, le module qui contient la valeur en cours de configuration.
    • CLASSNAME, le nom de classe de la valve spécifique du module.
    Par exemple :
    /subsystem=web/valve=clientlimiter:add(module="clientlimitermodule",class-name="org.jboss.samplevalves.RestrictedUserAgentsValve")
  2. En option : spécifier les paramètres

    Si la valve a des paramètres de configuration, spécifier les dans l'opération add-param.
    /subsystem=web/valve=VALVENAME:add-param(param-name="PARAMNAME", param-value="PARAMVALUE")
    Vous devrez indiquer les valeurs suivantes :
    • VALVENAME, le nom utilisé pour cette valve dans la configuration de l'application.
    • PARAMNAME, le nom du paramètre configuré pour une valve spécifique.
    • PARAMVALUE, la valeur du paramètre spécifié.
    Par exemple :

    Exemple 9.1. Configuration de la valve

    /subsystem=web/valve=clientlimiter:add-param(
       param-name="restrictedUserAgents", 
       param-value="^.*MS Web Services Client Protocol.*$"
    )
Cette valve est maintenant activée et configurée pour toutes les applications déployées.
Voir la section Create a Custom Valve du Guide de développement pour obtenir plus d'informations sur la façon de créer une valve personnalisée.

Chapitre 10. Déploiement d'applications

10.1. Les déploiements d'applications

JBoss EAP 6 dispose d'une gamme d'options de déploiement et de configuration d'application pour répondre à la fois aux environnements administratifs et de développement. Pour les administrateurs, la console de gestion et l'interface CLI offrent un graphisme et des interfaces de ligne de commande idéals pour gérer le déploiement des applications dans un environnement de production. Pour les développeurs, la gamme des options de testing de déploiement d'application incluent un scanner de déploiement hautement configurable de système de fichiers, l'utilisation d'un IDE comme JBoss Developer Studio, ou le déploiement et l'annulation du déploiement via Maven.

10.2. Déployer avec la console de gestion

10.2.1. Gérer le déploiement d'application à l'aide de la console de gestion

Le déploiement d'applications par l'intermédiaire de la console de gestion vous donne l'avantage d'une interface graphique facile à utiliser. Vous pouvez voir en un coup d'œil quelles applications sont déployées sur votre serveur ou les groupes de serveurs, et vous pouvez désactiver ou supprimer des applications dans le référentiel de contenu selon les besoins.

10.2.2. Activer une application déployée à l'aide de la console de gestion

Procédure 10.1. Activer une application déployée à l'aide de la console de gestion

  1. Sélectionner l'onglet Runtime en haut de la console.
    • Pour une domaine géré, étendre le menu Domain.
    • Pour une domaine autonome, étendre le menu Server.
  2. Sélectionner Manage Deployments.
  3. La méthode de déploiement des applications variera suivant que vous déployez dans une instance de serveur autonome ou dans un domaine géré.
    • Activer une application sur une instance de serveur autonome

      Le tableau Available Deployments affiche tous les déploiements d'applications disponibles et leurs statuts.
      1. Pour activer une application dans une instance de serveur autonome, sélectionner l'application, puis cliquer sur En/Disable.
      2. Cliquer sur confirm pour confirmer que l'application puisse être activée dans l'instance du serveur.
    • Activer une application dans un domaine géré

      L'onglet Content Repository contient un tableau Available Deployment Content qui montre tous les déploiements d'applications disponibles et leur statut.
      1. Pour activer une application dans un domaine géré, sélectionner l'application à déployer. Cliquer sur Assign au dessus du tableau Available Deployment Content.
      2. Cocher les cases pour chaque groupe de serveurs dans lesquels vous souhaitez ajouter l'application et cliquer sur le bouton Save pour terminer.
      3. Sélectionner l'onglet Server Groups pour afficher le tableau Server Groups. Votre application sera maintenant déployée dans les groupes de serveurs que vous avez sélectionnés.
Résultat

L'application est déployée sur le serveur qui convient ou dans le groupe de serveurs qui convient.

10.2.3. Désactiver une application déployée à l'aide de la console de gestion

Procédure 10.2. Désactiver une application déployée à l'aide de la console de gestion

    1. Sélectionner l'onglet Runtime en haut de la console.
      • Pour un domaine géré, étendre le menu Domain.
      • Pour un domaine autonome, étendre le menu Server.
    2. Sélectionner Manage Deployments.
  1. La méthode de suppression d'une application variera suivant que vous déployez dans une instance de serveur autonome ou dans un domaine géré.
    • Désactiver une application déployée dans une instance de serveur autonome

      Le tableau Available Deployments affiche tous les déploiements d'applications disponibles et leurs statuts.
      1. Sélectionner l'application à désactiver. Cliquer sur En/Disable pour désactiver l'application sélectionnée.
      2. Cliquer sur Confirm pour confirmer que l'application puisse être désactivée dans l'instance du serveur.
    • Désactiver l'application déployée dans un domaine géré

      L'affichage écran Manage Deployment Content contient un onglet Content Repository. Le tableau Available Deployment Content affiche tous les déploiements d'applications disponibles et leur statut.
      1. Sélectionner l'onglet Server Groups pour afficher les groupes de serveurs et le statut de leurs applications déployées.
      2. Sélectionner le nom du serveur dans le tableau Server Group pour supprimer un déploiement. Cliquer sur View pour voir les applications.
      3. Sélectionner l'application à désactiver et cliquer sur En/Disable pour désactiver l'application sur le serveur sélectionné.
      4. Cliquer sur Confirm pour confirmer que l'application puisse être désactivée dans l'instance du serveur.
      5. Répéter au besoin pour d'autres groupes de serveur. Le statut de l'application est confirmé pour chaque groupe de serveurs dans le tableau Group Deployments de ce groupe de serveurs.
Résultat

L'application n'est pas déployée à partir d'un serveur ou d'un groupe de serveurs qui convient.

10.2.4. Retirer le déploiement d'une application à l'aide de la Console de gestion

Procédure 10.3. Retirer le déploiement d'une application à l'aide de la Console de gestion

    1. Sélectionner l'onglet Runtime en haut de la console.
      • Pour une domaine géré, étendre le menu Domain.
      • Pour une domaine autonome, étendre le menu Server.
    2. Sélectionner Manage Deployments.
  1. La méthode de suppression d'une application utilisée variera suivant que vous supprimez un déploiement dans une instance de serveur autonome ou dans un domaine géré.
    • Supprimer une application déployée d'une instance de serveur autonome

      Le tableau Available Deployments affiche tous les déploiements d'applications disponibles et leurs statuts.
      1. Sélectionner l'application dont on doit supprimer le déploiement. Cliquer sur le bouton Remove pour supprimer le déploiement d'une application sélectionnée.
      2. Cliquer sur Confirm pour confirmer que le déploiement de l'application puisse être supprimé dans l'instance du serveur.
    • Supprimer le déploiement d'une application déployée dans un domaine géré

      L'affichage écran Manage Deployment Content contient un onglet Content Repository. Le tableau Available Deployment Content affiche tous les déploiements d'applications disponibles et leur statut.
      1. Sélectionner l'onglet Server Groups pour afficher les groupes de serveurs et le statut de leurs applications déployées.
      2. Sélectionner le nom du serveur dans le tableau Server Group pour supprimer un déploiement. Cliquer sur View pour voir les applications.
      3. Sélectionner l'application et cliquer sur Remove pour supprimer le déploiement de l'application d'une serveur sélectionné.
      4. Cliquer sur Confirm pour confirmer que le déploiement de l'application puisse être supprimé dans l'instance du serveur.
      5. Répéter au besoin pour d'autres groupes de serveur. Le statut de l'application est confirmé pour chaque groupe de serveurs dans le tableau Group Deployments de ce groupe de serveurs.
Résultat

Le déploiement de l'application est supprimé d'un serveur ou d'un groupe de serveurs particulier. Dans une instance autonome, le contenu du déploiement sera supprimé également. Dans un domaine géré, le contenu du déploiement restera dans le référentiel de contenu et le déploiement ne sera supprimé qu'à partir d'un groupe de serveurs.

10.3. Déployer part l'interface de commandes CLI

10.3.1. Gérer le déploiement d'une application à l'aide de l'interface CLI

Le déploiement d'applications par l'intermédiaire de l'interface CLI vous donne l'avantage d'une interface à ligne de commande facile à utiliser. Vous pouvez utiliser les capacités de scripting pour configurer le déploiement d'applications spécifiques et des scénarios de gestion. Vous pouvez gérer le statut de déploiement d'un serveur dans le cas d'une instance autonome, ou d'un réseau entier de serveurs dans le cas d'un domaine géré.

10.3.2. Déployer une application dans un serveur autonome à l'aide de l'interface CLI

Procédure 10.4. Déployer une application dans un serveur autonome

  • Exécuter la commande deploy

    À l'aide de l'interface CLI, saisir la commande deploy avec le chemin d'accès vers le déploiement de l'application.

    Exemple 10.1. La commande « deploy »

    [standalone@localhost:9999 /] deploy /path/to/test-application.war
    Veuillez noter qu'un déploiement réussi ne crée pas de sortie vers le CLI.
Résultat

L'application indiquée est maintenant déployée dans un serveur autonome.

10.3.3. Supprimer le déploiement d'une application dans un serveur autonome à l'aide de l'interface CLI

Procédure 10.5. Supprimer le déploiement d'une application dans un serveur autonome

Par défaut, la commande undeploy supprimera le déploiement et supprimera le contenu de déploiement de l'instance autonome de JBoss EAP. Pour retenir le contenu du déploiement, ajouter le paramètre --keep-content.
  • Exécuter la commande undeploy

    Pour supprimer le déploiement de l'application et supprimer le contenu du déploiement, avec l'interface CLI, saisir la commande undeploy avec le nom du fichier du déploiement de l'application.
    [standalone@localhost:9999 /] undeploy test-application.war
    Pour supprimer le déploiement de l'application et conserver le contenu du déploiement, avec l'interface CLI, saisir la commande undeploy avec le nom du fichier du déploiement de l'application et le paramètre --keep-content.
    [standalone@localhost:9999 /] undeploy test-application.war --keep-content
Résultat

Le déploiement de l'application spécifiée est maintenant retiré. Notez que la commande undeploy ne produit pas de sortie dans l'interface CLI si elle réussit.

10.3.4. Déployer une application dans un domaine géré à l'aide de l'interface CLI

Procédure 10.6. Déployer une application dans un domaine géré

  • Exécuter la commande deploy

    Par l'intermédiaire de l'interface CLI, saisir la commande deploy ainsi que le chemin d'accès vers le déploiement de l'application. Inclure le paramètre --all-server-groups afin de déployer tous les groupes de serveurs.
    [domain@localhost:9999 /] deploy /path/to/test-application.war --all-server-groups
    • Sinon, définir des groupes de serveurs particuliers de déploiement avec le paramètre --server-groups.
      [domain@localhost:9999 /] deploy /path/to/test-application.war --server-groups=server_group_1,server_group_2
    Veuillez noter qu'un déploiement réussi ne crée pas de sortie vers le CLI.
Résultat

L'application indiquée est maintenant déployée dans un groupe de serveurs dans votre domaine géré.

10.3.5. Supprimer le déploiement d'une application dans un domaine géré à l'aide de l'interface CLI

Procédure 10.7. Supprimer le déploiement d'une application dans un domaine géré

  • Exécuter la commande undeploy

    Par l'intermédiaire de l'interface CLI, saisir la commande undeploy ainsi que le nom de fichier du déploiement de l'application. On peut retirer le déploiement de l'application à partir de n'importe quel groupe de serveur dans lequel elle a été déployée à l'origine en ajoutant le paramètre --all-relevant-server-groups.
    [domain@localhost:9999 /] undeploy test-application.war --all-relevant-server-groups
    Veuillez noter qu'une suppression de déploiement réussie ne crée pas de sortie vers le CLI.
Résultat

L'application spécifiée n'est désormais plus déployée.

10.4. Déployer par l'API HTTP

10.4.1. Déployer une application par l'API HTTP

Résumé

Les applications peuvent être déployées via l'API HTTP en suivant les instructions suivantes.

Procédure 10.8. Déployer une application par DeployDmrToJson.java

  1. Utiliser DeployDmrToJson.java pour créer une requête à JSON de déploiement de votre application.

    Exemple 10.2. DeployDmrToJson.java class

    import org.jboss.dmr.ModelNode;
    import java.net.URL;
    
    public class DeployDmrToJson
    {
      public static void main(String[] args) throws Exception
      {
        if(args.length < 1)
          throw new IllegalArgumentException("The first argument must be a URL");
    
        URL url = new URL(args[0]);
        String[] pathElements = url.getFile().split("/");
        String name = pathElements[pathElements.length-1];
    
        ModelNode deploy = getDeploy(url.toExternalForm(), name);
        ModelNode undeploy = getUndeploy(name);
    
        System.out.println("Deploy\n------------------------------\n");
        System.out.println("Formatted:\n" + deploy.toJSONString(false));
        System.out.println("Unformatted:\n" + deploy.toJSONString(true));
        System.out.println("\nUndeploy\n------------------------------\n");
        System.out.println("Formatted:\n" + undeploy.toJSONString(false));
        System.out.println("Unformatted:\n" + undeploy.toJSONString(true));
      }
    
      public static ModelNode getUndeploy(String name)
      {
        ModelNode undeployRequest = new ModelNode();
        undeployRequest.get("operation").set("undeploy");
        undeployRequest.get("address", "deployment").set(name);
    
        ModelNode removeRequest = new ModelNode();
        removeRequest.get("operation").set("remove");
        removeRequest.get("address", "deployment").set(name);
    
        ModelNode composite = new ModelNode();
        composite.get("operation").set("composite");
        composite.get("address").setEmptyList();
        final ModelNode steps = composite.get("steps");
        steps.add(undeployRequest);
        steps.add(removeRequest);
        return composite;
      }
    
      public static ModelNode getDeploy(String url, String name)
      {
        ModelNode deployRequest = new ModelNode();
        deployRequest.get("operation").set("deploy");
        deployRequest.get("address", "deployment").set(name);
    
        ModelNode addRequest = new ModelNode();
        addRequest.get("operation").set("add");
        addRequest.get("address", "deployment").set(name);
        addRequest.get("content").get(0).get("url").set(url);
    
        ModelNode composite = new ModelNode();
        composite.get("operation").set("composite");
        composite.get("address").setEmptyList();
        final ModelNode steps = composite.get("steps");
        steps.add(addRequest);
        steps.add(deployRequest);
        return composite;
      }
    }
  2. Exécuter la classe par une commande basée sur les instructions suivantes :

    Exemple 10.3. Commande Execute

    java -cp .:$JBOSS_HOME/modules/org/jboss/dmr/main/jboss-dmr-1.1.1.Final-redhat-1.jar DeployDmrToJson \
    file:///Users/username/support/helloWorld.war/dist/helloWorld.war
  3. Quand la classe est exécutée, les formats de commande suivants seront affichés. Utiliser la commande deploy ou la commande undeploy selon vos besoins.

    Exemple 10.4. Commande de déploiement et de suppression de déploiement

    Deploy
    ------------------------------
    
    Formatted:
    {
        "operation" : "composite",
        "address" : [],
        "steps" : [
            {
                "operation" : "add",
                "address" : {"deployment" : "helloWorld.war"},
                "content" : [{"url" : "file:/Users/username/support/helloWorld.war/dist/helloWorld.war"}]
            },
            {
                "operation" : "deploy",
                "address" : {"deployment" : "helloWorld.war"}
            }
        ]
    }
    Unformatted:
    {"operation" : "composite", "address" : [], "steps" : [{"operation" : "add", "address" : {"deployment" : "helloWorld.war"}, "content" : [{"url" : "file:/Users/username/support/helloWorld.war/dist/helloWorld.war"}]},{"operation" : "deploy", "address" : {"deployment" : "helloWorld.war"}}]}
    
    Undeploy
    ------------------------------
    
    Formatted:
    {
        "operation" : "composite",
        "address" : [],
        "steps" : [
            {
                "operation" : "undeploy",
                "address" : {"deployment" : "helloWorld.war"}
            },
            {
                "operation" : "remove",
                "address" : {"deployment" : "helloWorld.war"}
            }
        ]
    }
    Unformatted:
    {"operation" : "composite", "address" : [], "steps" : [{"operation" : "undeploy", "address" : {"deployment" : "helloWorld.war"}},{"operation" : "remove", "address" : {"deployment" : "helloWorld.war"}}]}
    
  4. Utiliser la commande suivante pour déployer ou supprimer le déploiement d'une application. Remplacer json request par la requête décrite ci-dessus.

    Exemple 10.5. Commande Execute

    curl -f --digest -u "<user>:<pass>" -H Content-Type:\ application/json -d '<json request>' "http://localhost:9990/management"

10.5. Déployer avec le scanneur de déploiement

10.5.1. Gérer le déploiement d'applications dans le scanneur de déploiement

Déployer des applications dans une instance de serveur autonome par l'intermédiaire d'un scanner de déploiement vous permet de créer et de tester des applications d'une manière adaptée aux cycles de développement rapides. Vous pouvez configurer le scanner de déploiement en fonction de vos besoins de fréquence de déploiement et de comportement pour une variété de types d'applications.

10.5.2. Déployer une application dans une instance de serveur autonome par un scanneur de déploiement

Résumé

Cette tâche présente une méthode de déploiement des applications dans une instance de serveur autonome par le scanneur de déploiement. Comme il est indiqué dans la section Section 10.1, « Les déploiements d'applications », cette méthode est retenue pour la commodité des développeurs, où les méthodes de console de gestion ou d'interface CLI sont recommandées pour la gestion des applications dans les environnements de production.

Procédure 10.9. Utiliser le scanneur de déploiement pour déployer les applications.

  1. Copier le contenu dans le dossier de déploiement

    Copier le fichier de l'application dans un dossier de déploiement qui se situe EAP_HOME/standalone/deployments/.
  2. Modes d'analyses de déploiements

    Il existe deux méthodes de déploiement. Vous pouvez choisir entre les modes de traitement manuel ou automatique. Avant de démarrer une des méthodes de déploiement, lisez ceci Section 10.5.8, « Configurer le scanneur de déploiement avec l'interface CLI ».
    • Déploiement automatique

      Le scanner de déploiement saisit un changement d'état d'un dossier et crée un fichier de marquage, comme expliqué dans la section Section 10.5.8, « Configurer le scanneur de déploiement avec l'interface CLI ».
    • Déploiement manuel

      Le scanneur de déploiement a besoin d'un fichier de marqueurs pour déclencher le processus de déploiement. L'exemple suivant utilise la commande Unix touch pour créer un nouveau fichier .dodeploy.

      Exemple 10.6. Déploiement par la commande touch

      [user@host bin]$ touch $EAP_HOME/standalone/deployments/example.war.dodeploy
Résultat

Le fichier de l'application est déployé sur le serveur d'applications. Un fichier de marquage est créé dans le dossier de déploiement pour indiquer la réussite du déploiement, et l'application est marquée comme Enabled dans la console de gestion.

Exemple 10.7. Contenu du dossier de déploiement après le déploiement.

example.war
example.war.deployed

10.5.3. Supprimer le déploiement d'une application dans une instance de serveur autonome par un scanner de déploiement

Résumé

Cette tâche présente une méthode de retrait de déploiement d'applications en provenance d'une instance de serveur autonome qui ont été déployées par le scanneur de déploiement. Comme il est indiqué dans la section Section 10.1, « Les déploiements d'applications », cette méthode est retenue pour la commodité des développeurs, où les méthodes de console de gestion ou d'interface CLI sont recommandées pour la gestion des applications dans les environnements de production.

Note

Le scanneur de déploiement ne devrait pas servir en conjonction avec d'autres méthodes de déploiement pour la gestion des applications. Les applications supprimées du serveur d'applications par la console de gestion seront retirées du runtime sans affecter les fichiers de marquage ou l'application contenue dans le répertoire de déploiement. Pour minimiser le risque de redéploiement accidentel ou autre erreur, utilisez l'interface CLI et la console de gestion pour l'administration dans des environnements de production.

Procédure 10.10. Retirer le déploiement d'une application à l'aide d'une des méthodes suivantes

  • Supprimer le déploiement de l'application

    Il existe deux méthodes pour supprimer un déploiement d'application suivant que vous souhaitez supprimer l'application d'un dossier de déploiement ou bien que vous souhaitez uniquement modifier son statut de déploiement.
    • Retirer un déploiement par suppression du fichier de marquage

      Supprimer le fichier de marquage example.war.deployed de l'application qui est déployée pour commencer le retrait de déploiement de l'application du runtime.
      Résultat
      Le scanneur de déploiement retire l'application et crée un fichier de marquage example.war.undeployed. L'application demeure dans le dossier de déploiement.
    • Retirer le déploiement en supprimant l'application

      Note

      Annulez le déploiement d'un fichier WAR explosé à l'aide de cette méthode n'est pas valide. Seule une annulation en supprimant le fichier de marqueurs est valide. Tenter d'annuler le déploiement d'un fichier WAR explosé se traduira par un message ressemblant au message suivant enregistré.
      WARN  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015006: The deployment scanner found that the content for exploded deployment EXAMPLE.war has been deleted, but auto-deploy/undeploy for exploded deployments is not enabled and the EXAMPLE.war.deployed marker file for this deployment has not been removed. As a result, the deployment is not being undeployed, but resources needed by the deployment may have been deleted and application errors may occur. Deleting the EXAMPLE.war.deployed marker file to trigger undeploy is recommended.
      Supprimer l'application depuis le répertoire de déploiement pour encourager le scanneur de déploiement à commencer le retrait du déploiement de l'application du runtime.
      Résultat
      Le scanneur de déploiement retire l'application et crée un fichier de marquage filename.filetype.undeployed. L'application n'est plus présente dans le dossier de déploiement.
Résultat

Le fichier de l'application n'est plus déployé dans le serveur d'applications et n'est plus visible dans l'écran Deployments de la console de gestion.

10.5.4. Redéploiement d'une application dans une instance de serveur autonome par le scanneur de déploiement

Résumé

Cette tâche présente une méthode de retrait de déploiement d'applications dans une instance de serveur autonome qui a été déployée par le scanneur de déploiement. Comme il est indiqué dans la section Section 10.1, « Les déploiements d'applications », cette méthode est retenue pour la commodité des développeurs, où les méthodes de console de gestion ou d'interface CLI sont recommandées pour la gestion des applications dans les environnements de production.

Procédure 10.11. Déployer à nouveau une application dans un serveur autonome

  • Redéploiement de l'application

    Il existe trois méthodes possibles pour redéployer une application déployée par le scanner de déploiement. Ces méthodes déclenchent le scanneur de déploiement pour initier un cycle de déploiement, et peuvent être choisies en fonction des préférences personnelles.
Résultat

Le fichier de l'application est déployé à nouveau.

10.5.5. Référence pour les fichiers de marquage de scanneur de déploiement

Les fichiers de marquage

Les fichiers de marquage font partie du sous-système du scanneur de déploiement. Ces fichiers indiquent le statut d'une application dans un répertoire de déploiement de l'instance du serveur autonome. Un fichier de marquage a le même nom que l'application, avec un suffixe de fichier qui indique l'état du déploiement de l'application. Le tableau suivant définit les types et les réponses de chaque fichier de marquage.

Exemple 10.9. Exemple de fichier de marquage

L'exemple suivant montre un fichier de marquage d'une instance déployée réussie pour une application nommée testapplication.war.
testapplication.war.deployed

Tableau 10.1. Définitions de types de fichiers de marquage

Suffixe du nom de fichier Origine Description
.dodeploy Utilisateur généré Indique que le contenu doit être déployé ou redéployé dans le runtime.
.skipdeploy Utilisateur généré Désactive l'autodéploiement d'une application si présent. Utile pour bloquer temporairement l'auto-déploiement d'un contenu explosé, empêchant ainsi le risque de modifications de contenu imcomplètes d'être rendues live. Peut être utile pour le contenu compressé, bien que le scanneur détecte les changements en cours dans le contenu compressé et attend qu'ils soient terminés.
.isdeploying Système généré Indique l'initiation du déploiement. Le fichier de marquage sera effacé quand le processus de déploiement sera complété.
.deployed Système généré Indique que le contenu a été déployé. Le déploiement du contenu sera supprimé si le fichier est effacé.
.failed Système généré Indique les échecs de déploiement. Le fichier de marquage contient des informations sur la cause de l'échec. Si le fichier de marquage est supprimé, le contenu sera rendu visible dans l'auto-déploiement à nouveau.
.isundeploying Système généré Indique une réponse suite à la suppression d'un fichier .deployed. Le déploiement du contenu sera supprimé et le marqueur sera effacé automatiquement dès complétion.
.undeployed Système généré Indique si le contenu a été déployé. La suppression du fichier de marquage n'a pas d'impact sur le re-déploiement du contenu.
.pending Système généré Indique que les instructions de déploiement devront être envoyées au serveur suite à la résolution d'un problème qui a été detecté. Ce marqueur sert de blocage de déploiement global. Le scanneur ne demandera pas au serveur de déployer ou de supprimer un déploiement de contenu tant que cette condition existe.

10.5.6. Référence pour attributs de scanneur de déploiement

Le scanneur de déploiement contient les attributs suivants, qui sont exposés dans l'interface CLI et qui peuvent être configurés par l'opération write-attribute. Pour plus d'informations sur les options de configuration, se référer à la section suivante Section 10.5.8, « Configurer le scanneur de déploiement avec l'interface CLI ».

Tableau 10.2. Attributs de scanneur de déploiement

Nom Description Type Valeur par défaut
auto-deploy-exploded Permet le déploiement automatique d'un contenu éclaté sans nécessiter un fichier de marquage .dodeploy. Recommandé pour les scénarios de développement de base uniquement pour empêcher le déploiement d'applications éclatées de se produire lors de changements du développeur ou du système d'exploitation. Booléen False
auto-deploy-xml Autorise le déploiement automatique d'un contenu XML sans besoin de fichier de marquage .dodeploy. Booléen True
auto-deploy-zipped Autorise le déploiement automatique d'un contenu compressé sans besoin de fichier de marquage .dodeploy. Booléen True
deployment-timeout La durée nécessaire en secondes pour que le scanneur de déploiement puisse permettre un déploiement avant annulation. Long 600
path Définit le chemin du système de fichier à scanner. Si l'attribut relative-to est spécifié, la valeur path agira comme un ajout relatif à ce répertoire ou chemin d'acccès. String déploiements
relative-to Référence à un chemin de système de fichier défini dans la section paths du fichier de configuration XML du serveur. String jboss.server.base.dir
scan-enabled Autorise le scanning automatique des applications par scan-interval au démarrage. Booléen True
scan-interval L'intervalle en millisecondes entre les balayages de référentiels. Une valeur inférieure à 1 empêche le scanneur d'opérer au démarrage. Int 5000

10.5.7. Configurer le scanneur de déploiement

Le scanner de déploiement peut être configuré à l'aide de la console de gestion ou l'interface CLI. Vous pouvez créer un nouveau scanneur de déploiement ou bien gérer les attributs existants de scanneur, c'est à dire l'intervalle de balayage, l'emplacement du dossier de déploiement et les types de fichiers d'application qui déclencheront un déploiement.

10.5.8. Configurer le scanneur de déploiement avec l'interface CLI

Résumé

Bien qu'il existe plusieurs méthodes de configuration du scanneur de déploiement, l'interface CLI permet d'exposer et de modifier les attributs par l'utilisation de scripts de lots ou en temps réel. Vous pouvez modifier le comportement du scanneur de déploiement par l'utilisation de l'attribut lecture read-attribute et des opérations de ligne de commande write-attribute. Davantage d'informations sur les attributs de scanneur de déploiement sont définis dans la rubrique Section 10.5.6, « Référence pour attributs de scanneur de déploiement ».

Le scanneur de déploiement est un sous-système de JBoss EAP 6, que vous pouvez voir dans standalone.xml.

Exemple 10.10. Excerpt de standalone.xml

<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
    <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/>
</subsystem>

Procédure 10.12. Configurer le scanneur de déploiement

  1. Déterminer les attributs de scanner de déploiement à configurer

    Pour configurer le scanneur de déploiement par l'interface CLI, vous devrez tout d'abord exposer les noms d'attribut qui conviennent. Vous pouvez faire cela grâce à l'opération read-resources au nœud root, ou bien par la commande cd pour passer au nœud dépendant du sous-système. Vous pouvez également afficher les attributs par la commande ls à ce niveau.
    • Exposer les attributs de scanneur de déploiement par l'opération read-resource

      Utiliser l'opération read-resource pour exposer les attributs définis par la ressource de scanneur de déploiement par défaut.

      Exemple 10.11. Exemple de sortie read-resource

      [standalone@localhost:9999 /]/subsystem=deployment-scanner/scanner=default:read-resource
      {
          "outcome" => "success",
          "result" => {
              "auto-deploy-exploded" => false,
              "auto-deploy-xml" => true,
              "auto-deploy-zipped" => true,
              "deployment-timeout" => 600,
              "path" => "deployments",
              "relative-to" => "jboss.server.base.dir",
              "scan-enabled" => true,
              "scan-interval" => 5000
          }
      }
    • Exposer les attributs de scanneur de déploiement par la commande ls

      Utiliser la commande ls avec l'argument -l en option pour afficher une table de résultats qui incluent des attributs de nœud, des valeurs et types de sous-système. Vous pouvez en apprendre davantage sur la commande ls et ses arguments en exposant l'entrée ls --help. Pour plus d'informations sur le menu help de l'interface CLI, voir la section Section 3.5.5, « Comment obtenir de l'aide par l'interface CLI ».

      Exemple 10.12. Exemple de sortie ls -l

      [standalone@localhost:9999 /] ls -l /subsystem=deployment-scanner/scanner=default
      ATTRIBUTE            VALUE                 TYPE    
      auto-deploy-exploded false                 BOOLEAN 
      auto-deploy-xml      true                  BOOLEAN 
      auto-deploy-zipped   true                  BOOLEAN 
      deployment-timeout   600                   LONG    
      path                 deployments           STRING  
      relative-to          jboss.server.base.dir STRING  
      scan-enabled         true                  BOOLEAN 
      scan-interval        5000                  INT
  2. Configurer le scanneur de déploiement par l'opération write-attribute

    Une fois que vous avez déterminé le nom de l'attribut à modifier, utiliser la commande write-attribute pour spécifier le nom de l'attribut et la nouvelle valeur à indiquer. Les exemples suivants sont tous exécutés au niveau du nœud dépendant, qui peut être accédé en utilisant la commande cd et la saisie semi-automatique via la touche TAB pour passer au nœud de scanneur par défaut.
    [standalone@localhost:9999 /] cd subsystem=deployment-scanner/scanner=default
    1. Active le déploiement automatique du contenu explosé.

      Utiliser l'opération write-attribute pour activer le déploiement automatique du contenu d'application explosé.
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-exploded,value=true)
      {"outcome" => "success"}
    2. Désactiver le déploiement automatique du contenu XML

      Utiliser l'opération write-attribute pour désactiver le déploiement automatique du contenu d'application explosé.
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-xml,value=false)     
      {"outcome" => "success"}
    3. Désactiver le déploiement automatique du contenu compressé

      Utiliser la commande write-attribute pour désactiver le déploiement automatique du contenu d'applications compressé.
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-zipped,value=false)
      {"outcome" => "success"}
    4. Configurer l'attribut du chemin d'accès

      Utiliser l'opération write-attribute pour modifier l'attribut de chemin d'accès, pour substituer la valeur de l'exemple newpathname par un nouveau nom de chemin d'accès que le scanneur de déploiement puisse surveiller. Noter que le serveur aura besoin que le nouveau chargement prenne effet.
      [standalone@localhost:9999 scanner=default] :write-attribute(name=path,value=newpathname)            
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
    5. Configurer l'attribut du chemin relatif

      Utiliser l'opération write-attribute pour modifier la référence relative du chemin du système de fichier ainsi définie dans la section des chemins d'accès du fichier de configuration XML. Notez que le serveur aura besoin que le nouveau chargement prenne effet.
      [standalone@localhost:9999 scanner=default] :write-attribute(name=relative-to,value=new.relative.dir)
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
    6. Désactiver le scanneur de déploiement

      Utiliser l'opération write-attribute pour désactiver le scanneur de déploiement en définissant la valeur scan-enabled à false.
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-enabled,value=false)        
      {"outcome" => "success"}
    7. Changer l'intervalle de balayage

      Utiliser l'opération write-attribute pour modifier l'intervalle de balayage de 5 000 millisecondes à 10 000 millisecondes.
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-interval,value=10000)
      {"outcome" => "success"}
Résultat

Vos modifications de configuration sont sauvegardées dans le scanneur de déploiement.

10.6. Déployer avec Maven

10.6.1. Gestion du déploiement d'applications dans Maven

Le déploiement d'applications dans Maven vous permet d'incorporer un cycle de déploiement dans votre flux de développement existant.

10.6.2. Déployer une application dans Maven

Résumé

Cette tâche vous montre une méthode pour déployer des applications dans Maven. L'exemple fourni utilise l'application jboss-helloworld.war qui se trouve dans la collection Jboss EAP 6 Quickstarts. Le projet helloworld contient un fichier POM qui initialise le jboss-as-maven-plugin. Ce plugin fournit des simples opérations pour déployer ou supprimer le déploiement d'applications vers ou en provenance du serveur d'applications.

Procédure 10.13. Déployer une application dans Maven.

  1. Ouvrir la session de terminal et naviguer dans le répertoire qui contient les exemples Quickstart.

    Exemple 10.13. Passer au répertoire d'application helloworld

    [localhost]$ cd /QUICKSTART_HOME/helloworld
    
  2. Exécuter la commande de déploiement Maven pour déployer l'application. Si l'application est déjà en cours d'exécution, elle sera déployée à nouveau.
    [localhost]$ mvn package jboss-as:deploy
  3. Afficher les résultats.
    • Le déploiement peut être confirmé si vous regardez les entrées de journalisation de l'opération dans la fenêtre du terminal.

      Exemple 10.14. Confirmation Maven pour l'application helloworld

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESS
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 32.629s
      [INFO] Finished at: Fri Mar 14 09:09:50 EDT 2014
      [INFO] Final Memory: 23M/204M
      [INFO] ------------------------------------------------------------------------
      
    • Le déploiement peut également être confirmé dans le flux de statut de l'instance du serveur d'applications actives.

      Exemple 10.15. Confirmation du serveur d'applications pour l'application helloworld

      09:09:49,167 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/username/EAP_HOME/standalone/data/content/32/4b4ef9a4bbe7206d3674a89807203a2092fc70/content
      09:09:49,175 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")
      09:09:49,563 INFO  [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment jboss-helloworld.war
      09:09:49,611 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: jboss-helloworld.war
      09:09:49,680 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900 1.1.17 (redhat)
      09:09:49,705 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment jboss-helloworld.war
      09:09:50,080 INFO  [org.jboss.web] (ServerService Thread Pool -- 55) JBAS018210: Register web context: /jboss-helloworld
      09:09:50,425 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "jboss-helloworld.war" (runtime-name : "jboss-helloworld.war")
Résultat

L'application est déployée dans le serveur d'applications.

10.6.3. Supprimer le déploiement d'une application dans Maven

Résumé

Cette tâche vous montre une méthode pour supprimer le déploiement des applications dans Maven. L'exemple fourni utilise l'application jboss-helloworld.war qui se trouve dans la collection Jboss EAP 6 Quickstarts. Le projet helloworld contient un fichier POM qui initialise le jboss-as-maven-plugin. Ce plugin fournit des simples opérations pour déployer ou supprimer le déploiement d'applications vers ou en provenance du serveur d'applications.

Procédure 10.14. Supprimer le déploiement d'une application dans Maven

  1. Ouvrir la session de terminal et naviguer dans le répertoire qui contient les exemples Quickstart.

    Exemple 10.16. Passer au répertoire d'application helloworld

    [localhost]$ cd /QUICKSTART_HOME/helloworld
    
  2. Exécuter la commande de suppression de déploiement.
    [localhost]$ mvn jboss-as:undeploy
  3. Afficher les résultats.
    • La suppression du déploiement peut être confirmée si on observe les entrées de journalisation de la fenêtre de terminal.

      Exemple 10.17. Confirmation Maven pour la suppression du déploiement de l'application helloworld.

      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 1 second
      [INFO] Finished at: Mon Oct 10 17:33:02 EST 2011
      [INFO] Final Memory: 11M/212M
      [INFO] ------------------------------------------------------------------------
    • La suppression du déploiement peut également être confirmée dans le flux de statut de l'instance du serveur d'applications actives.

      Exemple 10.18. Confirmation du serveur d'applications pour la suppression du déploiement de l'application helloworld.

      09:51:40,512 INFO  [org.jboss.web] (ServerService Thread Pool -- 69) JBAS018224: Unregister web context: /jboss-helloworld
      09:51:40,522 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016009: Stopping weld service for deployment jboss-helloworld.war
      09:51:40,536 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment jboss-helloworld.war (runtime-name: jboss-helloworld.war) in 27ms
      09:51:40,621 INFO  [org.jboss.as.repository] (management-handler-thread - 10) JBAS014901: Content removed from location /home/username/EAP_HOME/jboss-eap-6.4/standalone/data/content/44/e1f3c55c84b777b0fc201d69451223c09c9da5/content
      09:51:40,621 INFO  [org.jboss.as.server] (management-handler-thread - 10) JBAS018558: Undeployed "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")
      
Résultat

La suppression du déploiement de l'application provient du serveur d'applications.

10.7. Contrôler l'ordre des applications déployées dans JBoss EAP 6

JBoss EAP 6 offre un contrôle à grain fin sur l'ordre de déploiement d'applications lors du démarrage du serveur. L'ordre strict de déploiement d'applications présentes dans plusieurs fichiers ear peut être activé avec la persistance de cet ordre après un redémarrage.

Procédure 10.15. Contrôler l'ordre de déploiement dans EAP 6.0

  1. Crée des scripts CLI qui déploient et retirent les déploiements d'applications dans un ordre séquentiel quand le serveur est à l'arrêt/démarrage.
  2. CLI prend également en charge le concept de mode batch qui permet de grouper les commandes et les opérations et les exécuter ensemble comme une unité atomique. Si au moins une des commandes ou opérations échoue, toutes les autres commandes et opérations exécutées avec succès dans le lot seront annulées.

Procédure 10.16. Contrôler l'ordre de déploiement dans EAP 6.1 et versions ultérieures

La nouvelle fonctionnalité nommée Inter Deployment Dependencies d'EAP 6.1, et versions ultérieures, vous permet de déclarer des dépendances entre les niveaux supérieurs de déploiement.
  1. Créer (s'il n'existe pas encore) un fichier jboss-all.xml dans le dossier app.ear/META-INFapp.ear est l'archive d'application qui dépend d'une autre archive d'application à déployer avant.
  2. Effectuer une saisie jboss-deployment-dependencies dans ce fichier comme indiqué ci-dessous. Notez que dans la liste ci-dessous, framework.ear est l'application de dépendance qui doit être déployée avant que l'archive d'application app.ear ne le soit.
    <jboss umlns="urn:jboss:1.0">
      <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
        <dependency name="framework.ear" />
      </jboss-deployment-dependencies>
    </jboss>

10.8. Remplacement du descripteur de déploiement

Une nouvelle fonctionnalité présente à partir de la version EAP 6.1 vous permet de remplacer des descripteurs de déploiement, des JAR, des classes, des pages JSP, et d'autres fichiers lors du temps d'exécution. Un deployment overlay représente un ensemble de règles de fichiers devant être remplacés dans les archives. Il fournit également des liens vers les nouveaux fichiers qui doivent être utilisés au lieu de ceux ayant été remplacés. Si le fichier remplacé n'est pas présent dans les archives de déploiement, il sera ajouté au déploiement.

Procédure 10.17. Remplacer le descripteur de déploiement en utilisant l'interface CLI

Les étapes suivantes partent du principe que vous possédez déjà une application déployée appelée app.war et que vous souhaitez remplacer son fichier WEB-INF/web.xml avec un autre fichier web.xml situé dans /home/user/web.xml.
  1. Ajouter une superposition de déploiement (deployment overlay) et y ajouter du contenu. Vous pouvez y parvenir de deux façons :
    • Utilisation d'une arborescence DMR

      1. /deployment-overlay=myoverlay:add
      2. /deployment-overlay=myoverlay/content=WEB-INF\/web.xml:add(content={url=file:///home/user/web.xml})
        Vous pouvez ajouter des règles de contenu supplémentaires en utilisant le deuxième code.
    • Utilisation des méthodes de facilité

      deployment-overlay add --name=myoverlay --content=WEB-INF/web.xml=/home/user/web.xml
  2. Relie la superposition à une archive de déploiement. Vous pouvez y parvenir de deux façons :
    • Utilisation d'une arborescence DMR

      /deployment-overlay=myoverlay/deployment=app.war:add
    • Utilisation des méthodes de facilité

      deployment-overlay link --name=myoverlay --deployments=app.war
      Pour spécifier plusieurs noms d'archives, séparez-les par des virgules.
    Veuillez noter que le nom d'archive de déploiement n'a pas besoin d'exister sur le serveur. Vous devez indiquer le nom, mais il ne sera pas encore lié à un déploiement.
  3. Redéploiement de l'application

    /deployment=app.war:redeploy

Chapitre 11. Configuration de sous-systèmes

11.1. Aperçu de la configuration du sous-système

Introduction

JBoss EAP 6 utilise une configuration simplifiée, avec un fichier de configuration par domaine ou par serveur autonome. En mode de domaine, un fichier distinct existe pour chaque contrôleur hôte également. Les modifications apportées à la configuration persistent automatiquement, donc le XML ne doit pas être édité manuellement. La configuration est scannée et automatiquement remplacée par l'API de gestion. La ligne de commande de l'interface CLI et la console de gestion basée-web permettent de configurer chaque aspect de JBoss EAP 6.

JBoss EAP 6 repose sur le concept de chargement de classes modulaire. Chaque API ou service fourni par la plateforme est implémenté comme un module, qui est chargé et déchargé à la demande. La plupart des modules incluent un élément configurable appelé un sous-système. Les informations de configuration du sous-système sont stockées dans le fichier de configuration unifiée EAP_HOME/domain/configuration/domain.xml pour un domaine géré ou EAP_HOME/standalone/configuration/standalone.xml pour un serveur autonome. La plupart des sous-systèmes incluent les détails de configuration configurés par l'intermédiaire de descripteurs de déploiements dans les versions précédentes de JBoss EAP.
Schémas de configuration du sous-système

Chaque configuration de sous-système est définie dans un schéma XML. Les schémas de configuration se trouvent dans le répertoire EAP_HOME/docs/schema/ de votre installation.

Les sous-systèmes suivants sont connus comme sous-systèmes simples, parce qu'ils n'ont pas d'attributs ou d'éléments configurables. Ils sont généralement répertoriés en haut du fichier de configuration.

Sous-systèmes simples

  • ee– l'implémentation Java EE 6 API
  • ejb– le sous-système d'Enterprise JavaBeans (EJB)
  • jaxrs– l'API JAX-RS API, fourni par RESTeasy.
  • sar– le sous-système qui supporte Service Archives.
  • threads– le sous-système qui supporte le traitement des threads.
  • weld– l'API Contexts and Dependency Injection, fourni par Weld.

Chapitre 12. Le sous-système de journalisation

12.1. Introduction

12.1.1. Logging (Journalisation)

JBoss EAP 6 fournit des fonctionnalités de journalisation hautement configurables pour son propre usage et pour utilisation par des applications déployées. Le sous-système d'enregistrement est basé sur JBoss LogManager et prend en charge plusieurs frameworks de journalisation d'applications de tierce partie en plus du JBoss Logging.
Le sous-système de journalisation est configuré à l'aide d'un système de catégories de journaux et de gestionnaires de journaux. Les catégories de journalisation définissent quels messages capturer et les gestionnaires de journaux définissent comment procéder avec ces messages (écriture sur disque, envoyer à la console, etc.).
Le profils de journalisation permettent à des configurations de journalisation possédant un nom unique d'être créées et assignées à des applications indépendamment de toute autre configuration de journalisation. La configuration des profils de journalisation est presque identique pour le sous-système de journalisation principal.

12.1.2. Frameworks de journalisations d'applications pris en charge par JBoss LogManager

JBoss LogManager prend en charge les frameworks de journalisation suivants :

12.1.3. Journalisation Bootup

JBoss EAP consigne les entrées du démarrage de l'environnement d'exécution Java et du démarrage de chaque service. Ce journal peut être utile pour les dépannages. Par défaut, toutes les entrées de journal sont écrites dans le fichier server.log, dont l'emplacement dépendra du mode d'exécution.
Mode autonome
EAP_HOME/standalone/log/server.log
Mode de domaine
EAP_HOME/domain/servers/SERVER_NAME/log/server.log
La configuration de la journalisation de Bootup est indiquée dans le fichier de configuration logging.properties, et son emplacement dépend du mode d'exécution.
Mode autonome
EAP_HOME/standalone/configuration/logging.properties
Mode de domaine
En mode de domaine, il y a un fichier logging.properties pour le contrôleur de domaine et pour chaque serveur.
Contrôleur de domaine : EAP_HOME/domain/configuration/logging.properties
Serveur : EAP_HOME/domain/servers/SERVER_NAME/data/logging.properties
Le fichier de configuration logging.properties est actif jusqu'à ce que le sous-système de journalisation démarre et prenne la relève.

Avertissement

Il est conseillé de ne pas éditer le fichier logging.properties directement, à moins que vous connaissiez un cas d'utilisation particulier qui le requiert. Avant de procéder, on vous conseille de soumetter un dossier de prise en charge.
Les modifications apportées au fichier logging.properties sont remplacées au démarrage.

12.1.4. Voir les erreurs de démarrage initial (bootup)

Quand on tente de résoudre des problèmes dans JBoss EAP, on doit commencer par vérifier les erreurs survenues au cours du démarrage. Il existe deux méthodes d'affichage des erreurs de démarrage, chacune avec ses avantages. Chaque méthode produit une liste de toutes les erreurs qui se sont produites au cours du démarrage. Utilisez les informations fournies pour diagnostiquer et résoudre leurs causes. Contact Support client de Red Hat pour l'assistance en cas de problème.
  • Examiner le fichier journal server.log.
    Cette méthode vous permet de voir chaque message d'erreur et les messages liés dans certains cas, ce qui vous permet d'obtenir plus d'informations sur la raison pour laquelle une erreur a pu avoir lieu. Cela vous permet également de voir les erreur en format brut.
  • À partir de JBoss EAP 6.4, utiliser la commande d'interface de commande read-boot-errors.
    Cette méthode ne nécessite pas d'accès au système de fichiers du serveur, ce qui est bien utile pour toute personne responsable de contrôler les erreurs et qui n'a pas d'accès au système de fichiers. Comme il s'agit d'une commande d'interface CLI, elle peut être utilisée dans un script. Par exemple, vous pouvez écrire un script qui démarre par des instances multiples de JBoss EAP, puis vérifier les erreurs qui ont lieu au démarrage.

Procédure 12.1. Examiner server.log pour chercher les erreurs

  1. Ouvrir le fichier server.log dans une visionneuse de fichiers.
  2. Déplacez-vous en fin de fichier.
  3. Rechercher l'identifiant du message JBAS015899 rétroactivement, qui indique le début de la dernière séquence de démarrage.
  4. Chercher les instances d'ERROR à partir de cet endroit dans le journal. Chaque instance devra inclure une description de d'erreur et la liste des modules concernés.

Exemple 12.1. Description de l'erreur de server.log

Ce qui suit est un exemple de description d'erreur du fichier journal server.log.
13:23:14,281 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) JBWEB003043: Error initializing endpoint: java.net.BindException: Address already in use /127.0.0.1:8080

Procédure 12.2. Lister les erreurs de démarrage par l'interface CLI

  • Exécuter la commande d'interface CLI suivante :
    /core-service=management:read-boot-errors
    Toute erreur qui a lieu lors du démarrage sera listée à cet endroit.
    L'heure de chaque erreur est définie par la méthode currentTimeMillis(), qui correspond à la différence, mesurée en millisecondes, entre l'heure actuelle et minuit le 1er janvier 1970 UTC.

Exemple 12.2. Sortie de la commande read-boot-errors

{
"outcome" => "success",
"result" => [{
    "failed-operation" => {
        "operation" => "add",
        "address" => [
            ("subsystem" => "web"),
            ("connector" => "http")
        ]
    },
    "failure-timestamp" => 1417560953245L,
    "failure-description" => "{\"JBAS014671: Failed services\" => {\"jboss.web.connector.http\" => \"org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed\"}}",
    "failed-services" => {"jboss.web.connector.http" => "org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed"}
}]
}

12.1.5. Journalisation de Garbage collection

La journalisation de Garbage collection consigne toutes les activités de collecte de la poubelle dans les fichiers journaux en texte clair. Ces fichiers journaux peuvent être utiles à des fins de diagnostique. À partir de JBoss EAP 6, la journalisation de la Garbage collection est activée par défaut en mode standalone (autonome) sur toutes les configurations prises en charge sauf JDK d'IBM.
La journalisation correspond à la sortie du fichier $EAP_HOME/standalone/log/gc.log.digit. La rotation de la journalisation est activée, avec un nombre de fichiers de journalisation ne devant pas dépasser cinq, et une taille de trois MiB maximum par fichier.

12.1.6. Dépendances d'API de journalisation implicites

Le sous-système de journalisation de JBoss EAP 6 possède un attribut add-logging-api-dependencies qui contrôle la possibilité pour le conteneur d'ajouter des dépendances d'API de journalisation implicites aux déploiements. Par défaut, cet attribut est défini à true, ce qui signifie que toutes les dépendances d'API de journalisation implicites doivent être ajoutées aux déploiements. Si défini sur false, les dépendances d'API de journalisation se seront pas ajoutées.
L'attribut add-logging-api-dependencies peut être configuré par l'interface CLI. Par exemple :
/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)

12.1.7. Emplacements de fichiers de journalisation par défaut

Il s'agit des fichiers de journalisation qui ont été créés pour les configurations de journalisation par défaut. La configuration par défaut écrit des fichiers de journalisation du serveur à l'aide de gestionnaires de journaux périodiques.

Tableau 12.1. Fichier de journalisation par défaut d'un serveur autonome

Fichier journal Description
EAP_HOME/standalone/log/server.log
Journal du serveur. Contient les messages de journalisation de serveur, dont les messages de démarrage de serveur.
EAP_HOME/standalone/log/gc.log
Journalisation de Garbage collection. Contient des informations sur tous les nettoyages de mémoire.

Tableau 12.2. Fichiers de journalisation par défaut d'un domaine géré

Fichier journal Description
EAP_HOME/domain/log/host-controller.log
Journal d'amorçage du contrôleur hôte. Contient les messages de journalisation liés au démarrage du contrôleur hôte.
EAP_HOME/domain/log/process-controller.log
Journal d'amorçage du contrôleur de processus. Contient les messages de journalisation liés au démarrage du contrôleur de processus.
EAP_HOME/domain/servers/SERVERNAME/log/server.log
Le journal du serveur pour le serveur nommé. Contient les messages de journalisation de ce serveur, dont les messages de démarrage de serveur.

12.1.8. Filtre les expressions de journalisation

Les expressions de filtrage sont utilisées pour enregistrer les messages de journalisation sur la base d'un certain nombre de critères. Le contrôle de filtrage est toujours effectué sur un message brut non formaté. Vous pouvez inclure un filtre de logger ou de gestionnaire, mais le filtre du logger aura la priorité sur le filtre du gestionnaire.

Note

Un filter-spec spécifié pour le root logger n'est pas hérité par les autres loggers. Au lieu de cela, un filter-spec devra être spécifié pour chaque gestionnaire.

Tableau 12.3. Filtre les expressions de journalisation

Type de filtre
expression
Description Paramètres
Accepter
accept
Accepter tous les messages de journalisation
accept
Refuser
deny
Refuser tous les messages de journalisation
deny
Not
not[filter expression]
Renvoie la valeur inversée de l'expression du filtre
Prend une expression de filtre unique comme paramètre
not(match("JBAS"))
Tout
all[filter expression]
Renvoie la valeur concaténée à partir de multiples expressions de filtre.
Prends plusieurs expressions de filtre séparées par des virgules
all(match("JBAS"),match("WELD"))
Tous
any[filter expression]
Renvoie une valeur à partir de multiples expressions de filtre.
Prends plusieurs expressions de filtre séparées par des virgules
any(match("JBAS"),match("WELD"))
Changement de niveau
levelChange[level]
Modifie l'enregistrement de journalisation avec le niveau indiqué
Prend un niveau basé chaîne unique comme argument
levelChange("WARN")
Niveaux
levels[levels]
Filtre les messages de journalisation avec un niveau apparaissant sur la liste des niveaux
Prend plusieurs niveaux basés chaînes séparées par des virgules en tant qu'arguments
levels("DEBUG","INFO","WARN","ERROR")
Gamme de niveaux
levelRange[minLevel,maxLevel]
Filtre les messages de journalisation dans la gamme de niveaux spécifiée.
L'expression de filtre utilise [ pour indiquer un niveau inclusif minimum et ] pour indiquer un niveau inclusif maximum. Sinon, vous pouvez utiliser ( ou ) respectivement pour indiquer une exclusivité. Le premier argument de l'expression est le niveau minimum autorisé, le deuxième argument est le niveau maximum autorisé.
Voici des exemples ci-dessous.
  • levelRange("DEBUG","ERROR")
    Le niveau minimum doit être supérieur à DEBUG et le niveau maximum doit être inférieur à ERROR.
  • levelRange["DEBUG","ERROR")
    Le niveau minimum doit être supérieur ou égal à DEBUG et le niveau maximum doit être inférieur à ERROR.
  • levelRange["INFO","ERROR"]
    Le niveau minimum doit être supérieur ou égal à INFO et le niveau maximum doit être inférieur ou égal à ERROR.
Match (match["pattern"]) Filtre basé sur une expression régulière. Le message non formaté est utilisé à l'encontre du modèle spécifié dans l'expression.
Prend une expression régulière comme argument
match("JBAS\d+")
Substitute (substitute["pattern","replacement value"]) Filtre qui remplace la première correspondance au modèle par une valeur de remplacement
Le premier argument de l'expression est le modèle, le deuxième est le texte de remplacement.
substitute("JBAS","EAP")
Remplacer tout (substituteAll["pattern","replacement value"]) Un filtre qui remplace toutes les correspondances du modèle avec la valeur de remplacement.
Le premier argument de l'expression est le modèle, le deuxième est le texte de remplacement.
substituteAll("JBAS","EAP")

12.1.9. Niveaux de journalisation

Les niveaux de journalisation sont des ensembles ordonnés de valeurs énumérées qui indiquent la nature et la sévérité d'un message de journalisation. Le niveau d'un message de journalisation donné est indiqué par le développeur par des méthodes qui conviennent dans un framework de journalisation particulier pour envoyer le message.
JBoss EAP 6 accepte tous les niveaux de journalisation utilisés par les frameworks de journalisation de l'application prise en charge. Les six niveaux de journalisation les plus utilisés sont (dans l'ordre croissant) : TRACE, DEBOG, INFO, ATTENTION, ERREUR et FATAL.
Les niveaux de journalisation sont utilisés par des catégories et des gestionnaires de journalisation pour limiter les messages dont ils sont responsables. Chaque niveau de journalisation possède une valeur numérique qui indique son ordre par rapport à d'autres niveaux de journalisation. Les catégories et gestionnaires de journalisation correspondent à un certain niveau de journalisation, et ils traitent les messages de journalisation du même niveau ou d'un niveau supérieur uniquement. Par exemple, un gestionnaire de journalisation du niveau ATTENTION enregistrera uniquement les messages des niveaux ATTENTION, ERREUR et FATAL.

12.1.10. Niveaux de journalisation pris en charge

Tableau 12.4. Niveaux de journalisation pris en charge

Niveau de journalisation Valeur Description
FINESSE MAX 300
-
PLUS FIN 400
-
TRACE 400
Utilisé pour des messages qui fournissent des informations détaillées sur l'état d'exécution d'une application. Les messages de journalisation TRACE sont habituellement capturés uniquement lors du débogage d'une application.
DEBOG 500
Utilisé pour des messages qui indiquent des demandes individuelles de progrès ou des activités d'une application. Les messages de journalisation DEBUG ne sont habituellement capturés que lors du débogage d'une application.
FINESSE 500
-
CONFIG 700
-
INFO 800
Utilisé pour des messages qui indiquent la progression globale de l'application. Souvent utilisé pour le démarrage de l'application, la fermeture et autres événements majeurs de cycle de vie.
AVERTISSEMENT 900
Utilisé pour indiquer une situation qui n'est pas en erreur, mais n'est pas considérée comme idéale. Peut indiquer des circonstances qui peuvent entraîner des erreurs dans le futur.
ATTENTION 900
-
ERREUR 1000
Utiliser pour indiquer une erreur qui s'est produite et qui puisse empêcher l'activité actuelle ou la demande de se remplir, mais qui n'empêchera pas l'application d'exécuter.
SÉVÈRE 1000
-
FATALE 1100
Utiliser pour indiquer les événements qui pourraient entraîner des défaillances de services critiques ou la fermeture de l'application, ou qui pourraient entraîner la fermeture de la plateforme JBoss EAP 6.

12.1.11. Catégories de journalisation

Les catégories de journalisation définissent les messages de journalisation à acquérir et un ou plusieurs gestionnaires de journalisation qui traitent les messages.
Les messages de journalisation à capturer sont définis par leur package Java d'origine et leur niveau de journalisation. Les messages de classes de ce package et de niveau de journalisation ou niveau inférieur sont capturés par la catégorie de journalisation et envoyés aux gestionnaires de journal spécifiés.
Les catégories ont la possibilité d'utiliser les gestionnaires de journalisation du root logger au lieu de leurs propres gestionnaires.

12.1.12. Root Logger

Le root logger capture tous les messages de journalisation qui sont envoyés au serveur (à un niveau indiqué) et qui ne sont pas capturés par une catégorie de journalisation particulière. Ces messages sont alors envoyés à un ou à plusieurs gestionnaires de journalisation.
Par défaut, le root logger est configuré pour utiliser une console et un gestionnaire de journalisation périodique. Le gestionnaire de journalisation périodique est configuré pour écrire sur le ficher server.log. On prénomme parfois ce fichier : journal du serveur (server log).

12.1.13. Gestionnaires de journaux

Les gestionnaires de journaux définissent la façon dont les messages de journalisation sont enregistrés dans JBoss EAP. Voici la liste des gestionnaires de journalisation : Console, File, Periodic, Size, Async, syslog, Periodic Size et Custom.

Note

Un gestionnaire de journaux doit être ajouté à un logger au moins pour être actif.

12.1.14. Types de gestionnaires de journalisation

Console
Les gestionnaires de journaux de console écrivent des messages de journalisation soit dans le système d'exploitation hôte (stdout) ou dans le flux d'erreurs standard (stderr). Ces messages sont affichés lorsque JBoss EAP 6 est exécuté à partir d'une invite de ligne de commande. Les messages d'un gestionnaire de journal de Console ne sont pas enregistrés à moins que le système d'exploitation ne soit spécifiquement configuré pour capturer stdout ou stderr.
Fichier
Les gestionnaires de journaux de fichiers inscrivent des messages de journalisation dans un fichier spécifique.
Périodique
Les gestionnaires de journaux périodiques écrivent des messages de journalisation dans un fichier nommé jusqu'à ce qu'une certaine durée se soit écoulée. Une fois que cette période a expiré, le fichier est nommé à nouveau en rajoutant l'horodatage et le gestionnaire continue d'écrire dans un fichier de journalisation nouvellement créé avec le nom d'origine.
Taille
Les gestionnaires de journaux de Taille écrivent les messages de journalisation dans un fichier jusqu'à ce que le fichier atteigne une taille spécifiée. Lorsque le fichier atteint une taille donnée, il est renommé avec un suffixe numérique et le gestionnaire continue d'écrire dans un fichier journal récemment créé avec le nom d'origine. Chaque gestionnaire de journaux de Taille doit spécifier le nombre maximal de fichiers contenus de cette façon.
Taille périodique
Disponible à partir de JBoss EAP 6.4. Correspond à une combinaison de gestionnaires Périodiques et de Taille, et prend en charge leurs attributs combinés.
Une fois que le fichier de journalisation a attteint une taille donnée, ou que la période donné a expiré, le fichier est nommé à nouveau en rajoutant l'horodatage et le gestionnaire continue d'écrire dans un fichier de journalisation nouvellement créé avec le nom d'origine.
Async
Les gestionnaires de journaux async sont des gestionnaires de journaux wrapper qui fournissent un comportement asynchrone pour un ou plusieurs autres gestionnaires de journaux. Ils sont utiles pour les gestionnaires de journaux qui pourraient avoir une latence élevée ou autres problèmes de performances comme l'écriture d'un fichier journal à un système de fichiers réseau.
Personnalisé
Les gestionnaires d'informations personnalisées vous permettent de configurer de nouveaux types de gestionnaires de journaux mis en place. Un gestionnaire personnalisé doit être implémenté comme classe Java qui s'étend java.util.logging.Handler et doit être contenu dans un module.
syslog
Les gestionnaires de syslog peuvent être utilisés pour envoyer des messages à un serveur de journalisation à distance. Cela permet à plusieurs applications d'envoyer leurs messages de journalisation au même serveur, où ils peuvent être analysés en même temps.

12.1.15. Log Formatters

Un formateur de journalisation (log formatter) est une propriété de configuration d'un gestionnaire de journalisation qui détermine l'apparence des messages de journalisation. Il s'agit d'un string qui utilise une syntaxe basée sur la classe java.util.Formatter.
Ainsi, le string du formateur de journalisation de la configuration par défaut, %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n, crée des messages de journalisation qui ressemblent à ceci :
15:53:26,546 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990

12.1.16. Syntaxe de Formateur de journaux

Tableau 12.5. Syntaxe de Formateur de journaux

Symbole Description
%c La catégorie de l'événement de journalisation
%p Le niveau de saisie de la journalisation (info/déboggage/etc)
%P Le niveau localisé de la saisie de journalisation
%d Les date/heure (yyyy-MM-dd HH:mm:ss,SSS form)
%r L'heure relative (en millisecondes depuis l'initialisation de la journalisation)
%z Le réseau horaire
%k Une clé de ressource de journalisation (utilisée pour la localisation de messages de journalisation)
%m Le message de journalisation (avec trace d'exception)
%s Le simple message de journalisation (sans trace d'exception)
%e Suivi de la pile d'exceptions (sans informations sur les modules étendus)
%E Suivi de la pile d'exceptions (avec informations sur les modules étendus)
%t Le nom du thread en cours
%n Un caractère de nouvelle ligne
%C La classe du code appelant la méthode de journalisation (lente)
%F Le nom de fichier de la classe appelant la méthode de journalisation (lente)
%l L'emplacement d'origine du code appelant la méthode de journalisation (lente)
%L Le numéro de ligne du code appelant la méthode de journalisation (lente)
%M La méthode du code appelant la méthode de journalisation (lente)
%x Contexte de diagnostique intégré
%X Contexte de diagnostique du message
%% Un pourcentage (caractère d'échappement)

12.2. Configurer la journalisation par la console de gestion

La console de gestion fournit une interface graphique utilisateur pour la configuration du root logger, des log handlers et des catégories de journalisation. Voir Section 3.4.1, « Console de management » pour obtenir plus d'informations sur la console de gestion.
Vous pourrez accéder à cette configuration en suivant les étapes suivantes :
  1. Se connecter à la console de gestion
  2. Naviguer dans la configuration du sous-système de logging. Cette étape varie suivant qu'il s'agisse de serveurs qui s'exécutent sur les serveurs autonomes ou des serveurs exécutant dans un domaine géré.
    • Serveur autonome

      Cliquer sur Configuration, étendre Core dans le menu Subsystems, et cliquer sur Logging.
    • Domaine géré

      Cliquer sur Configuration, sélectionner le profil que vous souhaitez modifier dans le menu déroulant. Étendre Core dans le menu Subsystems, et cliquer sur Logging.
Les tâches à effectuer pour configurer le root logger sont les suivantes :
  • Modifier le niveau de journalisation.
  • Ajouter et supprimer des log handlers.
Les tâches à effectuer pour configurer les catégories de journalisation sont les suivantes :
  • Ajouter et supprimer les catégories de journalisation.
  • Modifier les propriétés de catégories.
  • Ajouter et supprimer les log handlers d'une catégorie.
Les tâches principales à effectuer pour configurer les log handlers sont les suivantes :
  • Ajouter de nouveaux handlers.
  • Configurer les handlers.
Tous les log handlers pris en charge (y compris le handler personnalisé) peuvent être configurés dans la console de gestion.

12.3. Configuration de logging dans le CLI

Conditions préalables

L'interface CLI doit exécuter et est connectée à l'instance JBoss EAP qui convient. Pour plus d'informations, voir Section 3.5.2, « Lancement de l'interface CLI »

12.3.1. Configurer le root logger par le CLI

La configuration du Root Logger peut s'afficher ou être modifiée par l'interface CLI.
Les tâches principales à effectuer pour configurer le root logger sont les suivantes :
  • Ajouter des log handler au root logger.
  • Afficher la configuration du root logger.
  • Modifier le niveau de journalisation.
  • Supprimer des log handler du root logger.

Important

Pour la configuration du Root Logger dans un profil de journalisation de système autonome, la racine (root) du chemin de configuration est /subsystem=logging/logging-profile=NAME/ au lieu de /subsystem=logging/.
Dans un domaine géré, vous devez spécifier quel profil utiliser. Vous devez ajouter le nom de profil en début de chemin de configuration pour un domaine géré, et remplacer /subsystem=logging/ par /profile=NAME/subsystem=logging/.
Ajouter un log handler au root logger
Utiliser l'opération add-handler avec la syntaxe suivante HANDLER dans le nom du gestionnaire de journalisation (Log Hangler) à ajouter.
/subsystem=logging/root-logger=ROOT:add-handler(name="HANDLER")
Le log handler doit déjà avoir été créé avant de l'ajouter au root handler.

Exemple 12.3. Opération root logger add-handler

[standalone@localhost:9999 /] /subsystem=logging/root-logger=ROOT:add-handler(name="FILE")
{"outcome" => "success"}
Afficher le contenu de la configuration du root logger
Utiliser l'opération read-resource avec la syntaxe suivante.
/subsystem=logging/root-logger=ROOT:read-resource

Exemple 12.4. Opération root logger «read-resource»

[standalone@localhost:9999 /] /subsystem=logging/root-logger=ROOT:read-resource                                  
{
   "outcome" => "success",
   "result" => {
        "filter" => undefined,
        "filter-spec" => undefined,
        "handlers" => [
            "CONSOLE",
            "FILE"
      ],
      "level" => "INFO"
   }
}
Définir le niveau de j