Menu Close

Guide d'administration et de configuration

JBoss Enterprise Application Platform 6.2

À utiliser dans Red Hat JBoss Enterprise Application Platform 6

Sande Gilda

David Le Sage

Red Hat Engineering Content Services

Darrin Mison

David Ryan

Misty Stanley-Jones

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 (JBoss EAP 6)

Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6) est une plate-forme middleware rapide, sécurisée et puissante construite sur des standards ouverts et compatibles avec Java Enterprise Edition 6. Elle intègre JBoss Application Server 7 avec un clustering de haute disponibilité, une puissante messagerie, une mise en cache distribuée et autres technologies pour créer une plate-forme stable et évolutive.
La nouvelle structure modulaire permet que les services soient mis en place uniquement en fonction des besoins, ce qui augmente la vitesse de démarrage de façon importante. La console de gestion et l'interface de ligne de commande de gestion suppriment le besoin de modifier les fichiers de configuration XML manuellement, et rajoute la possibilité de script et d'automatisation des tâches. En outre, elle comprend des API et des frameworks de développement, que vous pouvez utiliser pour développer des applications Java EE puissantes, sécurisées et évolutives rapidement.

1.2. Les fonctionnalités de JBoss EAP 6

Tableau 1.1. Fonctionnalités 6.1.0

Fonctionnalité Description
Certification Java Implémentation certifiée des spécifications de JBoss Enterprise Application Platform 6 Full Profil et Web Profile.
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.
  • Les configurations, déploiements, liaisons de socket, modules, extensions et propriétés système sont gérées par le groupe de serveurs.
  • La sécurité des applications, qui comprend les domaines de sécurité, est gérée centralement pour une configuration simplifiée.
Console de gestion et Management CLI Il y a de nouvelles interfaces pour gérer le domaine ou serveur autonome. Il n'est nul besoin de modifier les fichiers de configuration XML à la main. Le Management CLI offre également un mode lot, ce qui signifie que vous pourrez scripter 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'application, au lieu d'utiliser les répertoires communs et spécifiques au serveur lib/. Les répertoires domain/ et standalone/ contiennent les artefacts et les fichiers de configuration pour le domaine et pour les déploiements autonomes.
Mécanisme de chargement de classes modulaire Les modules sont chargés et déchargés à la demande pour plus de performance et de sécurité et des démarrages et redémarrages plus rapides.
Gestion de 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 le Management CLI.
Temps de démarrage et d'arrêt optimisés JBoss EAP 6 utilise moins de ressources et est extrêmement efficace au niveau de l'utilisation des ressources. Surtout utile aux développeurs.

1.3. JBoss EAP 6 Operating Modes

JBoss EAP offre deux modes de fonctionnement des instances de JBoss EAP. Il peut soit être démarré dans un serveur autonome, ou dans un domaine géré. Chaque mode est conçu en fonction des différents scénarios. Il permet de choisir entre une installation sur serveur unique ou gestion multi-serveurs coordonnée à effet de levier des besoins de votre entreprise et pour automatiser les processus et faciliter la gestion.
Le choix entre un domaine géré et des serveurs autonomes dépend de la façon dont vos serveurs sont gérés et non pas par rapport aux capacités de réponse aux demandes de l'utilisateur final. Cette distinction est particulièrement importante lorsqu'il s'agit de clusters de haute disponibilité (High Availability ou HA). Il est important de comprendre que la fonctionnalité HA est orthogonale à des serveurs autonomes en cours d'exécution ou d'un domaine géré. Autrement dit, un groupe de serveurs autonomes peut être configuré pour former un cluster HA.

1.4. Les serveurs autonomes

Un serveur autonome correspond à l'un des deux modes opérationnels de JBoss EAP 6. 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

Un serveur autonome correspond à l'un des deux modes opérationnels d'une instance de JBoss EAP 6. Il s'agit d'un mode qui permet de gérer plusieurs instances de JBoss EAP 6 à partir d'un seul point de contrôle.
Une collection de serveurs gérés centralement est considérée comme membre d'un domaine. Toutes les instances de JBoss EAP 6 du domaine partagent la même politique de gestion. Un domaine consiste en un Contrôleur de domaine, une ou plusieurs Contrôleur(s) hôte(s), et aucun ou plusieurs groupes de serveur par hôte.
Un contrôleur de domaine est le point de départ à partir duquel le domaine est contrôlé. Il garantit que chaque serveur soit configuré selon la politique de gestion du domaine. Le contrôleur de 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 est exécuté. Contrairement au contrôleur de domaine, les contrôleurs hôtes sont configurés pour lui déléguer des tâches de gestion de domaine. Le contrôleur hôte de chaque hôte interagit avec le contrôleur de domaine pour vérifier le cycle de vie des instances du serveur d'application exécutées 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 sur lequel JBoss EAP 6 est installé et étant configurées comme une seule et même entité. Etant donné que le contrôleur de domaine gère la configuration et les applications déployées sur les groupes de serveurs, chaque serveur de groupe de serveurs partage la même configuration et les mêmes 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 ne rentrent en conflit.
Un domaine géré avec un contrôleur de domaine, trois contrôleurs d'hôte et trois groupes de serveurs. Les serveurs sont membres de groupes de serveurs et peuvent être situés sur l'un des contrôleurs hôte du domaine.

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 d'hôte est configurée pour agir en tant que contrôleur de domaine. Les responsabilités principales d'un contrôleur de gestion sont :
  • maintenir la politique centrale de gestion du domaine
  • s'assurer que tous les contrôleurs soient mis au courant de leurs contenus actuels
  • assister tous les contrôleurs pour que toutes les instances en cours de JBoss EAP 6 soient configurées suivant cette politique
La politique de gestion centrale est stockée par défaut dans le fichier domain/configuration/domain.xml, dans le fichier d'installation JBoss EAP 6 non compressé, sur le système de fichiers de l'hôte du contrôleur de domaines.
On doit pouvoir trouver un fichier de domain.xml dans le répertoire de domain/configuration/ du contrôleur hôte qui est destiné à être exécuté comme contrôleur de domaine. Ce fichier n'est pas obligatoire pour les installations sur les contrôleurs hôtes non destinés à être conçus comme contrôleur de domaine. Cependant, la présence d'un fichier domain.xml sur un tel serveur ne nuit pas. Le fichier domain.xml contient la configuration des divers profils qui peuvent être configurés pour exécuter sur les instances de serveur d'un domaine. Une configuration de profil inclut la configuration détaillée des différents sous-systèmes qui composent un profil. La configuration de domaine inclut également la définition des groupes de sockets et la définition des groupes de serveurs.

1.7. Échecs de Contrôleurs de domaines

Si un Contrôleur de domaines échoue pour une raison quelconque, vous pourrez configurer et promouvoir des Contrôleurs de domaines d'hôtes pour qu'ils se substituent à des contrôleurs de domaines.

1.8. Contrôleur hôte

Un contrôleur hôte est lancé lorsque le script domain.sh ou domain.bat script est exécuté sur un hôte. La responsabilité primaire d'un contrôleur hôte est la gestion de serveur. Il délègue des tâches de gestion de domaine et est responsable de lancer et d'arrêter les processus de serveurs d'applications individuels qui s'exécutent sur son hôte. Il interagit avec le contrôleur de domaines pour gérer la communication entre les serveurs et le contrôleur de domaines. Plusieurs contrôleurs hôte 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 peuvent avoir 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 :
  • Énumère 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 hôte contacte le contrôleur de domaines pour s'enregistrer 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 d'hôtes doit se persuader lui-même d'agir en tant que contrôleur de domaines
  • Configuration d'éléments 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 spécifique à 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 d'host.xml.

1.9. Les groupes de serveurs

Un groupe de serveurs est une collection d'instances de serveur qui sont gérées et configurées ensemble. Dans un domaine géré, chaque instance de serveur d'applications appartient à un groupe de serveurs, même si c'est le seul membre. Les instances de serveur d'un groupe partagent la même configuration de profil et de déploiement de leur contenu. Les contrôleurs de domaines et les contrôleurs hôtes appliquent la configuration standard sur toutes les instances de serveurs de chaque groupe de serveur dans son domaine. Un domaine peut se composer de plusieurs groupes de serveurs. Différents groupes de serveurs peuvent être configurés avec différents profils et déploiements, par exemple dans un domaine avec différents niveaux de serveurs offrant différents services. Différents groupes de serveurs peuvent également avoir le même profil et les déploiements, comme par exemple, pour supporter les scénarios de mise à jour d'applications qui s'enchaînent, quand une interruption totale du service est évitée grâce à la mise à niveau préalable de l'application sur un groupe de serveurs, suivie d'une mise à niveau d'un deuxième groupe de serveurs.
Voici un exemple de 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
Un groupe de serveurs inclut les attributs optionnels suivants :
  • 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 à la fois dans host.xml. Si le nom socket-binding-group n'est pas fourni dans l'élément server-group, il doit être donné pour chaque serveur dans le fichier host.xml.
  • 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 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 à utiliser dans la JVM du serveur.

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 simple 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. Quand le déploiement est retiré, 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 supprimer le déploiement de 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. Démarrer et stopper JBoss EAP 6

2.1.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.1.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 d'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.1.4. Démarrez 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.

Prérequis

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

Procédure 2.3. 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.1.5. 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, faire cesser une instance qui a été démarrée par un service et faire cesser une instance qui a été mise en arrière-plan par un script.

Note

Cette tâche ne règle pas l'arrêt d'un serveur ou d'un groupe de serveurs dans un Domaine géré. Pour ces scénarios, voir Section 2.2.3, « Stopper un serveur qui utilise une Console de gestion ».

Procédure 2.4. Stopper une instance autonome de JBoss EAP 6

  1. 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.
  2. 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.
  3. Stopper une instance qui exécute en arrière-plan (Red Hat Enterprise Linux)

    1. Cherchez l'instance dans la liste de processus. Une option consiste à exécuter la commande ps aux |grep "[j]ava -server". Cela renverra un résultat pour chaque instance de JBoss EAP 6 en cours d'exécution sur la machine locale.
    2. Envoyer au processus le signalTERM, en exécutant kill process_ID, avec process_ID comme numéro de deuxième champ de la commande ps aux 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.1.6. 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 permettent 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érent ou une configuration secondaire. Vous pourrez accéder à une liste des paramètres disponibles en passant la variable d'assistance au démarrage.

Exemple 2.5. 

L'exemple suivant ressemble au démarrage de serveur expliqué dans Section 2.1.2, « Démarrez JBoss EAP 6 comme un serveur autonome », avec les variables -h ou --help en plus. Les résultats de cette variable d'assistance sont expliqués dans le tableau ci-dessous.
[localhost bin]$ standalone.sh -h

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

Argument ou Variable Description
--admin-only 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.
-b=<value> Définir la propriété système jboss.bind.address à la valeur donnée.
-b <value> Définir la propriété système jboss.bind.address à la valeur donnée.
-b<interface>=<value> Définir la propriété système jboss.bind.address.<interface> à la valeur donnée.
-c=<config> Nommer le fichier de configuration du serveur à utiliser. La valeur par défaut est standalone.xml.
-c <config> Nommer le fichier de configuration du serveur à utiliser. La valeur par défaut est standalone.xml.
--debug [<port>] Activer 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>] Définir une propriété système.
-h Afficher le message d'assistance et sortir.
--help Afficher le message d'assistance et sortir.
--read-only-server-config=<config> 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é.
-P=<url> Télécharger les propriétés système de l'URL donné.
-P <url> Télécharger les propriétés système de l'URL donné.
--properties=<url> Télécharger les propriétés système de l'URL donné.
-S<name>[=<value>] Définir une propriété de sécurité.
--server-config=<config> Nommer le fichier de configuration du serveur à utiliser. La valeur par défaut est standalone.xml.
-u=<value> Définir la propriété système jboss.default.multicast.address à la valeur donnée.
-u <value> Définir la propriété système jboss.default.multicast.address à la valeur donnée.
-V Afficher la version du serveur d'application et sortir.
-v Afficher la version du serveur d'application et sortir.
--version Afficher la version du serveur d'application et sortir.

2.2. Démarrer et arrêter les serveurs

2.2.1. Démarrer et arrêter les serveurs par le Management CLI

Vous pouvez démarrer et arrêter les serveurs avec le Management CLI ou par la Console de gestion. 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, veuillez consulter Section 2.2.2, « Démarrer un serveur par la Console de gestion » pour obtenir des instructions. Si vous utilisez le Management CLI, le processus varie entre des instances de serveur autonome et de domaine géré.
Démarrer et arrêter un serveur autonome par le Management CLI

Vous pouvez démarrer une instance de serveur autonome par les scripts de ligne de commande, et le fermer par le Management 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.1.2, « Démarrez JBoss EAP 6 comme un serveur autonome ».

Exemple 2.6. Démarrer et arrêter une instance de serveur autonome par le Management CLI

[standalone@localhost:9999 /] shutdown
Démarrer et arrêter un domaine géré par le Management 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é via un Management CLI

Semblable à une instance de Serveur Autonome, la commande shutdown est utilisée pour fermer un hôte de Domaine Géré déclaré. Cette 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é via un Management 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 groupe de serveur disponible.
[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é via un Management 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.2.2. Démarrer un serveur par la Console de gestion

Procédure 2.5. Démarrer le serveur

  1. Naviguer dans Server Instances dans la Console de gestion

    1. Sélectionner l'onglet Runtime en haut de la console.
  2. Sélectionner un serveur

    À 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.
    En plaçant le curseur sur une instance de cette liste, vous verrez vos options en bleu sous Détails du serveur.
  3. Cliquer sur le bouton Start

    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.2.3. Stopper un serveur qui utilise une Console de gestion

Procédure 2.6. Stopper un serveur qui utilise une Console de gestion

  1. Naviguez dans Hôtes, groupes et instances de serveur dans la Console de gestion

    1. Sélectionner l'onglet Runtime en haut de la console. Les instances de serveur disponibles seront affichées sur le tableau général de l'onglet Topologie.
  2. Sélectionner un serveur

    À partir de la liste Server Instances, sélectionner le serveur que vous souhaitez stopper. Les serveurs qui sont en cours d'exécution sont indiqués.
  3. Cliquer sur le texte Stop Server.

    Cliquer sur le texte Stop Server qui apparaît quand vous bougez la souris sur l'entrée serveur. Une boîte de dialogue de confirmation apparaîtra.
  4. Cliquer sur le bouton Confirm pour arrêter le serveur.
Résultat

Le serveur sélectionné est stoppé.

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

2.3.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
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 fichier 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 de journalisation.
jboss.server.temp.dir Le répertoire que le serveur va utiliser pour le stockage de fichier temporaires.
jboss.controller.temp.dir Le répertoire que le contrôleur hôte va utiliser pour le stockage de fichier temporaires.
Les utilisateurs peuvent ajouter leurs propres chemins d'accès ou bien les remplacer tous sauf les cinq premiers en ajoutant l'élément path dans leur fichier de configuration. L'exemple suivant indique la nouvelle déclaration de chemin relatif qui se rapporte au répertoire root de l'instance du serveur individuel.

Exemple 2.11. Format d'un chemin relatif

<path name="examplename" path="example/path" relative-to="jboss.server.data.dir"/>

La structure de la déclaration du chemin utilise les attributs suivants.

Tableau 2.3. Attributs de chemin d'accès

Attribut Description
name Le nom du chemin d'accès.
path Le chemin d'accès du système de fichier. Considéré comme chemin absolu, à moins que l'attribut relative-to ne soit spécifié, dans lequel cas, la valeur sera traitée comme étant relative à ce chemin.
relative-to Un attribut optionnel qui indique le nom d'un autre nom ancienement nommé, ou bien qui correspond à un chemin standard défini par le système.
Un élément path (chemin) d'un fichier de configuration domain.xml ne requiert que le nom de l'attribut. Il n'a pas besoin d'inclure des informations sur le chemin du système de fichiers, comme le montre l'exemple suivant.

Exemple 2.12. Exemple de chemin de domaine

<path name="example"/>

Cette configuration déclare simplement qu'il existe un chemin exemple nommée exemple auquel les autres parties de la configuration du domain.xml peuvent faire référence. L'emplacement du système de fichiers courant déclaré par l'exemple est spécifique aux fichiers de configuration host.xml respectifs des instances de l'hôte qui se joignent aux groupes de domaine. Si cette approche est utilisée, il doit y avoir un élément de chemin dans l'host.xml de chaque machine, qui indique le chemin du système de fichier.

Exemple 2.13. Exemple de chemin d'hôte

<path name="example" path="path/to/example" />

Un élément path d'un fichier standalone.xml doit inclure la spécification du chemin d'accès du système de fichier.

2.4. Historique du fichier de configuration

2.4.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.4. Emplacements de 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écrits 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.4.2. 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 Management 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 rollback. 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.4.3. 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.
  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/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.

2.4.4. Sauvegarder un snapshot de configuration par le Management 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.7. 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.4.5. Charger un Snapshot de Configuration avec le Management 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.4.3, « Démarrer le serveur par une ancienne configuration », à partir de la ligne de commande et non pas l'interface Management 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.8. 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.4.6. Supprimer un snapshot de configuration par le Management 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.9. 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.10. 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.4.7. Lister tous les snapshots de configuration par le Management 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.11. 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 l'interface de commande CLI (Management Command Line Interface), 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, étant à la fois 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 Management 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

La Console de gestion est un exemple d'interface web construite avec Google Web Toolkit (GWT). La Console de gestion communique avec le serveur à l'aide de l'interface de gestion HTTP. Le point de terminaison HTTP API est le point d'entrée pour les clients de gestion basés sur le protocole HTTP, pour s'intégrer à la couche de gestion. Il utilise un protocole JSON encodé et un API de style RPC de-typed, pour décrire et exécuter des opérations de gestion en fonction d'un domaine géré ou d'un serveur autonome. L'API HTTP 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é soit avec le contrôleur de domaine ou une instance de serveur autonome. Le point de terminaison HTTP API sert deux contextes différents ; un pour l'exécution des opérations de gestion et un 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 entre la Console de gestion accessible comme localhost par défaut, la Console de gestion accessible à distance par un hôte spécifique et une combinaison de port, et l'API du domaine exposé.

Tableau 3.1. Les URL d'accès à la Console de gestion

URL Description
http://localhost:9990/console Le Console de gestion accédée par l'hôte local, 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 Le HTTP Management API 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 Management CLI 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 Management 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 le Management 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 Management 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 le Management CLI.

3.4. La console de gestion

3.4.1. Console de gestion

La Console de management est un outil administratif basé web pour la plateforme JBoss EAP.
Utilisez la Console de gestion 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 gestion 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 conncecter à la console de gestion

Prérequis

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

Procédure 3.1. Se conncecter à la console de gestion

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

    Naviguer vers la console de gestion. L'emplacement par défaut est http://localhost:9990/console/, où le port 9990 est prédéfini comme liaison de socket de console de gestion.
  2. Se conncecter à la console de gestion

    Saisir le nom d'utilisateur et le mot de passe du compte que vous avez déjà créé pour vous connecter à l'écran de connexion de la console de gestion.
    L'écran de connexion de la console de gestion.

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

Résultat

Une fois connecté, une des pages de la console de gestion apparaîtra :
Domaine géré
Serveur autonome

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.2. Changer la Langue de la Console de management basée-web

  1. Connectez-vous à la Console de management.

    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. Réactualiser votre navigateur pour pouvoir utiliser les nouveaux paramètres régionaux (Locale).

3.4.4. Configurer un Serveur par la Console de gestion

Procédure 3.3. Configurer le Serveur

  1. Naviguer dans le panneau Server Configurations qui se trouve dans la Console de gestion

    1. Sélectionner l'onglet Hosts en haut de la console. Les instances de serveur disponibles s'afficheront sur un tableau.
  2. Modifier la configuration du serveur

    1. Sélectionner l'instance de serveur à partir du tableau Available Server Configurations.
    2. Sélectionner le bouton Edit qui se trouve en dessous de la liste de serveurs.
    3. Procédez avec les changements des attributs de configuration.
    4. Sélectionnez le bouton Save qui se trouve en dessous de la liste du serveurs.
Résultat

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

3.4.5. Ajouter un déploiement dans une Console de gestion

Procédure 3.4. Ajouter et vérifier un déploiement

  1. Naviguez dans le panneau Manage Deployments de la Console de gestion.

    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 qui se trouve à gauche de la console et sélectionner Manage Deployments. Pour un domaine géré, étendre l'élément de menu Domain qui se trouve à gauche de la console, et sélectionner Manage Deployments.
    Le panneau Manage Deployments apparaît.
  2. Ajouter le contenu du déploiement.

    Sélectionner le bouton Add dans l'onglet Content Repository. Une boîte de dialogue Create Deployment apparaîtra.
  3. Choisissez un fichier à déployer

    Dans la boîte de dialogue, sélectionner le bouton Browse. Cherchez le fichier que vous souhaitez déployer, et sélectionnez-le en vue de son chargement. Sélectionner le bouton Next pour continuer une fois que le fichier a été sélectionné.
  4. Vérifier les noms de déploiement

    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 le bouton 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.6. Créer un nouveau serveur dans la Console de management

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

  1. Naviguez sur la page Server Configuration qui se trouve dans la Console de management

    Sélectionnez l'onglet Server qui se trouve en haut et à droite de la console.
  2. Créer une nouvelle configuration

    1. Sélectionner le bouton Add qui se trouve en haut du panneau Server Configuration.
    2. Modifier les paramètres de base du serveur dans la boîte de dialogue Create Server Configuration.
    3. Cliquez 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.7. Modifier les Niveaux de journalisation par défaut en utilisant la Console de gestion

Procédure 3.6. Modifier les niveaux de journalisation

  1. Naviguez dans le panneau Logging de la Console de gestion.

    1. Si vous travaillez dans un domaine géré, sélectionner l'onglet Profiles en haut de la console, puis, sélectionnez le profil qui convient dans la liste déroulante à gauche de la console.
    2. Pour une domaine géré ou un serveur autonome, sélectionner CoreLogging à partir du menu 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 sélectionner le bouton Edit dans la section Details ci-dessous.
    2. Définir le niveau de journalisation de la catégorie dans la zone déroulante Log Level. Sélectionner le bouton Save quand c'est fait.
Résultat

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

3.4.8. Créer un nouveau groupe de service dans la Console de gestion

Procédure 3.7. Configurer et Ajouter un groupe de serveurs

  1. Rendez-vous dans la vue Server Groups

    Sélectionner l'onglet Hosts en haut et à droite.
  2. Sélectionner l'onglet Server Groups dans le menu Server dans la colonne de gauche.
  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 dans lequel vous souhaitez ajouter le groupe de serveurs.
    3. Sélectionner la liaison de socket dans laquelle vous souhaitez ajouter le groupe de serveurs.
    4. Sélectionner le bouton Save pour sauvegarder le nouveau groupe.
Résultat

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

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 le Management 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 du Management CLI

Procédure 3.8. Lancement du CLI dans 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 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 le Management CLI

Procédure 3.9. Quitter le Management CLI

  • Exécutez la commande quit

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

3.5.4. Se connecter à une instance de serveur géré par le Management CLI

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

  • Exécutez la commande connect

    Avec Management CLI, saisir la commande connect :
    [disconnected /] connect
    Connected to domain controller at localhost:9999
    • Sinon, pour vous connecter à un serveur géré quand on démarre le Management CLI sur le 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 avec le Management CLI

Résumé

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

Procédure 3.11. Aide au niveau options Générales et options Sensibles au contexte

  1. Exécuter la commande help

    Avec le Management CLI, saisir la commande help :
    [standalone@localhost:9999 /] help
  2. Obtenez de l'aide au niveau sensibilité du contexte

    Avec le Management 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 help avec comme argument '--help'.
    [standalone@localhost:9999 /]  deploy --help 
Résultat

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

3.5.6. Utiliser le Management 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é.

Procédure 3.12. 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 du Management 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 la 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 fichiermyscript.txt.
    [standalone@localhost:9999 /] batch --file=myscript.txt
    Ce qui suit exécutera instantanément les commandes 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 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 modidié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. Utilisez 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 du Management CLI

Procédure 3.13. 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é.

      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 une 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. Références de Commandes de Management CLI

Résumé

La section Section 3.5.5, « Comment obtenir de l'aide avec le Management CLI » décrit comment accéder aux fonctionnalités d'assistance du Management 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 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és 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.
help Affiche le message d'assistance. 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'application 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.10. Référence aux Opérations de Management CLI

Exposer les opérations du Management CLI

Les opérations du Management 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 le Management 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 le Management CLI ».

Tableau 3.4. Les opérations de Management 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é 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 locale 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.6. Opérations de l'interface CLI

3.6.1. Afficher les attributs d'une ressource par le Management 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.14. 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.7. 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 il 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 le Management 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.15. Affiche l'utilisateur qui est actif dans le Management CLI par l'opération whoami

  • Exécuter l'opération whoami

    À partir du Management 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.8. 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 le Management CLI

Procédure 3.16. Affiche les informations Système et Serveur dans le Management CLI

  • Exécuter la commande version

    À partir du Management 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 le Management CLI

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

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

    À partir du Management 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 du Management CLI ».
    [standalone@localhost:9999 /]:read-operation-description(name=name-of-operation)

Exemple 3.9. 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 le Management CLI

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

Exemple 3.10. Afficher les noms de l'opération en utilisant le Management 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 le Management 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.19. Éxécuter la commande de Management CLI suivante

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

    Avec le Management 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.11. Exécuter l'opération read-resource niveau racine

    [standalone@localhost:9999 /]:read-resource
    {
        "outcome" => "success",
        "result" => {
            "deployment" => undefined,
            "deployment-overlay" => undefined,
            "management-major-version" => 1,
            "management-micro-version" => 0,
            "management-minor-version" => 4,
            "name" => "longgrass",
            "namespaces" => [],
            "product-name" => "EAP",
            "product-version" => "6.1.0.GA",
            "release-codename" => "Janus",
            "release-version" => "7.2.0.Final-redhat-3",
            "schema-locations" => [],
            "system-property" => undefined,
            "core-service" => {
                "management" => undefined,
                "service-container" => undefined,
                "server-environment" => undefined,
                "platform-mbean" => 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" => {
                "logging" => undefined,
                "datasources" => undefined,
                "deployment-scanner" => undefined,
                "ee" => undefined,
                "ejb3" => undefined,
                "infinispan" => undefined,
                "jaxrs" => undefined,
                "jca" => undefined,
                "jdr" => undefined,
                "jmx" => undefined,
                "jpa" => undefined,
                "jsf" => undefined,
                "mail" => undefined,
                "naming" => undefined,
                "pojo" => undefined,
                "remoting" => undefined,
                "resource-adapters" => undefined,
                "sar" => undefined,
                "security" => undefined,
                "threads" => undefined,
                "transactions" => undefined,
                "web" => undefined,
                "webservices" => undefined,
                "weld" => 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.12. 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.13. 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.14. 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 le Management CLI

Procédure 3.20. Éxécuter la commande de Management CLI suivante

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

    À partir du Management 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 du Management 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 Management CLI

Procédure 3.21. Charger à nouveau le serveur d'applications

Résultat

Le serveur d'applications charge à nouveau en fermant tout d'abord tous les services et en démarrant le runtime à nouveau. Le Management CLI reconnecte automatiquement.

3.6.9. Fermer le serveur d'applications à l'aide du Management CLI

Procédure 3.22. Fermer le Serveur d'applications

  • Exécuter l'opération shutdown

    • À partir du Management 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 du Management 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
      Connected to IP_ADDRESS:PORT_NUMBER
      [192.168.1.10:9999 /] :shutdown
      
      Remplacer l'IP_ADDRESS par l'adresse IP de votre instance.
Résultat

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

3.6.10. Configurer un attribut à l'aide du Management 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.23. Configurer un attribut de ressource à l'aide du Management CLI

  • Exécuter l'opérationwrite-attribute

    À partir du Management 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 Management CLI où le chemin de ressource complet est spécifié.

Exemple 3.15. 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.7. Historique des commandes de l'interface CLI

3.7.1. Utiliser l'Historique de commande à l'aide du Management CLI.

Le Management CLI contient une fonctionnalité d'historique de commande qui est activée par défaut dans l'installation du serveur d'applications. L'historique est conservé à la fois en tant qu'archive dans la mémoire volatile de la session CLI active, et est ajouté le fichier de journalisation 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. Le Management 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 à l'aide du Management CLI.

Procédure 3.24. Afficher l'Historique de commandes à l'aide du Management CLI.

  • Exécuter la commande history

    À partir du Management 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 à l'aide du Management CLI.

Procédure 3.25. Effacer l'Historique de commandes à l'aide du Management CLI.

  • Exécuter la commande history --clear

    À partir du Management CLI, saisir la commande version :
    [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 à l'aide du Management CLI.

Procédure 3.26. Désactiver l'Historique de commandes à l'aide du Management CLI.

  • Exécuter la commande history --disable

    À partir du Management 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 de commandes à l'aide du Management CLI.

Procédure 3.27. Activer l'Historique de commandes à l'aide du Management CLI.

  • Exécuter la commande history --enable

    À partir du Management 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

La journalisation de l'auditing peut être activée pour que les opérations effectuées via l'API de gestion puissent être enregistrées dans un journal d'audit. Qu'elles soient conduites via la Console de gestion, l'interface de Management CLI, ou une interface écrite à la main, elles sont toutes assujetties à la journalisation d'auditing. Les logs peuvent être envoyés dans un fichier, transmis à un serveur Syslog ou les deux à la fois. Par défaut, Audit Logging est désactivé.
Les données de journalisation sont en format JSON, avec plusieurs options de configuration pour pouvoir influencer les opérations incluses dans le log et le format des entrées de journalisation.
Avant d'être stockées, les entrées de journalisation passent par un formateur et un gestionnaire (handler). Le formateur spécifie le format des entrées de journalisation, tandis que le gestionnaire envoie les enregistrements vers une destination (ou plusieurs) particulière(s). Un seul formateur est actuellement disponible ; il crée des entrées en format JSON.

Note

La journalisation de l'auditing peut être configurée uniquement via Le Management CLI.

3.8.2. Activer la Journalisation d'auditing de l'interface de gestion par le Management CLI

Pour activer la Journalisation de l'auditing par le Management CLI, utiliser la commande suivante.
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
La Journalisation d'auditing est rendue dans une sortie préfigurée qui va dans le fichier EAP_HOME/standalone/data/audit-log.log.

3.8.3. Formateur pour la Journalisation d'auditing de l'interface de gestion

Le formateur spécifie le format des entrées de journalisation.

Tableau 3.5. Champs de formateur JSON

Attribut Description
include-date Valeur booléenne qui définit si l'horodatage est oui ou non inclus dans les archives log formatées.
date-separator Chaîne contenant des caractères pour séparer la date du reste des messages log formatés. Sera ignoré si include-date=false.
date-format Format de date utilisé pour les horodatages compris par java.text.SimpleDateFormat. Ignoré si include-date=false.
compact Si défini sur true, formatera le JSON sur une seule ligne. Il y a sans doute encore des valeurs contenant de nouvelles lignes, donc s'il est important pour vous d'avoir l'enregistrement total sur une seule ligne, définir escape-new-line ou escape-control-characters à true.
escape-control-characters Si défini sur true, échapera tous les caractères de contrôle (entrées ASCII à valeur décimales < 32) avec le code ASCII en octale ; par exemple, une nouvelle ligne devient '#012'. Si défini sur true, remplacera escape-new-line=false.
escape-new-line Si défini sur true, échappera toutes les nouvelles lignes avec le code ASCII en octale, comme par exemple "#012".

3.8.4. Gestionnaire de fichiers de journalisation de l'auditing de l'interface de gestion

Un gestionnaire de fichiers indique les paramètres par lesquels les enregistrements de journalisation sont mis dans les fichiers. Il indique plus particulièrement le formateur, le nom du fichier et le chemin d'accès du fichier.

Tableau 3.6. Champs de journalisation d'audit de Gestionnaire de fichiers.

Attribut Description Lecture seule
formateur Le nom d'un formateur JSON à utiliser pour formater les enregistrements de journalisation. False
path Le chemin d'accès du fichier de journalisation de l'auditing False
relative-to Le nom d'un chemin d'accès déjà nommé, ou d'un des chemins standard fournis par le système. Si relative-to est donné, la valeur de l'attribut du chemin d'accès sera traité comme relative au chemin spécifié par cet attribut. False
failure-count Le nombre d'échecs de journalisation depuis l'initialisation du gestionnaire. True
max-failure-count Le nombre maximum d'échecs de journalisation avant de désactiver ce gestionnaire. False
disabled-due-to-failure true si ce gestionnaire était désactivé à cause des échecs de journalisation. True

3.8.5. Gestionnaire de fichier Syslog de journalisation de l'auditing de l'interface de gestion

Un gestionnaire de syslog indique les paramètres par lesquels les entrées de journalisations d'auditing sont envoyées à un serveur syslog, comme le nom d'hôte du serveur syslog et le nom du port sur lequel le serveur syslog écoute.
Envoyer une journalisation d'auditing à un serveur de syslog fournit davantage d'options de sécurité que de journaliser dans un fichier local ou sur un serveur syslog local. On peut définir plusieurs gestionnaires syslog.
Les serveurs syslog peuvent varier dans leur implémentation, donc tous les paramètres ne sont pas forcément applicables à tous les serveurs syslog. Le testing a été suivi par l'implémentation syslog rsyslog. Les RFC référencés sont les suivants :
  • http://www.ietf.org/rfc/rfc3164.txt
  • http://www.ietf.org/rfc/rfc5424.txt
  • http://www.ietf.org/rfc/rfc6587.txt

Tableau 3.7. Champs de Gestionnaire Syslog

Champ Description Lecture seule
formateur Le nom du formateur à utiliser pour formater les enregistrements de journalisation. False
failure-count Le nombre d'échecs de journalisation depuis l'initialisation du gestionnaire True
max-failure-count Le nombre maximum d'échecs de journalisation avant de désactiver ce gestionnaire. False
disabled-due-to-failure True si ce gestionnaire était désactivé à cause des échecs de journalisation. True
syslog-format Format Syslog: RFC-5424 ou RFC-3164. False
max-length La taille maximum d'un message de journalisation (en octets), comprenant l'en-tête. Si non défini, la valeur par défaut sera de 1024 octets si le syslog-format est RFC3164, ou 2048 octets si le syslog-format est RFC5424. False.
truncate Indique si un message doit ou non tronquer le message quand la longueur en octets est supérieure à la longueur maximale. Si la valeur est définie sur false, les messages seront divisés et envoyés avec les mêmes valeurs d'en-tête. False

3.8.6. Activer la Journalisation d'auditing de l'interface de gestion par le Serveur Syslog.

Note

Ajouter le préfixe /host=HOST_NAME aux commandes /core-service si vous devez appliquer les changements à un domaine géré.

Procédure 3.28. Activer la Journalisation sur un Serveur Syslog

  1. Créer un Gestionnaire Syslog nommé msyslog

    [standalone@localhost:9999 /]batch
    [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
    [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
    [standalone@localhost:9999 /]run-batch
  2. Ajouter une référence au Gestionnaire Syslog.

    [standalone@localhost:9999 /]/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.7. Options de Journalisation d'auditing de l'interface de gestion

En plus d'activer ou de désactiver la Journalisation de l'auditing de l'interface de gestion, il existe d'autres options de journalisation.

Options de configuration

log-boot
Si défini sur true, quand on démarre le serveur, les opérations de gestion seront incluses dans le log d'auditing, sinon false. Notons que la valeur par défaut est false.
log-read-only
Si défini sur true, toutes les opérations d'auditing seront journalisées. Si défini sur false, seules les opérations qui changeront le modèle seront journalisées. La valeur par défaut est : false.

3.8.8. Champs de Journalisation d'auditing de l'interface de gestion

Tableau 3.8. 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 true si l'opération ne modifie pas le modèle de gestion, sinon false.
booting 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 Numéro de version de l'instance JBoss EAP.
user Nom d'utilisateur de l'utilisateur authentifié. Si l'opération a été journalisée via le CLI sur le même ordinateur que le serveur en cours d'exécution, l'utilisateur spécial $local sera utilisé.
domainUUID 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 Cela peut avoir une des valeurs suivantes : NATIVE, HTTP, JMX. NATIVE - l'opération provient de l'interface de gestion native, par exemple le CLI. HTTP - l'opération provient de l'interface HTTP de domaine, par exemple la Console d'administration. JMX - l'opération provient du sous-système de JMX. Voir JMX pour savoir comment configurer la journalisation del'auditing pour JMX.
remote-address l'adresse du client qui exécute l'opération.
success 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 correspondra à toutes les opérations résultant du traitement XML. Une fois démarré, la liste contiendra normalement une seule entrée.

Chapitre 4. Gestion des utilisateurs

4.1. Création d'utilisateur

4.1.1. Ajouter Utilisateur pour les Interfaces de gestion

Aperçu

Les Interfaces de gestion sont sécurisées par défaut dans JBoss EAP 6 car il n'y a aucun compte utilisateur initialement disponible, sauf si vous avez installé la plateforme à l'aide de l'installateur graphique. Il s'agit d'une précaution de sécurité pour empêcher les violations de sécurité des systèmes distants pour cause d'erreur de configuration simple. L'accès non-HTTP local est protégé par un mécanisme SASL, avec une négociation qui passe entre le client et le serveur chaque fois que le client se connecte pour la première fois à partir de l'hôte local.

Cette tâche décrit comment créer l'utilisateur d'administration d'origine, qui peut utiliser la console de gestion basée web et les instances éloignées du Management CLI pour configurer et administrer la plate-forme JBoss EAP 6 à partir de systèmes distants.

Note

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 recevriez une erreur parce qu'il n'y a pas de déploiement consistent tant que l'utilisateur n'a pas été ajouté.

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

  1. Invoquer le script add-user.sh ou add-user.bat script.

    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 le Management 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 s'il n'y a pas de groupes pour l'utilisateur.
  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 usernamepassword
    Pour utiliser le domaine d'application, utiliser le paramètre -a.
    [user@host bin]$ ./add-user.sh -a usernamepassword
  9. Vous pouvez supprimer la sortie normale du script add-user 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 de ligne de commande au script add-user.
Pour obtenir une liste d'arguments de ligne de commandes disponible pour add-user.sh ou add-user.bat, consulter Section 4.1.3, « Arguments de 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 de 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 de commande Add-user

Argument de ligne de commande Valeur d'argument Description
-a
N/A
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 :
  • Ne peut pas être identique au nom d'utilisateur.
  • Il doit contenir 8 caractères au moins.
  • Il doit contenir au moins un caractère alphanumérique.
  • 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.
-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
N/A
Exécuter le script add-user sans sortie vers la console.
-h
--help
N/A
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 utilisateur et rôle 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 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 spécifiant 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 ou 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 de 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 suivantes 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 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.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 suivantes 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 suivantes 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 suivantes 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 suivantes 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'interface nommées dans la configuration. Cela permet à la configuration de référencer les déclarations d'interface individuelle 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é peut 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 Messagerie. 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 groupes 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, le Management 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 le Management 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. 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 qui puisse être résolu.
link-local-address Élément vide indiquant qu'une partie du critère de sélection d'une interface doit 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 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 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

    Sélectionner le Management CLI ou la Console de gestion pour configurer vos attributs d'interface selon les besoins.
    • Configurer les attributs d'interface par le Management CLI

      Utiliser le Management CLI pour ajouter de nouvelles interfaces et pour écrire des nouvelles valeurs dans dans les attributs de l'interface.
      1. Ajouter une nouvelle interface

        Utiliser l'opération add (ajouter) pour créer une nouvelle interface selon les besoins. Vous pouvez exécuter cette commande à partir de la racine de la session de Management CLI, qui, dans l'exemple suivant, crée un nouveau titre de nom d'interface interfacename, avec inet-address déclaré ainsi 12.0.0.2.
        /interface=interfacename/:add(inet-address=12.0.0.2)
      2. Modifier les attributs d'une interface

        Utiliser l'opération write pour écrire une nouvelle valeur dans un attribut. Vous pouvez utiliser l'onglet de complétion pour terminer la chaîne de commande en cours, ainsi que pour exposer les attributs disponibles. L'exemple suivant met à jour la valeur de l' inet-address à 12.0.0.8
        /interface=interfacename/:write(inet-address=12.0.0.8)
      3. Modifier les attributs d'une interface

        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.
        [standalone@localhost:9999 interface=public] :read-resource(include-runtime=true)
    • Configurer les attributs d'interface par la Console de gestion

      Utiliser la Console de gestion pour ajouter des nouvelles interfaces et pour écrire des nouvelles valeurs dans les attributs de l'interface.
      1. Connectez-vous à la Console de gestion.

        Connectez-vous à la Console de gestion de votre instance de Serveur autonome ou Managed Domain (Domaine géré).
      2. Si vous utilisez le Managed Domain, sélectionner le profil qui convient.

        Sélectionner l'onglet Profiles en haut à droite, puis sélectionner le profil qui convient à partir du menu Profile en haut et à gauche de l'écran suivant.
      3. Sélectionner l'item Interfaces à partir du menu de navigation.

        Sélectionner l'item de menu Interfaces à partir du menu de navigation.
      4. Ajouter une nouvelle interface

        1. Cliquer sur le bouton Add (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 pour terminer.
      5. Modifier les attributs d'une interface

        1. Sélectionner l'interface à modifier 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 pour terminer.

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 du 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">
    <socket-binding name="http" port="8080"/>
    <socket-binding name="https" port="8443"/>
    <socket-binding name="jacorb" port="3528"/>
    <socket-binding name="jacorb-ssl" port="3529"/>
    <socket-binding name="jmx-connector-registry" port="1090" interface="management"/>
    <socket-binding name="jmx-connector-server" port="1091" interface="management"/>
    <socket-binding name="jndi" port="1099"/>
    <socket-binding name="messaging" port="5445"/>
    <socket-binding name="messaging-throughput" port="5455"/>
    <socket-binding name="osgi-http" port="8090" interface="management"/>
    <socket-binding name="remoting" port="4447"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
</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="osgi-http" interface="management" port="8090"/>
        <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="osgi-http" interface="management" port="8090"/>
        <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="osgi-http" interface="management" port="8090"/>
        <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="osgi-http" interface="management" port="8090"/>
        <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 le Management CLI. Les avantages d'utiliser la Console de gestion est l'interface utilisateur graphique avec une écran de Groupe de liaisons de sockets dédié dans la section Configuration générale . Le Management CLI propose un API et un flux de travail basés ligne de commande qui permet 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 unique. 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 socket 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

Composant Description Rôle
Nom 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
Adresse multi-diffusion Si le socket doit être utilisé en multi-diffusion, c'est l'adresse multi-diffusion qu'il vous faut. Option
Port multi-diffusion Lié au cycle de vie de la conversation. Le scope de la conversation correspond aux longueurs de la requête et de la session, et est contrôlé par l'application. Option
Port fixe Si les contextes ne correspondent pas à vos besoins, vous pourrez définir des scopes personnalisés. Option
  • Configurer des liaisons de sockets dans des Groupes de liaisons de sockets

    Sélectionner le Management CLI ou la Console de gestion pour configurer vos liaisons de sockets selon les besoins.
    • Configurer les liaisons de sockets par le Management CLI

      Sélectionner le Management CLI pour configurer les liaisons de sockets.
      1. Ajouter un 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 Management 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 le Management CLI pour configurer les liaisons de sockets.
      1. Connectez-vous à la Console de gestion.

        Connectez-vous à la Console de gestion de votre domaine géré ou de votre serveur autonome.
      2. Sélectionner le Profile tab

        Sélectionner l'onglet Profiles en haut et à droite.
      3. Sélectionner l'élément Socket Binding à partir du menu de navigation.

        Sélectionner l'élément de menu Socket Binding à partir du menu de navigation. Si vous utilisez un domaine géré, sélectionner le groupe désiré dans le menu Socket Binding Groups.
      4. Ajouter un 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 les attributs d'une interface

        1. Sélectionner la liaison de sockets à modifier et cliquer sur le bouton Edit.
        2. Saisir les valeurs qui conviennent pour les Name (Nom), Interface (Interface) etr 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 dépend de 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é.
  • Des 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, ajouter le décalage au numéro de port par défaut pour le groupe de liaisons de socket 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 liaison de socket par défaut

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets

Tableau 5.3. Référence aux Groupes de liaison de socket par défaut

Nom Port Port Multidiffusion 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é pour découverte de pair dans les groupements HA. Non configurable par les Interfaces de gestion. Oui Non Oui Non
jgroups-mping 45700 Multicast. Utilisé pour découvrir l'appartenance de groupe d'origine dans un cluster HA. Oui Non Oui Non
jgroups-tcp 7600 Découverte de pairs unicast 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 unicast 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 à distance. Oui Oui Non Non
mod_cluster 23364 Port multidiffusion pour la communication entre JBoss EAP 6 et l'équilibreur de charges HTTP. Oui Non Oui Non
osgi-http 8090 Utilisé par les composants internes qui utilisent le sous-système OSGi. Non configurable par les Interfaces de gestion. Oui Oui Oui Oui
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 socket, chaque contrôleur d'hôte ouvre deux ports supplémentaires pour la gestion :

  • 9990 - Le port de Console de gestion
  • 9999 - Le port utilisé par la Console de gestion et par le Management API

5.2.4. Valeurs de décalage des ports pour les Groupes de liaison de sockets par défaut

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 socket est 8080 et si votre serveur utilise un port offset de 100, son port HTTP sera 8180.

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

  • Configurer les Port Offset (valeurs de décalages de ports)

    Sélectionner le Management CLI ou la Console de gestion pour configurer vos ports offsets.
    • Configurer Port Offsets par le Management CLI

      Sélectionner le Management 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 de 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 Port Offsets par la Console de Management

      Sélectionner la Console de Management pour configurer vos ports offsets.
      1. Connectez-vous à la Console de gestion.

        Connectez-vous à la Console de gestion de votre domaine géré.
      2. Sélectionner l'onglet Hosts

        Sélectionner l'onglet Hosts en haut et à droite.
      3. Modifier les attributs de Port Offset

        1. Sélectionner le serveur dans la section Configuration Name et cliquer sur le bouton Edit.
        2. Saisir les valeurs que vous désirez dans le champ Port Offset.
        3. Cliquer sur le bouton Save pour terminer.

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 :
    # 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. Cliquer sur l'onglet Profile qui se trouve en haut et à droite de la console.
  2. Sélectionner l'option Interfaces qui se trouve sous General Configuration.
  3. Sélectionner l'interface réseau nommée à configurer.
  4. Cliquer sur le bouton Edit.
  5. Définir l'adresse inet à :
    ${jboss.bind.address.management:[ADDRESS]}
  6. Cliquez sur le bouton Enregistrer pour enregistrer les modifications.
  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 :
    # 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 supportées 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 dé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 le Management 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 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 supportées 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.

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

Note

Pour avoir un meilleur comportement de serveur au démarrage, la méthode d'installation préférée pour les pilotes JDBC est de les installer comme modules de base. Pour installer le pilote JDBC comme module de base, consultez : Section 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  :

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

Procédure 6.1. Déployer le pilote JDBC

  1. Accéder à la console de gestion

  2. Déployez le fichier JAR dans votre serveur ou groupe de serveurs.

    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 9.2.2, « Déployer une application par 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 suivante pour ajouter le module de pilote JDBC comme pilote :
    /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.1. Exemple de Commande CLI

    /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)
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 du 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écifique 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

    • 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.2. Exemple de 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.3. Exemple de fichier jboss-deployment-structure.xml

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

Exemple 6.4. Accède à 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 le Management CLI.

Prérequis

  • 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 auraient créé une erreur. Ce paramètre n'est plus requis pour certaines applications.

Procédure 6.4. Créer une Source de données par le Management CLI ou la Console de gestion

    • Management CLI

      1. Lancer l'outil CLI et connectez-vous à votre serveur.
      2. Exécuter la commande suivante pour créer une source de données non-XA, et configurer les variables comme il se doit :
        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. Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion

          • Mode autonome

            Sélectionner l'onglet Profile en haut de la console.
          • Mode Domaine

            1. Sélectionner l'onglet Profiles en haut de la console.
            2. 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.
        1. Sélectionner ConnectorDatasources à partir du menu à gauche de la console.
      3. Créer une nouvelle source de données

        1. Sélectionner le bouton 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 appuyez sur Next.
        4. Saisir les paramètres de connexion dans l'assistant Create Datasource et appuyez sur Done.
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 avec 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 le Management CLI.

Note

Les sources de données non-XA peuvent être intégrées avec 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

    • Management 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. Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion

          • Mode autonome

            Sélectionner l'onglet Profile en haut de la console.
          • Mode Domaine

            1. Sélectionner l'onglet Profiles en haut de la console.
            2. 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.
        1. Sélectionner ConnectorDatasources à partir du menu à gauche de la console.
      2. Modifier la source de données

        1. Sélectionner la source de données qui convient à partir de la liste Available Datasources. Les attributs de la source de données 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 et sélectionner le bouton Save quand c'est fait.
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 avec 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 le Management CLI.

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

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

          • Mode autonome

            Sélectionner l'onglet Profile en haut de la console.
          • Mode Domaine

            1. Sélectionner l'onglet Profiles en haut de la console.
            2. 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.
        1. Sélectionner ConnectorDatasources à partir du menu à gauche de la console.
      2. Sélectionner la source de données enregistrée à supprimer, et cliquer sur le bouton Remove qui se trouve en haut et à droite de la console.
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 avec 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 le Management 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 auraient 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 le Management CLI ou la Console de gestion

    • Management CLI

      1. Exécuter la commande suivante pour créer une source de données XA, et configurer les variables comme il se doit:
        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. Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion

          • Mode autonome

            Sélectionner l'onglet Profile en haut de la console.
          • Mode Domaine

            1. Sélectionner l'onglet Profiles en haut de la console.
            2. 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.
        1. Sélectionner ConnectorDatasources à partir du menu à gauche de la console.
      2. Sélectionner l'onglet XA Datasource.
      3. Créer une nouvelle source de données XA

        1. Sélectionner le bouton Add qui se trouve en haut du panneau Datasources.
        2. Saisir les attributs de la nouvelle source de données XA de l'assistant Create XA Datasource et appuyez sur Next.
        3. Saisir les informations sur le pilote JDBC dans l'assistant Create XA Datasource et appuyez sur Next.
        4. Modifier les propriétés et appuyer sur Next.
        5. Saisir les paramètres de connexion dans l'assistant Create XA Datasource et appuyer sur Done.
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 base 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 le Management CLI.

Procédure 6.8. Modifier une source de données XA en utilisant le Management CLI ou la Console de gestion

    • Management 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. Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion

          • Mode autonome

            Sélectionner l'onglet Profile en haut de la console.
          • Mode Domaine

            1. Sélectionner l'onglet Profiles en haut de la console.
            2. 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.
        1. Sélectionner ConnectorDatasources à partir du menu à gauche de la console.
      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 avec 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 le Management CLI.

Procédure 6.9. Supprimer une source de données XA en utilisant le Management 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

          • Mode autonome

            Sélectionner l'onglet Profile en haut de la console.
          • Mode Domaine

            1. Sélectionner l'onglet Profiles en haut de la console.
            2. 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.
        1. Sélectionner ConnectorDatasources à partir du menu à gauche de la console.
      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 qui se trouve en haut et à droite de la console.
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 le Management CLI par ligne de commande. Se référer à Section 6.4.1, « Créer une source de données XA avec les Interfaces de gestion » and Section 6.4.2, « Modifier une base 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 :
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.
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.

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

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

La meilleure solution de sécuriser les bases 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 :

Exemple 6.5. Exemple de domaine de sécurité

<security>
   <security-domain>mySecurityDomain</security-domain>
</security>

Exemple 6.6. Exemple de mots de passe

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

6.6. Configuration des sources de données

6.6.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.
activé 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. Le paramètre logging-category doit également être défini à org.jboss.jdbc.
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-delimiter Le délimiteur d'URLs d'une connexion url pour les bases de données clusterisées HA (Haute disponibilité).
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 ».

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
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.
mot de passe 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é.
Spécifier « true » pour Validate-on-match n'est généralement pas effectué conjointement avec la spécification « true » de background-validation. Validate-on-match est nécessaire lorsqu'un client doit avoir une connexion validée avant l'utilisation. Ce paramètre est true 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 connexion 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.6.2. Les URL de connexion de sources de données

Tableau 6.13. 

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:microsoft:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME

6.6.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 fatal 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.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker

6.6.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 :

Procédure 6.10. 

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

Note

Veillez à ce que l'argument include-runtime=true et à ce que tous les statistiques soient en runtime uniquement et la valeur par défaut est false.

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

6.7. Exemples de sources de données

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

Exemple 6.7. 

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.
<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>
      <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.
<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.7.2. Exemple de source de données PostgreSQL XA

Exemple 6.8. 

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.
<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>
      <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.
<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.7.3. Exemple de source de données MySQL

Exemple 6.9. 

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.
<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>
      <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.
<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.7.4. Exemple de source de données MySQL XA

Exemple 6.10. 

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.
<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>
      <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.
<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.7.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 auraient créé une erreur. Ce paramètre n'est plus requis pour certaines applications.

Exemple 6.11. 

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.
<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>
      <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.
<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.7.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 auraient 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 recourvrement XA fonctionne correctement. La valeur user est une valeur définir 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)

Exemple 6.12. 

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.
<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>
      <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.
<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.7.7. Exemple de source de données Microsoft SQLServer

Exemple 6.13. 

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.
<datasources>
  <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:microsoft: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>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </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.
<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.7.8. Exemple de source de données Microsoft SQLServer XA

Exemple 6.14. 

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.
<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>
      <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.
<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.7.9. Exemple de source de données IBM DB2

Exemple 6.15. 

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.
<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>
      <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.
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

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

Exemple 6.16. 

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.
<datasources>
  <xa-datasource jndi-name="java:/DB2XADS" pool-name="DB2XADS">
    <driver>ibmdb2</driver>
    <xa-datasource-property name="DatabaseName">ibmdb2db</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>
      <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.
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc.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.7.11. L'exemple de source de données Sybase

Exemple 6.17. 

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.
<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>
      <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.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.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.
<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.7.12. L'exemple de source de données Sybase

Exemple 6.18. 

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.
<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>
    <validation>
      <background-validation>true</background-validation>
      <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.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.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.
<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. Tous les modules offrent les mêmes caractéristiques.
Modules statiques
Les modules statiques sont prédéfinis dans le répertoire EAP_HOME/modules/ du serveur d'application. Chaque sous-répertoire représente un module et contient un ou plusieurs fichiers JAR et un fichier de configuration (module.xml). Le nom de ce module est défini dans le fichier module.xml. Toutes les API fournies par le serveur d'application sont fournies en tant que modules statiques, comme les API Java EE ainsi que d'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.
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.
Modules dynamiques
Les modules dynamiques sont créés et chargés par le serveur d'application 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

    Arrêter le serveur JBoss EAP.
  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 fichier 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. L'élément <profile> du fichier de configuration contient plusieurs éléments du sous-système. L'élément du sous-système a comme espace-nom de urn:jboss:domain:ee:1.0.
    <profile>
    
       ...
    
       <subsystem xmlns="urn:jboss:domain:ee:1.0" />
    
       ...
    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.0" ></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.0" ></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.0" ><ear-subdeployments-isolated>false</ear-subdeployments-isolated></subsystem>
  6. Démarrer le serveur

    Lancer à nouveau le serveur JBoss EAP 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.

Prérequis

  1. Vous devez connaître le nom des modules qui ont été ajoutés comme modules globaux. Voir Section 7.4.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.4.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 conncecter à la console de gestion »
  2. Naviguez dans le panneau EE Subsystem.
      • Mode autonome

        Sélectionner l'onglet Profile qui se trouve en haut de la console.
      • Mode Domaine

        1. Sélectionner l'onglet Profiles qui se trouve en haut de la console.
        2. 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.
    1. Sélectionner ContainerEE à partir du menu à gauche de la console.
  3. Cliquer sur le bouton 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 le bouton Enregistrer pour ajouter le nouveau module global, ou bien cliquer sur le lien Annuler pour annuler.
    • Si vous cliquez sur le bouton Enregistrer, la boîte de dialogue va se fermer et le module spécifié sera ajouté à la liste des modules globaux.
    • Si vous cliquez sur le bouton Annuler, 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. Référence

7.4.1. Les modules inclus

  • asm.asm
  • ch.qos.cal10n
  • com.google.guava
  • com.h2database.h2
  • com.sun.jsf-impl
  • com.sun.jsf-impl
  • com.sun.xml.bind
  • com.sun.xml.messaging.saaj
  • gnu.getopt
  • javaee.api
  • javax.activation.api
  • javax.annotation.api
  • javax.api
  • javax.ejb.api
  • javax.el.api
  • javax.enterprise.api
  • javax.enterprise.deploy.api
  • javax.faces.api
  • javax.faces.api
  • javax.inject.api
  • javax.interceptor.api
  • javax.jms.api
  • javax.jws.api
  • javax.mail.api
  • javax.management.j2ee.api
  • javax.persistence.api
  • javax.resource.api
  • javax.rmi.api
  • javax.security.auth.message.api
  • javax.security.jacc.api
  • javax.servlet.api
  • javax.servlet.jsp.api
  • javax.servlet.jstl.api
  • javax.transaction.api
  • javax.validation.api
  • javax.ws.rs.api
  • javax.wsdl4j.api
  • javax.xml.bind.api
  • javax.xml.jaxp-provider
  • javax.xml.registry.api
  • javax.xml.rpc.api
  • javax.xml.soap.api
  • javax.xml.stream.api
  • javax.xml.ws.api
  • jline
  • net.sourceforge.cssparser
  • net.sourceforge.htmlunit
  • net.sourceforge.nekohtml
  • nu.xom
  • org.antlr
  • org.apache.ant
  • org.apache.commons.beanutils
  • org.apache.commons.cli
  • org.apache.commons.codec
  • org.apache.commons.collections
  • org.apache.commons.io
  • org.apache.commons.lang
  • org.apache.commons.logging
  • org.apache.commons.pool
  • org.apache.cxf
  • org.apache.httpcomponents
  • org.apache.james.mime4j
  • org.apache.log4j
  • org.apache.neethi
  • org.apache.santuario.xmlsec
  • org.apache.velocity
  • org.apache.ws.scout
  • org.apache.ws.security
  • org.apache.ws.xmlschema
  • org.apache.xalan
  • org.apache.xerces
  • org.apache.xml-resolver
  • org.codehaus.jackson.jackson-core-asl
  • org.codehaus.jackson.jackson-jaxrs
  • org.codehaus.jackson.jackson-mapper-asl
  • org.codehaus.jackson.jackson-xc
  • org.codehaus.woodstox
  • org.dom4j
  • org.hibernate
  • org.hibernate.envers
  • org.hibernate.infinispan
  • org.hibernate.validator
  • org.hornetq
  • org.hornetq.ra
  • org.infinispan
  • org.infinispan.cachestore.jdbc
  • org.infinispan.cachestore.remote
  • org.infinispan.client.hotrod
  • org.jacorb
  • org.javassist
  • org.jaxen
  • org.jboss.as.aggregate
  • org.jboss.as.appclient
  • org.jboss.as.cli
  • org.jboss.as.clustering.api
  • org.jboss.as.clustering.common
  • org.jboss.as.clustering.ejb3.infinispan
  • org.jboss.as.clustering.impl
  • org.jboss.as.clustering.infinispan
  • org.jboss.as.clustering.jgroups
  • org.jboss.as.clustering.service
  • org.jboss.as.clustering.singleton
  • org.jboss.as.clustering.web.infinispan
  • org.jboss.as.clustering.web.spi
  • org.jboss.as.cmp
  • org.jboss.as.connector
  • org.jboss.as.console
  • org.jboss.as.controller
  • org.jboss.as.controller-client
  • org.jboss.as.deployment-repository
  • org.jboss.as.deployment-scanner
  • org.jboss.as.domain-add-user
  • org.jboss.as.domain-http-error-context
  • org.jboss.as.domain-http-interface
  • org.jboss.as.domain-management
  • org.jboss.as.ee
  • org.jboss.as.ee.deployment
  • org.jboss.as.ejb3
  • org.jboss.as.embedded
  • org.jboss.as.host-controller
  • org.jboss.as.jacorb
  • org.jboss.as.jaxr
  • org.jboss.as.jaxrs
  • org.jboss.as.jdr
  • org.jboss.as.jmx
  • org.jboss.as.jpa
  • org.jboss.as.jpa.hibernate
  • org.jboss.as.jpa.hibernate
  • org.jboss.as.jpa.hibernate.infinispan
  • org.jboss.as.jpa.openjpa
  • org.jboss.as.jpa.spi
  • org.jboss.as.jpa.util
  • org.jboss.as.jsr77
  • org.jboss.as.logging
  • org.jboss.as.mail
  • org.jboss.as.management-client-content
  • org.jboss.as.messaging
  • org.jboss.as.modcluster
  • org.jboss.as.naming
  • org.jboss.as.network
  • org.jboss.as.osgi
  • org.jboss.as.platform-mbean
  • org.jboss.as.pojo
  • org.jboss.as.process-controller
  • org.jboss.as.protocol
  • org.jboss.as.remoting
  • org.jboss.as.sar
  • org.jboss.as.security
  • org.jboss.as.server
  • org.jboss.as.standalone
  • org.jboss.as.threads
  • org.jboss.as.transactions
  • org.jboss.as.web
  • org.jboss.as.webservices
  • org.jboss.as.webservices.server.integration
  • org.jboss.as.webservices.server.jaxrpc-integration
  • org.jboss.as.weld
  • org.jboss.as.xts
  • org.jboss.classfilewriter
  • org.jboss.com.sun.httpserver
  • org.jboss.common-core
  • org.jboss.dmr
  • org.jboss.ejb-client
  • org.jboss.ejb3
  • org.jboss.iiop-client
  • org.jboss.integration.ext-content
  • org.jboss.interceptor
  • org.jboss.interceptor.spi
  • org.jboss.invocation
  • org.jboss.ironjacamar.api
  • org.jboss.ironjacamar.impl
  • org.jboss.ironjacamar.jdbcadapters
  • org.jboss.jandex
  • org.jboss.jaxbintros
  • org.jboss.jboss-transaction-spi
  • org.jboss.jsfunit.core
  • org.jboss.jts
  • org.jboss.jts.integration
  • org.jboss.logging
  • org.jboss.logmanager
  • org.jboss.logmanager.log4j
  • org.jboss.marshalling
  • org.jboss.marshalling.river
  • org.jboss.metadata
  • org.jboss.modules
  • org.jboss.msc
  • org.jboss.netty
  • org.jboss.osgi.deployment
  • org.jboss.osgi.framework
  • org.jboss.osgi.resolver
  • org.jboss.osgi.spi
  • org.jboss.osgi.vfs
  • org.jboss.remoting3
  • org.jboss.resteasy.resteasy-atom-provider
  • org.jboss.resteasy.resteasy-cdi
  • org.jboss.resteasy.resteasy-jackson-provider
  • org.jboss.resteasy.resteasy-jaxb-provider
  • org.jboss.resteasy.resteasy-jaxrs
  • org.jboss.resteasy.resteasy-jsapi
  • org.jboss.resteasy.resteasy-multipart-provider
  • org.jboss.sasl
  • org.jboss.security.negotiation
  • org.jboss.security.xacml
  • org.jboss.shrinkwrap.core
  • org.jboss.staxmapper
  • org.jboss.stdio
  • org.jboss.threads
  • org.jboss.vfs
  • org.jboss.weld.api
  • org.jboss.weld.core
  • org.jboss.weld.spi
  • org.jboss.ws.api
  • org.jboss.ws.common
  • org.jboss.ws.cxf.jbossws-cxf-client
  • org.jboss.ws.cxf.jbossws-cxf-factories
  • org.jboss.ws.cxf.jbossws-cxf-server
  • org.jboss.ws.cxf.jbossws-cxf-transports-httpserver
  • org.jboss.ws.jaxws-client
  • org.jboss.ws.jaxws-jboss-httpserver-httpspi
  • org.jboss.ws.native.jbossws-native-core
  • org.jboss.ws.native.jbossws-native-factories
  • org.jboss.ws.native.jbossws-native-services
  • org.jboss.ws.saaj-impl
  • org.jboss.ws.spi
  • org.jboss.ws.tools.common
  • org.jboss.ws.tools.wsconsume
  • org.jboss.ws.tools.wsprovide
  • org.jboss.xb
  • org.jboss.xnio
  • org.jboss.xnio.nio
  • org.jboss.xts
  • org.jdom
  • org.jgroups
  • org.joda.time
  • org.junit
  • org.omg.api
  • org.osgi.core
  • org.picketbox
  • org.picketlink
  • org.python.jython.standalone
  • org.scannotation.scannotation
  • org.slf4j
  • org.slf4j.ext
  • org.slf4j.impl
  • org.slf4j.jcl-over-slf4j
  • org.w3c.css.sac
  • sun.jdk

7.4.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. Valves globales

8.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 sont généralement empaquetées dans une application.
Les versions 6.1.0 et supérieures prennent en charge les valves globales.

8.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 statique 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.

8.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()
Elle peut être utilisée pour implémenter des schémas d'authentification supplémentaires.

8.4. Installation d'une Valve globale

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

Prérequis :

  • 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 8.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 /usr/share/jboss/modules/system/layers/base/MyValveModule/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 modules.xml /usr/share/jboss/modules/system/layers/base/MyValveModule/main
Les classes Valve déclarées dans le module sont maintenant disponibles et peuvent être configurées dans le sous-système web.

8.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 du JBoss CLI.

Procédure 8.2. Configuration d'une Valve globale

  1. Activer la Valve

    Utiliser l'opération add pour ajouter une nouvelle saisie 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 dans le module.
    /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=testvalve:add-param(param-name="NAME", param-value="VALUE")
    /subsystem=web/valve=testvalve: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.

Chapitre 9. Déploiement d'applications

9.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 le Management 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.

9.2. Déployer avec la console de gestion

9.2.1. Gérer le déploiement d'une 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.

9.2.2. Déployer une application par la Console de gestion

Procédure 9.1. Déployer une application par la Console de gestion

  1. Naviguer dans le panneau Manage Deployments de la Console de gestion.

    1. Sélectionner l'onglet Runtime en haut de la console.
    2. Déplier le menu Domain ou Standalone (s'il ne l'est pas déjà).
    3. Sélectionner l'option Manage Deployments à partir du menu à gauche de la console.
  2. Déployer une application

    La méthode de déploiement variera suivant que vous déployez dans une instance de serveur autonome ou dans un domaine géré.
    • Déployer dans une instance de serveur autonome.

      Le tableau Available Deployment Content affiche tous les déploiements d'applications disponibles et leurs statuts.
      1. Activer l'application dans une instance de serveur autonome

        Cliquer sur le bouton Enable du tableau Deployments pour activer le déploiement de l'application.
      2. Confirmer

        Cliquer sur le bouton confirm pour confirmer que l'application puisse être activée dans l'instance du serveur.
    • Déployer dans un domaine géré.

      La section Deployment Content contient un tableau Content Repository qui affiche tous les déploiements d'applications et leurs statuts.
      1. Activer l'application dans un domaine géré

        Cliquer sur le bouton Add dans le tableau Content Repository.
      2. Sélectionner les groupes de serveurs

        Cocher les cases pour chaque groupe de serveurs dans lesquels vous souhaitez ajouter l'application et cliquer sur le bouton Save pour continuer.
      3. Confirmer

        Cliquer sur l'onglet Server Group Deployments 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.

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

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

  1. Naviguer dans le panneau Manage Deployments de la Console de gestion.

    1. Sélectionner l'onglet Runtime en haut de la console.
    2. Déplier le menu Domain ou Standalone (s'il ne l'est pas déjà).
    3. Sélectionner l'option Manage Deployments à partir du menu à gauche de la console.
  2. Supprimer le déploiement d'une application

    La méthode de suppression du déploiement variera suivant que vous déployez dans une instance de serveur autonome ou dans un domaine géré.
    • Supprimer le déploiement d'une instance de serveur autonome.

      Le tableau Available Deployment Content affiche tous les déploiements d'applications disponibles et leurs statuts.
      1. Désactiver l'application dans une instance de serveur autonome

        Cliquer sur le bouton Disable du tableau Deployments pour désactiver le déploiement de l'application.
      2. Confirmez que vous souhaitez désactiver l'application

        Cliquer sur le bouton confirm pour confirmer que l'application puisse être désactivée dans l'instance du serveur.
    • Supprimer le déploiement à partir d'un domaine géré

      La section Deployment Content contient un tableau Content Repository. Available Deployment Content affiche tous les déploiements d'applications disponibles et leurs statuts.
      1. Désactiver l'application dans un domaine géré

        Cliquer sur l'onglet Server Groups pour afficher les groupes de serveurs et le statut de leurs applications déployées.
      2. Sélectionner le groupe de serveurs

        Cliquer sur le nom du serveur dans le tableau Server Group pour supprimer un déploiement.
      3. Désactiver l'application à partir du serveur sélectionné

        Cliquer sur le bouton disable pour désactiver l'application d'un serveur sélectionné.
      4. Confirmez que vous souhaitez désactiver l'application

        Cliquer sur le bouton confirm pour confirmer que l'application puisse être désactivée dans l'instance du serveur.
      5. Répéter la suppression du déploiement pour les groupes de serveurs qui restent.

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

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

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

9.3.1. Gérer le déploiement d'une application à l'aide du Management CLI

Le déploiement d'applications par l'intermédiaire du Management 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 déploiement d'un serveur dans le cas d'une instance autonome, ou un réseau entier de serveurs dans le cas d'un domaine géré.

9.3.2. Déployer une application dans un domaine géré à l'aide du Management CLI

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

  • Exécuter la commande deploy

    Par l'intermédiaire du Management 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 de votre domaine géré.

9.3.3. Supprimer le déploiement d'une application dans un domaine géré à l'aide du Management CLI

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

  • Exécuter la commande undeploy

    Par l'intermédiaire du Management 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 /]undeploytest-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 plus déployée maintenant.

9.3.4. Déployer une application dans une Serveur autonome à l'aide du Management CLI

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

  • Exécuter la commande deploy

    Avec Management CLI, saisir la commande deploy avec le chemin d'accès vers le déploiement de l'application.
    [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.

9.3.5. Supprimer le déploiement d'une application dans un serveur autonome à l'aide du Management CLI

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

  • Exécuter la commande undeploy

    Avec Management CLI, saisir la commande undeploy avec le nom du fichier du déploiement de l'application.
    [standalone@localhost:9999 /] undeploy test-application.war
    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.

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

9.4.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 scanneur 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 scanneur 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.

9.4.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 9.1, « Les déploiements d'applications », cette méthode est retenue pour la commodité des développeurs, où les méthodes de Management Console ou de Management CLI sont recommandées pour la gestion des applications dans les environnements de production.

Procédure 9.7. 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

    Le déploiement d'une application varie entre un mode d'analyse de déploiement manuel ou automatique.
    • Déploiement automatique

      Le scanneur de déploiement saisit un changement d'état d'un dossier et crée un fichier de marquage, comme expliqué dans la section Section 9.4.5, « Référence pour les fichiers de marquage de scanneur de déploiement ».
    • 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 9.1. 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 9.2. Contenu du dossier de déploiement après le déploiement.

example.war
example.war.deployed

9.4.3. Supprimer le déploiement d'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 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 9.1, « Les déploiements d'applications », cette méthode est retenue pour la commodité des développeurs, où les méthodes de Management Console ou de Management 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 accidentelle ou autres erreurs, utilisez le Management CLI et la Console de gestion pour l'administration dans des environnements de production.

Procédure 9.8. 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 souhaitiez supprimer l'application d'un dossier de déploiement ou bien que vous souhaitiez 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

      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.

9.4.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 9.1, « Les déploiements d'applications », cette méthode est retenue pour la commodité des développeurs, où les méthodes de Management Console ou de Management CLI sont recommandées pour la gestion des applications dans les environnements de production.

Procédure 9.9. 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.

9.4.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 9.4. 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 9.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.

9.4.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 le Management 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 9.4.8, « Configurer le scanneur de déploiement avec le Management CLI ».

Tableau 9.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

9.4.7. Configurer le scanneur de déploiement

Le scanner de déploiement peut être configuré à l'aide de la Console de gestion ou le Management 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.

9.4.8. Configurer le scanneur de déploiement avec le Management CLI

Résumé

Bien qu'il existe plusieurs méthodes de configuration du scanneur de déploiement, le Management CLI permet d'exposer et de modifier les attributs par l'utilisation de batch scripts 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 .

Le scanneur de déploiement est un sous-système de JBoss EAP 6, que vous pouvez voir dans 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 9.10. 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 le Management 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.
      [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 du Management CLI, voir la section Section 3.5.5, « Comment obtenir de l'aide avec le Management CLI ».
      [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. Notez 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.

9.5. Déployer avec Maven

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

9.5.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-as-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 9.11. Déployer une application dans Maven.

  1. Exécuter la commande de déploiement de Maven dans une session de terminal

    Ouvrir la session de terminal et naviguez dans le répertoire qui contient les exemples Quickstart.
  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. Confirmer le déploiement de l'application

    • Voir le résultat dans la fenêtre du terminal

      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 9.5. Confirmation Maven pour l'application helloworld

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 3 seconds
      [INFO] Finished at: Mon Oct 10 17:22:05 EST 2011
      [INFO] Final Memory: 21M/343M
      [INFO] ------------------------------------------------------------------------
      
      
    • Voir les résultats dans la fenêtre du terminal du serveur

      Le déploiement peut également être confirmé dans le flux de statut de l'instance du serveur d'applications actives.

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

      17:22:04,922 INFO  [org.jboss.as.server.deployment] (pool-1-thread-3) Contenu ajouté dans /home/username/EAP_HOME/standalone/data/content/2c/39607b0c8dbc6a36585f72866c1bcfc951f3ff/content
      17:22:04,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "jboss-as-helloworld.war"
      17:22:04,954 INFO  [org.jboss.weld] (MSC service thread 1-3) Processing CDI deployment: jboss-as-helloworld.war
      17:22:04,973 INFO  [org.jboss.weld] (MSC service thread 1-2) Starting Services for CDI deployment: jboss-as-helloworld.war
      17:22:04,979 INFO  [org.jboss.weld] (MSC service thread 1-4) Starting weld service
      17:22:05,051 INFO  [org.jboss.web] (MSC service thread 1-2) registering web context: /jboss-as-helloworld
      17:22:05,064 INFO  [org.jboss.as.server.controller] (pool-1-thread-3) Deployed "jboss-as-helloworld.war"
Résultat

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

9.5.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-as-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 9.12. Supprimer un déploiement d'application dans Maven

  1. Exécuter la commande de déploiement de Maven dans une session de terminal

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

    Exemple 9.7. Passes au répertoire d'application helloworld

    [localhost]$ cd /path/to/EAP_Quickstarts/helloworld
    
  2. Exécuter la commande de suppression de déploiement.
    [localhost]$ mvn jboss-as:undeploy
  3. Confirmer la suppression du déploiement de l'application

    • Voir le résultat dans la fenêtre du terminal

      La suppression du déploiement peut être confirmée si on observe les entrées de journalisation de la fenêtre de terminal.

      Exemple 9.8. Confirmation Maven pour l'application helloworld

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] Building JBoss AS Quickstarts: Helloworld
      [INFO]    task-segment: [jboss-as:undeploy]
      [INFO] ------------------------------------------------------------------------
      [INFO] [jboss-as:undeploy {execution: default-cli}]
      [INFO] Executing goal undeploy for /home/username/EAP_Quickstarts/helloworld/target/jboss-as-helloworld.war on server localhost (127.0.0.1) port 9999.
      Oct 10, 2011 5:33:02 PM org.jboss.remoting3.EndpointImpl <clinit>
      INFO: JBoss Remoting version 3.2.0.Beta2
      Oct 10, 2011 5:33:02 PM org.xnio.Xnio <clinit>
      INFO: XNIO Version 3.0.0.Beta2
      Oct 10, 2011 5:33:02 PM org.xnio.nio.NioXnio <clinit>
      INFO: XNIO NIO Implementation Version 3.0.0.Beta2
      [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] ------------------------------------------------------------------------
      
      
    • Voir les résultats dans la fenêtre du terminal du serveur

      La suppression du déploiement peut également être confirmée dans le flux de statut de l'instance du serveur d'applications d'applications actives.

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

           
      17:33:02,334 INFO  [org.jboss.weld] (MSC service thread 1-3) Stopping weld service
      17:33:02,342 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Stopped deployment jboss-as-helloworld.war in 15ms
      17:33:02,352 INFO  [org.jboss.as.server.controller] (pool-1-thread-5) Undeployed "jboss-as-helloworld.war"
      
      
Résultat

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

9.6. 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 9.13. Contrôle de l'ordre de déploiement dans EAP 6.0.X

  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 9.14. Contrôler l'ordre de déploiement dans EAP 6.1.X

La nouvelle fonctionnalité nommée Inter Deployment Dependencies d'EAP 6.1.X 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>
    

9.7. Remplacement du descripteur de déploiement

Une nouvelle fonctionnalité de EAP 6.1 x vous permet de remplacer des descripteurs de déploiement 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 9.15. Remplacer le descripteur de déploiement en utilisant le Management 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})
        Si vous le souhaitez, vous pouvez ajouter des règles de contenu 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. Lier la superposition à une archive de déploiement

    • deployment-overlay link --name=myoverlay --deployments=app.war
      Vous pouvez spécifier plusieurs noms d'archives séparés par des virgules.
    • /deployment-overlay=myoverlay/deployment=app.war:add
      Veuillez noter que le nom d'archive de déploiement n'a pas besoin d'exister sur le serveur pour l'instant. Vous devez indiquer le nom, mais il ne sera pas encore lié à un déploiement.
  3. Déployer à nouveau l'application

    /deployment=app.war:redeploy

Chapitre 10. Sécuriser JBoss EAP 6

10.1. La sécurité du sous-système

Le sous-système de sécurité fournit l'infrastructure pour toutes les fonctionnalités de sécurité de JBoss EAP 6. La plupart des éléments de configuration ne doivent pas être changés souvent. Le seul élément de configuration qui pourrait devoir être changé est le choix de l'utilisation de deep-copy-subject-mode. De plus, vous pouvez configurer des propriétés de sécurité dans tout le système. L'ensemble de la configuration se soucie des domaines de sécurité.
Mode Deep Copy

Si le mode de sujet deep copy est désactivé (par défaut), la copie d'une structure de données de sécurité se réfère à l'original uniquement au lieu de copier toute la structure de données. Ce comportement est plus efficace, mais enclin à la corruption des données si plusieurs threads possédant la même identité effacent le sujet lors d'un vidage ou d'une déconnexion.

Le mode de sujet Deep Copy entraîne la copie totale de la structure des données et de toutes les données associées possibles, quand elles sont marquées « clonables ». C'est plus sûr au niveau thread, mais moins efficace.
Propriétés de sécurité dans tout le système

Vous pouvez définir des propriétés de sécurité dans tout le système, qui sont appliquées à la classe java.security.Security class.

Security Domain

Un domaine de sécurité est un ensemble de configuration de sécurité déclarative Java Authentication and Authorization Service (JAAS) qu'une ou plusieurs applications utilisent pour contrôler l'authentification, l'autorisation, l'auditing de et le mapping. Trois domaines de sécurité sont inclus par défaut: jboss-ejb-policy, jboss-web-policy, et other. Vous pouvez créer autant de domaines de sécurité que vous souhaitez pour accommoder les besoins de vos applications.

10.2. Structure du sous-système de sécurité

Le sous-système de sécurité est configuré dans le domaine géré ou le fichier de configuration autonome. La plupart des éléments de configuration peuvent être configurés à l'aide de la Console de gestion via web ou du Management CLI sur console. Voici le code XML qui représente un exemple de sous-système de sécurité.

Exemple 10.1. Exemple de configuration de sous-système de sécurité

<subsystem xmlns="urn:jboss:domain:security:1.2">
	<security-management>
		...
	</security-management>
	<security-domains>
        <security-domain name="other" cache-type="default">
            <authentication>
                <login-module code="Remoting" flag="optional">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
                <login-module code="RealmUsersRoles" flag="required">
                    <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/>
                    <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/>
                    <module-option name="realm" value="ApplicationRealm"/>
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
            </authentication>
        </security-domain>
        <security-domain name="jboss-web-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
        <security-domain name="jboss-ejb-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
    </security-domains>
    <vault>
    	...
    </vault>
</subsystem>		
		

Les éléments <security-management>, <subject-factory> et <security-properties> ne sont pas présents dans la configuration par défaut. Les éléments <subject-factory> et <security-properties> ont été désapprouvés sur JBoss EAP 6.1 et versions ultérieures.

10.3. Configurer le sous-système de sécurité

Vous pouvez configurer le sous-système de sécurité par le Management CLI ou par la Console de gestion basée web.
Chaque élément de niveau supérieur du sous-système de sécurité contient des informations sur un aspect différent de la configuration de la sécurité. Voir Section 10.2, « Structure du sous-système de sécurité » pour obtenir un exemple de configuration de sous-système.
<security-management>
Cette section remplace les comportements de haut niveau du sous-système de sécurité. Chaque paramètre est optionnel. Il est rare de modifier ces paramètres sauf pour le mode de sujet Deep Copy.
Option Description
deep-copy-subject-mode
Indiquez si l'on doit copier ou lier les tokens de sécurité pour la sécurité des threads.
authentication-manager-class-name
Indiquer un nom de classe d'implémentation AthentificationManager alternatif à utiliser.
authorization-manager-class-name
Indiquer un nom de classe d'implémentation AthorizationManager alternatif à utiliser.
audit-manager-class-name
Indiquer un nom de classe d'implémentation Audit Manager alternatif à utiliser.
identity-trust-manager-class-name
Indiquer un nom de classe d'implémentation IdentityTrustManager alternatif à utiliser.
mapping-manager-class-name
Indiquer le nom de classe d'implémentation MappingManager à utiliser.
<subject-factory>
La fabrique de sujets contrôle la création d'instances de sujets. Elle utilise sans doute le gestionnaire d'authentification pour vérifier l'appelant. L'utilisation principale du sujet est la création d'un sujet par les composants JCA. Il est rare que l'on ait besoin de modifier la fabrique de sujets.
<security-domains>
Un élément de conteneur qui contient plusieurs domaines de sécurité. Un domaine de sécurité peut contenir des informations sur des modules d'authentification, d'autorisation, de mappage, et d'auditing, ainsi qu'une autorisation JASPI et une configuration JSSE. Votre application indique ainsi un domaine de sécurité pour gérer ses informations de sécurité.
<security-properties>
Contient des noms et valeurs définis dans la classe java.security.Security

10.4. Mode de sujet Deep Copy

Si le mode de sujet Deep Copy (deep copy subject mode) est désactivé (par défaut), copier une structure de données de sécurité se réfère à l'original, au lieu de copier toute la structure de données. Ce comportement est plus efficace, mais enclin à la corruption des données si plusieurs threads possédant la même identité effacent le sujet lors d'un vidage ou d'une déconnexion.
Le mode de sujet Deep Copy entraîne la copie totale de la structure des données et de toutes ses données associées, quand elles sont marquées « clonables ». C'est plus sûr au niveau thread, mais moins efficace.
Le mode de sujet Deep Copy est configuré dans le cadre du sous-système de sécurité.

10.5. Activer le Mode de sujet Deep Copy

Vous pouvez activer le mode de sécurité Deep Copy à partir de la console de gestion basée web ou du Management CLI.

Procédure 10.1. Activer le mode de sécurité Deep Copy à partir de la Console de gestion

  1. Connectez-vous à la Console de gestion.

    La console de gestion est normalement disponible à par un URL commme http://127.0.0.1:9990/. Ajuster cette valeur pour qu'elle corresponde à vos besoins.
  2. Domaine géré : sélectionner le profil qui convient.

    Dans un domaine géré, le sous-système de sécurité est configuré par profil, ou vous pouvez activer ou désactiver le mode de sécurité Deep Copy pour chacun, de manière indépendante.
    Pour sélectionner un profil, cliquer sur Profiles en haut et à droite de l'affichage console, puis sélectionner le profil que vous souhaitez modifier à partir de la case de sélection Profile en haut et à gauche.
  3. Ouvrir le menu de configuration Security Subsystem.

    Étendre l'item de menu Security à droite de la console de gestion, puis cliquer sur le lien Security Subsystem.
  4. Modifier deep-copy-subject-mode.

    Cliquer sur le bouton Edit. Cocher la case qui se trouve à côté de Deep Copy Subjects: pour activer le mode Copier Sujet (copy subject).
Activer Deep Copy Subject Mode par la Console CLI

Si vous préférez utiliser le Management CLI pour activer cette option, utiliser une des commandes suivantes.

Exemple 10.2. Domaine géré

/profile=full/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

Exemple 10.3. Serveur autonome

/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

10.6. Domaines de sécurité

10.6.1. Les domaines de sécurité

Les domaines de sécurité font partie du sous-système de sécurité JBoss EAP. La configuration de la sécurité est désormais gérée de façon centralisée, ou par le contrôleur de domaines d'un domaine géré ou par le serveur autonome.
Un domaine de sécurité se compose de configurations d'authentification, d'autorisation, de mappage de sécurité et d'audit. Il met en place la sécurité déclarative Java Authentication and Authorization Service (JAAS).
L'authentification est impliquée dans la vérification de l'identité d'un utilisateur. Dans la terminologie de la sécurité, cet utilisateur est appelé un principal. Bien que l'authentification et l'autorisation soient différentes, de nombreux modules d'authentification intégrés gèrent également l'autorisation.
Une authorization est une police de sécurité par laquelle le serveur détermine si un utilisateur authentifié a la permission d'accéder à des privilèges ou ressources particulières dans le système ou opération. Dans la terminologie de sécurité, on parle de « role ».
Security mapping se rapporte à la possibilité d'ajouter, de modifier ou de supprimer des informations d'un principal, rôle ou attribut avant de passer les informations à votre application.
L'Auditing Manager vous permet de configurer les provider modules pour contrôler la façon dont les événements de sécurité sont rapportés.
Si vous utilisez des domaines de sécurité, vous pouvez supprimer toutes les configurations de sécurité spécifiques à votre application proprement dite. Cela permet de modifier les paramètres de sécurité de façon centralisée. Un scénario courant qui bénéficie de ce type de structure de configuration est le processus de déplacement des applications entre les environnements de test et de production.

10.6.2. Picketbox

Picketbox est le cadre de sécurité de base qui fournit l'authentification, l'autorisation, la vérification et des fonctions de mappage à des applications Java exécutant dans JBoss EAP 6. Il fournit les fonctions suivantes, dans un cadre unique avec une configuration simple :

10.6.3. Authentification

L'authentification consiste à identifier un sujet et à vérifier l'authenticité de l'identification. Le mécanisme d'authentification le plus commun est une combinaison de nom d'utilisateur et de mot de passe. D'autres mécanismes d'authentification communs utilisent des clés partagées, des smart cards (cartes à puce) ou des empreintes digitales. Le résultat d'une authentification réussie s'appelle un Principal, en termes de sécurité déclarative Java Enterprise Edition.
JBoss EAP utilise un système pouvant se connecter à des modules d'authentification en vue de flexibilité et d'intégration avec les systèmes d'authentification que vous utilisez dans votre organisation. Chaque domaine de sécurité contient un ou plusieurs modules d'authentification configurés. Chaque module comprend des paramètres de configuration supplémentaires pour personnaliser son comportement. Le plus simple consiste à configurer le sous-système d'authentification dans la console de gestion web.
L'authentification n'est pas la même chose que l'autorisation, même si elles sont souvent liées. Bon nombre des modules d'authentification intégrés peuvent également gérer des autorisations.

10.6.4. Configurer l'authentification dans un Domaine de sécurité

Pour configurer les paramètres d'authentification d'un domaine de sécurité, vous connecter dans la console de gestion et suivre la procédure suivante :

Procédure 10.2. Configurer l'authentification dans un Domaine de sécurité

  1. Ouvrir l'affichage détaillé du domaine de sécurité.

    Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine géré, sélectionner le profil à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.
  2. Naviguer dans la configuration du sous-système d'authentification.

    Cliquer sur l'étiquette Authentification en haut de l'affichage s'il n'a pas déjà été sélectionné.
    La zone de configuration est divisée en deux : Login Modules et Details. Le module de connexion est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices d'autorisation, et chacune peut inclure plusieurs attributs et options.
  3. Ajouter un module de connexion

    Cliquer sur le bouton Add pour ajouter un module de police d'authentification JAAS. Remplir les informations pour votre module. Le Code est le nom de classe de votre module. Les Flags contrôlent la façon dont le module est lié à d'autres modules de polices d'authentification du même domaine de sécurité.
    Explication des indicateurs

    La spécification Java Enterprise Edition 6 fournit l'explication suivante sur les marqueurs des modules de sécurité. La liste suivante provient de http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Consulter ce document pour obtenir des informations plus détaillées.

    Marqueur Détails
    requis
    Le LoginModule est requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.
    pré-requis
    Le LoginModule est requis pour la réussite. En cas de succès, l'authentification continue vers le bas de la liste LoginModule. En cas d'échec, le contrôle est renvoyé immédiatement à l'application (l'authentification ne continue pas son chemin le long de la liste LoginModule).
    suffisant
    The LoginModule n'est pas nécessaire pour aboutir. S'il ne réussit pas, le contrôle retourne immédiatement à l'application (l'authentification ne se déroule pas vers le bas de la liste LoginModule). S'il échoue, l'authentification se poursuit vers le bas de la liste LoginModule.
    option
    Le LoginModule n'est pas requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.
    Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Flags (indicateurs) en cliquant sur le bouton Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.
  4. Option : ajouter ou supprimer un module

    Pour ajouter des options à votre module, cliquer sur leurs entrées dans la liste Login Modules, et sélectionner l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquer sur le bouton Add, et fournir la clé et la valeur de l'option. Utiliser le bouton Remove pour supprimer l'option.
Résultat

Votre module d'authentification est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.

L'option de module jboss.security.security_domain

Par défaut, chaque module de connexion défini dans un domaine de sécurité a l'option de module jboss.security.security_domain ajoutée automatiquement. Cette option cause des problèmes avec les modules de connexion, qui vérifient que seules les options connues soient définies. Le module de connexion Kerberos d'IBM com.ibm.security.auth.module.Krb5LoginModule est l'un d'entre eux.

Vous pouvez désactiver le comportement d'ajout de cette option de module, en définissant la propriété de système sur true en démarrant la plate-forme JBoss EAP 6. Ajouter ce qui suit pour démarrer les paramètres.
-Djboss.security.disable.secdomain.option=true
Vous pourrez également définir cette propriété par la Console de gestion. Dans un serveur autonome, vous pouvez définir les propriétés de système dans la section Profile de configuration. Dans un domaine géré, vous pouvez définir les propriétés du système pour chaque groupe de serveur.

10.6.5. L'autorisation

L'autorisation est un mécanisme d'octroi ou de refus de permission d'accéder à une ressource, basé sur l'identité. Ce mécanisme est implémenté sous forme de rôles de sécurité déclarative, qui peuvent être donnés à des principaux.
JBoss EAP utilise un système modulaire pour configurer l'autorisation. Chaque domaine de sécurité peut contenir une ou plusieurs stratégies d'autorisation. Chaque stratégie possède un module de base qui définit son comportement. Il est configuré via les attributs et indicateurs spécifiques. La façon la plus simple consiste à configurer le sous-système de l'autorisation à l'aide de la console de gestion basée web.
L'authentification est différente de l'autorisation, et a lieu, en général, après l'authentification. La plupart des modules d'authentification gèrent également l'autorisation.

10.6.6. Configurer l'autorisation pour un domaine de sécurité

Pour configurer les paramètres d'un domaine de sécurité, connectez-vous à la console de gestion et suivre la procédure suivante:

Procédure 10.3. Configurer l'autorisation pour un domaine de sécurité

  1. Ouvrir l'affichage détaillé du domaine de sécurité.

    Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine géré, sélectionner le profil à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.
  2. Naviguer dans la configuration du sous-système d'autorisation.

    Cliquer sur l'étiquette Authorization en haut de l'affichage si elle n'a pas déjà été sélectionnée.
    La zone de configuration est divisée en deux: Policies et Details. Le module de connexion est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices d'autorisation, et chacune d'elle peut inclure plusieurs attributs ou options.
  3. Ajouter une police.

    Cliquer sur le bouton Add pour ajouter un module de police d'autorisation JAAS. Remplir les informations pour votre module. Le Code est le nom de classe de votre module. Les Flags contrôlent la façon dont le module est lié à d'autres modules de polices d'autorisation du même domaine de sécurité.
    Explication des indicateurs

    La spécification Java Enterprise Edition 6 fournit l'explication suivante sur les marqueurs des modules de sécurité. La liste suivante provient de http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Consulter ce document pour obtenir des informations plus détaillées.

    Marqueur Détails
    requis
    Le LoginModule est requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.
    pré-requis
    Le LoginModule est requis pour la réussite. En cas de succès, l'autorisation continue vers le bas de la liste LoginModule. En cas d'échec, le contrôle est renvoyé immédiatement à l'application (l'autorisation ne continue pas son chemin le long de la liste LoginModule).
    suffisant
    The LoginModule n'est pas nécessaire pour aboutir. S'il ne réussit pas, le contrôle retourne immédiatement à l'application (l'autorisation ne se déroule pas vers le bas de la liste LoginModule). S'il échoue, l'authentification se poursuit vers le bas de la liste LoginModule.
    option
    Le LoginModule n'est pas requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.
    Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Flags (indicateurs) en cliquant sur le bouton Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.
  4. Option : ajouter, éditer, ou supprimer un module

    Si vous avez besoin d'ajouter des options à votre module, cliquer sur leurs entrées dans la liste Login Modules, et sélectionner l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquer sur le bouton Add, et fournir la clé et la valeur de l'option. Pour la modifier, cliquer sur la clé et modifier. Utiliser le bouton Remove pour supprimer l'option.
Résultat

Votre module de police de sécurité est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.

10.6.7. Security Auditing

Security Auditing se réfère au déclenchement d'événements, comme écrire un blog en réponse à un événement qui a lieu dans le sous-système de sécurité. Les mécanismes de sécurité sont configurés dans le cadre du domaine de sécurité, avec les informations d'authentification, d'autorisation ou de mappage de sécurité.
Auditing utilise des modules de fournisseur. Vous pouvez en utiliser un existant ou bien créer le vôtre.

10.6.8. Configurer Security Auditing

Pour configurer les paramètres de Security Auditing, connectez-vous à la console de gestion et suivre la procédure suivante :

Procédure 10.4. Configurer Security Auditing pour un domaine de sécurité

  1. Ouvrir l'affichage détaillé du domaine de sécurité.

    Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine autonome, l'onglet est intitulé Profile. Dans un domaine géré, sélectionner le profil à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.
  2. Naviguer dans la configuration du sous-système Auditing.

    Cliquer sur l'étiquette Audit en haut de l'affichage si elle n'a pas déjà été sélectionnée.
    La zone de configuration est divisée en deux : Provider Modules et Details. Le module de fournisseur est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices d'autorisation, et chacune peut inclure plusieurs attributs et options.
  3. Ajouter un module de fournisseur.

    Cliquer sur le bouton Add pour ajouter un module de fournisseur. Remplir la section Code avec le nom de classe du module du fournisseur.
    Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code en cliquant sur le bouton Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.
  4. Vérifier que le module fonctionne

    Le but d'un module d'auditing est d'offrir un moyen de surveiller les événements dans le sous-système de sécurité. Ce monitoring peut être réalisé sous la forme d'écriture dans un fichier de journalisation, des notifications email ou autre mécanisme d'audit mesurable.
    Par exemple, JBoss EAP 6 inclut le module LogAuditProvider par défaut. S'il est activé par les étapes décrites ci-dessus, ce module d'audit écrira des notifications de sécurité dans un fichier audit.log qui se situe dans le sous-dossier log du répertoire EAP_HOME.
    Pour vérifier si les étapes ci-dessus fonctionnent dans le contexte LogAuditProvider, procédez à une action qui risque de déclencher une notification, puis vérifier le fichier de journalisation de l'audit.
    Pour obtenir une liste complète des Modules Security Auditing Provider, voir : Section 11.4, « Modules Security Auditing Provider inclus »
  5. Option : ajouter, éditer, ou supprimer un module

    Si vous avez besoin d'ajouter des options à votre module, cliquer sur leurs entrées dans la liste Module, et sélectionner l'onglet Module Options dans la section Details de la page. Cliquer sur le bouton Add, et fournir la clé et la valeur de l'option. Pour modifier une option existante, la supprimer en cliquant sur l'étiquette Remove, et l'ajouter à nouveau grâce aux options qui conviennent en cliquant sur le bouton Add.
Résultat

Votre module d'audit de sécurité est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.

10.6.9. Security Mapping

Le mappage de sécurité vous permet de combiner l'authentification et l'autorisation d'informations après que l'authentification ou l'autorisation aient eu lieu, mais avant que l'information ait été passée à votre application. Un exemple qui l'illustre est l'utilisation d'un certificat X509 pour l'authentification, puis la conversion du principal du certificat en nom logique que votre application puisse afficher.
Vous pouvez mapper vos principaux (authentification), rôles (autorisation), ou identifiants (attributs qui ne sont ni principaux, ni rôles).
Le mappage de rôles est utilisé pour ajouter, remplacer ou supprimer des rôles du sujet après l'authentification.
Le mappage du principal est utilisé pour modifier un principal après l'authentification.
Le mappage d'attributs est utilisé pour convertir des attributs d'un système externe à utiliser par votre application, et vice versa.

10.6.10. Configurer le Security Mapping dans un domaine de sécurité

Pour configurer les paramètres de Security Mapping, vous connecter à la console de gestion et suivre la procédure suivante :

Procédure 10.5. Configurer le Mappage de sécurité pour un Domaine de sécurité

  1. Ouvrir l'affichage détaillé du domaine de sécurité.

    Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine autonome, l'onglet est intitulé Profile. Dans un domaine géré, sélectionner le profile à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.
  2. Naviguer dans la configuration du sous-système de Mapping

    Cliquer sur l'étiquette Mapping en haut de l'affichage si elle n'a pas déjà été sélectionnée.
    La zone de configuration est divisée en deux : Modules et Details. Le module de connexion est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices de mapping, et chacune peut inclure plusieurs attributs et options.
  3. Ajouter un module.

    Cliquer sur le bouton Add pour ajouter un module de police de mapping. Remplir les informations pour votre module. Le Code est le nom de classe du module. Le champ Type se rapporte au type de mapping effectué par ce module. Les valeurs autorisées sont les suivantes : principal, rôle, attribut ou identifiant.
    Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Type en cliquant sur le bouton Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.
  4. Option : ajouter, éditer ou supprimer un module

    Pour ajouter des options à votre module, cliquer sur leurs entrées dans la liste Modules, et sélectionner l'onglet Module Options dans la section Details. Cliquer sur le bouton Add, et fournir la clé et la valeur de l'option. Pour modifier une option existante, la supprimer en cliquant sur l'étiquette Remove, et ajouter la nouvelle valeur. Utiliser le bouton Remove pour supprimer une option.
Résultat

Votre module de mappage de sécurité est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.

10.6.11. Utiliser un domaine de sécurité dans votre application

Aperçu

Pour utiliser un domaine de sécurité dans votre application, vous devez tout d'abord configurer le domaine dans le fichier de configuration du serveur ou dans le fichier de descripteur de l'application. Ensuite, vous devez ajouter les annotations requises à l'EJB qui l'utilisent. Cette rubrique décrit les étapes requises pour utiliser un domaine de sécurité dans votre application.

Avertissement

Si une application fait partie d'un domaine de sécurité qui utilise un cache d'authentification, les authentifications utilisateur de cette application seront rendues disponibles à d'autres applications dans ce domaine de sécurité.

Procédure 10.6. Configurez votre application pour qu'elle puisse utiliser un domaine de sécurité

  1. Définir le domaine de sécurité

    Vous pouvez définir le domaine de sécurité soit dans le fichier de configuration du serveur, soit dans le fichier du descripteur de l'application.
    • Configurez le domaine de sécurité dans le fichier de configuration du serveur

      Le domaine de sécurité est configuré dans le sous-système de sécurité du fichier de configuration du serveur. Si l'instance de JBoss EAP 6 s'exécute dans un domaine géré, il s'agira du fichier domain/configuration/domain.xml. Si l'instance de JBoss EAP 6 s'exécute comme un serveur autonome, ce sera le fichier standalone/configuration/standalone.xml.
      Les domaines de sécurité other, jboss-web-policy, et jboss-ejb-policy sont fournis par défaut dans JBoss EAP 6. L'exemple XML suivant a été copié à partir du sous-système de sécurité dans le fichier de configuration du serveur.
      <subsystem xmlns="urn:jboss:domain:security:1.2">
          <security-domains>
              <security-domain name="other" cache-type="default">
                  <authentication>
                      <login-module code="Remoting" flag="optional">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                      <login-module code="RealmDirect" flag="required">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                  </authentication>
              </security-domain>
              <security-domain name="jboss-web-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
              <security-domain name="jboss-ejb-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
          </security-domains>
      </subsystem>
      
      Vous pouvez configurer des domaines de sécurité supplémentaires selon les besoins par la console de gestion ou par l'interface CLI.
    • Configurer le domaine de sécurité dans le fichier de descripteur de l'application.

      Le domaine de sécurité est spécifié dans l'élément enfant <security-domain> de l'élément <jboss-web> du fichier WEB-INF/jboss-web.xml de l'application. L'exemple suivant configure un domaine de sécurité nommé my-domain.
      <jboss-web>
          <security-domain>my-domain</security-domain>
      </jboss-web>
      
      Il s'agit d'une des configurations que vous pouvez indiquer dans le descripteur WEB-INF/jboss-web.xml.
  2. Ajoutez l'annotation requise à l'EJB.

    Vous pouvez configurer la sécurité dans EJB par les annotations @SecurityDomain et @RolesAllowed. L'exemple de code EJB suivant limite l'accès au domaine de sécurité other aux utilisateurs ayant pour rôle guest (invité).
    package example.ejb3;
    
    import java.security.Principal;
    
    import javax.annotation.Resource;
    import javax.annotation.security.RolesAllowed;
    import javax.ejb.SessionContext;
    import javax.ejb.Stateless;
    
    import org.jboss.ejb3.annotation.SecurityDomain;
    
    /**
     * Simple secured EJB using EJB security annotations
     * Allow access to "other" security domain by users in a "guest" role.
     */
    @Stateless
    @RolesAllowed({ "guest" })
    @SecurityDomain("other")
    public class SecuredEJB {
    
       // Inject the Session Context
       @Resource
       private SessionContext ctx;
    
       /**
        * Secured EJB method using security annotations
        */
       public String getSecurityInfo() {
          // Session context injected using the resource annotation
          Principal principal = ctx.getCallerPrincipal();
          return principal.toString();
       }
    }
    Pour obtenir des exemples de code supplémentaires, voir le quickstart ejb-security dans le package JBoss EAP 6 Quickstarts disponible à partir du portail clients de Red Hat.

10.6.12. Java Authorization Contract for Containers (JACC)

10.6.12.1. Java Authorization Contract for Containers (JACC)

Java Authorization Contract for Containers (JACC) est une norme qui définit un contrat entre les conteneurs et les fournisseurs de services d'autorisation, et qui se traduit par l'implémentation de fournisseurs qui seront utilisés par des conteneurs. Elle a été définie dans JSR-115, qui se trouve sur le site Web de Java Community Process http://jcp.org/en/jsr/detail?id=115. Elle a fait partie de la spécification Java Enterprise Edition (Java EE) depuis la version 1.3 de Java EE.
JBoss EAP 6 implémente un support pour JACC dans la fonctionnalité de sécurité du sous-système de sécurité.

10.6.12.2. Configurer la sécurité JACC (Java Authorization Contract for Containers)

Pour configurer JACC (Java Authorization Contract for Containers), il convient de configurer votre domaine de sécurité avec le module qui convient, puis de modifier votre fichier jboss-web.xml pour y inclure les paramètres qu'il faut.
Ajouter JACC Support au domaine de sécurité

Pour ajouter JACC au domaine de sécurité, ajouter la police d'autorisation JACC à la pile d'autorisations du domaine de sécurité, avec l'indicateur requis. Voici un exemple de domaine de sécurité avec support JACC. Cependant, le domaine de sécurité est configuré dans la console de gestion ou Management CLI, plutôt que directement dans le code XML.

<security-domain name="jacc" cache-type="default">
    <authentication>
        <login-module code="UsersRoles" flag="required">
        </login-module>
    </authentication>
    <authorization>
        <policy-module code="JACC" flag="required"/>
    </authorization>
</security-domain>

Configurer une application web qui utilise JACC

Le fichier jboss-web.xml se trouve dans META-INF/ ou dans le répertoire WEB-INF/ de votre déploiement, et contient des ajouts ou remplacements de configuration spécifique JBoss pour le conteneur web. Pour utiliser votre domaine de sécurité activé-JACC, vous devrez inclure l'élément <security-domain>, et aussi définir l'élément <use-jboss-authorization> sur true. L'application suivante est configurée correctement pour pouvoir utiliser le domaine de sécurité JACC ci-dessus.

<jboss-web>
    <security-domain>jacc</security-domain>
    <use-jboss-authorization>true</use-jboss-authorization>
</jboss-web>

Configurer une application EJB pour utiliser JACC

La façon de configurer les EJB pour qu'ils utilisent un domaine de sécurité et pour qu'ils utilisent JACC diffère des applications Web. Pour un EJB, vous pouvez déclarer des method permissions (permissions de méthode) sur une méthode ou sur un groupe de méthodes, dans le descripteur ejb-jar.xml. Dans l'élément <ejb-jar>, chaque élément <method-permission> dépendant contient des informations sur les rôles JACC. Voir l'exemple de configuration pour plus d'informations. La classe EJBMethodPermission fait partie de l'API Java Enterprise Edition 6, et est documentée dans http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html.

Exemple 10.4. Exemple de permissions de méthode JACC dans un EJB

<ejb-jar>
  <method-permission>
    <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description>
    <role-name>employee</role-name>
    <role-name>temp-employee</role-name>
    <method>
      <ejb-name>EmployeeService</ejb-name>
      <method-name>*</method-name>
    </method>
  </method-permission>
</ejb-jar>
	      

Vous pouvez également contraindre les mécanismes d'authentification et d'autorisation d'un EJB à l'aide d'un domaine de sécurité, comme vous pouvez le faire pour une application web. Les domaines de sécurité sont déclarés dans le descripteur jboss-ejb3.xml qui se trouve dans l'élément enfant <security>. En plus du domaine de sécurité, vous pouvez également spécifier le run-as principal, qui change le principal que l'EJB exécute.

Exemple 10.5. Exemple de déclaration de domaine de sécurité dans un EJB


<security>
  <ejb-name>*</ejb-name>
  <security-domain>myDomain</security-domain>
  <run-as-principal>myPrincipal</run-as-principal>
</security>


10.6.13. JASPI (Java Authentication SPI for Containers)

10.6.13.1. Sécurité Java Authentication SPI pour Conteneurs (JASPI)

Java Application SPI pour Conteneurs (JASPI ou JASPIC) est une interface enfichable pour applications JSR-196 du Java Community Process. Consulter http://www.jcp.org/en/jsr/detail?id=196 pour obtenir des informations sur la spécification.

10.6.13.2. Configuration de la sécurité Java Authentication SPI pour conteneurs (JASPI)

Pour s'authentifier auprès d'un fournisseur JASPI, ajouter un élément <authentication-jaspi> à votre domaine de sécurité. La configuration est similaire à celle d'un module d'authentification standard, mais les éléments de module de login sont inclus dans l'élément <login-module-stack>. La structure de configuration est la suivante :

Exemple 10.6. Structure de l'élément authentication-jaspi

<authentication-jaspi>
	<login-module-stack name="...">
	  <login-module code="..." flag="...">
	    <module-option name="..." value="..."/>
	  </login-module>
	</login-module-stack>
	<auth-module code="..." login-module-stack-ref="...">
	  <module-option name="..." value="..."/>
	</auth-module>
</authentication-jaspi>


Le module de connexion est lui-même configuré de la même façon que le module d'authentification standard.
Comme la console de gestion basée web n'expose pas la configuration des modules d'authentification JASPI, vous devez stopper la plateforme JBoss EAP 6 complètement avant d'ajouter la configuration directement dans le fichier EAP_HOME/domain/configuration/domain.xml ou dans le fichier EAP_HOME/standalone/configuration/standalone.xml.

10.7. Sécurité dans l'interface de gestion

10.7.1. Configuration Sécurité Utilisateur par défaut

Introduction

Toutes les interfaces de gestion de JBoss EAP 6 sont sécurisées par défaut. Cette sécurité existe sous deux formes :

  • Les interfaces locales sont sécurisées par un contrat SASL entre des clients locaux et le serveur auquel ils se connectent. Ce mécanisme de sécurité repose sur la capacité du client à accéder au système de fichiers local. C'est parce que l'accès au système de fichiers local permettrait au client d'ajouter un utilisateur ou encore de modifier la configuration pour déjouer les autres mécanismes de sécurité. Cela est conforme au principe selon lequel si l'accès physique au système de fichiers est réussi, les autres mécanismes de sécurité sont superflus. Le mécanisme passe par quatre étapes :

    Note

    L'accès HTTP est considéré comme éloigné, même si vous vous connectez à l'hôte local par HTTP.
    1. Le client envoie un message au serveur incluant une requête pour authentifier le mécanisme SASL local.
    2. Le serveur génère un token unique, qu'il écrit dans un fichier unique, et envoie un message au client avec le chemin d'accès fichier complet.
    3. Le client lit le token dans le fichier et l'envoie au serveur, pour vérifier qu'il a l'accès local au système de fichiers.
    4. Le serveur vérifie le token et efface le fichier.
  • Les clients distants, y compris HTTP, utilisent une sécurité basée domaine. Le domaine par défaut qui comprend les autorisations pour configurer la plate-forme JBoss EAP 6 à distance en utilisant les interfaces de gestion est ManagementRealm. Un script est fourni pour vous permettre d'ajouter des utilisateurs à ce domaine (ou à des domaines que vous créez). Pour plus d'informations sur la façon d'ajouter des utilisateurs, voir le chapitre Getting Started de JBoss EAP 6 Installation Guide. Pour chaque utilisateur, le nom d'utilisateur, un mot de passe haché et le domaine sont stockés dans un fichier.
    Domaine géré
    EAP_HOME/domain/configuration/mgmt-users.properties
    Serveur autonome
    EAP_HOME/standalone/configuration/mgmt-users.properties