[
"<p>Le sous-système de traitement par lots permet de configurer un environnement pour l'exécution d'applications groupées.</p>\n<p>${build.fullName} utilise <a href=\"https://github.com/jberet/jsr352\" rel=\"nofollow\" target=\"_blank\">JBeret</a> pour son implémentation par lots. Vous trouverez des informations spécifiques sur JBeret dans le <a href=\"http://jberet.gitbooks.io/jberet-user-guide/content/\" rel=\"nofollow\" target=\"_blank\">guide de l'utilisateur</a>.</p>\n",
"<p>Bean Validation est une spécification Java qui</p>\n<ul>\n    <li>vous permet d'exprimer des contraintes sur les modèles d'objets par le biais d'annotations</li>\n    <li>vous permet d'écrire des contraintes personnalisées de manière extensible</li>\n    <li>fournit des API pour valider les objets et les graphiques d'objets</li>\n    <li>fournit des API pour valider les paramètres et retourne des valeurs de retour de méthodes et de constructeurs</li>\n    <li>signale l'ensemble des violations (localisées)</li>\n    <li>fonctionne en Java SE, mais est intégré dans Java EE (6 et 7 ; Bean Validation 2.0 doit bientôt faire partie de Java EE 8)</li>\n</ul>\n<p>build.fullName} <a href=\"http://hibernate.org/validator/\" rel=\"nofollow\" target=\"_blank\">utilise Hibernate Validator</a> pour son implémentation par lots.</p>\n",
"<p>Les deux types généraux de ressources sont appelés sources de données et sources de données XA.</p>\n<ul>\n    <li>Les <strong>sources de données non-XA</strong> sont utilisées pour des applications qui n'utilisent pas de transactions, ou des applications qui utilisent des transactions avec une seule base de données.</li>\n    <li>Les <strong>sources de données XA</strong> sont utilisées par des applications dont les transactions sont réparties sur plusieurs bases de données. Les sources de données XA introduisent des frais généraux supplémentaires.</li>\n</ul>\n",
"<p>Le sous-système de source de données vous permet de créer et de configurer des sources de données et de gérer les pilotes de base de données JDBC.</p>\n<h2>Datasources</h2>\n<p>Les deux types généraux de ressources sont appelés sources de données et sources de données XA.</p>\n<ul>\n    <li>Les <strong>sources de données non-XA</strong> sont utilisées pour des applications qui n'utilisent pas de transactions, ou des applications qui utilisent des transactions avec une seule base de données.</li>\n    <li>Les <strong>sources de données XA</strong> sont utilisées par des applications dont les transactions sont réparties sur plusieurs bases de données. Les sources de données XA introduisent des frais généraux supplémentaires.</li>\n</ul>\n<h2>Pilotes JDBC</h2>\n<p>Avant que votre application puisse se connecter à une source de données, les pilotes JDBC de votre fournisseur de source de données doivent être installés. Vous pouvez choisir entre deux façons différentes d'installer les pilotes JDBC :</p>\n<dl>\n    <dt>Modules</dt>\n    <dd><p>Pour installer un pilote JDBC en tant que module, vous devez créer une structure de chemin de fichier sous les <code>modules ${build.installDir}/modules</code>, copier le pilote JDBC JAR dans le sous-répertoire <code>principal</code> et créer un fichier <code>module.xml</code>.</p>\n        <p>Une fois que le pilote JDBC est disponible en tant que module, vous pouvez utiliser cette section pour ajouter et supprimer des configurations de pilotes.</p>\n    </dd>\n\n    <dt>Déploiements</dt>\n    <dd>\n        <p>Vous pouvez déployer les pilotes JDBC comme pour tout autre déploiement. Cela signifie que vous pouvez les déployer sur plusieurs serveurs dans un groupe de serveurs, si vous utilisez un domaine géré. Tout pilote conforme à JDBC 4 sera automatiquement reconnu et installé dans le système par son nom et sa version.</p>\n        <p>En mode domaine, les pilotes déployés en tant qu'applications n'apparaîtront dans cette section que s'il y a des serveurs en cours d'exécution qui correspondent au profil sélectionné.</p>\n    </dd>\n</dl>\n",
"<p>L'analyseur de déploiement n'est utilisé qu'en mode autonome. Son travail consiste à surveiller un répertoire pour les nouveaux fichiers et à déployer ces fichiers.</p>\n<p>Vous pouvez définir davantage d'entrées d’analyseur de déploiement pour rechercher des déploiements à partir d'un plus grand nombre d'emplacements. </p>\n",
"<p>La configuration globale du système. Permet d'accéder aux principaux profils de configuration qui peuvent être appliqués aux groupes de serveurs.</p>\n\n<p>Visualiser et modifier la configuration de chaque <strong>sous-système</strong> disponible. Par exemple, ajoutez une source de données, configurez un fournisseur de messagerie ou configurez la sécurité des applications.</p>\n\n<p>Liens utiles</p>\n<ul>\n    <li><a href=\"#runtime\">Runtime de domaine</a></li>\n</ul>",
"<p>Le sous-système EE fournit des fonctionnalités communes à la plate-forme Java EE, telles que les utilitaires EE Concurrency Utilities (JSR 236) et l'injection <code>@Resource</code>. Le sous-système est également responsable de la gestion du cycle de vie des déploiements de l'application Java EE, c'est-à-dire les fichiers.ear.</p>\n<p>La configuration du sous-système EE peut être utilisée pour :</p>\n<ul>\n    <li>permettre de personnaliser le comportement de déploiement des applications Java EE.</li>\n    <li>gérer les modules globaux : un ensemble de modules JBoss qui seront ajoutés en tant que dépendances au module JBoss de chaque déploiement Java EE. de telles dépendances permettent aux déploiements Java EE de voir les classes exportées par les modules globaux.</li>\n    <li>Gestion des services publics concomitants de l'EE (JSR 236) : Il a été introduit avec Java EE 7, pour faciliter l'écriture d'applications Java EE multithread. Les instances de ces utilitaires sont gérées par ${build.fullName}, et la configuration associée fournie par le sous-système EE.</li>\n</ul>",
"<p>Les entités beans Enterprise sont des composants d’applicatiions côté serveur définis dans la spécification Enterprise JavaBeans (EJB) 3.1, JSR-318. Les entités beans Enterprise sont conçus pour la mise en œuvre de la logique métier applicative de manière découplée afin d'encourager la réutilisation. Les entités beans Enterprise sont écrits comme des classes Java et annotés avec les annotations EJB appropriées. Ils peuvent être déployés sur le serveur d'application dans leurs propres archives (fichier JAR) ou être déployés dans le cadre d'une application Java EE. Le serveur d'application gère le cycle de vie de chaque entreprise et leur fournit des services tels que la sécurité, les transactions et la gestion de la concurrence. Un bean Enterprise peut également définir un nombre quelconque d'interfaces commerciales. Les interfaces d’entreprise offrent un meilleur contrôle avec les entités bean qui sont à la disposition des clients, et peuvent également permettre l'accès aux clients se trouvant dans des JVM distantes. Il existe trois types d’entités beans Enterprise : Les Session beans, Message-driven beans et les Entity beans.</p>\n\n<h2>Session Beans</h2>\n<p>Les beans de session sont des entités beans d'entreprise qui encapsulent un ensemble de processus ou de tâches commerciales connexes et ils sont injectés dans les classes qui en font la demande. Il existe trois types de beans de session : stateless, stateful et singleton.</p>\n\n<h2>Message-Driven Beans</h2>\n<p>Les Message-driven Beans (MDBs) fournissent un modèle événementiel pour le développement d'applications. Les méthodes des MDBs ne sont pas injectées dans, ou invoquées à partir du code client, mais sont déclenchées par la réception de messages provenant d'un service de messagerie tel qu'un serveur Java Messaging Service (JMS). La spécification Java EE 6 exige que JMS soit pris en charge, mais d'autres systèmes de messagerie peuvent également être pris en charge.</p>\n\n<h2>Entity Beans</h2>\n<p>Les entités beans Enterprise sont maintenant obsolètes dans EJB 3.1 et il est recommandé d'utiliser les entités JPA à la place. Les entités beans Enterprise ne doivent être utilisés que pour assurer une rétrocompatibilité avec les systèmes existants.</p>",
"<h2>Fabriques</h2>\n<p>Une fabrique d'authentification est une politique d'authentification utilisée pour des mécanismes d'authentification spécifiques. Les fabriques d’authenticaion sont spécifiquement basées sur le mécanisme d'authentification, par exemple http-authentication-factory, sasl-authentication-factory, sasl-authentication-factory et kerberos-security-factory.</p>\n<h2>Transformateurs principaux</h2>\n<p>Un transformateur principal peut être utilisé à plusieurs endroits dans le sous-système elytron. Un transformateur principal peut transformer ou mapper un nom à un autre nom.</p>\n",
"<h2>Mappeurs de rôles</h2>\n<p>Un mappeur de rôle applique une modification de rôle à une identité. Cela peut aller de la normalisation du format des rôles à l'ajout ou la suppression de rôles spécifiques. Un mappeur de rôles peut être associé divers domaines de sécurité (security realms &amp; security domains).</p>\n<h2>Mappeurs de permissions</h2>\n<p>Un mappeur de permissions est associé à un domaine de sécurité et attribue un ensemble de permissions à une SecurityIdentity.</p>\n<h2>Principaux décodeurs</h2>\n<p>Un décodeur principal peut être utilisé à plusieurs endroits dans le sous-système elytron. Un décodeur principal convertit l'identité d'un Principal en une chaîne de caractères représentant le nom. Par exemple, le décodeur X500PrincipalDecoder vous permet de convertir un X500Principal du nom distingué d'un certificat en une représentation sous forme de chaîne de caractères.</p>\n<h2>Décodeurs de rôles</h2>\n<p>Un décodeur de rôle est associé à un domaine de sécurité et est utilisé pour décoder les rôles de l'utilisateur en cours. Le décodeur de rôle prend l'AuthorizationIdentity brute retournée du domaine de la sécurité et convertit ses attributs en rôles. </p>\n\n",
"<p>Cette section comprend plusieurs ressources comme expliqué ci-dessous :</p>\n<h2>Configuration de l'authentification</h2>\n<p>Une définition de configuration d'authentification individuelle, qui est utilisée par les clients déployés dans ${build.fullName} et d'autres ressources pour l'authentification lors de l'établissement d'une connexion à distance.</p>\n<h2>Contexte d'authentification</h2>\n<p>Une définition de contexte d'authentification individuelle, qui est utilisée pour fournir un contexte ssl et une configuration d'authentification lorsque des clients déployés vers ${build.shortName} et d'autres ressources établissent une connexion distante. </p>\n<h2>Stores</h2>\n<p>Key Store : est la définition d'un keystore ou d'un truststore incluant le type de keystore, son emplacement et les informations d'identification pour y accéder. Stockage d’identifiants pour conserver un alias pour les informations sensibles telles que les mots de passe pour les services externes. </p>\n<h2>SSL</h2>\n<p>Configurez les connexions SSL côté client et côté serveur. Une définition de gestionnaire de clés pour la création de la « key manager list » utilisée pour créer un contexte SSL. Autres ressources disponibles : Propriété de sécurité, Chargeur de fournisseurs, Fournisseurs d'agrégats.</p>\n<h2>Security Domains</h2>\n<p>Un domaine de sécurité est la représentation d'une politique de sécurité qui est soutenue par un ou plusieurs domaines de sécurité et un ensemble de ressources qui effectuent des transformations.</p>\n<h2>Logs</h2>\n<p>Audit loggers qui persistent sur les fichiers et syslog.</p>\n",
"<h2>Security Realms</h2>\n<p>Les domaines de sécurité donnent accès à une fabrique d'identité et sont utilisés pour obtenir des justificatifs d'identité. Ces informations d'identification permettent aux mécanismes d'authentification d'obtenir l' AuthorizationIdentity brute pour effectuer l'authentification.</p>\n<h2>Realm Mappers ou Mappeurs de zones</h2>\n<p>Un Realm Mapper est associé à un domaine de sécurité et est utilisé dans les cas où un domaine de sécurité comporte plusieurs zones de sécurité configurées. Le Real Mapper utilise le nom fourni lors de l'authentification pour choisir une zone de sécurité pour l'authentification.</p>\n",
"<p>L'architecture CORBA (Common Object Request Broker Architecture) est une norme qui permet aux applications et aux services de fonctionner ensemble même lorsqu'ils sont écrits dans plusieurs langues incompatibles ou hébergés sur des plates-formes distinctes. Les requêtes CORBA sont court-circuitées par un composant côté serveur appelé Object Request Broker (ORB). ${build.shortName} fournit une instance ORB, au moyen du composant Open JDK ORB.</p>\n",
"<p>Infinispan est une plate-forme de grille de données Java. Il fournit une interface de cache compatible <a href=\"http://www.jcp.org/en/jsr/detail?id=107\">JSR-107</a> pour la gestion des données mises en cache.\n</p>\n<p>Les conteneurs de cache Infinispan suivants sont utilisés dans ${build.fullName} :</p>\n<ul>\n    <li><code>web</code> pour le regroupement de sessions Web</li>\n    <li><code>ejb</code> pour Stateful Session Bean Clustering</li>\n    <li><code>hibernation</code> pour la mise en cache d'entités</li>\n    <li><code>singleton</code> pour la mise en cache de singletons</li>\n</ul>\n<p>Chaque conteneur de cache définit un \"repl\" et un cache \"dist\". Ces caches ne doivent pas être utilisés directement par les applications des utilisateurs.</p>\n\n<p>Pour plus d'informations sur la fonctionnalité Infinispan et les options de configuration, consultez la <a href=\"http://infinispan.org/docs/5.3.x/index.html\">documentation Infinispan</a>.</p>\n\n<h2>Modes de clustering</h2>\n<p>Le clustering peut être configuré de deux manières différentes dans ${build.shortName} en utilisant Infinispan. La méthode correcte à utiliser pour votre application dépendra de vos besoins. Il faudra faire un compromis entre la disponibilité, la cohérence, la fiabilité et l'évolutivité de chaque mode. Avant de choisir un mode de clustering, vous devez identifier les principales caractéristiques de votre réseau (pour vous), et équilibrer ces exigences.</p>\n\n<h3>Mode Réplication</h3>\n<p>Le mode de réplication détecte et ajoute automatiquement de nouvelles instances sur le cluster. Les modifications apportées à ces instances seront répliquées sur tous les nœuds du cluster. Le mode répliqué fonctionne généralement mieux dans les petits clusters en raison de la quantité d'informations qui doivent être répliquées sur le réseau. Infinispan peut être configuré pour utiliser la multidiffusion UDP, ce qui réduit la congestion du réseau jusqu’à un certain point.</p>\n\n<h3>Mode de distribution</h3>\n<p>Le mode de distribution permet à Infinispan de mettre le cluster à échelle de manière linéaire. Le mode de distribution utilise un algorithme de hachage cohérent pour déterminer l'emplacement d'un nouveau nœud dans une grappe. Le nombre de copies des informations à conserver est configurable. Il y a un compromis entre le nombre de copies conservées, la durabilité des données et la performance : plus le nombre de copies conservées est élevé, plus l'impact sur la performance sera important, mais moins vous risquerez de perdre des données en cas de panne de serveur. L'algorithme de hachage permet également de réduire le trafic réseau en localisant les entrées sans avoir recours à la multidiffusion ou au stockage des métadonnées.\n</p>\n<p>On devrait envisager d'utiliser le mode Distribution (dist) comme stratégie de mise en cache lorsque la taille du cluster dépasse 6-8 nœuds. Avec le mode Distribution, les données ne sont distribuées qu'à un sous-ensemble de nœuds au sein du cluster, et non pas à tous les nœuds (mode Répliqué par défaut).\n</p>\n\n<h3>Réplication synchrone et asynchrone</h3>\n<p>La réplication peut être effectuée en mode synchrone ou asynchrone, et le mode choisi dépend de vos besoins et de votre application. Avec la réplication synchrone, le thread qui traite la demande de l'utilisateur est bloquée jusqu'à ce que la réplication aboutisse. Ce n'est que lorsque la réplication est réussie qu'une réponse est renvoyée au client et le fil de discussion est libéré. La réplication synchrone a un impact sur le trafic réseau car elle nécessite une réponse de chaque nœud du cluster. Elle a cependant l'avantage d’assurer que toutes les modifications ont été apportées à tous les nœuds du cluster.</p>\n<p>La réplication asynchrone est exécutée en arrière-plan. Infinispan implémente une file d'attente de réplication, qui est utilisée par un thread d’arrière plan pour effectuer la réplication. La réplication est déclenchée soit sur une base temporelle, soit sur la taille de la file d'attente. Une file d'attente de réplication permet d'augmenter les performances car il n'y a pas de conversation entre les nœuds du cluster. L'inconvénient de la réplication asynchrone est qu'elle n'est pas aussi précise. Les tentatives de réplication échouées sont écrites dans un journal; elles ne sont pas notifiées en temps réel.</p>\n\n<h2>Conteneur Cache</h2>\n<p>Un conteneur de caches est un référentiel pour les caches utilisés par un sous-système. Pour Infinispan, les conteneurs de cache par défaut sont définis dans les fichiers xml de configuration. Un cache est défini comme étant le cache par défaut: il correspond au cache qui sera utilisé pour le clustering.</p>\n",
"<p>Un nom logique pour une interface réseau / adresse IP / nom d'hôte à laquelle les sockets peuvent être liés. Les configurations <code>domain.xml</code>, <code>host.xml</code> et <code>standalone.xml</code> incluent toutes une section où les interfaces peuvent être déclarées. D'autres sections de la configuration peuvent alors faire référence à ces interfaces par leur nom logique, plutôt que d'avoir à inclure tous les détails de l'interface (qui peuvent varier selon les machines).</p>\n\n<p>Une configuration d'interface comprend le nom logique de l'interface ainsi que des informations spécifiant les critères à utiliser pour résoudre l'adresse physique réelle à utiliser.</p>",
"<p>Le sous-système IO définit les workers XNIO et les pools tampons utilisés par d'autres sous-systèmes, tels que Undertow et Remoting.</p>\n<h2>Worker</h2>\n<p>Les workers sont des instances de workers XNIO. Une instance de worker XNIO est une couche d'abstraction pour les API Java NIO, qui fournissent des fonctionnalités telles que la gestion des IO et des threads de workers, ainsi que la prise en charge de SSL. Par défaut, ${build.shortName} fournit un seul worker appelé par <code>défaut</code>, mais il est possible d'en définir d'autres.</p>\n<h2>Pools de mémoire tampon</h2>\n<p>Les pools de mémoire tampon sont des instances de mémoire tampon NIO groupées.</p>\n<p><strong>Important :</strong><br/>\n    Changer la taille de la mémoire tampon a un impact important sur les performances de l'application. Pour la plupart des serveurs, la taille idéale est généralement de 16k.\n</p>",
"<p>Le sous-système JAX-RS est utilisé pour permettre le déploiement et la fonctionnalité des applications JAX-RS.</p>\n<p>build.fullName} <a href=\"http://resteasy.jboss.org/\" rel=\"nofollow\" target=\"_blank\">utilise RESTEasy</a> pour son implémentation JAX-RS.</p>",
"<p>L'architecture Java EE Connector Architecture (JCA) définit une architecture standard de systèmes Java EE pour les systèmes d'information d'entreprise (EIS) externes hétérogènes. Les systèmes de planification des ressources d'entreprise (ERP) (Enterprise Resource Planning), le traitement des transactions de l'ordinateur central (TP) (Mainframe transaction processing), les bases de données et les systèmes de messagerie sont des exemples d'EIS. Un adaptateur de ressources est un composant qui implémente l'architecture de l'API Java EE Connector.</p>\n<p>JCA 1.7 offre des fonctions de gestion :</p>\n<ul>\n    <li>connexions</li>\n    <li>transactions</li>\n    <li>sécurité</li>\n    <li>cycle de vie</li>\n    <li>Instances de travail</li>\n    <li>Flux interne de transactions</li>\n    <li>Flux interne de messages</li>\n</ul>\n<p>JCA 1.7 a été développé dans le cadre du Processus de Communauté Java sous le nom de <a href=\"https://www.jcp.org/en/jsr/detail?id=322\" rel=\"nofollow\" target=\"_blank\">JSR-322</a>.</p>\n\n<h2>Adaptateurs de ressources</h2>\n<p>Un adaptateur de ressources est un composant Java EE déployable qui assure la communication entre une application Java EE et un système d'information d'entreprise (EIS) en utilisant la spécification Java Connector Architecture (JCA). Un adaptateur de ressources est souvent fourni par les fournisseurs de SIE pour faciliter l'intégration de leurs produits avec les applications Java EE.</p>\n<p>Un système d'information d'entreprise (EIS) peut être n'importe quel système logiciel au sein d'une organisation. Les systèmes de planification des ressources de l'entreprise (ERP), les systèmes de base de données, les serveurs de messagerie électronique et les systèmes de messagerie propriétaires en sont des exemples.</p>\n<p>Un adaptateur de ressources est empaqueté dans un fichier RAR (Resource Adapter Archive) qui peut être déployé dans ${build.shortName}. Un fichier RAR peut également être inclus dans le déploiement d'une archive d'entreprise (EAR).</p>\n",
"<p>Avant que votre application puisse se connecter à une source de données, les pilotes JDBC de votre fournisseur de source de données doivent être installés. Vous pouvez choisir entre deux façons différentes d'installer les pilotes JDBC :</p>\n<dl>\n    <dt>Modules</dt>\n    <dd><p>Pour installer un pilote JDBC en tant que module, vous devez créer une structure de chemin de fichier sous les <code>modules ${build.installDir}/modules</code>, copier le pilote JDBC JAR dans le sous-répertoire <code>principal</code> et créer un fichier <code>module.xml</code>.</p>\n        <p>Une fois que le pilote JDBC est disponible en tant que module, vous pouvez utiliser cette section pour ajouter, modifier et supprimer des configurations de pilotes.</p>\n    </dd>\n\n    <dt>Déploiements</dt>\n    <dd>\n        <p>Vous pouvez déployer les pilotes JDBC comme pour tout autre déploiement. Cela signifie que vous pouvez les déployer sur plusieurs serveurs dans un groupe de serveurs, si vous utilisez un domaine géré. Tout pilote conforme à JDBC 4 sera automatiquement reconnu et installé dans le système par son nom et sa version.</p>\n        <p>En mode domaine, les pilotes déployés en tant qu'applications n'apparaîtront dans cette section que s'il y a des serveurs en cours d'exécution qui correspondent au profil sélectionné.</p>\n    </dd>\n</dl>\n",
"<p>Les abonnés ${build.shortName} peuvent fournir cette information à Red Hat lorsqu'ils requièrent un support.</p>",
"<p>JGroups est une boîte à outils pour une messagerie fiable qui peut être utilisé pour créer des clusters dont les nœuds peuvent s'envoyer des messages entre eux.</p>\n<p>Le sous-système <code>jgroups</code> fournit un support de communication de groupe pour les services de haute disponibilité dans ${build.shortName}. Il vous permet de configurer les canaux nommés et des piles de protocoles, ainsi que de visualiser les statistiques d'exécution des canaux. Le sous-système <code>jgroups</code> est disponible lorsqu'on utilise une configuration qui fournit des capacités de haute disponibilité, comme le profil <i>ha</i> ou <i>full-ha</i> dans un domaine géré, ou le fichier de configuration <code>standalone-ha.xml</code> ou <code>standalone-full-ha.xml</code> pour un serveur autonome.</p>\n<p>build.shortName} est préconfiguré avec deux piles JGroups :</p>\n<dl>\n    <dt>udp</dt>\n    <dd>Les nœuds du cluster utilisent la multidiffusion du protocole UDP (User Datagram Protocol) pour communiquer entre eux. C'est la pile par défaut.</dd>\n    <dt>tcp</dt>\n    <dd>Les nœuds du cluster utilisent le protocole TCP (Transmission Control Protocol) pour communiquer entre eux.</dd>\n</dl>\n<p>Vous pouvez utiliser les piles préconfigurées ou définir vos propres piles pour répondre aux besoins spécifiques de votre système.</p>\n<p><strong>Note :</strong><br/>\n    TCP a plus de frais généraux et est souvent considéré comme étant plus lent qu’ UDP puisqu'il gère la vérification des erreurs, l'ordre des paquets et le contrôle de la congestion lui-même. JGroups gère ces fonctionnalités pour UDP, alors que TCP les garantit lui-même. TCP est un bon choix lorsque vous utilisez JGroups sur des réseaux peu fiables ou à forte congestion, ou lorsque la multidiffusion n'est pas disponible.\n</p>\n",
"<p>Configurer l'accès aux extensions de gestion Java à distance (JMX).</p>\n<p>Le sous-système JMX enregistre un service avec le point d'extrémité Remoting afin que l'accès à distance à JMX puisse être obtenu par l'intermédiaire du connecteur Remoting exposé.</p>\n<p>Ceci est activé par défaut en mode autonome et accessible sur le port 9990 mais est désactivé en mode domaine, et doit donc être activé - en mode domaine, le port sera le port du connecteur Remoting pour l'instance ${build.fullName} à surveiller.</p>\n",
"<p>Gère les exigences gérées par conteneur de l'API de persistance Java (JPA) 2.1 et vous permet de déployer des définitions d'unités persistantes, des annotations et des descripteurs.</p>\n<p>L'API de persistance Java (JPA) est une spécification Java pour l'accès, la persistance et la gestion des données entre les objets ou classes Java et une base de données relationnelle. La spécification JPA reconnaît l'intérêt et le succès de l'objet transparent ou du paradigme de mappage relationnelle. Il standardise les API de base et les métadonnées nécessaires à tout objet ou mécanisme de persistance relationnel.</p>",
"<p>Gérer les implémentations JavaServer Faces (JSF).</p>",
"<p>Fournir des capacités de gestion de l'EE Java définies par la spécification <a href=\"https://jcp.org/en/jsr/detail?id=77\" rel=\"nofollow\" target=\"_blank\">JSR-77</a>.</p>",
"<p>Le sous-système de journalisation fournit des installations de journalisation hautement configurables pour son propre usage interne et pour l'utilisation par les applications déployées. Il est basé sur JBoss LogManager et prend en charge plusieurs cadres de journalisation d'applications tierces en plus de JBoss Logging.</p>\n\n<p>Le sous-système de journalisation est configuré à l'aide d'un système de catégories de journaux et de gestionnaires de journaux. Les catégories de journaux définissent les messages à capturer et les gestionnaires de journaux définissent comment traiter ces messages (écriture sur disque, envoi sur console, etc.).</p>\n\n<p>Les profils de journalisation permettent de créer des ensembles de configuration de journalisation portant un nom unique et de les affecter à des applications indépendantes de toute autre configuration de journalisation. La configuration des profils de journalisation est presque identique à celle du sous-système principal de journalisation.</p>",
"<p>Le sous-système de journalisation est configuré à l'aide d'un système de catégories de journaux et de gestionnaires de journaux. Les catégories de journaux définissent les messages à capturer et les gestionnaires de journaux définissent comment traiter ces messages (écriture sur disque, envoi sur console, etc.).</p>\n",
"<p>Les profils de journalisation permettent de créer des ensembles de configuration de journalisation portant un nom unique et de les affecter à des applications indépendantes de toute autre configuration de journalisation. La configuration des profils de journalisation est presque identique à celle du sous-système principal de journalisation.</p>",
"<p>Le sous-système Mail vous permet de configurer des paramètres de messagerie séparés, c'est à dire mail-session. Une session de messagerie ne peut avoir que trois types de serveurs : IMAP, POP, SMTP.</p>\n<p>Chaque service fait référence à un socket sortant existant qui relie le<code>outbound-socket-binding</code> (voir <a href=\"#configuration;path=configuration%255C2socket-bindings\">Groupes de liaisons de socket</a>).</p>\n",
"<h2>Apache ActiveMQ Artemis</h2>\n<p>Apache ActiveMQ Artemis est un projet open source pour un système de messagerie asynchrone. Il est hautement performant, intégrable, en grappe et supporte plusieurs protocoles. ${build.shortName} utilise Apache ActiveMQ Artemis comme broker JMS et est configuré en utilisant le sous-système messaging-activemq. Ceci remplace entièrement le broker HornetQ mais conserve la compatibilité du protocole avec les versions précédentes.</p>\n\nActiveMQ Artemis core est JMS-agnostic et fournit une API non-JMS, qui est appelée l'API core. ActiveMQ Artemis fournit également une API client JMS qui utilise une couche de façade pour appliquer la sémantique JMS sur l'API core. Essentiellement, les interactions JMS sont traduites en opérations API core du côté client à l'aide de l'API client JMS. De là, toutes les opérations sont envoyées en utilisant l'API core du client et le format de connexion Apache ActiveMQ Artemis. Le serveur lui-même n'utilise que l'API core Pour plus de détails sur l'API core et ses concepts, reportez-vous à la <a target=\"_blank\" href=http://activemq.apache.org/artemis/docs/1.1.0/using-core.html\">documentation d'ActiveMQ Artemis</a>.\n",
"<p>Les clusters de messagerie ${build.shortName} permettent de regrouper des groupes de serveurs de messagerie ${build.shortName} afin de partager la charge de traitement des messages. Chaque nœud actif du cluster est un serveur de messagerie ${build.shortName} actif qui gère ses propres messages et ses propres connexions.</p>\n\n<p>Le cluster est formé par chaque nœud déclarant des connexions de cluster à d'autres nœuds dans le fichier de configuration ${build.shortName}. Lorsqu'un nœud forme une connexion de cluster avec un autre nœud, il crée, en interne, une connexion core api entre lui-même et l'autre nœud. Cela se fait de manière transparente dans les coulisses ; vous n'avez pas besoin de déclarer un api explicite pour chaque nœud. Ces connexions cluster permettent aux messages de circuler entre les nœuds du cluster pour équilibrer la charge.</p>\n\n<p>Pour une documentation complète sur le clustering, voir <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-28-clusters-overview\">Aperçu sur les clusters</a>.\n</p>\n\n<p>Cette section contient la configuration pour les sujets suivants :</p>\n<ul>\n    <li>Groupes de diffusion</li>\n    <li>Groupes de découverte</li>\n    <li>Connexions de cluster</li>\n    <li>Handlers de groupe</li>\n    <li>Core Bridges</li>\n</ul>\n\n<h2>Groupes de diffusion</h2>\n<p>Un groupe de diffusion est le moyen par lequel un serveur diffuse des connecteurs sur le réseau. Un connecteur définit la manière dont un client, ou un autre serveur, peut établir des connexions au serveur.</p>\n\n<p>Le groupe de diffusion prend un ensemble de connecteurs et les diffuse sur le réseau. Selon la technique de diffusion que vous configurez le cluster, il utilise UDP ou JGroups pour diffuser des informations sur les paires de connecteurs.</p>\n\n<p>Les groupes de diffusion sont définis dans le sous-système messaging-activemq de la configuration de serveur. Il peut y avoir plusieurs groupes de diffusion par serveur de messagerie ${build.shortName}.</p>\n\n<h2>Groupes discovery</h2>\n<p>Alors que le groupe de diffusion définit comment l'information sur les connecteurs est diffusée à partir d'un serveur, un groupe discovery définit comment l'information sur les connecteurs est reçue à partir d'un point d'extrémité de diffusion, par exemple, une adresse multicast UDP ou un canal JGroup.</p>\n\n<p>Un groupe discovery maintient une liste de connecteurs, un pour chaque diffusion par un serveur différent. Lorsqu'il reçoit des émissions sur le point final de diffusion à partir d'un serveur particulier, il met son entrée à jour dans la liste dédiée à ce serveur. S'il n'a pas reçu de diffusion d'un serveur particulier pendant un certain temps, il supprimera l'entrée de dédiée à ce serveur dans sa liste.</p>\n\n<h2>Connexions de cluster</h2>\n<p>Regrouper les connexions de serveurs de groupe en clusters afin que les messages puissent être chargés de manière équilibrée entre les nœuds du cluster. Les connexions de cluster sont définies dans la configuration de serveur ${build.shortName} en utilisant l'élément de <code>connexion cluster</code>. Il peut y avoir zéro ou plusieurs connexions de cluster définies par serveur de messagerie ${build.shortName}.\n</p>\n\n<h2>Handlers de groupe</h2>\n<p>Dans un cluster, les groupes de messages avec des ID de groupe spécifiques peuvent arriver sur n'importe lequel des nœuds. Il est important pour un nœud de déterminer quels identificateurs de groupe sont liés à quel consommateur et sur quel nœud. Chaque nœud est responsable de l'acheminement correct des groupes de messages vers le nœud qui a le consommateur traitant ces identifiants de groupe, indépendamment de l'endroit où les groupes de messages arrivent par défaut. Une fois que des messages ayant un identifiant de groupe donné sont envoyés à un consommateur spécifique connecté au nœud donné dans le cluster, ces messages ne sont jamais envoyés à un autre nœud même si le consommateur est déconnecté.</p>\n\n<p>Cette situation est traitée par un gestionnaire (ou handler) de regroupement. Chaque nœud dispose d'un gestionnaire de regroupement et ce gestionnaire de regroupement (avec d'autres gestionnaires) est responsable de l'acheminement des groupes de messages vers le nœud qui convient.</p>\n\n<h2>Core Bridges</h2>\n<p>La fonction d'une api est de consommer les messages d'une destination et de les transférer à une autre, typiquement sur un serveur de messagerie ${build.shortName} différent.</p>\n\n<p>Les serveurs source et cible n'ont pas besoin d'être dans le même cluster, ce qui permet d'envoyer de manière fiable des messages d'un cluster à l'autre, par exemple, à travers un WAN ou Internet et quand la connexion peut ne pas être fiable.</p>\n\n<p>L'api a une résilience intégrée à la défaillance, de sorte que si la connexion du serveur cible est perdue, par exemple, en raison d'une défaillance du réseau, l'api essayera à nouveau de se connecter à la cible jusqu'à ce qu'elle revienne en ligne. Lorsqu'il sera de nouveau en ligne, il reprendra son fonctionnement normal.</p>\n\n<p>Les ponts sont un moyen fiable de connecter deux serveurs de messagerie ${build.shortName} séparés ensemble. Avec un core api, les serveurs source et cible doivent être des serveurs de messagerie ${build.shortName}.</p>\n",
"<p>Contient la configuration des topics suivants :</p>\n<ul>\n    <li>Accepteurs et Connecteurs</li>\n    <li>Services de connexion</li>\n    <li>Fabriques de connexions (regroupées)</li>\n</ul>\n\n<h2>Accepteurs et Connecteurs</h2>\n<p>Un accepteur définit quels types de connexion sont acceptés par le serveur de messagerie intégré ${build.shortName}. Vous pouvez définir un nombre quelconque d'accepteurs par serveur.</p>\n\n<p>Un connecteur définit comment se connecter à un serveur de messagerie ${build.shortName} intégré, et est utilisé par un client pour établir des connexions.</p>\n\n<p>Pour plus d'informations sur les accepteurs et les connecteurs, voir la <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-8-configuring-the-messaging-transports\">section Accepteurs et Connecteurs</a>.\n</p>\n\n<h2>Services de connexion</h2>\n<p>Un service de connecteur vous permet d'intégrer des composant externes dans ApacheActiveMQ Artemis pour envoyer et recevoir des messages.</p>\n\n<h2>Usines de connexion</h2>\n<p>Par défaut, le sous-système de messagerie ${build.shortName} fournit les fabriques de connexion <code>InVmConnectionFactory</code> et <code>RemoteConnectionFactory</code>, ainsi que la fabrique de connexion mutualisée <code>activemq-ra</code>.</p>\n\n<p><code>InVmConnectionFactory</code> fait référence à un <code>connecteur in-vm</code> et peut être utilisé pour envoyer et recevoir des messages lorsque le client et le serveur fonctionnent dans la même JVM. <code>RemoteConnectionFactory</code> fait référence à un <code>connecteur http</code> et peut être utilisé pour envoyer et recevoir des messages via HTTP lorsque le client et le serveur fonctionnent dans des JVM différentes.\n</p>\n\n<p>Les fabriques de connexion regroupées vous permettent de configurer les connecteurs d'entrée et de sortie de l'adaptateur de ressources ActiveMQ Artemis intégré. Pour plus d'informations sur la configuration d'une fabrique de connexion groupée pour se connecter à un serveur Artemis ActiveMQ distant, voir <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/configuring_messaging/resource_adapters#use_provided_amq_adapter\">Utilisation de l'adaptateur de ressources intégré pour les connexions à distance</a>.\n</p>\n",
"<p>Contient la configuration des topics suivants :</p>\n<ul>\n    <li>Files d'attente core</li>\n    <li>Destinations JMS</li>\n    <li>Paramètres de sécurité</li>\n    <li>Paramètres d'adresse</li>\n    <li>Déviations</li>\n</ul>\n\n<h2>Files d'attente core</h2>\n<p>Apache ActiveMQ Artemis core est JMS-agnostic. Il n'a pas de concept de topic JMS. Un topic JMS est implémenté (core) sous forme d’une adresse (le nom du topic) avec zéro ou plusieurs files d'attente qui lui sont liées. Chaque file d'attente liée à cette adresse représente un abonnement à un topic. De même, une file d'attente JMS est implémentée comme une adresse (le nom de la file d'attente JMS) avec une seule file d'attente qui lui est liée et qui représente la file d'attente JMS.</p>\n\n<p>Par convention, toutes les files d'attente de JMS correspondent à des files d'attente core où le nom de la file d'attente a la chaîne \"jms.queue\". Par exemple, la file d'attente core JMS du nom \"orders.europe\" correspond à la file d'attente centrale ayant pour nom \"jms.queue.orders.europe\". L'adresse à laquelle la file d'attente du noyau est liée est également donnée par le nom de la file d'attente core.</p>\n\n<p>Pour les topics JMS, l'adresse à laquelle les files d'attente qui représentent les abonnements sont liées est donnée en ajoutant la chaîne de caractères \"jms.topic\" au nom du sujet JMS. Par exemple, le sujet JMS avec le nom \"news.europe\" correspont à l'adresse core \"jms.topic.news.europe\" ;</p>\n\n<h2>Destinations JMS</h2>\n<p>Les destinations JMS, ainsi que les fabriques de connexion JMS, sont des objets administratifs JMS. Les destinations sont utilisées par les clients JMS pour la production et la consommation des messages. La destination permet au client JMS de spécifier la cible lorsqu'il produit des messages et la source des messages lorsqu'il consomme des messages. Lorsque vous utilisez un modèle « publish-subscribe », les destinations sont appelées topics. Lors de l'utilisation d'un modèle « point-to-point », les destinations sont appelées files d'attente.</p>\n\n<p>Les applications peuvent utiliser de nombreuses destinations JMS différentes, qui sont configurées côté serveur, et auxquelles on accède généralement via JNDI.</p>\n\n<h2>Paramètres de sécurité</h2>\n<p>Les paramètres de sécurité sont utilisés pour configurer la sécurité pour des destinations spécifiques. Cela se fait en ajoutant une contrainte de sécurité à l'aide de l'élément de configuration security-setting. ${build.shortName} messaging est livré avec un <code>security-setting</code> configuré par défaut.</p>\n\n<p>L'option security-setting utilise des caractères génériques pour gérer les destinations sur lesquelles il faut appliquer la contrainte de sécurité. La valeur d'un seul modèle <code>#</code> pourra établir une correspondance avec toutes les adresse. Pour plus d'informations sur l'utilisation des caractères génériques dans les contraintes de sécurité, voir <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-7-configuring-security#role_based_security_for_address\">Sécurité basée Rôles pour les adresses</a>.\n</p>\n\n<h2>Paramètres d'adresse</h2>\n<p>Le sous-système messaging-activemq dispose de plusieurs options configurables qui contrôlent les aspects suivants : comment et quand un message est délivré, combien de tentatives doivent être faites et quand le message expire. Ces options de configuration existent toutes dans l'élément de configuration &lt;adress-setting>. Vous pouvez demander à ${build.shortName} d'appliquer un seul paramètre &lt;address-setting> à plusieurs destinations en utilisant une syntaxe de caractère générique.</p>\n\n<p>Pour plus d'informations sur l'utilisation des caractères génériques dans les configurations d'adresse, voir <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-6-address-settings\">Syntaxe des caractères génériques</a>.\n</p>\n\n<h2>Déviations</h2>\n<p>Les déviations sont des objets configurés dans la messagerie ${build.shortName} qui aident à détourner les messages d'une adresse vers une autre. Les dérivations peuvent être catégorisées en types suivants :\n\n<dl>\n    <dt>Exclusif</dt>\n    <dd>Un message n'est que dévié vers une nouvelle adresse et n'est jamais envoyé à l'ancienne adresse.</dd>\n    <dt>Non exclusif</dt>\n    <dd>Un message est envoyé à l'ancienne adresse et une copie est également envoyée à la nouvelle adresse. Des déviations non exclusives peuvent être utilisées pour fractionner le flux de messages.</dd>\n</dl>\n\n<p>Une déviation ne redirigera un message que vers une adresse sur le même serveur. Si vous voulez dévier vers une adresse sur un serveur différent, un modèle commun serait de dévier vers une file d'attente locale, puis de configurer une api qui consomme à partir de cette file d'attente et transfère vers une adresse sur un serveur différent.</p>",
"<p>La haute disponibilité est la capacité du système à continuer à fonctionner après une panne d'un ou plusieurs serveurs.</p>\n\n<p>Une caractéristique de la haute disponibilité est le basculement, c'est-à-dire la capacité des connexions client à migrer d'un serveur à un autre en cas de panne de serveur afin que les applications client puissent continuer à fonctionner.</p>\n\n<p><strong>Note</strong><br/> Seules les données de messages persistants survivront au basculement. Les données des messages non persistants ne seront pas disponibles après le basculement.</p>\n\n<h2>Paires Live / Backup</h2>\n<p>La messagerie ${build.shortName} permet aux serveurs d'être reliés entre eux en tant que paires Live / Backup, chaque serveur live ayant une sauvegarde. Les serveurs live reçoivent les messages des clients, tandis qu'un serveur de sauvegarde (backup) n'est pas opérationnel tant que le basculement n’a pas eu lieu. Un serveur de sauvegarde ne peut appartenir qu'à un seul serveur live, et il restera en mode passif, en attendant de prendre en charge le travail du serveur live.</p>\n\n<p>Lorsqu'un serveur live tombe en panne ou est mis hors service dans le mode qui convient, le serveur de sauvegarde actuellement en mode passif deviendra le nouveau serveur live. Si le nouveau serveur live est configuré pour permettre le failback automatique, il détectera le retour de l'ancien serveur en direct et s'arrêtera automatiquement, permettant ainsi à l'ancien serveur live de commencer à recevoir à nouveau des messages.</p>\n\n<p><strong>Note</strong><br/> Si vous déployez une seule paire de serveurs live / backup, vous ne pouvez pas utiliser efficacement un répartiteur de charge devant la paire car l'instance de sauvegarde ne traite pas activement les messages. De plus, des services tels que JNDI et le serveur web Undertow ne sont pas actifs sur le serveur de sauvegarde non plus. Pour ces raisons, le déploiement d'applications JEE sur une instance de ${build.shortName} utilisée comme serveur de messagerie de sauvegarde n'est pas supporté.</p>\n\n<h2>Politiques de Haute disponibilité (HA)</h2>\n<p>La messagerie ${build.shortName} prend en charge deux stratégies différentes pour la sauvegarde d'un serveur : la <em>réplication</em> et le <em>stockage partagé</em>. Chaque stratégie peut jouer le rôle d'un maître ou d'un esclave. Rappelez-vous qu'une seule option de politique HA peut être configurée par serveur de messagerie.</p>\n\n<p>Pour plus d'informations sur la haute disponibilité et les différentes stratégies et politiques, voir <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-29-high-availability\">Haute disponibilité</a>.</p>\n",
"<p>La messagerie ${build.shortName} inclut une api de message JMS entièrement fonctionnelle. La fonction d'une api JMS est de consommer les messages d'une file d'attente ou d'un topic source et de les envoyer à une file d'attente ou à un topic cible, généralement sur un serveur différent.</p>\n\n<p>Les serveurs source et cible n'ont pas besoin d'être dans le même cluster, ce qui rend le pontage approprié pour l'envoi fiable de messages d'un cluster à l'autre, par exemple à travers un WAN, et où la connexion peut ne pas être fiable.</p>\n\n<p>\n    <strong>Note</strong><br/>Ne pas confondre un pont JMS avec un système de pontage core bridge Un pont JMS peut être utilisé pour relier deux fournisseurs JMS compatibles JMS 1.1 et utilise l'API JMS. Un core bridge est utilisé pour ponter deux instances de messagerie ${build.shortName} et utilise l'API de base. Il est préférable d'utiliser un core bridge au lieu d'un pont JMS dans la mesure du possible.\n</p>",
"<p>Contains the configuration for discover groups, connector, connection factory, queues and topics to a remote ActiveMQ Artemis server:</p>\n\n<h2>Connectors</h2>\n<p>A connector defines how to connect to a remote ActiveMQ Artemis server.</p>\n\n<p>For more information about connectors, see the\n    <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/configuring_messaging/acceptors_and_connectors\">Connectors documentation</a>.\n</p>\n\n<h2>Discovery Groups</h2>\n<p>A discovery group defines how connector information is received from a broadcast endpoint, for example, a UDP multicast address or JGroup channel.</p>\n<p>A discovery group maintains a list of connectors, one for each broadcast by a different server. As it receives broadcasts on the broadcast endpoint from a particular server, it updates its entry in the list for that server. If it has not received a broadcast from a particular server for a length of time it will remove that server’s entry from its list.</p>\n\n\n<h2>Connection Factories</h2>\n<p>By default, the ${build.shortName} messaging subsystem provides the <code>InVmConnectionFactory</code> and\n    <code>RemoteConnectionFactory</code> connection factories, as well as the\n    <code>activemq-ra</code> pooled connection factory.\n</p>\n\n<p>Pooled connection factories allow you to configure the inbound and outbound connectors of the remote ActiveMQ Artemis resource adapter. For more information on configuring a pooled-connection-factory to connect to a remote ActiveMQ Artemis server, see\n    <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/configuring_messaging/resource_adapters#use_provided_amq_adapter\">Using the Integrated Resource Adapter for Remote Connections</a>.\n</p>\n\n<h2>External Queue / Topic</h2>\n<p>The queues and topics that exists in the remote ActiveMQ Artemis server.</p>\n",
"<p>Un serveur Apache ActiveMQ Artemis. Chaque serveur Apache ActiveMQ Artemis possède son propre journal persistant ultra-performant, qu'il utilise pour les messages et autres persistances.</p>\n\n<p>L'utilisation d'un journal de haute performance permet d'obtenir un rendement vertigineux de messages de persistance, ce qui n'est pas réalisable lorsqu'on utilise une base de données relationnelle pour la persistance.</p>\n\n<p>Les clients Apache ActiveMQ Artemis, potentiellement sur différentes machines physiques, interagissent avec le serveur Apache ActiveMQ Artemis. Apache ActiveMQ Artemis fournit actuellement deux API pour la messagerie côté client :</p>\n\n<ol>\n    <li>API core client Il s'agit d'une API Java simple et intuitive qui comprend l'ensemble des fonctionnalités de messagerie sans la complexité liée à JMS.</li>\n    <li>API client JMS. L'API standard JMS est disponible côté client.</li>\n</ol>\n\n<p>Apache ActiveMQ Artemis fournit également différentes implémentations de protocoles sur le serveur afin que vous puissiez utiliser les clients respectifs pour ces protocoles :</p>\n\n<ol>\n    <li>Stomp</li>\n    <li>OpenWire</li>\n    <li>AMQP</li>\n</ol>\n\n<p>La sémantique JMS est implémentée par une couche de façade JMS côté client.</p>\n\n<p>Le serveur Apache ActiveMQ Artemis ne comprend pas JMS et ne connaît rien à propos de JMS, c'est un serveur de messagerie agnostique conçu pour être utilisé avec des protocoles différents.</p>\n\n<p>Lorsqu'un utilisateur utilise l'API JMS côté client, toutes les interactions JMS sont traduites en opérations sur l'API client Apache ActiveMQ Artemis avant d'être transférées sur le fil en utilisant le format de fil Apache ActiveMQ Artemis.</p>\n\n<p>Le serveur ne s'occupe toujours que des interactions d’API core.</p>",
"<p>Support Eclipse MicroProfile Config pour les applications déployées dans WildFly. L'intégration utilise le composant <a href=\"https://github.com/smallrye/smallrye-config/\">SmallRye</a> pour l'implémentation de la Config MicroProfile.\n</p>\n",
"<!--\n  ~ Copyright 2015-2016 Red Hat, Inc, and individual contributors.\n  ~\n  ~ Licensed under the Apache License, Version 2.0 (the \"License\");\n  ~ you may not use this file except in compliance with the License.\n  ~ You may obtain a copy of the License at\n  ~\n  ~ http://www.apache.org/licenses/LICENSE-2.0\n  ~\n  ~ Unless required by applicable law or agreed to in writing, software\n  ~ distributed under the License is distributed on an \"AS IS\" BASIS,\n  ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n  ~ See the License for the specific language governing permissions and\n  ~ limitations under the License.\n  -->\n<p>Support Eclipse MicroProfile Metrics in WildFly. The integration uses the\n    <a href=\"https://github.com/smallrye/smallrye-metrics/\">SmallRye</a> component to provide the MicroProfile Metrics implementation.\n</p>\n",
"<p>mod_cluster est un équilibreur de charge basé httpd. Comme mod_jk et mod_proxy, mod_cluster utilise un canal de communication pour transmettre les requêtes de httpd vers un ensemble de nœuds de serveur d'application. Contrairement à mod_jk et mod_proxy, mod_cluster tire parti d'une connexion supplémentaire entre les nœuds du serveur d'application et httpd.</p>\n\n<p>Les nœuds de serveur d'application utilisent cette connexion pour transmettre les facteurs d'équilibrage de charge côté serveur et les événements du cycle de vie à httpd via un ensemble personnalisé de méthodes HTTP, affectueusement appelé Mod-Cluster Management Protocol (MCMP). Ce canal de rétroaction supplémentaire permet à mod_cluster d'offrir un niveau d'intelligence et de granularité que l'on ne trouve pas dans d'autres solutions d'équilibrage de charge.</p>",
"<p>Lier les entrées dans les espaces de noms JNDI globaux et configurer l'interface JNDI distante.</p>",
"<p>Un nom logique pour un chemin d'accès au système de fichiers. Les configurations <code>domain.xml</code>, <code>host.xml</code> et <code>standalone.xml</code> incluent toutes une section où les chemins peuvent être déclarés. D'autres sections de la configuration peuvent alors référencer ces chemins d’accès par leur nom logique, plutôt que d'avoir à inclure les détails complets du chemin d’accès (pouvant varier sur différentes machines).</p>\n\n<p>Par exemple, la configuration du sous-système de journalisation inclut une référence au chemin <code>jboss.server.log.log.dir</code> qui pointe vers le répertoire <code>log</code> du serveur.</p>",
"<p>Activer le déploiement d'applications contenant les services JBoss Microcontainer, ainsi supporté par les versions précédentes de ${build.shortName}.</p>",
"<p>Un profil est un ensemble de sous-systèmes désigné, comprenant les configurations de chaque sous-système. Un sous-système est un ensemble de capacités supplémentaires ajoutées au serveur core par une extension. Les sous-systèmes fournissent des capacités comme servlet-handling, un conteneur EJB, JTA, etc.</p>\n\n<p>Des profils variés peuvent être définis pour répondre aux besoins spécifiques de différents groupes de serveurs.</p>\n\n<img class=\"preview\" src=\"previews/profiles.png\"/>",
"<p>JBoss Remoting possède trois éléments configurables de niveau supérieur : le pool de threads de travail, un ou plusieurs connecteurs et une série d'URI de connexion locale et distante.</p>\n<p>La plupart d’entre vous n'auront pas besoin de configurer le sous-système Remoting, à moins qu'ils n'utilisent des connecteurs personnalisés pour leurs propres applications. Les applications qui agissent comme clients Remoting, comme les EJBs, ont besoin d'une configuration séparée pour se connecter à un connecteur spécifique.</p>",
"<p>Le fichier ${build.shortName} peut être suspendu ou fermé gracieusement. Cela permet aux demandes actives de se terminer normalement, sans accepter de nouvelles demandes. Une valeur de délai d'attente spécifie pendant combien de temps l'opération de mise en attente ou d'arrêt durera en attendant que les demandes actives soient terminées. Pendant que le serveur est suspendu, les demandes de gestion sont toujours traitées.</p>\n<p>Un arrêt en douceur est coordonné à l'échelle du serveur, principalement centré sur les points d'entrée par lesquels une requête entre dans le serveur. Les sous-systèmes suivants prennent en charge l'arrêt en douceur :</p>\n<dl>\n    <dt>Undertow</dt>\n    <dd>Le sous-système <code>Undertow</code> attendra que toutes les requêtes soient terminées.</dd>\n    <dt>Modcluster</dt>\n    <dd>Le sous-système <code>modcluster</code> avertira l'équilibreur de charge que le serveur est mis en attente dans la phase <code>PRE_SUSPEND</code>.\n    </dd>\n    <dt>EJB</dt>\n    <dd>Le sous-système <code>ejb3</code> attendra que toutes les requêtes EJB et que les livraisons de messages MDB à distance soient terminées. La livraison aux MDB est interrompue dans la phase <code>PRE_SUSPEND</code>. Les minuteries EJB sont suspendues et les minuteries manquées seront activées à la reprise du serveur.\n    </dd>\n    <dt>EE Concurrence </dt>\n    <dd>Le serveur attendra que tous les travaux actifs soient terminés. Tous les travaux en file d'attente seront ignorés. Simultanément, puisque la concurrence en matière d'EE n'a pas de persistance, les tâches en attente qui ont été ignorées seront perdues.<br/>Pendant que le serveur est dans un état suspendu, les tâches planifiées continueront à s'exécuter à leur heure prévue mais émettront une <code>exception java.lang.IllegalStateException</code>. Une fois que le serveur reprend, les tâches planifiées continueront à s'exécuter normalement et dans la plupart des cas, les tâches n'auront pas besoin d'être reprogrammées.\n    </dd>\n    <dt>Lot</dt>\n    <dd>Le serveur arrêtera tous les travaux en cours d'exécution pendant la période de temporisation et reportera tous les travaux planifiés.<br/>Un arrêt en douceur ne rejettera pas les transactions distribuées à distance ou les nouveaux messages JMS entrants. Les jobs par lots EE et les tâches simultanées EE programmées par l’activité en vol sont actuellement autorisées. Cependant, les tâches concurrentes EE soumises qui vont au delà de la fenêtre de temporisation sont simultanément en erreur lorsqu'elles sont exécutées.\n    </dd>\n</dl>\n<p>Les requêtes sont suivies par le sous-système request-controller. Sans ce sous-système, les capacités de suspension et de reprise sont limitées et le serveur n'attendra pas que les requêtes soient terminées avant de suspendre ou de fermer. Cependant, si vous n'avez pas besoin de cette capacité, le sous-système request-controller peut être retiré pour une petite amélioration des performances.</p>",
"<p>Un adaptateur de ressources est un composant Java EE déployable qui assure la communication entre une application Java EE et un système d'information d'entreprise (EIS) en utilisant la spécification Java Connector Architecture (JCA). Un adaptateur de ressources est souvent fourni par les fournisseurs de SIE pour faciliter l'intégration de leurs produits avec les applications Java EE.</p>\n<p>Un système d'information d'entreprise (EIS) peut être n'importe quel système logiciel au sein d'une organisation. Les systèmes de planification des ressources de l'entreprise (ERP), les systèmes de base de données, les serveurs de messagerie électronique et les systèmes de messagerie propriétaires en sont des exemples.</p>\n<p>Un adaptateur de ressources est empaqueté dans un fichier RAR (Resource Adapter Archive) qui peut être déployé sur le serveur. Un fichier RAR peut également être inclus dans le déploiement d'une archive d'entreprise (EAR).</p>",
"<p>Permettre le déploiement d'archives SAR contenant des services MBean, ainsi supporté par les versions précédentes de ${build.shortName}.</p>",
"<p>Un domaine de sécurité se compose de configurations pour l'authentification, l'autorisation, le mappage de sécurité et l'audit. Il implémente la sécurité déclarative Java Authentication &amp; Authorization Service (JAAS).</p>\n<p>L'authentification consiste à vérifier l'identité d'un utilisateur. Dans la terminologie de sécurité, cet utilisateur est désigné comme « principal » Bien que l'authentification et l'autorisation soient différentes, de nombreux modules d'authentification inclus gèrent également l'autorisation.\n</p>\n<p>L'autorisation est un processus par lequel le serveur détermine si un utilisateur authentifié a la permission ou les privilèges d'accéder à des ressources spécifiques dans le système ou l'opération.</p>\n<p>Le mappage de sécurité fait référence à la possibilité d'ajouter, de modifier ou de supprimer des informations d'un principal, d'un rôle ou d'un attribut avant de transmettre les informations à votre application.</p>\n<p>Le gestionnaire d'audit vous permet de configurer les modules des fournisseurs 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 elle-même. Ceci vous permet de modifier les paramètres de sécurité de manière centralisée. Un scénario commun 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.</p>",
"<p>Le sous-système elytron est nouveau dans ${build.fullName}. Il est basé sur le projet WildFly Elytron, qui est un cadre de sécurité utilisé pour unifier la sécurité sur l'ensemble du serveur d'application. Le sous-système elytron crée un point de configuration unique pour la sécurisation des applications et des interfaces de gestion. WildFly Elytron fournit également un ensemble d'API et de SPI pour fournir des implémentations personnalisées de fonctionnalités et l'intégration avec le sous-système.</p>\n<p>De plus, il y a plusieurs autres caractéristiques importantes d'Elytron :</p>\n<ul>\n    <li>Des mécanismes d'authentification plus forts pour l'authentification HTTP et SASL.</li>\n    <li>Une architecture améliorée qui permet aux SecurityIdentities de se propager à travers les domaines de sécurité. Cela garantit une transformation transparente et prête à être utilisée pour l'autorisation. Cette transformation s'effectue à l'aide de décodeurs de rôles configurables, de mappeurs de rôles et de mappeurs de permissions.</li>\n    <li>Point centralisé pour la configuration SSL/TLS, y compris les suites de chiffrement et les protocoles.</li>\n    <li>Les optimisations SSL/TLS telles que la construction de SecureIdentity et l'autorisation étroitement liée à l'établissement d'une connexion SSL/TLS. La construction Eager SecureIdentity élimine le besoin de construire une SecureIdentity à la demande. Le fait de lier étroitement l'authentification à l'établissement d'une connexion SSL/TLS permet de vérifier les autorisations AVANT de recevoir la première requête.</li>\n    <li>Une base de données d'authentification sécurisée qui remplace l'ancienne implémentation de l'espace d’archivage sécurisé. Le nouveau store sécurisé peut stocker plusieurs autres types de justificatifs cryptés en plus des chaînes cryptées.</li>\n</ul>\n<p>Le nouveau sous-système elytron existe en parallèle avec le sous-système de sécurité et d’authentification management core hérités. Les méthodes héritées et Elytron peuvent être utilisées pour sécuriser les interfaces de gestion et assurer la sécurité des applications.</p>",
"<p>Configurez les politiques de sécurité Java à utiliser par le Java Security Manager</p>\n<p>Le gestionnaire de sécurité Java est une classe qui gère la limite externe du bac à sable (sandbox) de la machine virtuelle Java (JVM), contrôlant la façon dont l'exécution du code dans la JVM peut interagir avec des ressources extérieures à la JVM. Lorsque le gestionnaire de sécurité Java est activé, l'API Java vérifie l’approbation du gestionnaire de sécurité avant d'exécuter un large éventail d'opérations potentiellement dangereuses. Le gestionnaire de sécurité Java utilise une politique de sécurité pour déterminer si une action donnée sera autorisée ou refusée.</p>",
"<p>Définir des politiques singleton pour configurer le comportement des déploiements singleton ou pour créer des services MSC singleton.</p>\n<p>Un service unique en grappe, également connu sous le nom de service unique à haute disponibilité (HA), est un service déployé sur plusieurs nœuds dans une grappe ou cluster. Le service est fourni sur un seul des nœuds. Le nœud qui exécute le service singleton est généralement appelé le nœud maître.</p>\n<p>Lorsque le nœud maître tombe en panne ou s'éteint, un autre maître est sélectionné parmi les nœuds restants et le service est redémarré sur le nouveau maître. Mis à part un bref intervalle lorsqu'un maître s'est arrêté et qu'un autre n'a pas encore pris le relais, le service est fourni par un, mais un seul, nœud.</p>",
"<p>Un socket binding est une configuration nommée pour un socket. Les configurations <code>domain.xml</code> et <code>standalone.xml</code> incluent toutes deux une section où les configurations de socket nommées peuvent être déclarées. 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 des sockets (qui peuvent varier selon les machines).</p>",
"<p>Configurer les sous-systèmes et les ressources globales telles que les interfaces, les liaisons de socket, les chemins et les propriétés du système.</p>\n\n<p>Visualiser et modifier la configuration de chaque <strong>sous-système</strong> disponible. Par exemple, ajoutez une source de données, configurez un fournisseur de messagerie ou configurez la sécurité des applications.</p>\n\n<p>Liens utiles</p>\n<ul>\n    <li><a href=\"#runtime\">Server Runtime</a></li>\n</ul>",
"<p>Un ensemble de configurations de sous-système. Un sous-système est un ensemble de capacités ajoutées au serveur principal par une extension. En tant que tel, un sous-système fournit des capacités de manipulation de servlet, un conteneur EJB, un support JTA, etc.</p>",
"<p>Les valeurs des propriétés du système peuvent être définies à plusieurs endroits dans <code>domain.xml</code>, <code>host.xml</code> et <code>standalone.xml</code>. Les valeurs du fichier <code>standalone.xml</code> sont définies dans le cadre du processus de démarrage du serveur. Les valeurs dans <code>domain.xml</code> et <code>host.xml</code> sont appliquées aux serveurs lorsqu'ils sont lancés.</p>",
"<p>Configurez les options du gestionnaire de transactions, telles que les valeurs de délai d'attente, l'enregistrement des transactions et l'utilisation ou non de Java Transaction Service (JTS).</p>",
"<p>Le sous-système Undertow vous permet de configurer les paramètres du serveur Web et du conteneur de servlet. Il implémente la <a href=\"https://jcp.org/en/jsr/detail?id=340\" target=\"_blank\">spécification Java Servlet 3.1</a> ainsi que les webockets et prend en charge la mise à niveau HTTP et l'utilisation de gestionnaires de haute performance non bloquants dans les déploiements de servlets. Le sous-système Undertow a également la capacité d'agir comme un proxy inversé de haute performance qui supporte mod_cluster.\n</p>\n\n<p>Dans le sous-système Undertow, il y a six composants principaux à configurer :</p>\n<ol>\n    <li>Paramètres globaux</li>\n    <li>Caches tampons</li>\n    <li>Serveur</li>\n    <li>Conteneur de servlet</li>\n    <li>Filtres</li>\n    <li>Handlers</li>\n</ol>\n\n<p><strong>Important</strong><br/>\n    Le sous-système Undertow s'appuie également sur le sous-système E/S pour fournir des workers XNIO et des pools tampons. Le sous-système E/S est configuré séparément et fournit une configuration par défaut qui devrait donner des performances optimales dans la plupart des cas.\n</p>\n",
"<p>Un mappage à partir des références d'un domaine de sécurité dans une application déployée et des paramètres de Single Sign-on (SSO).</p>\n",
"<p>Le cache tampon est utilisé pour mettre en cache les ressources statiques. ${build.shortName} permet à plusieurs caches d'être configurés et référencés par des déploiements, permettant à différents déploiements d'utiliser des tailles de cache différentes. Les tampons sont alloués par région et ont une taille fixe. La quantité totale d'espace utilisé peut être calculée en multipliant la taille du tampon par le nombre de tampons par région et par le nombre maximum de régions. La taille par défaut d'une mémoire tampon est de 10 Mo.</p>",
"<p>Un pool de mémoire tampon d'octets utilisé pour les opérations d'E/S, qui offre les mêmes capacités que le pool de mémoire tampon du sous-système E/S, pouvant ainsi être utilisées de manière interchangeable et doivent avoir un nom unique. Ce pool de mémoire tampon permet une configuration plus précise de la quantité totale de mémoire conservée que le sous-système E/S.</p>",
"<p>Un filtre permet de modifier certains aspects d'une requête et peut utiliser des prédicats pour contrôler l’exécution d’un filtre. Certains cas d'utilisation courants pour les filtres incluent le réglage des en-têtes ou la compression GZIP.</p>\n\n<p>Les types de filtres suivants peuvent être définis :</p>\n<ol>\n    <li>Filtre personnalisé</li>\n    <li>Page d'erreur</li>\n    <li>Filtre d'expression</li>\n    <li>GZip</li>\n    <li>Mod Cluster</li>\n    <li>Limite de demande</li>\n    <li>En-tête de réponse</li>\n    <li>Réécriture</li>\n</ol>\n\n<p><strong>Remarque</strong><br/>\n    Un filtre est fonctionnellement équivalent à une valve globale utilisée dans les versions précédentes de ${build.shortName}.</p>\n",
"<p>Undertow permet de configurer deux types de gestionnaires ou handlers :</p>\n<ol>\n    <li>Gestionnaire de fichiers</li>\n    <li>Gestionnaires de proxy inversé (reverse-proxy)</li>\n</ol>\n<p>Les gestionnaires de fichiers s’occupent des fichiers statiques. Chaque gestionnaire de fichiers doit être attaché à un emplacement dans un hôte virtuel. Les gestionnaires de proxy inversé autorisent ${build.shortName} à être utilisés en tant que reverse-proxy de haute performance. Il peut gérer AJP, HTTP et HTTP.2 et supporte mod_cluster.</p>\n\n",
"<p>Un serveur représente une instance de Undertow et se compose de plusieurs éléments :</p>\n<ol>\n    <li>Hôte </li>\n    <li>HTTP Listener</li>\n    <li>HTTPS Listener</li>\n    <li>AJP Listener</li>\n</ol>\n\n<p>L'élément hôte fournit une configuration d'hôte virtuel tandis que les trois listeners fournissent des connexions de ce type à l'instance Undertow.</p>\n\n<p><strong>Remarque</strong><br/>\n    Plusieurs serveurs peuvent être configurés, ce qui permet d'isoler complètement les déploiements et les serveurs. Ceci peut être utile dans certains scénarios tels que les environnements multi-tenant avec plusieurs clients.\n</p>",
"<p>Un conteneur de servlet fournit toutes les configurations de servlet, de JSP et de socket web, y compris la configuration de session. Alors que la plupart des serveurs n'auront besoin que d'un seul conteneur de servlet, il est possible de configurer plusieurs conteneurs de servlet en ajoutant un élément servlet-conteneur supplémentaire. Le fait d'avoir plusieurs conteneurs de servlets permet un comportement tel que le déploiement de plusieurs déploiements sur le même chemin de contexte sur différents hôtes virtuels.</p>\n\n<p><strong>Remarque</strong><br/>\n    Une grande partie de la configuration fournie par le conteneur de servlet peut être écrasée individuellement par les applications déployées en utilisant leur fichier <code>web.xml</code>.</p>",
"<p>Les composants JBossWS sont fournis au serveur d'application par l'intermédiaire du sous-système de services Web. Les composants JBossWS prennent en charge le traitement des points de terminaison WS. Le sous-système prend en charge la configuration des adresses des points de terminaison publiées et des chaînes de gestionnaires de points de terminaison. Un sous-système de services Web par défaut est fourni dans le domaine du serveur et dans les fichiers de configuration autonomes.</p>\n\n<h2>Ressources supplémentaires</h2>\n<p>Le sous-système de service web est fourni par le projet JBossWS. Pour une description détaillée des propriétés de configuration disponibles, veuillez consulter la documentation du projet.</p>\n<ul>\n    <li>Page d'accueil de JBossWS <a href=\"http://www.jboss.org/jbossws\" target=\"_blank\">: http://www.jboss.org/jbossws</a></li>\n    <li>Documentation du projet <a href=\"https://docs.jboss.org/author/display/JBWS\" target=\"_blank\">: https://docs.jboss.org/author/display/JBWS</a>\n    </li>\n</ul>",
"<p>Configurez la fonctionnalité CDI (Contexts and Dependency Injection) pour ${build.shortName}.</p>",
"<p>core-management configure les fonctions suivantes :</p>\n<ul>\n    <li>Changements de configuration : Activez ou désactivez l'enregistrement en mémoire pour toute modification de configuration de ce profil. Les changements de configuration de la section Profil peuvent être visualisés dans la section Runtime du serveur associé à ce profil.</li>\n    <li>Listener de l'état du processus : Ajout d'une classe d'écoute (listen) personnalisée pour tout changement sur l'état du processus du serveur.</li>\n</ul>\n",
"<p>Le référentiel de contenu contient tout le contenu téléchargé vers le contrôleur de domaine. Après avoir été téléchargé, le contenu peut être assigné à un groupe de serveurs.</p>\n\n<p id=\"drag-and-drop-deployment\">Vous pouvez utiliser la fonction <strong>glisser-déposer</strong> pour ajouter un nouveau contenu ou remplacer un contenu existant. Il suffit de faire glisser un ou plusieurs fichiers sur la colonne de contenu. S'il y a déjà un contenu avec le même nom, le contenu sera remplacé, sinon le contenu sera ajouté.</p>\n\n<p>Vous pouvez également ajouter des déploiements non gérés. Un déploiement non géré pointe vers un dossier du système de fichiers local du serveur. Par rapport aux déploiements gérés, les déploiements non gérés ne seront pas copiés (c'est-à-dire téléchargés) dans le référentiel de déploiement du serveur avant d'être déployés. Le contenu de déploiement restera sur place et sera déployé directement à partir de son emplacement d'origine.</p>\n\n<p>Si un contenu n'est plus affecté à un groupe de serveurs, vous pouvez à nouveau supprimer le contenu.</p>",
"<p>Un <strong>déploiement</strong> est une ressource, telle qu'une application WAR ou EAR, qui peut être déployée sur un serveur.</p>\n\n<p>Dans un domaine géré, les déploiements sont affectés à des groupes de serveurs. Toutes les instances de serveur d'un groupe de serveurs auront le même contenu de déploiement.</p>\n\n<img class=\"preview\" src=\"previews/deployments.png\"/>",
"<p>Gérer les déploiements d'un groupe de serveurs</p>\n<p id=\"drag-and-drop-deployment\">Vous pouvez utiliser le <strong>glisser-déposer</strong> pour ajouter de nouveaux déploiements au groupe de serveurs sélectionné. Il suffit de faire glisser un ou plusieurs fichiers sur la colonne de déploiement. Les déploiements ajoutés par glisser-déposer seront désactivés par défaut.\n</p>\n<p>Sélectionnez un ou plusieurs éléments dans le référentiel de contenu et déployez-le dans le groupe de serveurs sélectionné.</p>\n<p>Ajoutez des déploiements non gérés. Un déploiement non géré pointe vers un dossier du système de fichiers local du serveur. Par rapport aux déploiements gérés, les déploiements non gérés ne seront pas copiés (c'est-à-dire téléchargés) dans le référentiel de déploiement du serveur avant d'être déployés. Le contenu de déploiement restera sur place et sera déployé directement à partir de son emplacement d'origine.</p>\n",
"<p>Un groupe de serveurs est une collection d'instances de serveurs qui sont gérées et configurées en une seule instance. Dans un domaine géré, chaque instance de serveur d'application 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 le même contenu déployé.</p>\n\n<p>Utilisez cette colonne pour gérer les déploiements qui ont été affectés à un ou plusieurs groupes de serveurs. Téléchargez de nouveaux déploiements, déployez du contenu à partir du référentiel de contenu ou créez des déploiements non gérés.</p>\n",
"<p>Un déploiement représente tout ce qui peut être déployé (par ex. une application comme EJB-JAR, WAR, EAR, toute sorte d'archive standard comme RAR ou un déploiement spécifique-JBoss) dans un serveur.</p>\n<p id=\"drag-and-drop-deployment\">Vous pouvez utiliser le <strong>glisser-déposer</strong> pour ajouter du nouveau contenu ou remplacer des déploiements existants. Il suffit de faire glisser un ou plusieurs fichiers sur la colonne de déploiement. S'il existe déjà un déploiement portant le même nom, le déploiement sera remplacé, sinon le déploiement sera ajouté. Les déploiements ajoutés par glisser-déposer seront activés par défaut.\n</p>",
"<p>Les extensions sont un moyen d'ajouter de nouvelles fonctionnalités à la console d'administration. Ils sont écrits en JavaScript et devraient utiliser l'<a href=\"https://github.com/hal/hal.next/wiki/JavaScript-API\">API JavaScript</a> pour interagir avec la console et l'interface de gestion. Si vous souhaitez développer une extension, consultez <a href=\"https://github.com/hal/hal.next/wiki/Extensions\">https://github.com/hal/hal.next/wiki/Extensions</a> pour plus d'informations.\n</p>\n\n<div class=\"alert alert-warning\">\n    <span class=\"pficon pficon-warning-triangle-o\"></span>Les extensions sont écrites en <strong>JavaScript</strong> et sont <strong>injectées</strong> dans le navigateur. Veuillez n'installer que des extensions en lesquelles vous avez confiance !\n</div>\n\n<h2>Points d'extension</h2>\n<p>La console fournit quatre points d'extension différents qui peuvent être utilisés par des extensions :</p>\n<ol>\n    <li>En-tête : Ajoute un élément de menu au menu déroulant \"Extensions\" dans l'en-tête</li>\n    <li>Rechercher un élément : Ajoute un nouvel élément à une colonne de recherche spécifique</li>\n    <li>Pied de page : Ajoute un élément de menu au menu déroulant \"Extensions\" dans le pied de page</li>\n    <li>Personnalisé : C'est à l'extension de décider comment s'ajouter à la console</li>\n</ol>\n\n<h2>Installation</h2>\n<p>Les extensions peuvent être ajoutées à la console de deux façons différentes :</p>\n\n<dl>\n    <dt>Extensions groupées</dt>\n    <dd>\n        <p>Les extensions groupées font partie de l'installation ${build.fullName} et sont installées sous forme de modules. Elles doivent être installées à l'extérieur de la console. WildFly et la console doivent être redémarrés / rechargés après l'ajout ou la suppression des extensions groupées.</p>\n    </dd>\n\n    <dt>Extensions autonomes</dt>\n    <dd>\n        <p>Les extensions autonomes sont hébergées par un terminal accessible au public. Ce point d'extrémité doit servir un fichier JSON qui contient des métadonnées pour l'extension. Vous pouvez ajouter et supprimer des extensions autonomes à l'aide de la console de gestion. Elles sont stockées dans le stockage local du navigateur. En tant que tel, elles sont dirigées vers le navigateur et l'URL qui exécute la console d'administration.</p>\n    </dd>\n</dl>\n",
"<p>Configurer les paramètres liés à l'interface de gestion, revoir les derniers changements de configuration et gérer les extensions de la console de gestion.</p>\n\n<h2>Interface de gestion</h2>\n<p>Visualiser et modifier les paramètres des interfaces de gestion http et natives comme la liste des origines autorisées, le domaine de sécurité, le contexte SSL.</p>\n\n<h2>Extensions</h2>\n<p>Visualiser et gérer les extensions de la console de gestion. Les extensions sont un moyen d'ajouter de nouvelles fonctionnalités à la console d'administration. Elles sont écrites en JavaScript et se répartissent en deux catégories :</p>\n<ul>\n    <li>Extensions groupées : Une partie de l'installation ${build.fullName} fournie par les modules</li>\n    <li>Extensions autonomes : Extensions tierces hébergées par un serveur public</li>\n</ul>\n",
"<p>La méthode d'application d'un correctif à ${build.shortName} dépend de votre méthode d'installation. Si vous avez installé ${build.shortName} en utilisant la méthode ZIP ou la méthode d'installation, vous devez utiliser le système de gestion des correctifs basé ZIP. Si vous avez utilisé RPMs pour installer ${build.shortName} sur Red Hat Enterprise Linux, vous devez utiliser des correctifs RPM. Important.</p>\n\n<p>Avant d'appliquer ou d'annuler un correctif, vous devez sauvegarder votre serveur ${build.shortName}, y compris tous les déploiements et les fichiers de configuration.</p>\n\n<p>Des correctifs cumulatifs pour une installation ZIP ou Installer de ${build.shortName} sont disponibles pour téléchargement à partir du Portail Client Red Hat.</p>\n\n<p>Pour plusieurs hôtes ${build.shortName} dans un environnement de domaine géré, les hôtes individuels peuvent être patchés à partir de votre contrôleur de domaine ${build.shortName}.</p>\n\n<p>En plus d'appliquer un patch, vous pouvez également faire reculer l'application d'un correctif.</p>\n\n<h3>Remarques importantes sur le correctif d'installation de ZIP/Installer</h3>\n\n<ul>\n    <li>Si vous appliquez un correctif qui met à jour un module, les nouveaux JAR patchés qui sont utilisés lors de l'exécution seront stockés dans <code>${build.installDir}/modules/system/system/layers/base/.overlays/PATCH_ID/MODULE</code>. Les fichiers originaux non corrigés sont laissés dans <code>${build.installDir}/modules/system/system/layers/base/MODULE</code>, mais ces JAR ne sont pas utilisés au moment de l'exécution.</li>\n    <li>Afin de diminuer significativement la taille des correctifs cumulatifs pour ${build.shortName}, vous ne pouvez plus effectuer un retour partiel d'un correctif cumulatif. Pour un correctif déjà appliqué, vous ne pourrez pas revenir en arrière.</li>\n    <li>Par exemple, si vous appliquez CP03 à ${build.shortName}, vous ne pourrez pas revenir à CP01 ou CP02. Si vous souhaitez pouvoir revenir sur chaque correctif cumulatif, chaque patch cumulatif devra être appliqué séparément dans l'ordre dans lequel ils sont sortis.</li>\n</ul>",
"<p>Les utilisateurs authentifiés à l'aide du fichier <code>mgmt-users.properties, ou d'un serveur LDAP, peuvent être membres de groupes d'utilisateurs. Un groupe d'utilisateurs est un libellé arbitraire qui peut être attribuée à un ou plusieurs utilisateurs.</p>\n<p>Le système RBAC peut être configuré pour attribuer automatiquement des rôles aux utilisateurs en fonction des groupes d'utilisateurs auxquels ils appartiennent. Il peut également exclure des utilisateurs de rôles basés sur l'appartenance à un groupe.</p>\n<p>Lors de l'utilisation du fichier <code>mgmt-users.properties</code>, les informations de groupe sont stockées dans le fichier <code>mgmt-groups.properties.</code> Lors de l'utilisation de LDAP, les informations de groupe sont stockées dans le serveur LDAP et conservées par les responsables du serveur LDAP.</p>",
"<p>Role-Based Access Control (RBAC) est un mécanisme de spécification d'un ensemble de permissions pour les utilisateurs gestionnaires. Il permet à plusieurs utilisateurs de partager la responsabilité de la gestion des serveurs sans que chacun d'entre eux n'ait besoin d'un accès illimité. En prévoyant une \"séparation des tâches\" pour les utilisateurs de gestion, il est facile de répartir les responsabilités entre les individus ou les groupes sans accorder de privilèges inutiles. Cela garantit la sécurité maximale possible de vos serveurs et de vos données tout en offrant la flexibilité nécessaire à la configuration, au déploiement et à la gestion.</p>\n<p>Le contrôle d'accès basé sur les rôles fonctionne grâce à une combinaison de permissions et de contraintes de rôles. Sept rôles prédéfinis sont fournis, chacun ayant des permissions fixes différentes. Les rôles prédéfinis sont : Monitor, Operator, Maintainer, Deployer, Auditor, Administrator, et SuperUser (sélectionnez en un pour obtenir plus de détails sur ses permissions). Chaque utilisateur gestionnaire se voit attribuer un ou plusieurs rôles, qui spécifient ce que l'utilisateur est autorisé à faire pour la gestion du serveur.</p>\n<p><strong>Important :</strong> Avant de changer le fournisseur pour <code>rbac</code>, assurez-vous que votre configuration a un utilisateur qui sera mappé à l'un des rôles RBAC, de préférence avec au moins un utilisateur possédant le rôle Administrateur ou SuperUtilisateur. Sinon, votre installation ne sera pas gérable à moins qu'elle ne soit fermée et que la configuration XML ne soit modifiée.</p>",
"<h2>Rôles standard</h2>\n<p>Il existe sept rôles utilisateur prédéfinis :</p>\n<ul>\n    <li>Contrôleur (Monitor)</li>\n    <li>Opérateur (Operator)</li>\n    <li>Chargé de maintenance (Maintainer)</li>\n    <li>Déployeur (Deployer)</li>\n    <li>Auditeur (Auditor)</li>\n    <li>Administrateur (Administrator)</li>\n    <li>SuperUtilisateur (SuperUser)</li>\n</ul>\n<p>Chacun de ces rôles a un ensemble différent de permissions et est conçu pour des cas d'utilisation spécifiques. Les rôles Monitor, Operator, Maintainer, Administrator et SuperUser se construisent les uns sur les autres, chacun ayant plus de permissions que le précédent. Les rôles Auditor et Deployer sont semblables à ceux de Monitor et Maintainer, mais ils ont des permissions et des restrictions spéciales supplémentaires.</p>\n\n<h2>Roles Scoped (champ d’application limité)</h2>\n<p>Les rôles Scoped sont des rôles définis par l'utilisateur qui accordent les permissions de l'un des rôles standard, mais seulement pour un ou plusieurs groupes de serveurs ou hôtes spécifiés. Les rôles Scoped permettent d'accorder aux utilisateurs de gestion des permissions qui sont limitées aux seuls groupes de serveurs ou hôtes requis.</p>\n<p>Ils sont définis par cinq caractéristiques :</p>\n<ol>\n    <li>Un nom unique.</li>\n    <li>Rôle(s) standard sur lequel il est basé.</li>\n    <li>S’il s'applique aux groupes de serveurs ou aux hôtes</li>\n    <li>La liste des groupes de serveurs ou des hôtes auxquels il est limité.</li>\n    <li>Si tous les utilisateurs sont automatiquement inclus. Cette valeur par défaut est false.</li>\n</ol>\n<p>Une fois créé, un rôle scoped peut être assigné aux utilisateurs et aux groupes de la même manière que les rôles standard.</p>\n<p>La création d'un rôle Scoped ne vous permet pas de définir de nouvelles permissions. Les rôles Scoped ne peuvent être utilisés que pour appliquer les permissions d'un rôle existant dans un champ d'application limité. Par exemple, vous pouvez créer un rôle Scoped basé sur le rôle Deployer qui est limité à un seul groupe de serveurs.</p>\n<p>Il n'y a que deux champs d'application auxquels les rôles peuvent être limités, à savoir le groupe d'hôtes et le groupe de serveurs.</p>\n<dl>\n    <dt>Rôles Host-Scoped</dt>\n    <dd>Un rôle dont le champ d’application au niveau hôte et qui limite les permissions de ce rôle à un ou plusieurs hôtes. Cela signifie que l'accès est fourni aux arborescences de ressources /host=*/ pertinents mais les ressources spécifiques à d'autres hôtes sont cachées.</dd>\n    <dt>Rôles Server-Group-Scoped </dt>\n    <dd>Un rôle Server-Group-Scoped limite les permissions de ce rôle à un ou plusieurs groupes de serveurs. De plus, les permissions de rôle s'appliqueront également au profil, au groupe de liaison de socket, à la configuration de serveur et aux ressources de serveur qui sont associées aux groupes de serveurs spécifiés. Toutes les sous-ressources à l'intérieur de celles qui ne sont pas logiquement liées au groupe de serveurs ne seront pas visibles pour l'utilisateur.</dd>\n</dl>",
"<p>Il existe sept rôles utilisateur prédéfinis :</p>\n<ul>\n    <li>Contrôleur (Monitor)</li>\n    <li>Opérateur (Operator)</li>\n    <li>Chargé de maintenance (Maintainer)</li>\n    <li>Déployeur (Deployer)</li>\n    <li>Auditeur (Auditor)</li>\n    <li>Administrateur (Administrator)</li>\n    <li>SuperUtilisateur (SuperUser)</li>\n</ul>\n<p>Chacun de ces rôles a un ensemble différent de permissions et est conçu pour des cas d'utilisation spécifiques. Les rôles Monitor, Operator, Maintainer, Administrator et SuperUser se construisent les uns sur les autres, chacun ayant plus de permissions que le précédent. Les rôles Auditor et Deployer sont semblables à ceux de Monitor et Maintainer, mais ils ont des permissions et des restrictions spéciales supplémentaires.</p>",
"<p>Ce qu'un utilisateur de gestion est autorisé à faire est déterminé par les rôles auxquels l'utilisateur est assigné. Un système d'inclusion et d'exclusion basé sur l'appartenance de l'utilisateur détermine à quel rôle un utilisateur appartient.</p>\n<p>Un utilisateur est associé à un rôle si :</p>\n<ol>\n    <li>L'utilisateur est :</li>\n    <ul>\n        <li>répertorié en tant qu'utilisateur à inclure dans le rôle, ou</li>\n        <li>membre d'un groupe à inclure dans le rôle.</li>\n    </ul>\n    <li>L'utilisateur n'est pas :</li>\n    <ul>\n        <li>répertorié en tant qu'utilisateur à exclure du rôle, ou</li>\n        <li>membre d'un groupe à exclure du rôle.</li>\n    </ul>\n</ol>\n<p>Les exclusions ont priorité sur les inclusions.</p>",
"<p>Affiche la configuration du domaine de sécurité de l'application et ses déploiements associés.</p>\n",
"<p>Permet d'accéder aux opérations d'exécution telles que'Test de connexion' et les opérations de vidage.</p>\n<p>Afin de visualiser la source des données et les statistiques JDBC, assurez-vous de les activer dans la section configuration.</p>",
"<p>Affiche les métriques d'exécution pour les servlets et les webockets tels qu'ils sont contenus dans les déploiements.</p>\n",
"<p>Un domaine se compose d'un contrôleur de domaine, d'un ou plusieurs contrôleur(s) hôte(s) et de zéro ou plusieurs groupes de serveurs par hôte.</p>\n<img class=\"preview\" src=\"previews/domain.png\"/>\n<p>Un contrôleur de domaine est le point central à partir duquel le domaine est contrôlé. Il s'assure que chaque serveur est configuré selon la politique de gestion du domaine. Le contrôleur de domaine est également un contrôleur hôte.</p>\n<p>Un contrôleur d'hôte est un hôte physique ou virtuel sur lequel le script domain.sh ou domain.bat est exécuté. Les contrôleurs d'hôte sont configurés pour déléguer des tâches de gestion de domaine au contrôleur de domaine. Le contrôleur hôte de chaque hôte interagit avec le contrôleur de domaine pour contrôler le cycle de vie des instances du serveur d'application s'exécutant sur son hôte et pour aider le contrôleur de domaine à les gérer. Chaque hôte peut contenir plusieurs groupes de serveurs.</p>\n<p>Un groupe de serveurs est un ensemble d'instances de serveurs qui ont ${build.shortName} installé sur elles-mêmes et qui sont gérés et configurés comme un seul. Le contrôleur de domaine gère la configuration et les applications déployées sur les groupes de serveurs. Par conséquent, chaque serveur d'un groupe de serveurs partage la même configuration et les mêmes déploiements.</p>\n",
"<p>Fournit un ensemble d'opérations d'exécution pour les ressources suivantes du sous-système elytron :</p>\n<ul>\n    <li><strong>Compte d'autorité de certification</strong> : Crée, désactive et met à jour un compte et modifier la clé de compte.</li>\n    <li><strong>Gestionnaire de clés</strong> : Réinitialise le gestionnaire clé.</li>\n    <li><strong>Domaine de sécurité :</strong> Lit une identité.</li>\n    <li><strong>Gestionnaire de certificats de confiance</strong> : Recharge la liste de révocation des certificats.</li>\n</ul>",
"<p>Fournit un ensemble d'opérations d'exécution pour les ressources suivantes du sous-système elytron :</p>\n<ul>\n    <li><strong>Caching Realm</strong> : Supprime toutes les entrées du cache.</li>\n    <li><strong>Domaine personnalisable et modifiable sur mesure :</strong> Ajoute, lit et supprime des identités. Définit également un mot de passe pour une identité.</li>\n    <li><strong>Filesystem Realm</strong>: Ajoute, lit et supprime des identités. Définit également un mot de passe pour une identité.</li>\n    <li><strong>LDAP Realm</strong> : Ajoute, lit et supprime des identités. Définit également un mot de passe pour une identité.</li>\n    <li><strong>Properties Realm</strong>: Recharge les fichiers de propriétés à partir du système de fichiers.</li>\n</ul>",
"<p>Fournit un ensemble d'opérations d'exécution pour les ressources suivantes du sous-système elytron :</p>\n<ul>\n    <li><strong>Magasin d’authentifications</strong>: Ajoute, lit et supprime des alias, définit un mot de passe pour un alias. Aussi, recharge le store d’authentifications</li>\n    <li><strong>Magasin de clés de filtrage</strong>: Lit et supprime les alias.</li>\n    <li><strong>Magasin de clés</strong>: Lit, modifie et supprime des alias. Importe et exporte un certificat. Génére une paire de clés. Génére une demande de signature de certificat. Charge et stocke le magasin de clés</li>\n    <li><strong>Magasin de clés LDAP :</strong> Lit et supprime les alias.</li>\n</ul>",
"<p>Un contrôleur d'hôte est lancé lorsque le script <code>domain.sh</code> ou <code>domain.bat</code> est exécuté sur un hôte.</p>\n\n<p>La responsabilité première d'un contrôleur hôte est la gestion du serveur. Il délègue les tâches de gestion de domaine et est responsable du démarrage et de l'arrêt des différents processus du serveur d'application qui s'exécutent sur son hôte.</p>\n\n<p>Il interagit avec le contrôleur de domaine pour aider à gérer la communication entre les serveurs et le contrôleur de domaine. Plusieurs contrôleurs hôtes d'un domaine peuvent interagir avec un seul contrôleur de domaine. Par conséquent, tous les contrôleurs hôtes et les instances de serveur fonctionnant en mode domaine unique ont un contrôleur de domaine unique et doivent appartenir au même domaine.</p>\n\n<p>Par défaut, chaque contrôleur hôte lit sa configuration à partir du fichier <code>domain/configuration/host.xml</code> situé dans le fichier d'installation ${build.shortName} décompressé sur le système de fichiers de son hôte. Le fichier <code>host.xml</code> contient les informations de configuration suivantes qui sont spécifiques à l'hôte en question :\n</p>\n\n<ul>\n    <li>Les noms des instances ${build.shortName} destinées à être exécutées à partir de cette installation.</li>\n    <li>Une des configurations suivantes :</li>\n    <ul>\n        <li>Comment le contrôleur contacte le contrôleur de domaines pour s'enregistrer lui-même et pour accéder à la configuration de domaine.</li>\n        <li>Comment rechercher et contacter un contrôleur de domaines éloigné.</li>\n        <li> Si le contrôleur hôte doit agir en tant que contrôleur de domaine</li>\n    </ul>\n    <li>Configurations spécifiques à l'installation physique locale. Par exemple, les définitions d'interface nommées déclarées dans <code>domain.xml</code> peuvent être mappées à une adresse IP spécifique à la machine dans <code>host.xml</code>. Et les noms de chemins d’accès abstraits dans le domaine.xml peuvent être mappés aux chemins réels du système de fichiers dans <code>host.xml</code>.\n    </li>\n</ul>",
"<p>Liste des ressources REST déployées</p>",
"<p>Fournit une vue d'ensemble de l'espace noms JNDI local. La spécification de la plate-forme Java EE définit les contextes JNDI suivants :</p>\n<ul>\n    <li><code>java:comp</code> - L'espace de nommage est étendu au composant actuel (EJB)</li>\n    <li><code>java:module</code> - Limité au module en cours</li>\n    <li><code>java:app</code> - Limité à l’application en cours</li>\n    <li><code>java:global</code> - Limité au serveur d'application</li>\n</ul>\n<p>En plus des espaces de noms standard, ${build.shortName} fournit également les deux espaces de noms globaux suivants :</p>\n<ul>\n    <li><code>java:jboss</code></li>\n    <li><code>java:/ / java</code></li>\n</ul>\n<p>Veuillez noter que seules les entrées du contexte java:jboss/exportés sont accessibles via JNDI distant. Pour les déploiements web, <code>java:comp</code> est aliasé en <code>java:module</code>, de sorte que les EJB déployés dans un war n'ont pas leur propre espace de noms comp.</p>",
"<p>Affiche les statistiques pour les unités de persistance qui font partie des déploiements actifs du serveur sélectionné.</p>\n<p>Afin de visualiser les statistiques, assurez-vous de les activer en ajoutant &lt;property <code>name=\"hibernate.generate_statistics\" value=\"true\"/></code> à votre persistence.xml.\n</p>",
"<p>Visualiser les journaux du serveur et des applications afin d'aider à diagnostiquer les erreurs, les problèmes de performance et autres problèmes. Pour qu'un journal soit visible, il doit être situé dans le répertoire <code>jboss.server.log.log.dir</code> du serveur. La console respecte également l'attribution des rôles RBAC de l'utilisateur, de sorte qu'un utilisateur ne peut voir que les journaux auxquels il peut accéder.\n</p>\n\n<p>Par défaut, la console affiche les 2000 dernières lignes d'un fichier journal. Si vous voulez voir le fichier journal dans son ensemble, veuillez sélectionner «Télécharger ». Pour visualiser ou suivre le fichier journal dans une fenêtre de navigateur séparée, sélectionner « Ouvrir »dans la fenêtre externe.</p>",
"<p>Affiche les métriques d'exécution pour les équilibreurs, les nœuds et les contextes.</p>\n",
"<p>Le sous-système elytron est nouveau dans ${build.fullName}. Il est basé sur le projet WildFly Elytron, qui est un framework de sécurité utilisé pour unifier la sécurité sur l'ensemble du serveur d'application. Le sous-système elytron permet un point de configuration unique pour la sécurisation des applications et des interfaces de gestion. WildFly Elytron fournit également un ensemble d'API et de SPI pour fournir des implémentations personnalisées de fonctionnalités et l'intégration avec le sous-système.</p>\n<p>Cet affichage de runtime fournit des informations dynamiques sur les différents magasins, domaines de sécurité et ressources SSL qui sont configurés pour ce serveur.</p>",
"<p>Un groupe de serveurs est une collection d'instances de serveurs qui sont gérées et configurées en une seule instance. Dans un domaine géré, chaque instance de serveur d'application appartient à un groupe de serveurs, même s’il s’agit d’un seul membre. Les instances de serveur d'un groupe partagent la même configuration de profil et le même contenu déployé.</p>\n\n<p>Un contrôleur de domaines et un contrôleur hôte font appliquer la configuration standard sur toutes les instances de serveur de chaque groupe de serveurs sur son domaine.</p>\n\n<p>Un domaine peut être constitué de plusieurs groupes de serveurs. Différents groupes de serveurs peuvent être configurés avec différents profils et déploiements. Un domaine peut être configuré avec différents niveaux de serveurs fournissant différents services, par exemple.</p>\n\n<p>Différents groupes de serveurs peuvent également avoir le même profil et les mêmes déploiements. Cela peut, par exemple, permettre d'effectuer des mises à niveau d'applications lorsque l'application est mise à niveau sur un groupe de serveurs, puis mise à jour sur un deuxième groupe de serveurs, évitant ainsi une panne de service complète.</p>\n",
"<p>Visualisez et surveillez les services d'exécution, tels que les fichiers journaux, les métriques JVM et les données d'exécution spécifiques au sous-système.</p>",
"<p class=\"topology\">Une vue d'ensemble des hôtes, groupes de serveurs et serveurs définis dans votre domaine avec les groupes de serveurs en colonnes et les hôtes en lignes. Les serveurs sont affichés en fonction de leur état : <span class=\"status error\">erreur</span>, <span class=\"status warning\">besoin de recharger / redémarrage</span>, <span class=\"status suspended\">mise en attente</span>, en état de <span class=\"status ok\">exécution</span> et <span class=\"status inactive\">arrêt ou désactivé</span>.</p>\n<p>Sélectionnez un hôte, un groupe de serveurs ou un serveur pour voir des informations supplémentaires ou exécuter des opérations.</p>",
"<p>Affiche les métriques d'exécution des connecteurs enregistrés en tant qu’ ajp-listener, http-listener et https-connectors d'un serveur spécifique.</p>",
"<p>Le serveur web (Undertow) contient de nombreuses métriques d'exécution, réparties dans les sections suivantes :</p>\n<ul>\n    <li><strong>Domaine de sécurité des applications :</strong> Affiche la configuration du domaine de sécurité des applications et de leurs déploiements associés.</li>\n    <li><strong>Serveur :</strong> Affiche les métriques d'exécution des connecteurs enregistrés en tant qu’ ajp-listener, http-listener et https-connectors d'un serveur spécifique.</li>\n    <li><strong>Modcluster :</strong> Affiche les métriques d'exécution pour les équilibreurs, les nœuds et les contextes.</li>\n    <li><strong>Déploiement :</strong> Affiche les métriques d'exécution pour les servlets et les webockets tels qu'ils sont contenus dans les déploiements.</li>\n</ul>",
"<p>Les workers sont des instances de workers XNIO. Une instance de worker XNIO est une couche d'abstraction pour les API Java NIO, qui fournissent des fonctionnalités telles que la gestion des IO et des threads de workers, ainsi que la prise en charge de SSL. Par défaut, ${build.shortName} fournit un seul worker appelé par <code>défaut</code>, mais il est possible d'en définir d'autres.</p>"]