Guide d'administration et de configuration

JBoss Enterprise Application Platform 6.1

À utiliser dans JBoss Enterprise Application Platform 6

Édition 3

Nidhi Chaudhary

Lucas Costi

Russell Dickenson

Sande Gilda

Vikram Goyal

Eamon Logue

Darrin Mison

Scott Mumford

David Ryan

Misty Stanley-Jones

Keerat Verma

Tom Wells

Résumé

Cet ouvrage est un guide d'administration et de configuration de JBoss Enterprise Application Platform 6 et de ses correctifs.

Preface

Chapitre 1. Introduction

1.1. JBoss Enterprise Application Platform 6

JBoss Enterprise Application Platform 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 va augmenter 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'automatiser les 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. Fonctionnalités de JBoss Enterprise Application Platform 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éploiement, 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'applications, 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é, 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 Enterprise Application Platform 6 utilise moins de ressources et est très efficace dans son utilisation de ressources de système. Cela est particulièrement avantageux pour les développeurs.

1.3. Les modes d'opération de JBoss Enterprise Application Platform 6

JBoss Enterprise Application Platform offre deux modes de fonctionnement des instances de JBoss Enterprise Application Platform. 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é (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 Enterprise Application Platform. Un mode de serveur autonome est un processus indépendant qui ressemble au mode d'exécution unique des anciennes versions de JBoss Enterprise Application Platform.
L'instance de JBoss Enterprise Application Platform 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 Enterprise Application Platform. Il s'agit d'un mode qui permet de gérer plusieurs instances de JBoss Enterprise Application Platform à partir d'un seul point de contrôle.
Une collection de serveurs gérés de manière centralisée sont connus comme étant membres d'un domaine. Toutes les instances de JBoss Enterprise Application Platform du domaine partagent une politique commune de la gestion. Un domaine se compose d'un contrôleur de domaine, d'un ou plusieurs contrôleurs hôte et zéro ou plusieurs groupes de serveurs par l'hôte.
Un contrôleur de domaine est le point central d'où le domaine est contrôlé. Il s'assure que chaque serveur est configuré conformément à la politique de gestion du domaine. Le contrôleur de domaine est également un contrôleur hôte. Un contrôleur d'hôte est un procédé physique ou un hôte virtuel sur lequel est exécuté le script domain.sh ou domain.bat. À la différence du contrôleur de domaine, les contrôleurs hôte sont configurés pour déléguer des tâches de gestion du domaine à eux-mêmes. Le contrôleur hôte sur chaque hôte interagit avec le contrôleur de domaine pour contrôler le cycle de vie des instances de serveur d'applications s'exécutant sur l'hôte et d'aider du contrôleur de domaine pour les gérer. Chaque hôte peut contenir plusieurs groupes de serveurs. Un groupe de serveurs est un ensemble d'instances de serveur, avec JBoss Enterprise Application Platform installé dessus, géré et configuré comme un ensemble. Étant donné que le contrôleur de domaine gère la configuration et les applications qui sont déployées sur des groupes de serveurs, chaque serveur d'un groupe de serveurs partage la même configuration et les mêmes déploiements.
Il est possible pour le contrôleur de domaine, un contrôleur d'hôte unique, et pour plusieurs serveurs d'exécuter dans la même instance de la plate-forme EAP, sur le même système physique. Les contrôleurs hôte sont liés à des hôtes spécifiques physiques (ou virtuels). Vous pouvez exécuter plusieurs contrôleurs hôte sur le même matériel si vous utilisez des configurations différentes, afin que les ports et les autres ressources n'entrent pas 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 Enterprise Application Platform 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 Enterprise Application Platform 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 Enterprise Application Server 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. Le 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 Enterprise Application Platfrom 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 Enterprise Application Platform 6 sensées être exécutées à partir de l'installation.
  • Une des configurations suivantes :
    • la façon dont le contrôleur contacte le contrôleur de domaines pour s'enregistrer lui-même et pour accéder à la configuration de domaine
    • la façon de rechercher et contacter un contrôleur de domaines éloigné
    • comment le contrôleur 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 d'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.
  • déployments : 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. About JBoss Enterprise Application Platform 6 Profiles

Le concept des profils qui ont été utilisées dans les versions précédentes d'Enterprise Application Platform n'est plus utilisé. JBoss Enterprise Application Platform 6 utilise maintenant un petit nombre de fichiers de configurations simples.
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 Enterprise Application Platform 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 serveur d'applications

2.1. Démarrer JBoss Enterprise Application Platform 6

2.1.1. Démarrer JBoss Enterprise Application Platform 6

Démarrer JBoss Enterprise Application Platform 6 d'une des manières suivantes :

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 Enterprise Application Platform 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 du serveur autonome JBoss EAP 6 démarre.

2.1.3. Démarrer JBoss Enterprise Application Platform 6 en tant que domaine géré

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 du serveur géré JBoss EAP 6 démarre.

2.1.4. Démarrer la plateforme Enterprise Application Platform avec une Configuration différente.

Si vous n'indiquez pas de fichier de configuration, le serveur démarrera avec le fichier par défaut. Malgré tout, 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 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 EAP_HOME/standalone/configuration/.

Note

Plusieurs exemples de configurations sont inclus dans les répertoires de configuration. 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. Domaine géré

    Pour un Domaine géré, fournir le nom du fichier de configuration comme option du paramètre --domain-config. Vous n'avez pas besoin de procurer le nom complet, si le fichier de configuration se trouve dans le répertoire EAP_HOME/domain/configuration/.

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

    Exemple 2.2. 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
  2. Serveur autonome

    Pour un Domaine autonome, fournir le nom du fichier de configuration comme option du paramètre --server-config. Vous n'avez pas besoin de procurer le nom complet, si le fichier de configuration se trouve dans le répertoire EAP_HOME/standalone/configuration/.

    Exemple 2.3. Utiliser un fichier de configuration alternatif pour un Serveur autonome Red Hat Enterprise Linux.

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

    Exemple 2.4. Utiliser un fichier de configuration alternatif pour un Serveur autonome Microsoft Windows.

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

La plateforme Enterprise Application Platform est maintenant en cours d'exécution, avec une configuration différente.

2.1.5. Stopper JBoss Enterprise Application Platform 6

La façon dont vous arrêtez la plate-forme JBoss Enterprise Application Platform 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 Enterprise Application Platform 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 Enterprise Application Platform 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 faîtes 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 Enterprise Application Platform 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 Enterprise Application Platform 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. Le 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.
-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

Vous pouvez démarrer et arrêter les serveurs par le Management CLI ou la Console de gestion.
Si vous exécutez une instance de Serveur Autonome, vous pourrez éteindre le serveur par l'opération shutdown du Management CLI. Il n'y a pas d'équivalent dans la Console de gestion, car vous avez la possibilité de passer par votre système de fichiers pour fermer l'instance en cours.
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.
Si vous souhaitez démarrer ou stopper un Domaine géré par le Management CLI, vous pouvez le faire en utilisant les commandes appropriées à la situation.

Exemple 2.6. Démarrer/Stopper un Groupe de serveurs dans un Domaine géré via un Management CLI

# start server group named main
/server-group=main:start-servers
# stop server group named main
/server-group=main:stop-servers

Exemple 2.7. Démarrer/Stopper une Instance de serveur dans un Domaine géré via un Management CLI

# start server instance named server-one
/host=master/server-config=server-one:start
# stop server instance named server-one
/host=master/server-config=server-one:stop

Exemple 2.8. /Stopper un Hôte de serveur dans un Domaine géré via un Management CLI

# stop server host named master
/host=master:shutdown

2.2.2. Démarrer un serveur par la Console de gestion

Procédure 2.5. Démarrer le serveur

  1. Naviguez dans Server Instances dans la Console de gestion

    1. Sélectionner l'onglet Runtime en haut et à droite de la console.
    2. Sélectionner Domain StatusServer Instances à partir du menu à gauche de la console.
    Instances du serveur

    Figure 2.1. Instances du serveur

  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.
  3. Cliquer sur le bouton Start

    Cliquer sur le bouton Start en haut de la liste du serveur pour ouvrir la fenêtre de dialogue de confirmation. Cliquer sur le bouton Confirm pour démarrer le serveur.
    Confirmer la modification de serveur

    Figure 2.2. Confirmer la modification de serveur

Résultat

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

Serveur démarré

Figure 2.3. Serveur démarré

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 Server Instances dans la Console de gestion

    1. Sélectionner l'onglet Runtime en haut et à droite de la console.
    2. Sélectionner Domain StatusServer Instances à partir du menu à gauche de la console.
    Instances du serveur

    Figure 2.4. Instances du serveur

  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. Cliquez sur le bouton Stop.

    Cliquer sur le bouton Stop en haut de la liste du serveur pour ouvrir la fenêtre de dialogue de confirmation. Cliquer sur le bouton Confirm pour stopper le serveur.
Résultat

Le serveur sélectionné est stoppé.

Serveur stoppé

Figure 2.5. Serveur 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 Enterprise Application Platform 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 profite 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.9. Exemple de chemin d'accès relatif du répertoire de logging

<file relative-to="jboss.server.log.dir" path="server.log"/>

JBoss Enterprise Application Platform 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 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.log.dir Le répertoire que le serveur va utiliser pour le stockage de fichier de journalisation.
jboss.server.tmp.dir Le répertoire que le serveur va utiliser pour le stockage de fichiers temporaires.
jboss.domain.servers.dir Le répertoire sous lequel le contrôleur hôte va créer la zone de travail des instances de serveurs individuelles, dans un domaine géré.
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.10. 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 anciennement 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.11. 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.12. 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. Les fichiers de configuration de JBoss Enterprise Application Platform 6

La configuration de JBoss Enterprise Application Platform 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 sont entrain de modifier 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ée.

2.4.5. Télécharger un snapshot de configuration

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 Enterprise Application Platform 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 Enterprise Application Platform 6 offre trois approches différentes pour configurer et gérer des serveurs: une interface web, la ligne de commande et un ensemble de fichiers de configuration XML. Malgré 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 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 de l'autre pour accéder à l'interface web. Par défaut, il s'exécute sur le port 9990.

Exemple 3.1. Exemple de fichier de configuraiton HTTP API

<management-interfaces>
    [...]
    <http-interface interface="management" port="9990"/>
<management-interfaces>
La console web est servie 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. TableTitle

URL Description
http://localhost:9990/console La Console de gestion à laquelle accéde l'hôte local, et qui contrôle la configuration du Domaine géré.
http://hostname:9990/console La Console de gestion accédée à distance, qui nomme l'hôte et qui contrôle la configuration du Domaine géré.
http://hostname:9990/management 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-typed».

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ée avec un Contrôleur hôte ou un Serveur autonome. Il doit être activé pour utiliser le ManagementCLI. 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 interface="management" port="9999"/>
    [...]
<management-interfaces>

3.3. Console de gestion et Management CLI

Dans JBoss Enterprise Application Platform 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 management

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

3.4.2. Connectez-vous à la Console de management

Pré-requis

  • JBoss Enterprise Application Platform 6 doit être en cours d'exécution.

Procédure 3.1. Connectez-vous à la Console de management

  1. Naviguez vers la page de démarrage de la Console de management

    Naviguez vers la Console de management. 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 management.
  2. Connectez-vous à la Console de management

    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 management.
    L'écran de connexion de la Console de management.

    Figure 3.1. Écran de connexion de la Console de management

Résultat

Une fois connecté, une des pages de la Console de management 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 des 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 management

Procédure 3.3. Configurer le serveur

  1. Naviguez dans le panneau Server Configuration qui se trouve dans la Console de management

    1. Sélectionnez l'onglet Server qui se trouve en haut et à droite de la console.
    2. Déployez l'élément de menu Server Configurations qui se trouve à gauche de la console et sélectionnez le serveur qui convient dans la liste.
    Configuration du serveur

    Figure 3.2. Configuration du serveur

  2. Modifier la configuration du serveur

    1. Sélectionner le bouton Edit qui si trouve en dessous de la liste de serveurs.
    2. Procédez avec les changements des attributs de configuration.
    3. 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 management

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

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

    1. Sélectionner l'onglet Runtime en haut et à droite 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.
    Gestion des déploiements de domaines

    Figure 3.3. Gestion des déploiements de domaines

  2. Ajouter le contenu du déploiement.

    Sélectionner le bouton Add en haut et à droite du panneau Deployments. Une boîte de dialogue Upload apparaîtra.
  3. Choisir un fichier à déployer

    Dans la boîte de dialogue, sélectionner le bouton Choose File. 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é.
    Sélection du déploiement

    Figure 3.4. Sélection du déploiement

  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 Upload. Sélectionner le bouton Save pour charger le fichier une fois que les noms auront été vérifiés.
    Vérifier les noms de déploiement

    Figure 3.5. Vérifier les noms de déploiement

Résultat

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

Déploiement téléchargé dans une instance de serveur autonome

Figure 3.6. Déploiement téléchargé dans une instance de serveur autonome

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 management

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 et à gauche de la console, puis, sélectionner 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.
    3. Cliquer sur l'onglet Log Categories en haut de la console.
    Panneau de Logging

    Figure 3.7. Panneau de Logging

  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 zône 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 management

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

  1. Se rendre dans la vue Server Groups

    Sélectionner l'onglet Hosts en haut et à droite.
  2. Sélectionner l'onglet Group Configurations dans le menu Server Groups dans la colonne de gauche.
    La vue Server Groups

    Figure 3.8. La vue Server Groups

  3. Ajouter un groupe de serveurs

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

    1. Saisir un nom pour le groupe de serveurs
    2. Sélectionner le profil 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.
    Le dialogue Create Server Group

    Figure 3.9. Le dialogue Create Server Group

Résultat

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

3.5. Le Management 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 Enterprise Application Platform 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. Launch CLI in Linux or 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. General and Context-Sensitive Help

  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 Enterprise Application Platform 6 CLI. Ces commandes ne peuvent être utilisées que pour travailler en lots.

Tableau 3.2. Commandes CLI Mode Lot

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

3.5.8. Utiliser les opérations et les commandes 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 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ées en exécutant cette commande avec ce nom comme argument.
cd Change le chemin du nœud en cours à l'argument. Le chemin du nœud en cours est utilisé comme adresse pour les requêtes opérationnelles qui ne contiennent pas la partie adresse. Si une opération n'inclut pas d'adresse, l'adresse incluse sera considérée comme relative au chemin du nœud en cours. Le chemin du nœud en cours peut finir en type de nœud. Dans ce cas, exécuter une opération en spécifiant un nom de nœud est suffisant, comme logging:read-resource.
clear Efface l'écran
command Vous permet d'ajouter, de supprimer ou de lister des commandes existantes de type standard. Une commande de type standard est une commande qui est assignée à un type de nœud spécifique et qui vous permet d'effectuer une opération disponible à une instance de ce type. Elle vous permet de modifier n'importe quelle propriété exposée par le type de n'importe quelle instance existante.
connect Connecte le contrôleur à l'hôte et au port spécifiés.
connection-factory Définit une usine de connexions
data-source Gère les configurations de sources de données JDBC dans le sous-système de la source de données.
deploy Déploie l'application désignée par le chemin d'accès au fichier ou bien, active une application qui est pré-existante, mais désactivée dans le référentiel. Si elle est exécutée sans argument, cette commande énumérera tous les déploiements existants.
help Affiche le message d'asistance. Peut être utilisé avec l'argument --commands pour fournir aux commandes données des résultats sensibles au contexte.
history Affiche l'historique en mémoire de la commande CLI et affiche un statut pour savoir si l'expansion de l'historique est activée ou non. Peut être utilisé avec des arguments pour effacer, désactiver, ou activer l'expansion de l'historique selon les besoins.
jms-queue Définit une file d'attente JMS dans le sous-système de messagerie.
jms-topic Définit un topic dans le sous-système de messagerie.
ls Lister les contenus du chemin d'accès au nœud. Par défaut, le résultat est imprimé dans des colonnes qui utilisent toute la largeur du terminal. Utiliser -l affichera les résultats sur la base d'un nom par ligne.
pwd Affiche le chemin d'accès du nœud pour le nœud en cours
quit Termine l'interface de ligne de commande.
read-attribute Affiche la valeur et, suivant les arguments, la description de l'attribut d'une ressource gérée.
read-operation Affiche la description d'une opération particulière, ou bien liste toutes les opérations si aucune n'est spécifiée.
undeploy Annule une demande lorsque celle-ci est exécutée avec le nom de l'application prévue. Peut être exécuté avec des arguments pour supprimer également l'application du référentiel. Imprime la liste de tous les déploiements existants si exécutée sans application spécifiée.
version Affiche la version de serveur d'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 configuratino 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 les 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 ne 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 Management CLI

3.6.1. Affiche 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. Affiche 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",
        "reply-properties" => {
            "type" => OBJECT,
            "value-type" => {
                "directory" => {
                    "type" => STRING,
                    "description" => "The directory where the snapshots are stored"
                },
                "names" => {
                    "type" => LIST,
                    "value-type" => STRING,
                    "description" => "The names of the snapshots within the snapshots directory"
                }
            }
        },
        "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",
        "shutdown",
        "take-snapshot",
        "upload-deployment-bytes",
        "upload-deployment-stream",
        "upload-deployment-url",
        "validate-address",
        "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 à 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, faîtes 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és 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-admin.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 disconnecté 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 de la commande Management 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.

Chapitre 4. Gestion des utilisateurs

4.1. Création d'utilisateur

4.1.1. Ajouter l'utilisateur d'origine dans les interfaces de gestion

Aperçu

La gestion des interfaces de gestion de la plate-forme JBoss EAP 6 sont sécurisées par défaut, et il n'y a pas de comptes d'utilisateur disponibles au départ, à moins que vous ayez installé la plateforme par l'installateur graphique. Il s'agit d'une précaution de sécurité, afin de prévenir les atteintes à la sécurité des systèmes à distance pour cause de simples erreurs de configuration. L'accès non HTTP local est protégé par un mécanisme SASL, par une négociation qui a lieu 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. Pour plus d'informations sur la configuration de sécurité par défaut, reportez-vous à Section 10.7.1, « Configuration Sécurité Utilisateur par défaut ».

Note

La communication HTTP avec la plate-forme EAP 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.

    Remplacer le répertoire JJP_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.

    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. Choisissez le domaine pour l'utilisateur :

    L'invite suivante se rapporte au domaine où l'utilisateur sera ajouté. Pour un utilisateur ayant les permissions de gérer JBoss EAP 6, choisissez la valeur par défaut, qui est ManagementRealm.
  4. Saisir le nom d'utilisateur et le mot de passe que vous souhaitez.

    Lorsque vous y êtes invité, saisir le domaine de sécurité, le nom d'utilisateur et le mot de passe. Appuyer sur ENTER sélectionne le domaine ManagementRealm par défaut, qui permet à l'utilisateur d'administrer la plate-forme JBoss EAP 6 en utilisant les interfaces de gestion. Vous devez ajouter au moins un utilisateur dans le domaine. Vous êtes invité à confirmer l'information. Si vous êtes satisfait, saisir yes .
  5. Décidez si l'utilisateur représente une instance de serveur de JBoss Enterprise Application Platform 6 à distance.

    En plus des administrateurs, un autre type d'utilisateur qui a parfois besoin d'être ajouté à JBoss Enterprise Application Platform 6 dans le domaine ManagementRealm est un utilisateur qui représente une autre instance de JBoss Enterprise Application Platform 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.
  6. 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.
  7. 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
  8. Vous pouvez supprimer la sortie normale du script utilisateur ajouter 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. Ajout d'un utilisateur dans l'interface de gestion

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 permettent é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 golbal 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 profuil 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 réseau et leur relation aux interfaces réseau utiles à votre configuration JBoss Enterprise Application Platform 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 du 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 à 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 uniques. Le serveur autonome contient un de ces groupes, le groupe standard-sockets, et ne peut pas créer de groupes supplémentaires. À la place, vous pouvez créer des fichiers de configuration de serveur autonome alternatif. Pour le domaine géré cependant, vous pouvez créer des groupes de liaisons de sockets et configurer les liaisons de sockets qu'ils contiennent selon vos besoins. Le tableau suivant montre les attributs disponibles pour chaque liaison de sockets.

Tableau 5.2. Attributs de liaisons de sockets

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 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 du 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) ou Port (Port).
        3. Cliquer sur le bouton Save pour terminer.

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

Les ports de réseau utilisés par la configuration par défaut de la plateforme JBoss EAP 6 dépendent 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 Multicast. Utilisé pour la découverte de paires dans les groupements HA. Oui Non Oui Non
jgroups-mping 45700 Multicast. Utilisé pour découvrir l'appartenance de groupe d'orgine dans un cluster HA. Oui Non Oui Non
jgroups-tcp 7600 Découverte de paires 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 paires unicast dans les groupements HA avec TCP. 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 difffusion 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 multicast de communication entre l'équilibreur de charge HTTP et JBoss Enterprise Application Platform. Oui Non Oui Non
osgi-http 8090 Utilisé par les composants internes qui utilisent le sous-système OSGi. 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 port (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 la commande write pour écrire une nouvelle valeur d'attribut de port offset. L'exemple suivant met à jour la valeur socket-binding-port-offset du server-two à 250. Ce serveur est un membre du groupe d'hôte local par défaut.Vous aurez besoin d'un redémarrage pour que les changements puissent voir lieu.
        [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électionnez l'onglet Hosts qui se trouve 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 le IPv6 Networking de l'installation JBoss Enterprise Application Platform 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 section couvre la configuration de l'installation JBoss Enterprise Application Platform 6 pour qu'elle favorise les adresses IPv6 à travers les fichiers de configuration.

Procédure 5.3. Configurer l'installation JBoss Enterprise Application Platform 6 pour qu'elle favorise 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 de 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 aux 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émarrer avec JDBC et avec les sources de données, voir la section sur le Pilote JDBC du Guide d'administration et de configuration de JBoss Enterprise Application Platform 6.

6.1.2. Bases de données supportées dans JBoss Enterprise Application Platform 6

Liste de bases de données JDBC conformes supportées par JBoss Enterprise Application Platform 6 : http://www.redhat.com/resourcelibrary/articles/jboss-enterprise-application-platform-supported-configurations.

6.1.3. Types de sources de données

Les deux grands types de ressources sont dénommées 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émentaires.
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 Enterprise Application Platform 6 inclut une base de données H2. C'est un système de gestion de base de données relationnelle léger qui fournit aux développeurs la possibilité de créer rapidement des applications et c'est l'exemple de source de données exemple 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 dans JBoss Enterprise Application Platform 6  ».

6.1.5. Déploiement des fichiers -ds.xml

Dans JBoss Enterprise Application Platform 6, les sources de données sont définies comme ressources du sous-système du serveur. Dans les versions précédentes, on avait besoin d'un fichier de configuration de source de données *-ds.xml dans le répertoire de déploiement de la configuration du serveur. Les fichiers *-ds.xml peuvent encore être déployés dans JBoss Enterprise Application Platform 6, selon le schéma suivant : http://docs.jboss.org/ironjacamar/schema/datasources_1_1.xsd.

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, les pilotes JDBC de votre fournisseur de source de données doivent être installés dans un endroit où la plate-forme d'applications EAP puisse les utiliser. Le serveur d'applications JBoss Enterprise vous permet de déployer ces pilotes tout comme tout autre déploiement. Cela signifie que, si vous utilisez un domaine géré, vous pourrez les déployer sur plusieurs serveurs dans un groupe de serveurs.

Note

La meilleure méthode d'installation des pilotes JDBC est de les installer comme module principal. Pour installer le pilote JDBC comme module principal, voir: Section 6.2.2, « Installer un Pilote JDBC comme Core Module ».
Prérequis

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

Prérequis

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 qui ressemble à l'exemple suivant :

    Exemple 6.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.
  4. Démarrer le serveur.
  5. Démarrer le Management 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.2. 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 communes à la plate-forme JBoss EAP. Ces liens pointent vers des sites de tiers qui ne sont pas contrôlés, ni 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 du fournisseur de votre base de données

6.2.4. Accès aux Classes Spécifique 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 classe 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.3. 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.4. Exemple de fichier jboss-deployment-structure.xml

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

Exemple 6.5. 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. Non-XA Datasources

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 Enterprise Application Platform 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 en utilisant 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électionnez l'onglet Profil qui se trouve en haut et à droite de la console.
          • Mode Domaine

            1. Sélectionnez l'onglet Profiles qui se trouve en haut et à droite 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.
        Panneau de sources de données

        Figure 6.1. Panneau de sources de données

      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électionnez l'onglet Profil qui se trouve en haut et à droite de la console.
          • Mode Domaine

            1. Sélectionnez l'onglet Profiles qui se trouve en haut et à droite 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.
        Panneau de sources de données

        Figure 6.2. Panneau de sources de données

      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é

Cette section couvre les étapes à suivre pour supprimer une source de données XA de JBoss Enterprise Application Platform 6, par 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 un source de données non-XA :
        data-source remove --name=DATASOURCE_NAME
    • Console de gestion

      1. Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion

          • Mode autonome

            Sélectionnez l'onglet Profil qui se trouve en haut et à droite de la console.
          • Mode Domaine

            1. Sélectionnez l'onglet Profiles qui se trouve en haut et à droite 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.
        Panneau de sources de données

        Figure 6.3. Panneau de sources de données

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

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électionnez l'onglet Profil qui se trouve en haut et à droite de la console.
          • Mode Domaine

            1. Sélectionnez l'onglet Profiles qui se trouve en haut et à droite 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.
        Panneau de sources de données

        Figure 6.4. Panneau de sources de données

      2. Sélectionner le panneau 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 appuyez sur Next.
        5. Saisir les paramètres de connexion dans l'assistant Create XA Datasource et appuyez 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électionnez l'onglet Profil qui se trouve en haut et à droite de la console.
          • Mode Domaine

            1. Sélectionnez l'onglet Profiles qui se trouve en haut et à droite 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.
        Panneau de sources de données

        Figure 6.5. Panneau de sources de données

      2. Sélectionner le panneau 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é

Cette section couvre les étapes à suivre pour supprimer une source de données XA de JBoss Enterprise Application Platform 6, par 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. Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion

          • Mode autonome

            Sélectionnez l'onglet Profil qui se trouve en haut et à droite de la console.
          • Mode Domaine

            1. Sélectionnez l'onglet Profiles qui se trouve en haut et à droite 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.
        Panneau de sources de données

        Figure 6.6. Panneau de sources de données

      2. Sélectionner le panneau 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 Enterprise Application Platform 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 devez utiliser un module personnalisé, vous pourrez 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
i 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.6. Exemple de domaine de sécurité

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

Exemple 6.7. 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 les éléments enfant qui représentent les paramètres de sécurité. Consulter Tableau 6.8, « Paramètres de sécurité ».
validation
Contient les éléments enfant qui représentent les paramètres de validation. Consulter Tableau 6.9, « Paramètres de validation ».
timeout
Contient les éléments enfant qui représentent les paramètres de timeout. Consulter Tableau 6.10, « Paramètre de timeout ».
énoncé
Contient les éléments enfant qui représentent les paramètres d'énoncé. Consulter 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 connexion 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 les éléments enfant qui représentent les paramètres de pooling. Consulter 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é 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 enfant qui représentent les paramètres de pooling. Consulter 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 enfant qui représentent les paramètres de recouvrement. Consulter 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 doit être vidé en cas d'erreur. Les valeurs valides sont :
  • FailingConnectionOnly
  • IdleConnections
  • EntirePool
La valeur par défaut est FailingConnectionOnly.
allow-multiple-users Indique si plusieurs utilisateurs pourront accéder à la source de données à travers la méthode getConnection (utilisateur, mot de passe), et si le type de pool interne devrait expliquer 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 niveau de connexion est effectuée lorsqu'une fabrique de connexion tente de faire correspondre une connexion gérée avec un ensemble donné.
Indiquer "true" pour validate-on-match n'est pas normalement fait en conjonction avec "true" pour background-validation. Validate-on-match est utile quand un client doit avoir une connexion vallidée avant utilisation. Ce paramètre est à true par défaut.
background-validation
Indique que les connexions sont validées sur un thread d'arrière plan. La validation d'arrière plan est une optimisation de performance si non utilisée en conjonction avec validate-on-match. Si validate-on-match est sur true, utiliser background-validation peut aboutir à des contrôles qui n'ont plus cours. La validation d'arrière plan ne vous donne pas la possibilité d'obtenir des mauvaises connexions pour le client (une connexion se détériore entre le balayage de validation et avant qu'elle soit remise au client), dont l'application client doit prendre en compte cette possibilité.
background-validation-millis La durée, en millisecondes, d'exécution de la validation d'arrière-plan.
use-fast-fail
Si true, l'allocation de connexion échouera dès la première tentative, quand la connexion est invalide. La valeur par défaut est false.
stale-connection-checker
Une instance de org.jboss.jca.adapters.jdbc.StaleConnectionChecker qui fournit une méthode de booléen isStaleConnection(SQLException e). Si cette méthode renvoie true, l'exception sera contenue dans une org.jboss.jca.adapters.jdbc.StaleConnectionException, une sous-classe de SQLException.
exception-sorter
Une instance de org.jboss.jca.adapters.jdbc.ExceptionSorter qui fournit une méthode de booléen isExceptionFatal(SQLException e). Cette méthode valide le fait que l'exception doit être envoyée à toutes les instances de javax.resource.spi.ConnectionEventListener comme message connectionErrorOccurred.

Tableau 6.10. Paramètre de timeout

Paramètre Description
use-try-lock Utilise tryLock() à la place de lock(). Tente d'obtenir le verrou pour le nombre de secondes configuré, avant le timeout, au lieu d'échouer immédiatement quand le verrou n'est pas rendu 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, en millisecondes, de blocage en attendant une connexion. Après de délai, l'exception est envoyée. Cela aura pour effet de bloquer uniquement tandis qu'on attend un permis de connexion, et cela n'aura pas pour effet de lancer une exception si la création d'une nouvelle connexion prend trop de temps. La valeur par défaut est de 30000, ce qui correspond à 30 secondes.
idle-timeout-minutes
La durée maximum, en minutes, avant qu'une connexion inutile puisse être fermée. La durée maximum dépend du temps de balayage de l'idleRemover, qui correspond à la moitié du idle-timeout-minutes le plus petit de n'importe quel pool.
set-tx-query-timeout
Indique si on doit définir le timeout d'interrogation par rapport au temps qui reste avant le timeout de transaction. Si aucune transaction n'existe, on utilisera le timeout de recherche qui a été configuré. La valeur par défaut est false.
query-timeout Timeout pour les recherches, en secondes. La valeur par défaut est «no timeout».
allocation-retry Le nombre de tentatives de connexions avant d'envoyer une connexion. La valeur par défaut est 0, pour qu'une exception puisse être envoyée à la première défaillance.
allocation-retry-wait-millis
Le temps, en millisecondes, qu'il faut attendre avant de retenter d'allouer une connexion. La valeur par défaut est 5 000, soit 5 secondes.
xa-resource-timeout
Si la valeur est non nulle, elle passe à la méthode XAResource.setTransactionTimeout.

Tableau 6.11. Paramètres d'instruction

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

Valeurs valides

  • true: les instructions et les ensembles de résultats sont suivis, et un avertissement sera émis s'ils ne sont pas fermés.
  • false: ni les instructions, ni les ensembles de résultats ne seront suivis.
  • nowarn: les instructions sont suivies, mais il n'y a aucun avertissement. Valeur par défaut.
prepared-statement-cache-size Le nombre d'instructions préparées par connexion, dans le cache LRU (Least Recently Used / Utilisé le moins souvent 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 fatale pour la connexion sur laquelle l'exception a été lancée
org.jboss.jca.adapters.jdbc.spi.StaleConnection <stale-connection-checker> Met les SQLExceptions caduques dans une 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 Enterprise Application Platform 6 comprend également les 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 bases 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 à spécifier l'argument include-runtime=true, car tous les statistiques sont des informations de runtime et la valeur par défaut est false.

6.6.5. Statistiques de bases de données

Statistiques principales

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

Tableau 6.15. Statistiques principales

Nom Description
ActiveCount
Le nombre de connexions actives. Chacune des connexions est soit utilisée par une autre application ou disponible dans le 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.8. 

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

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

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

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

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>
      <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. L'exemple de source de données 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.13. 

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

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

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

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

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>
      <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>
      <recovery-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>
      </recovery-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.18. 

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

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>
      <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 la gestion de dépendance et le chargement de classe. JBoss Enterprise Application Platform 6 identifie deux types de modules, parfois appelés modules statiques et dynamiques. 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 telles que JBoss Logging, par exemple.
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 Enterprise Application Platform 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 comme modules dynamiques et utilisent des dépendances pour accéder aux API fournis par JBoss Enterprise Application Platform 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é.
Les dépendances implicites sont ajoutées automatiquement par le serveur d'applications quand on trouve certaines conditions ou métadonnées dans un déploiement. Les API Java EE 6 fournis avec JBoss Enterprise Application Platform 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.1. 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 server de JBoss Enterprise Application Platform.
  2. Ouvrir le fichier de configuration du serveur

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

    Chercher la configuration de sous-système EE. 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 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 ler serveur

    Lancer à nouveau le serveur JBoss Enterprise Application Platform pour qu'il commence d'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, « Modules inclus » pour obtenir la liste des modules statiques inclus dans JBoss Enterprise Application Platform 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. Naviguez dans le panneau EE Subsystem.
    Panneau EE Subsystem

    Figure 7.1. Panneau EE Subsystem

  2. Cliquer sur le bouton Add dans la section Global Modules. La boîte de dialogue Create Module apparaîtra.
  3. Saisir alors le nom du module et le slot de module, en option.
  4. 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. 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 Enterprise Application Platform 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 Boss Enterprise Application Platform 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 Enterprise Application Platform 6. Cette tâche vous montre comment installer le module.

Prérequis :

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 Enterprise Application Platform 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 de œ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 et à droite de la console.
    2. Sélectionner l'option DeploymentsManage 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 Deployments affiche tous les déploiements d'applications disponibles et leurs statuts.
      Déploiements disponibles

      Figure 9.1. Déploiements disponibles

      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éploiements disponibles dans un serveur autonome.

        Figure 9.2. Déploiements disponibles dans un serveur autonome.

    • 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.
      Déploiements disponibles dans un domaines géré.

      Figure 9.3. Déploiements disponibles dans un domaines géré.

      1. Activer l'application dans un domaine géré

        Cliquer sur le bouton Add to Groups 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.
        Sélectionnner les groupes de serveurs pour le déploiement de l'application

        Figure 9.4. Sélectionnner les groupes de serveurs pour le déploiement de l'application

      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.
        Confirmation du déploiement d'applications dans les groupes de serveurs.

        Figure 9.5. Confirmation du déploiement d'applications dans les groupes de serveurs.

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 et à droite de la console.
    2. Sélectionner l'option DeploymentsManage 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 Deployments affiche tous les déploiements d'applications disponibles et leurs statuts.
      Déploiements disponibles

      Figure 9.6. Déploiements disponibles

      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. Confirmer 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.
        Confirmer l'application à désactiver

        Figure 9.7. Confirmer l'application à désactiver

    • Supprimer le déploiement à partir d'un domaine géré

      La section Deployment Content contient un tableau Content Repository qui affiche tous les déploiements d'applications et leurs statuts.
      Déploiements disponibles dans un domaines géré.

      Figure 9.8. Déploiements disponibles dans un domaines géré.

      1. Désactiver l'application dans un domaine géré

        Cliquer sur l'onglet Server Group Deployments pour afficher les groupes de serveurs et le statut de leurs applications déployées.
        Déploiements du groupe de serveurs

        Figure 9.9. Déploiements du groupe de serveurs

      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. Confirmer 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.
        Confirmer l'application à désactiver

        Figure 9.10. Confirmer l'application à désactiver

      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.
        Confirmation du déploiement d'applications à partir d'un groupe de serveurs.

        Figure 9.11. Confirmation du déploiement d'applications à partir d'un groupe de serveurs.

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 avec le Management 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écutez 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
    'test-application.war' déployé..
    • 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 
      'test-application.war' déployé.
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écutez 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-groupsSuccessfully undeployed test-application.war.   
    
    
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écutez 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 
    'test-application.war' déployé.
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écutez 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 
    Successfully undeployed test-application.war.
Résultat

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

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éer 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époiement. 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 une 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é or 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 complition.
.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 60
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'accè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 scripts de lots (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 Section 9.4.6, « Référence pour attributs de scanneur de déploiement ».

Le scanneur de déploiement est un sous-système de JBoss Enterprise Application Platform 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étermine 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 noeud root, ou bien par la commande cd pour passer au noeud 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" => 60,
              "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   60                    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 noeud dépendant, qui peut être acccédé en utilisant la commande cd et la saisie semi-automatique via la touche TAB pour passer au noeud de scanneur par défaut.
    [standalone@localhost:9999 /] cd subsystem=deployment-scanner/scanner=default
    
    1. Active le déploiement automatique du contenu explosé.

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

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

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

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

      Utiliser l'opération write-attribute pour modifier la référence relative du chemin du système de fichier ainsi définie dans la sections des chemins d'accès du fichier de configuration XML. Noter 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 5000 millisecondes à 10000 millisecondes.
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-interval,value=10000)
      {"outcome" => "success"}
      
Résultat

Vos modifications de configuration sont sauvegardés 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 Enterprise Application Platform 6 Quick Starts. Le projet helloworld contient un fichier POM qui initialise le jboss-as-maven-plugin. Ce pugin fournit des simples opérations pour déployer ou supprimer le déploiement d'applications vers ou en provenance su 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 redéployée.
    [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 d'applications dans Maven. L'exemple fourni utilise l'application jboss-as-helloworld.war qui se trouve dans la collection Enterprise Application Server Quick Starts. Le projet helloworld contient un fichier POM qui initialise le jboss-as-maven-plugin. Ce plug-in 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 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 Application Platform

JBoss Enterprise Application Platform 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. Éffectuer 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>
    

Chapitre 10. Sécuriser JBoss Enterprise Application Platform

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

Le sous-système de sécurité fournit l'infrastructure pour la fonctionnalité de sécurité de JBoss Enterprise Application Platform. La plupart des éléments de configuration ne doivent pas souvent utiliser 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 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 prône à 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 Deep Copy entraîne la copie totale de la structure des données et de toutes ses données associées, si elles sont marquées comme «clonables». C'est plus sûr 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 à 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 sécurité et le mapping de sécurité. 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 font pas partie de la configuration par défaut. Les éléments <subject-factory> et <security-properties> ont été dépréciés à partir de JBoss Enterprise Application Platform 6.1.

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 la 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 comportemens 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.
default-callback-handler-class-name
Spécifie un nom de classe global pour l'implémentation de CallbackHandler à utiliser avec les modules de connexion.
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 la nom de classe d'implémentation MappingManager à utiliser.
<subject-factory>
L'usine 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 l'usine 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é fait une référence à l'original, au lieu de copier toute la structure de données. Ce comportement est plus efficace, mais prône à 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 tout ce que ses données associées, quand elles sont marquées «clonables». C'est plus sûr 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 le 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 à un URL tel que 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é Depp 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. Cochez 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 Enterprise Application Platform. La configuration de la sécurité est désormais gérée de façon centralisée, ou par le contrôleur de domaine 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é, qui contient des informations sur les actions qui sont autorisées ou interdites. Dans la teminologie de sécurité, on parle de «rôle».
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 de 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 Enterprise Application Platform. 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 à succès s'appelle un Principal, en termes de sécurité déclarative Java Enterprise Edition.
JBoss Enterprise Application Platform 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 le 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 Domane de sécurité

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

Procédure 10.2. Configurer l'authentification dans un Domane 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 profile à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichge 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
    Le 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, é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 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'une d'entre elles.

Vous pouvez désactiver le comportement d'ajout de cette option de module, en définissant la propriété de système à true en démarrant la plate-forme JBoss Enterprise Application Platform. 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 Enterprise Application Platform 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 sil 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
    Le 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 Enterprise Application Server 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 de fournisseurs d'auditing de sécurité 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 Modules, et sélectionner 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 modifier une option existante, supprimez-là en cliquant sur l'étiquette Remove, et ajoutez-la à nouveau grâce aux options qui conviennent en cliquant le bouton Add.
Résultat

Votre module d'auditing 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 Sécurity Mapping, connectez-vous à 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

    Si vous avez besoin d'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, supprimez-là 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'utilise. Cette rubrique décrit les étapes requises pour utiliser un domaine de sécurité dans votre application.

Procédure 10.6. Configurer 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.
    • Configurer le domaine de sécurité dans le fichier de configuration du serveur

      Le domaine de la sécurité est configuré dans le sous-système de sécurité du fichier de configuration du serveur. Si l'instance de JBoss Enterprise Application Platform s'exécute dans un domaine géré, il s'agira du fichier domain/configuration/domain.xml. Si l'instance de JBoss Enterprise Application Platform 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 Enterprise Application Platform 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 le Management 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. Ajouter 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 ejb-security Quickstart dans le package JBoss Enterprise Application Platform 6 Quickstarts disponible à partir du Portail Clients 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. Il a été défini dans JSR-115, qui se trouve sur le site Web de Java Community Process http://jcp.org/en/jsr/detail?id=115. A fait partie de la spécification Java Enterprise Edition (Java EE) depuis la version 1.3 de Java EE.
JBoss Enterprise Application Platform 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), vous devez configurer votre domaine de sécurité avec le module qui convient, puis modifiez votre fichier jboss-web.xml pour y inclure les paramètres qu'il faut.
Ajouter JACC 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 required. 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> à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 selon de la méthode utilisée pour les 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 dépendant <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</s:security-domain>
  <run-as-principal>myPrincipal</s:run-as-principal>
</s:security>


10.6.13. Java Authentication SPI for Containers (JASPI)

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

Java Application SPI pour Conteneurs (JASPI or 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 Enterprise Application Platform 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. Management Interface Security

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

Introduction

Toutes les interfaces de gestion de JBoss Enterprise Application Platform 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 (Guide de démarrage) de la plateforme JBoss EAP 6. Pour chaque utilisateur, le nom d'utilisateur, un mot de passe haché et le domaine sont stockés dans un fichier.
    Serveur autonome
    JPP_HOME/standalone/configuration/mgmt-users.properties
    Même si les contenus de mgmt-users.properties sont masqués, le fichier doit toujours être considéré comme un fichier sensible. Il est recommandé qu'il soit défini sur le mode de fichier 600, qui ne donne aucun accès autre que l'accès en lecture et écriture au propriétaire du fichier.

10.7.2. Aperçu Général de la Configuration de l'Interface de Gestion avancée

La configuration de l'interface de Gestion EAP_HOME/domain/configuration/host.xml or EAP_HOME/standalone/configuration/standalone.xml contrôle laquelle de vos interfaces réseau lie le processus contrôleur hôte, les types d'interfaces de gestion qui sont disponibles à tous, et quel type de système d'authentification est utilisé pour authentifier les utilisateurs sur chaque interface. Cette rubrique explique comment configurer les interfaces de gestion en fonction de votre environnement.
Le sous-système de Gestion est formé d'un élément <management> avec plusieurs attributs configurables, et les trois éléments enfants configurables suivants. Les domaines de sécurité et les connexions sortantes sont tout d'abord définis, puis appliqués aux interfaces de gestion en tant qu'attributs.
  • <security-realms>
  • <outbound-connections>
  • <management-interfaces>
Domaines de sécurité

Le domaine de sécurité est chargé de l'authentification et de permettre aux utilisateurs autorisés d'administrer JBoss Enterprise Application Platform via l'API de gestion, le Management CLI ou la Console de gestion basée-web.

Il existe deux domaines de sécurité basés fichier différents qui existent dans l'installation par défaut : ManagementRealm et ApplicationRealm. Chacun de ces domaines de sécurité utilise un fichier -users.properties pour stocker les utilisateurs et les mots de passe de hachage, et -roles.properties pour stocker les correspondances entre les utilisateurs et les rôles. Un support est également inclus pour le domaine de sécurité activé-LDAP.

Note

Les domaines de sécurité peuvent également être utilisés pour vos propres applications. Les domaines de sécurité dont il s'agit sont particuliers aux interfaces de gestion.
Les connexions de sortie

Certains domaines de sécurité se connectent à des interfaces externes, comme un serveur LDAP. Une connexion sortante définit la manière d'établir cette connexion. Un type de connexion prédéfinie, la connexion ldap-connection, définit tous les attributs obligatoires et facultatifs pour se connecter au serveur LDAP et vérifier les informations d'identification.

Interfaces de gestion

Une interface de gestion comprend des propriétés sur la façon de connecter et configurer JBoss Enterprise Application Platform. Ces informations comprennent l'interface réseau nommée, le port, le domaine de sécurité et autres informations configurables sur l'interface. Deux interfaces sont incluses dans une installation par défaut :

  • http-interface est la configuration de la console de gestion basée-web.
  • native-interface est la configuration pour la Management CLi en ligne de commande et l'API de gestion Rest-like.
Chacun des trois principaux éléments configurables du sous-système de gestion de l'hôte sont étroitement liés. Un domaine de sécurité fait référence à une connexion sortante et une interface de gestion à un domaine de sécurité.

10.7.3. LDAP

Lightweight Directory Access Protocol (LDAP) est un protocole pour le stockage et la distribution d'informations en provenance de répertoires à travers un réseau. Ces informations de répertoires incluent des informations sur les utilisateurs, les périphériques physiques, les rôles d'accès et de restrictions et autres informations.
Certaines de implémentations communes de LDAP incluent OpenLDAP, Microsoft Active Directory, IBM Tivoli Directory Server, Oracle Internet Directory, et autres.
La plateforme JBoss Enterprise Application Platform comprend plusieurs modules d'authentification et d'autorisation qui vous permettent d'utiliser un serveur LDAP comme autorité d'authentification et d'autorisation pour vos applications Web et EJB.

10.7.4. Utiliser LDAP pour vous authentifier auprès des interfaces de Gestion

Pour utiliser un serveur de répertoire LDAP comme source d'authentification pour la Console de gestion, le Management CLI ou l'API de gestion, vous devez effectuer les procédures suivantes :
  1. Créer une connexion sortante au serveur LDAP.
  2. Créer un domaine de sécurité activé-LDAP.
  3. Référencer le nouveau domaine de sécurité dans l'interface de Gestion.
Créer une Connexion sortante au serveur LDAP

La connexion sortante LDAP autorise les attributs suivants :

Tableau 10.1. Attributs d'une Connexion sortante LDAP

Attribut Requis Description
Le nom oui
Le nom qui sert à identifier cette connexion. Ce nom est utilisé dans la définition du domaine de sécurité.
url oui
Ĺ'adresse URL du serveur de répertoires.
search-dn oui
Le nom unique (DN) de l'utilisateur autorisé à effectuer des recherches.
search-credentials oui
Le mot de passe de l'utilisateur autorisé à effectuer des recherches.
initial-context-factory non
L'usine de contexte initiale à utiliser quand on établit une connexion. Valeur par défaut com.sun.jndi.ldap.LdapCtxFactory.

Exemple 10.7. Ajouter une connexion sortante LDAP

Cette exemple ajoute une connexion sortante par le jeu de propriétés suivant :
  • Search DN: cn=search,dc=acme,dc=com
  • Search Credential: myPass
  • URL: ldap://127.0.0.1:389
/host=master/core-service=management/ldap-connection=ldap_connection/:add(search-credential=myPass,url=ldap://127.0.0.1:389,search-dn="cn=search,dc=acme,dc=com")

Exemple 10.8. XML représentant un connexion sortante LDAP

<outbound-connections>
   <ldap name="ldap_connection" url="ldap://127.0.0.1:389" search-dn="cn=search,dc=acme,dc=com" search-credential="myPass" />
</outboundconnections>	
	

Créer un domaine de sécurité activé-LDAP

Les Interfaces de gestion peuvent authentifier sur le serveur LDAP au lieu des domaines de sécurité basés propriété-fichier et configurés par défaut. L'authentificateur LDAP fonctionne en établissant tout d'abord une connexion au serveur de répertoires distant. Il effectue ensuite une recherche en utilisant le nom d'utilisateur que l'utilisateur a transmis au système d'authentification, afin de trouver le nom unique complet (DN) du dossier LDAP. Une nouvelle connexion est alors établie, utilisant le DN de l'utilisateur comme informations d'identification et mot de passe fournis par l'utilisateur. Si cette authentification au serveur LDAP réussit, le DN est considéré comme valide.

Le domaine de sécurité LDAP utilise les éléments et attributs de configuration suivants pour pouvoir effectuer ses fonctions.
connection
Le nom de la connexion définie dans <outbound-connections> à utiliser pour se connecter au répertoire LDAP.
base-dn
Le nom unique (DN) du contexte pour commencer à chercher l'utilisateur.
recursive
Indique si la recherche doit être récursive dans toute l'arborescence de répertoires LDAP, ou si l'on doit rechercher uniquement le contexte spécifié. La valeur par défaut est false.
user-dn
Attribut de l'utilisateur qui détient le nom unique (DN). Utilisé par la suite pour tester l'authentification. Valeur par défaut dn.
Soit username-filter ou advanced-filter, comme élément enfant.
Le username-filter utilise un attribut unique nommé attribute, dont la valeur correspond au nom de l'attribut LDAP qui contient le nom d'utilisateur, comme userName ou sambaAccountName.
Le advanced-filter prend un attribut unique nommé filter, qui contient une recherche de filtre en syntaxe LDAP standard. Veillez à bien échapper les caractères & en commutant à & amp;. Un exemple de filtre est :
(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))
Après avoir échappé un caractère esperluette, le filtre apparaîtra ainsi :
(&amp;(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))

Exemple 10.9. XML représentant un Domaine de sécurité activé-LDAP

Cet exemple utilise les paramètres suivants :
  • connection - ldap_connection
  • base-dn - cn=users,dc=acme,dc=com.
  • username-filter - attribute="sambaAccountName"
<security-realm name="TestRealm">
   <authentication>
      <ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com">
         <username-filter attribute="sambaAccountName" />
      </ldap>
  </authentication>
</security-realm>	


Avertissement

Il est important de veiller à ne pas autoriser les mots de passe LDAP. À moins que vous désiriez particulièrement les avoir dans votre environnement, ils représentent un problème de sécurité sérieux.
EAP 6.1 inclut un correctif pour CVE-2012-5629, qui définit l'option allowEmptyPasswords des modules de connexion LDAP à false si l'option n'est pas déjà configurée. Pour les versions plus anciennes, cette option devra être configurée manuellement.

Exemple 10.10. Ajout d'un Domaine de sécurité LDAP

La commande ci-dessous ajoute un domaine de sécurité et définit ses attributs pour un serveur autonome.
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap:add(base-dn="DC=mycompany,DC=org", recursive=true, username-attribute="MyAccountName", connection="ldap_connection")
Appliquer le Nouveau domaine de sécurité à l'Interface de gestion

Après avoir créé un domaine de sécurité, vous devez le référencer dans la configuration de votre interface de gestion. L'interface de gestion utilisera le domaine de sécurité pour l'authentification HTTP digest.

Exemple 10.11. Ajouter le Domaine de sécurité à l'interface HTTP

Une fois que la configuration est en place, et que vous aurez démarré à nouveau le contrôleur d'hôtes, la Console de gestion basée-web utilisera LDAP pour authentifier ses utilisateurs.
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)

10.7.5. Disable the HTTP Management Interface

Dans un domaine géré, vous avez seulement besoin d'un accès à l'interface HTTP sur le contrôleur de domaine, plutôt que sur des serveurs membres de domaine. En outre, sur un serveur de production, vous pouvez finalement décider de désactiver la Console de gestion basée-web.

Note

Les autres clients, tels que JBoss Operations Network, opèrent également par l'interface HTTP. Si vous souhaitez utiliser ces services ou tout simplement désactiver la gestion de la Console elle-même, vous pouvez définir l'attribut console-enabled-attribute de l'interface HTTP à false, au lieu de désactiver l'interface complètement.
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
Pour désactiver l'interface HTTP, ce qui désactive également l'accès à la Console de gestion basée-web, vous pouvez finalement supprimer l'interface HTTP.
La commande JBoss CLI suivante vous permettra de lire le contenu actuel de votre interface HTTP, si vous décidez de l'ajouter à nouveau.

Exemple 10.12. Lire la configuration de l'interface HTTP

/host=master/core-service=management/management-interface=http-interface/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "console-enabled" => true,
        "interface" => "management",
        "port" => expression "${jboss.management.http.port:9990}",
        "secure-port" => undefined,
        "security-realm" => "ManagementRealm"
    }
}
Pour supprimer l'interface HTTP, lancer la commande suivante :

Exemple 10.13. Supprimer l'interface HTTP

/host=master/core-service=management/management-interface=http-interface/:remove
Pour activer l'accès à nouveau, lancer la commande suivante pour recréer l'Interface HTTP avec les valeurs par défaut.

Exemple 10.14. Recréer l'Interface HTTP

/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=true)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=interface,value=management)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=port,value=${jboss.management.http.port:9990})
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealm)

10.7.6. Supprimer l'Authentification silencieuse du Domaine de sécurité par défaut.

Résumé

L'installation par défaut de JBoss Enterprise Application Platform 6 contient une méthode d'authentification silencieuse pour un utilisateur de Management LCI locaI. Cela donne à l'utilisateur local la possibilité d'accéder au Management CLI sans authentification du nom d'utilisateur ou du mot de passe. Cette fonctionnalité est activée dans un but pratique et pour faciliter l'exécution des scripts de Management CLI sans exiger l'authentification des utilisateurs locaux.Cette méthode est considérée comme une caractéristique utile étant donné que l'accès à la configuration locale donne généralement aussi à l'utilisateur la possibilité d'ajouter ses propres détails utilisateur ou sinon la possibilité de désactiver les contrôles de sécurité

La commodité de l'authentification silencieuse des utilisateurs locaux peut être désactivée quand un plus grand contrôle de sécurité est requis. Ceci peut être réalisé en supprimant l'élément local au sein de la section security-realm du fichier de configuration. S'applique à la fois pour standalone.xml pour une instance de serveur autonome, ou pour host.xml pour un domaine géré. Vous ne devriez envisager de supprimer que l'élément local si vous comprenez l'impact que ceci pourrait avoir sur la configuration de votre serveur particulier.
La meilleure méthode pour désactiver l'authentification silencieuse est d'utiliser le Management CLI, qui retire l'élément local visible dans l'exemple suivant.

Exemple 10.15. Exemple d'élément local dans security-realm

<security-realms>
    <security-realm name="ManagementRealm">
        <authentication>
            <local default-user="$local"/>
            <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
    </security-realm>
    <security-realm name="ApplicationRealm">
        <authentication>
            <local default-user="$local" allowed-users="*"/>
            <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
        <authorization>
            <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
        </authorization>
    </security-realm>
</security-realms>

Procédure 10.7. Supprimer l'Authentification silencieuse du Domaine de sécurité par défaut.

  • Supprimer l'authentification silencieuse par le Management CLI

    Supprimer l'élément local du Domaine de gestion et du Domaine d'applications comme requis.
    1. Supprimer l'élément local du Domaine de gestion.
      • Pour les serveurs autonomes

        /core-service=management/security-realm=ManagementRealm/authentication=local:remove
      • Pour les domaines gérés

        /host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove
    2. Supprimer l'élément local du Domaine d'applications.
      • Pour les serveurs autonomes

        /core-service=management/security-realm=ApplicationRealm/authentication=local:remove
      • Pour les domaines gérés

        /host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
Résultat

L'authentification silencieuse est retirée du ManagementRealm et de l' ApplicationRealm.

10.7.7. Désactiver l'accès à distance du Sous-système JMX

Une connectivité à distance JMX vous permet de déclencher JDK et les opérations de gestion d'applications. Afin de garantir une installation, désactivez cette fonction. Vous pouvez faire cela soit en enlevant la configuration de la connexion à distance, ou en enlevant le sous-système JMX entièrement. Les commandes du JBoss CLI référencent le profil par défaut dans une configuration de domaine géré. Pour modifier un profil différent, modifiez la partie de la commande /profil=default. Pour un serveur autonome, retirez complètement cette partie de la commande.

Note

Dans un domaine géré, le connecteur distant est retiré du sous-système JMX par défaut. Cette commande est fournie pour votre information, au cas où vous souhaiteriez l'ajouter en cours de développement.

Exemple 10.16. Supprimer le Connecteur distant du Sous-système JMX

/profile=default/subsystem=jmx/remoting-connector=jmx/:remove

Exemple 10.17. Supprimer le Sous-système JMX

Exécuter cette commande pour chaque profil que vous utilisez, si vous utilisez un domaine géré.
/profile=default/subsystem=jmx/:remove

10.7.8. Configurer les Domaines de sécurité pour les Interfaces de gestion

Les interfaces de gestion utilisent des domaines de sécurité pour contrôler l'authentification et l'accès aux mécanismes de configuration de JBoss Enterprise Application Platform. Cette section vous montre comment lire et configurer les domaines de sécurité. Ces commandes utilisent le Management CLI.
Lire une configuration de domaine de sécurité

Cet exemple montre la configuration par défaut du domaine de sécurité du ManagementRealm. Utilise un fichier mgmt-users.properties qui contient ses informations de configuration.

Exemple 10.18. ManagementRealm par défaut

	/host=master/core-service=management/security-realm=ManagementRealm/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "authorization" => undefined,
        "server-identity" => undefined,
        "authentication" => {"properties" => {
            "path" => "mgmt-users.properties",
            "plain-text" => false,
            "relative-to" => "jboss.domain.config.dir"
        }}
    }
}
Rédiger un domaine de sécurité

Les commandes suivantes créent un nouveau domaine de sécurité nommé TestRealm et définissent le nom et le répertoire du fichier de propriétés qui conviennent.

Exemple 10.19. Rédaction d'un domaine de sécurité

/host=master/core-service=management/security-realm=TestRealm/:add/host=master/core-service=management/security-realm=TestRealm/authentication=properties/:add(path=TestUsers.properties, relative-to=jboss.domain.config.dir)

Ajouter le Domaine de sécurité à l'interface de gestion

Après avoir ajouté un domaine de sécurité, donner son nom comme référence à l'interface de gestion.

Exemple 10.20. Ajouter un Domaine de sécurité à une interface de gestion

host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)

10.8. Sécurité de réseau

10.8.1. Sécuriser les interfaces de gestion

Résumé

Dans un environnement de test, il est de pratique courante de faire fonctionner JBoss Enterprise Application Platform 6 sans couche de sécurité sur les interfaces de gestion, composées de la Console de gestion, du Management CLI ou autre implémentation de l'API. Cela permet des changements rapides de développement et de configuration.

De plus, un mode silencieux d'authentification est présent par défaut, permettant à un client local sur une machine hôte de se connecter au Management CLI sans exiger un nom d'utilisateur ou un mot de passe. Ce comportement est pratique pour les utilisateurs locaux et les scripts de Management CLI, mais peut être désactivé si nécessaire. La procédure est décrite dans la rubrique .
Quand vous commencez à tester ou à préparer votre environnement pour aller en production, il est vitalement important de sécuriser les interfaces de gestion par l'une des méthodes suivantes au moins:

10.8.2. Indiquer les interfaces réseau que la plateforme JBoss EAP utilise

Aperçu

Isoler les services afin qu'ils soient accessibles uniquement aux clients qui en ont besoin augmente la sécurité de votre réseau. JBoss Enterprise Application Platform inclut deux interfaces dans sa configuration par défaut, qui se lient toutes les deux à l'adresse IP 127.0.0.1 ou localhost, par défaut. Une des interfaces est appelée management et est utilisée par les consoles de CLI et API de gestion. L'autre est appelée public et est utilisée pour déployer des applications. Ces interfaces ne sont pas spéciales, ni importantes, mais sont fournies comme point de départ.

L'interface management utilise les ports 9990 et 9999 par défaut, et l'interface public utilise le port 8080, ou le port 8443 avec HTTPS.
Vous pouvez changer l'adresse IP de l'interface de gestion, de l'interface publique ou bien les deux à la fois.

Avertissement

Si vous exposez les interfaces de gestion à d'autres interfaces de réseau non accessibles par les hôtes distants, vérifiez les implications au niveau de la sécurité. Le plus souvent, il n'est pas conseillé de donner un accès à distance aux interfaces de gestion.
  1. Stopper JBoss Enterprise Application Platform.

    Arrêter JBoss Enterprise Application Platform en interrompant votre système d'exploitation de manière appropriée. Si vous exécutez Enterprise Application Platform comme une application de premier plan, vous devrez appuyer sur Ctrl+C .
  2. Démarrer à nouveau JBoss Enterprise Application Platform, en indiquant l'adresse de liaison.

    Utilisez la ligne de commande -b pour démarrer JBoss Enterprise Application Platform sur une interface particulière.

    Exemple 10.21. Indiquer l'interface publique.

    EAP_HOME/bin/domain.sh -b 10.1.1.1

    Exemple 10.22. Indiquer l'interface de gestion.

    EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1

    Exemple 10.23. Indiquer des adresses différentes pour chaque interface.

    EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1

    Exemple 10.24. Lier l'interface publique à toutes les interfaces de réseau.

    EAP_HOME/bin/domain.sh -b 0.0.0.0
Il est possible de modifier votre fichier de configuration XML directement, pour changer les adresses de liaison par défaut. Toutefois, si vous faites cela, vous ne serez plus en mesure d'utiliser la commande -b pour spécifier une adresse IP en cours d'exécution, donc ce n'est pas recommandé. Si vous décidiez de le faire, n'oubliez pas d'arrêter JBoss Enterprise Application Platform complètement avant d'éditer le fichier XML.

10.8.3. Configurer les pare-feux de réseau pour qu'ils soient opérationnels dans JBoss Enterprise Application Platform 6

Résumé

La plupart des environnements de production utilisent des pare-feux pour la stratégie globale de sécurité réseau. Si vous avez besoin de plusieurs instances de serveurs pour communiquer les uns avec les autres ou avec des services externes tels que des serveurs web ou des bases de données, votre pare-feu doit en tenir compte. Un pare-feu bien géré ouvre seulement les ports qui sont utiles à l'opération et limite l'accès aux ports à des adresses IP spécifiques, des sous-réseaux et des protocoles réseau.

Une discussion plus complète sur les pare-feux est au delà du dessein de cette documentation.

Prérequis

  • Détermine les ports que vous avez besoin d'ouvrir. Voir Section 10.8.4, « Ports de réseau utilisés par la plateforme JBoss EAP 6 » pour déterminer la liste des ports pour votre situation.
  • Vous devez avoir une bonne compréhension de vos logiciels de pare-feux. Cette procédure utilise la commande system-config-firewall de Red Hat Enterprise Linux 6. Microsoft Windows Server inclut un pare-feu intégré, et plusieurs solutions de pare-feux de tierce partie existent pour chaque plate-forme.
Hypothèses

Cette procédure configure un pare-feu dans un environnement qui comprend les hypothèses suivantes :

  • Le système d'exploitation est Red Hat Enterprise Linux 6
  • La plate-forme JBoss EAP 6 exécute sur l'hôte 10.1.1.2. En option, le serveur peut posséder son propre pare-feu.
  • Le serveur du pare-feu de réseau exécute sur l'hôte 10.1.1.1 sur l'interface eth0, et possède une interface externe eth1.
  • Le traffic de réseau devra être redirigé vers le port 5445 (port utilisé par JMS) renvoyé sur EAP. Le traffic ne doit pas pouvoir transiter par le pare-feu du réseau.

Procédure 10.8. Gérer les pare-feux de réseau pour qu'ils soient opérationnels dans JBoss Enterprise Application Platform 6

  1. Connectez-vous à la Console de gestion.

    Connectez-vous à la Console de gestion. Par défaut, exécute sur http://localhost:9990/console/.
  2. Déterminer les liaisons de socket utilisées par le groupe de liaisons de socket.

    Cliquer sur l'étiquette Profiles qui se trouve en haut et à droite de la Console de gestion. Sur la gauche de l'écran, vous verrez une série de menus. Le titre en bas du menu est General Configuration (Configuration générale). Cliquer sur Socket Binding Groups sous ce titre. L'écran Socket Binding Declarations apparaîtra. Pour commencer, vous verrez le groupe standard-sockets. Vous pourrez choisir un autre groupe en le sélectionnant de la case mixte à droite.

    Note

    Si vous utilisez un serveur autonome, il ne possédera qu'un seul groupe de liaisons de socket.
    La liste de noms de sockets et des ports apparaît, avec six valeurs par page. Vous pourrez naviguer entre les pages grâce à la flèche de navigation en dessous du tableau.
  3. Déterminer les ports que vous souhaitez ouvrir.

    Suivant la fonction d'un port particulier, et suivant les besoins de votre environnement, certains ports devront sans doute être disponibles en dépit du pare-feu. Si vous n'êtes pas certain du but de la liaison de socket, voir Section 10.8.4, « Ports de réseau utilisés par la plateforme JBoss EAP 6 » pour obtenir une liste des liaisons de socket par défaut, et leur but.
  4. Configurer votre pare-feu pour rediriger le trafic réseau vers la plateforme JBoss EAP 6.

    Procédez à ces étapes de configuration de votre pare-feu de réseau pour permettre au trafic de se diriger vers le port désiré.
    1. Connectez-vous au pare-feu de votre machine, et accéder à cette commande, en tant qu'utilisateur root.
    2. Saisir la commande system-config-firewall pour lancer l'utilitaire de configuration du pare-feu. Un GUI ou Utilitaire de ligne de commande opérera, selon la façon dont vous êtes connecté au système de pare-feu. Cette tâche assume que vous êtes connecté via SSH et que vous utilisez l'interface de ligne de commande.
    3. Utiliser la clé TAB de votre clavier pour naviguer vers le bouton Customize, puis appuyer sur la clé ENTER. L'écranTrusted Services apparaîtra.
    4. Ne changez aucune valeur, mais utilisez la clé TAB pour naviguer vers le bouton Forward, puis, appuyer sur ENTER pour aller vers le prochain écran. L'écran Other Ports apparaîtra.
    5. Utiliser la clé TAB pour naviguer vers le bouton <Add>, puis appuyer sur la clé ENTER. L'écran Port and Protocol apparaîtra.
    6. Saisissez 5445 dans le champ Port / Port Range, puis utilisez la clé TAB pour vous rendre dans le champ Protocol, puis saisissez tcp. Utilisez la clé TAB pour naviguer vers le bouton OK, puis appuyez sur ENTER.
    7. Utilisez la clé TAB pour naviguer vers le bouton Forward jusqu'à ce que vous atteigniez Port Forwarding.
    8. Utiliser la clé TAB pour naviguer vers le bouton <Add>, puis appuyer sur la clé ENTER.
    9. Remplir les valeurs suivantes pour définir la redirection de port vers port 5445.
      • Interface source: eth1
      • Protocol: tcp
      • Port / Port Range: 5445
      • Destination IP address: 10.1.1.2
      • Port / Port Range: 5445
      Utiliser la clé TAB pour naviguer vers le bouton OK, puis appuyer sur la clé ENTER.
    10. Utiliser la clé TAB pour naviguer vers le bouton Close, puis appuyer sur la clé ENTER.
    11. Utiliser la clé TAB pour naviguer vers le bouton OK, puis appuyer sur ENTER. Pour appliquer les changements, lire la notice d'avertissement, puis appuyer sur Yes.
  5. Configurer un pare-feu sur votre hôte de plateforme JBoss EAP 6.

    Certaines organisations choisissent de configurer un pare-feu sur le serveur JBoss EAP 6 lui-même et de fermer tous les ports qui ne sont pas utiles à son fonctionnement. Consulter Section 10.8.4, « Ports de réseau utilisés par la plateforme JBoss EAP 6 » pour déterminer quels ports ouvrir, puis fermer le reste. La configuration par défaut de Red Hat Enterprise Linux 6 ferme tous les ports sauf 22 (utilisé pour Secure Shell (SSH) et 5353 (utilisé pour la multi-diffusion DNS). Si vous configurez les ports, assurez-vous que vous avez un accès physique à votre serveur pour ne pas, par inadvertance, vous verrouiller vous-même.
Résultat

Votre pare-feu est configuré pour renvoyer le trafic vers votre serveur JBoss EAP 6 interne, de la façon dont vous avez spécifié dans la configuration de votre pare-feu. Si vous avez choisi d'activer un pare-feu sur votre serveur JBoss Enterprise Application Platform 6, tous les ports seront fermés sauf ceux nécessaires à l'exécution de vos applications.

10.8.4. Ports de réseau utilisés par la plateforme JBoss EAP 6

Les ports de réseau utilisés par la configuration par défaut de la plateforme JBoss EAP 6 dépendent 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 10.2. 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 Multicast. Utilisé pour la découverte de paires dans les groupements HA. Oui Non Oui Non
jgroups-mping 45700 Multicast. Utilisé pour découvrir l'appartenance de groupe d'orgine dans un cluster HA. Oui Non Oui Non
jgroups-tcp 7600 Découverte de paires 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 paires unicast dans les groupements HA avec TCP. 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 difffusion 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 multicast de communication entre l'équilibreur de charge HTTP et JBoss Enterprise Application Platform. Oui Non Oui Non
osgi-http 8090 Utilisé par les composants internes qui utilisent le sous-système OSGi. 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

10.9. Java Security Manager

10.9.1. Java Security Manager

Java Security Manager
Le gestionnaire de sécurité Java est une classe qui gère la limite extérieure de la sandbox Java Virtual Machine (JVM), contrôlant ainsi comment le code qui est exécuté dans la JVM peut interagir avec les ressources à l'extérieur de la machine virtuelle Java. Lorsque le gestionnaire de sécurité Java est activé, l'API Java vérifie avec le gestionnaire de sécurité pour approbation avant d'exécuter une vaste gamme d'opérations potentiellement dangereuses.
Le Java Security Manager utilise une police de sécurité pour déterminer si une action est permise ou refusée.