Cité 144 Logements

Résidence El-Bahia Hai

Fellaoucene N°35B ORAN

Tel / Fax : 041.272.927

Mobile 0779.177.761

Formation – Études – Conseil – Assistance – Consulting

FORMATION
WILDFLY -
Administration

DATE: Du 21-25 Avril 2019. Formateur :

LIEU: FORMATECH INSTITUT. Mr Ahmed LAOUEDJ
 Programme de La formation
1) Introduction à Java EE et WildFly
2) Installation de WildFly
3) Configuration standalone
4) Déploiement d’applications et de modules
5) Administration d’un domaine WildFly
6) Gestion des traces
7) Inspection du serveur
8) Optimisation des performances
9) Sécurité du serveur et des applications
1) Introduction à Java EE et WildFly

 Présentation de Java et de Java EE

 Typologie des applications Java EE
 Présentation de WildFly, JBoss AS et JBoss EAP
Java EE Overview
 Client
Physical Web UI Client Web Services Client
server 1 Tier

Application Server HTTP(S) XML/JSON

HTTP(S)
Web Container
Services
Web Layer Transverses
Web
Servlets, JSP, JSF, EL, JSTL
Tier JTA

JPA

JMX
Business Container
Physical Service Layer JAAS
server 2 Local EJB Session
Remote EJB Session
Message Driven Bean JAX-WS

Business Data Access Layer EJB EJB JAX-RS

Entity Entity
Tier EJB
WebSocket
Entity

Connectivity Layer CDI

JMS JDBC JCA JNDI

Concurency

Other
Physical
EIS Topic/ Legacy
Queue Database LDAP
servers Tier System
• JPA (Java Persistence API)
 Mapper des objets Java vers des tables de base de données et vice versa (Mapping O/R)
 JPA est une spécification qui a plusieurs implémentations ; Hibernate, EclipseLink ,OpenJPA etc
…

• JMS (Java Messaging Sevice)

 Envoyer et recevoir des messages entre systèmes.
 Faible couplage entre composants.
 Communication Asynchrone.

• JCA (Java Connector Architecture)

 Founrir un standard d’architecture permettant au composants JEE de se connecter à des
resources du système d’information externe EIS (Entreprise Information System).

• EJB (Entreprise Java Bean)

 Composants Serveur distribués qui respectent les spécifications JEE de Sun.
 Faciliter la création d’applications distribuées.
 Permettre au développeur de se concentrer sur le code métier et déléguer certains
traitements tel que la gestion des transactions, la persistance des données , la sécurité au
serveur d’application.
 Trois types d’EJB , Session , Entity et Message Driven.
• Servlet
 Un Programme qui s’exécute coté serveur pour renvoyer du contenu dynamique au client.
 Repose sur le principe de communication client/serveur par exemple un serveur http.
 Pour s’exécuter, une servlet a besoin d’un conteneur web qui peut être intégré dans un serveur
d’application.
 Le conteneur web gère : le chargement de la servlet, gestion de son cycle de vie et passage des
requêtes et des réponses.
 L’API Java Servlet a été étendu pour créer d’autres APIs : JSP, JSF, EL, JAX-RS , JAX-WS, JSON,
WebSocket et WebFragment.

• JSP (Java Server Page)

 Permet la génération des pages web dynamiques.
 Permet la séparation de la présentation (code html) et les traitements écrits en Java sous forme
de JavaBean ou Servlets.
 Unifie la puissance du Java côté serveur et la facilité de mise en page HTML côté client.
 Se compose des tags HTML, des tags JSP et des scriptlets.
 Les JSP sont basés sur les servlets, le moteur JSP génère et compile automatiquement la servlet
qui permet la génération de la page web.
• JSF(Java Server Faces)
 Un framework MVC qui facilite et standarise le développement des applications Web.
 Fournit un ensemble de composants UI standard et réutilisables avec l’implémentation de
référence.
 Se distingue par un traitement de requêtes qui passe par 6 phases (steps) : Restor View, Apply
Request Value, Process Validation, Update Model Values, Invoke Application, Render Response.
 Les données des composants UI sont stockés dans des beans managés et controlés par JSF.
 Système de navigation entre les pages web.
 Une bibliothèque de tags personalisés pour utiliser des composants graphiques.
 Un système de rendu qui ne se limite pas à la technologie HTML mais ouvert à d’autre type de
devices.

• JAX-WS (Java API for Xml Web Services)

 Une API standard Java utilisé pour créer et consommer des Web Service de type SOAP.
 SOAP est une spécification XML pour envoyer des messages sur le réseau.
 Le message SOAP est complétement indépendant des systèmes d’exploitation et peut utiliser
plusieurs protocoles de communication comme HTTP ou SMTP.
 Il existe deux approches pour créer des Web service contrat-first qui commence par la création
du contrat WSDL ou contrat-last qui commence par la création de l’interface endpoint et son
implémentation et ensuite générer le WSDL.
• JAX-RS (Java API for Restful Web Services)
 Une API (Ensemble d’interfaces et annotations) offerte par Java EE pour créer et consommer
des services web de type RESTFull .
 REST (Representational State Transfer) est un style d’architecture qui permet de créer des
services web performants et scalables.

• JSON
 Une API Java pour parser, transformer et requêter des données JSON.

• WebSocket
 Une API Java pour intégrer les WebSockets dans Java EE.

• CDI (Context and Dependency Injection)

 Un framework d’injection de dépendance (DI) standard JEE.
 Création , gestion de cycle de vie et injections des composants vers d’autres composants
clients.
 Configurable via les annotations ou fichiers XML.

• Concurency
 A partir de JEE 7 il est possible d’exécuter des tâches en parallèle dans un conteneur JEE , chose
qu’était dangereuse avant.
 Utilisation du ManagedExecutorService comme étant une resource gérée par le conteneur pour
exécuter des tâches asynchrones.
• JTA (Java Transaction API)
 Une API pour gérer les transactions, elle permet de créer , commiter et rollbacker les
transaction.
 JTA peux gérer plusieur resources transactionelles comme exemple une base de données et un
serveur JMS.
 L’implémentation de JTA est fournie par le serveur d’application mais il est possible d’inclure
une gestionnaire de transactions JTA dans une application standalone.

• JNDI (Java Naming and Directory Interface)

 Permet à un composant JEE de localiser d’autres composants ou resources via un annuaire
central qui associe un nom unique à un objet pour faciliter son obtention. Par exemple un
composant qui se obtient une connection à une resource JDBC.

• JAAS (Java Authentication and Authorization Service)

 Permet d’authentifier les utilisateurs pour déterminer qui est entrain d’exécuter le code d’une
manière agnostique par rapport au type de composant (bean, servlet ou ejb)
 Permet d’autoriser les utilisateurs pour s’assurer qu’ils possèdent les permissions nécessaires
pour les actions exécutées.

• Batch
 Batch Processing for Java Platform a été introduit à partir de JEE 7.
 Définit une modèle de programmation pour les applications Batch (Job, Step, Item Reader, Item
Processor, Item Writer ) largement inspirer de Spring Batch.
Les typologies des applications Java EE
 • Application WEB Java EE

Java
Servlets JSP JSF EL JSTL
Bean

 Contenu généré dynamiquement en différents formats pour le client

 Collecter les données à partir de l’interface utilisateur et retourner le résultat approprié
 Controller le workflow des données entres les pages web.
 Gérer les sessions utilisateurs
 Effectuer quelques traitements au niveau des composants javabean.
 S’exécute dans un conteneur Web
 • Application Métier Java EE

Managed
EJB JAX-RS JAX-WS JPA
Bean

JTA JCA JMS JNDI

 Fournir la logique métier pour un domaine spécifique (Banque, E-commerce …)

 Répondre à un besoin plus large d’une entreprise
 S’exécute dans un serveur d’application qui englobe un conteneur Web et un conteneur EJB
 Réside dans un contexte doté de services transverses comme JTA, JCA, JMS , JNDI..
WildFly, JBoss AS et JBoss EAP
 Les différentes versions de JBoss

• JBOSS AS est la version communautaire (Open Source) du

serveur d’application
• En 2006 Red Hat a fait l’acquisition de JBoss et a créé la
version commerciale JBoss EAP (Entreprise Application
Platform)
• A partir de la version 8 JBoss a été renommé en WildFly pour
le distinguer de la version commerciale
 …
• WildFly 14  Java EE 8
 2) Installation de WildFly

 Prérequis de l’installation
 Installation de WildFly
 Démarrage de WildFly
 Création d’un Administrateur
 Arrêt de WildFly
 Installation de WildFly en Service
 Prérequis d’installation WildFly
 Il est recommandé d’utiliser JDK 9 ou plus.
 Téléchargement JDK 12
https://www.oracle.com/technetwork/java/javase/downloads/index.html

WildFly Labs-1
 Installer JDK dur C:\WildFlyTraing\tools\java\jdk-12
 Créer la variable d’environnement JAVA_HOME
 Installation WildFly
 Téléchargement WildFly http://www.wildfly.org
 Dé-zipper l’archive sous C:\WildFlyTraing\tools\server\wildfly-16
 Créer la variable d’environnement $JBOSS_HOME =
C:\WildFlyTraing\tools\server\wildfly-16
 Structure des répertoires WildFly
 Deux parties principales : une pour le mode serveur standalone et l’autre pour le mode
serveur domaine.
 Le répertoire modules est commun entre les deux et il contient le cœur du système.
 appclient est utilisé pour démarrer un conteneur léger de de wildfly pour déployer des
applications afin de leur permettre d’utiliser les services WildFly tel que Dependency
Injection (DI)
 bin contient les scripts de démarrage et leur de fichiers de configuration ainsi que plusieurs
scripts utilitaires tel que add-user.bat. Dans le sous-répertoire client se trouve le jar
nécessaire pour les clients non-maven.
 docs/schema contient les schémas xsd de définitions des fichiers xml de configuration.
 doc/examples/config contient quelques exemples de configuration en mode standalone.
 modules contient tous les modules installés dans le serveur d’application.
 standalone contient les fichiers de configuration, le répertoire de déploiement et d’autre
zone modifiable comme les logs utilisés par le server en mode standalone.
 domaine contiens les fichiers de configuration , le répertoire de déploiement et d’autre
zone modifiable comme les logs utilisés par le serveur en mode domain.
 welcome-content contient les ressources utilisées (html, images) par l’application web.
 Démarrer WildFly
 Il existe deux modes de serveur standalone et domain
 La différence n’est pas au niveau des fonctionnalités mais eu niveau du management du
serveur d’application.
 le mode domaine est utilisé pour gérer plusieurs instances de WildFly à partir d’un seul
point d’entrée.

WildFly Labs-2

 Pour démarrer WildFly en mode standalone , aller au répertoire $JBOSS_HOME/bin et

lancer :

/standalone.bat

 Pour démarrer WildFly en mode domaine , aller au répertoire $JBOSS_HOME/bin et lancer

/domain.bat

 Vérifier que le serveur est accessible par l’url : http://localhost:8080

 Créer un Administrateur
 Si vous voulez gérer le serveur d’application il faut créer un utilisateur administrateur.
 Pour le faire , juste exécuter la commande add-user.bat dans le répertoire $JBOSS_HOME/bin.

WildFly-Labs 3

 Créer un administrateur
En suivant les étapes affichées
 Arrêter WildFly
 La manière recommandée est d’utiliser le Command Line Interface (CLI)
 Pour le faire , juste exécuter la commande jboss-cli.bat dans le répertoire $JBOSS_HOME/bin.

WildFly-Labs 4

 Exécuter la commande jboss-cli.bat

 Connectez-vous ensuite par la commande connect
 Arrêter WildFly par la commande shutdown
 Il est possible de redémarrer avec la commande shutdown --restart=true
 En mode non-interactif en une seule commande jboss-cli.bat -c - -command=shutdown

Mode Remote
Si vous êtes connectez à un serveur distant alors un mot de passe est nécessaire pour exécuter la
commande CLI
 Installation de WildFly en Service sous Windows

 WildFly peut être installé comme un service pour qu’il soit lancé automatiquement au
démarrage de la machine.

WildFly-Labs 5

 Copier le répertoire $JBOSS_HOME/docs/contrib/scripts/service dans $JBOSS_HOME/bin

 Aller au répertoire $JBOSS_HOME/bin/service
 Pour installer WildFly en mode standalone comme un service, exécuter service install
 Maintenant vous pouvez gérer le service par Windows
 Vous pouvez gérer votre serveur d’application via le service windows (star/stop/restart)
 $JBOSS_HOME/bin/service/service restart
 Pour installer WildFly en mode domaine vous devez spécifier d’autre options comme le domaine
contrôleur et le host
 service install /controller localhost:9990 /host master
 Pour désinstaller le service, exécuter service uninstall
 Installation de WildFly en Service sous Unix
 Créer un lien symbolique au répertoire de Wildfly

 Créer le groupe et l’utilisateur qui sera le ownership du répertoire de l’installation :

 Configurer systemd et commencer par créer un répertoire /etc/wildfly/

 Copier vers /etc/wildfly les scripts qui sont dans $JBOSS_HOME/docs/contrib/scripts/systemd

 Notre service est prêt à démarrer:

 Arrêter :
 Démarrer automatiquement au startup de la machine
 3) Configuration de WildFly

 Les deux modes de WildFly

 Les deux outils d’administration
 Principaux éléments de configuration
 Configuration et Administration WildFly en mode
Standalone (CLI + Web Console)
 Configuration et Administration WildFly en mode
Domaine (CLI + Web Console)
 Quand la Web Console est bien utile
 Les deux modes du serveur d’application

 Dans le mode standalone chaque instance du serveur est un process indépedant, les
fichiers de configuration sont dans $JBOSS_HOME/standalone/configuration

 Dans le mode domaine vous pouvez lancer plusieurs serveurs d’application et les
gérer à partir d’un point central. Un domaine pourrais se composer de plusieurs
machine (physique ou virtuelle). Chaque machine peut avoir plusieurs instances du
serveur d’application qui sont sous le contrôle d’un du process Host Controller, les
fichiers de configuration sont dans $JBOSS_HOME/domain/configuration
 Les deux outils de configuration

 La console d’administration

 Une application web qui fait partie de la distribution WildFly

 Permet de configurer le serveur d’application , déployer des applications et consulter les
statistiques
 Un moyen simple pour entrer dans le cœur du système.

 Command Line Interface (CLI)

 Un outil en ligne de commande qui permet de réaliser des configurations avancées du
serveur d’application.
 Un accès plus large aux options, propriétés et statistiques en runtime.

Il existe une autre manière de configurer le serveur par modification directe du fichier XML de
configuration, il n’est pas recommander de l’utiliser car peut générer des erreurs au démarrage
du serveur d’application.
 Comprendre les éléments de configuration du
serveur

 La configuration est structurée en arborescence, l’élément root est le server qui

contient plusieurs éléments.
 Extensions

 La majorité des fonctionnalités du serveur d’application sont des extensions, chaque

extension implémente soit une spécification Java EE ou un des composants du cœur
du serveur.
 Si vous voulez rajouter une extension dans le serveur alors il faut rajouter l’élément
<extension/> dans domain.xml ou standalone.xml.
 Paths
 Un Path est un nom logique qui référence un chemin d’accès dans le système de
fichier.

 Cette référence peut être utilisée ailleurs dans le fichier de configuration.

Dans cet exemple le fichier de log se trouve dans /home/wildfly/logs/server.log

 Un Path peut être relatif à une autre référence

Dans cet exemple, si le serveur est installé dans /opt alors le path sera traduit en /opt/wildfly-
14.0.0.Final/standalone/data/example
 Interfaces
 Les interfaces contient la configuration des adresses IP ou les noms des serveurs sur lesquels le serveur
d’application peut être exposé.
 Deux interfaces réseaux sont définis par défaut : management et public.
 L’interface management est utilisé pour l’administration du serveur (comme par exemple CLI)
 L’interface public est utilisé pour accéder au services du serveur d’application.

 Dans cette exemple les interfaces public et management sont exposé respectivement aux propriétés
system jboss.bind.address.management et jboss.bind.address, il est possible de les modifier au
démarage par

 Il est possible de remplacer jboss.bind.address par l’option –b et jbss.bind.address.management par

l’option -bmanagement
 Socket binding groups
 Le socket binding associe un nom à une configuration de socket.
 A travers cette configuration , vous avez la possibilité de configurer les ports réseau à
ouvrir et écouter pour les connections entrantes.
 Chaque groupe de socket binding est associé à une interface réseau.

L’attribut jboss.socket.binding.port-offset sert à décaler les définitions de port avec un nombre fixe,
dans le cas où plusieurs instances tournent sur la même machine.
 System Properties
 Les propriétés système peuvent être configurés dans les scripts de démarrage ou dans
le fichier de configuration.

 Il est possible de définir les propriétés système par les outils de management ou
passer un argument au script de démarrage

 Si la liste des propriétés est longue, il est possible de les définir dans un fichier et les
charger au r du serveur d’application
 Profile
 Un profile est un ensemble de subsystems, chaque subsystem est une collection de
fonctionnalités du serveur d’application.

 Par exemple , le subsystem Undertow contiens une collections de connecteurs utilisés

par le serveur Web, le subsystem EJB définit la configuration du conteneur EJB et les
modules qu’il utilise.

 La configuration d’un profile est la même dans les fichiers standalone.xml et

domain.xml, la seule différence est que le mode standalone n’a qu’un seul profile
mais le mode domain peut avoir plusieurs profiles, un par groupe de serveurs.
 Configuration de WildFly en mode Standalone
 La configuration en mode standalone est basée sur profile unique qui contient la
configuration des différents susbsytems, les interfaces réseau et sockets etc … .
 La configuration par défaut est standalone.xml qui se trouve dans
JBOSS_HOME/standalone/configuration
 D’autres configurations sont disponibles comme par exemple standalone-full.xml qui
rajoute par rapport à la configuration standard le messaging et iiop-openjdk.

WildFly-Labs 6

 Démarrer WildFly avec la configuration Full

standalone.bat –c standalone-full.xml
 Vérifier que les substsèmes IIOP et Messaging sont activés
 Configuration de la JVM en mode Standalone

Dans le répertoire bin du serveur d’application, il se trouve un fichier standalone.conf.bat

qui est exécuté au démarrage du serveur, il permet de configurer plusieurs options parmi
lesquelles celles de la JVM

WildFly-Labs 7

 Démarrer WildFly avec la configuration ci-dessous

 Vérifier que les valeurs Xmx et MaxMetaspaceSize sont bien logguées dans la console.
 Configuration des interfaces réseau en mode
Standalone
WildFly-Labs 8
 Il est recommandé d’utiliser l’option –D pour configurer le binding réseau pour les
interfaces management et public mais il est possible de les modifier par CLI.
 Il est nécessaire de recharger la configuration comme demandé par le serveur
d’application
 Configuration Socket Binding en mode Standalone

 Socket Binding permet de modifier les ports utilisés par les interfaces.
 Il y a deux types de Socket Binding : Inbound pour les connections entrantes et
Outbound pour les connections sortantes comme par exemple les connections mail
pour envoyer des mails à l’extérieure.

WildFly-Labs 9

 Modifier le port http en utilisant CLI comme suite :

 Vérifier que l’interface Web est accessible via le port 8180.

 Configuration Path en mode Standalone
 Un Path peut être défini pour pointer sur une ressource externe :

WildFly-Labs 10

 Par ailleurs , il peut pointer sur une autre référence déjà définie :
 Configuration WildFly en mode Domain
 Un domaine est un ensemble de groupes de serveurs.
 Un groupe de serveurs est un ensemble de serveurs.
 Un groupe de serveurs est souvent utilisé pour associer une configuration unique à un
ensemble de serveurs : profile , paramètres JVM, sockets bindings ou applications
déployées.
 Du point de vue process, un domaine se compose :

 Domain Controller : c’est le point de contrôle du domaine , une instance du AS lancée

en mode domaine et joue le rôle du Domaine Controller
 Host Controller : C’est un process qui coordonne avec le Domain Controller le cycle de
vie des serveurs et la distribution des déploiements.
 Application server nodes : Des instances du serveur d’applications , chaque serveur
est associé à un groupe.
 Configuration WildFly en mode Domain
WildFly-Labs 11
Part1 : domain.xml

 La configuration serveur du domaine est centralisée dans domain.xml

 Il se trouve dans domain/configuration et contient la configuration utilisée par toutes
les instances du serveurs
 Ce fichier est nécessaire que pour le Domain Controller.
 Dans ce fichier nous définissions les groupes de serveurs.
 Configuration WildFly en mode Domain
Part2 : host.xml du master
 L’autre partie importante de la configuration domaine est le host.xml, il définit :
 Les serveurs d’application qui font partie du serveur du domaine et leurs groupes de
serveurs, dans notre exemple nous allons créer un serveur dédié au Domain
Controller qui n’aura aucun server d’application

 La localisation du Domain Controller, dans nôtre cas le Domain Controller va tourner

sur le même host

① Master Controller

 Démarrer le Domain Controller en spécifiant l’adresse IP du management et public

et le nom du fichier host s’il est différent avec l’option - - host-config
 Configuration WildFly en mode Domain
Part3 : host.xml du slave
 Après avoir configuré et démarré le Domain Controller , prochain étape est de
configurer les deux hosts slaves. Le Host Controller du slave téléchargera la
configuration du domaine et utilisera son propre host.xml
 La première chose à faire est de définir un nom unique pour chaque Host :

Host Controller 1

 Host Controller 2
 Configuration WildFly en mode Domain
Part3 : host.xml du slave
 Ensuite, nous avons besoin de spécifier comment le Host Controller se connectera au
Domain Controller
 En plus nous spécifions l’utilisateur qui sera utilisé pour se connecter au Domain
Controller, c’est l’utilisateur wildflyadmin qu’on a créé avant.

① Pas de valeur par

défaut pour cette
property car nous
allons la définir au
démarrage

 Finalement , nous spécifions le mot de passe qui sert à identifier l’utilisateur auprès
du Domain Controller (server identity)
 La dernière étape est de définir les serveurs de chaque host :
Host Controller 1

Host Controller 2

 Notez le flag auto-start qui indique que le serveur ne sera pas démarré
automatiquement au démarrage du Host Controller
 Le port-offset sert à éviter les conflits de port , avec ce paramètre on peut utiliser le
même socket binding group pour plusieurs serveurs sur le même host.
 Avec cette configuration , nous allons pouvoir démarrer les Host Controller
Host Controller 1

Host Controller 2

 Si vous regardez la console du Domain Controller (le master), vous verrez que les deux
host controllers sont connéctés.
 Cette configuration à donné l’architecture suivante:

Host Controller 1= 127.0.0.3

Host Controller 2= 127.0.0.4

Jboss.domain.master.address= 127.0.0.2
Jboss.domain.master.port:9999
 Administration de WildFly en Mode Domain
WildFly- Labs 12
 Se connecter au domain controller via CLI :

Regardons de près les éléments suivants :

profile  Configurer les profiles contenus dans le domaine

Host  Administration des serveurs du domaine (reload/restart)
server-groupe  Administration des groupes de serveurs (start/stop/restart/realod)
 Administration Des Profiles
 Une des tâches récurrentes d’un administrateur est de modifier la configuration d’un
profile

 Par exemple changer le time-out des EJB dans le subsystem ejb3 inclus dans le profile
full
 Administration des serveurs du domaine
 Il est possible d’effectuer les opérations suivantes sur les nœuds (serveur
d’application) : start, stop, suspend, resume et restart

 Ajouter un serveur à un groupe de serveur

 Vérifier que le host inclut bien le nouveau serveur

 Démarrer le nouveau serveur

 Stopper le nouveau serveur

 Supprimer le nouveau serveur

 Administration du Host Controller
WildFly- Labs 13
 Il est possible de contrôler le Host Controller et ainsi contrôler toutes les instances
des serveurs d’applications qu’il contient :

 Faire un rechargement de la configuration

 Arrêter un Host Controller et toutes ces instances de serveurs d’application

 Administration du goupe de serveurs
WildFly- Labs 14
 Certaines opérations d’administrations peuvent être effectuées au niveau du groupe
de serveur exactement comme au niveau du serveur (start, stop, suspend, resume et
restart) mais dans ce cas l’opération sera exécutée au niveau de tous les nœuds

 Recharger la configuration d’un groupe de serveurs

 Administration du WildFly avec la Console Web
 La console Admin est un autre moyen non négligeable d’administration de WildFly,
intuif et simple, il permet d’effectuer la plupart des tâches d’une manière rapide et
efficace.
 Si vous avez lié l’interface management avec 127.0.0.2 , alors vous pouvez se
connecter via l’adresse suivante : http://127.0.0.2:9990
 Ci-dessus, vous avez la page d’accueil qui vous permet d’accéder à toutes les
fonctionnalités du serveur d’application :

 Deployment : Permet d’installer ou désinstaller une application dans le serveur.

 Configuration : C’est la partie la plus importante qui permet de configurer les services
offerts par le serveur d’application.

 Runtime : Permet de consulter les statistiques sur les services en cous d’exécutions ou
les statistiques de la JVM du serveur d’application.

 Access Contrôl : Permet de définir les rôles d’autorisation qui contrôlent l’accès au
serveur d’application et ses ressources.

 Patchning : Permet d’appliquer un patch (update) à la version actuelle du serveur.

 WildFly Configuration avec la Web Console
 En cliquant sur l’onglet Configuration vous accédez à la configuration des services de
WildFly.
 WildFly Configuration avec la Web Console
 Si vous avez accès vous pouvez modifier la configuration en cliquant sur Edit.
 Administration du domain avec la Web Console
 L’admin console du domaine est riche de ces fonctionnalités et permet de gérer les
différents profiles et hôtes du domaine.
 Il est possible d’y accéder via l’adresse jboss.bind.address.management et le port
jboss.management.http.port, dans notre exemple : http://127.0.0.2:9990
 Administration du domain avec la Web Console
 Vous pouvez aller sur Runtime Hosts , sélectionner host1 et accéder à toutes les
opération de management possible sur ce serveur
 Copy Permet de créer un copie de serveur dans le domaine
 Edit URL Permet de modifier L’URL accessible depuis l’extérieure
par le Web
 Configuration Changes permet de tracer les modifications de
configuration gardées en mémoire
 Reload permet de recharger la configuration du serveur
 Restart permet de redémarrer le serveur
 Suspends permet de suspendre un serveur
 Stop permet d’arrêter un serveur
 Kill permet de stopper un serveur en envoyant un signal ‘kill’, sinon
de le détruire.
 Ajouter un serveur au domaine
 A partir de l’onglet Runtime, il est possible de modifier la typologie du domaine en
rajoutant de nouveaux serveurs
 Ajouter un serveur au domaine
 Ajouter « serveur-five » à l’hôte « host1»
 Administrer un groupe de serveur
 Il est possible aussi de gérer un serveur de groupe comme suite :
 Administrer un groupe de serveur
 Créer un groupe de serveur comme suite :
 Configuration de la JVM du domaine
 IL est possible de configurer la JVM à trois niveau

 Host : La configuration sera appliquée à tous les serveurs du Host

 Server Group : La configuration sera valable à tous les serveurs du groupe
 Server : La configuration sera appliquée juste sur le serveur en question

 Une règle générale (valable aussi pour la configuration à plusieurs niveaux comme System
Properties, Path et Interfaces) , la configuration la plus spécifique prime sur la
configuration la plus générale, par exemple la configuration de la JVM Server Group prime
sur la configuration du Host alors que la configuration Server prime sur celle du Server
Group.
Configuration de la JVM du Host
 Configuration de la JVM du Host
 Ci-dessous la JVM par défaut que vous pouvez modifier la configuration ou rajouter
d’autres JVM pour le Host en question.
Configuration de la JVM du Server Group
 Configuration de la JVM du Server Group
 Ci-dessous la JVM par défaut que vous pouvez modifier la configuration ou rajouter
d’autres JVM pour le Server Group en question.
Configuration de la JVM du Serveur
 Configuration de la JVM du Serveur
 Ci-dessous la JVM par défaut que vous pouvez modifier la configuration ou rajouter
d’autres JVM pour serveur en question.
 Quand La Console Admin est bien utile ?
Dans certains cas La console d’admin est bien plus pratique plus que CLI :

 Définition de datasource : Avec l’introduction du datasource template , il est plus

facile du créer une datasource surtout s’il est nécessaire d’en créer un JDBC driver.
 Deploiement : Le déploiement d’une application distante à l’aide de la console
d’admin est plus simple.
 Domaine : La console d’admin fournit une vue panoramique de votre domaine , ce qui
est possible avec CLI aussi mais après plusieurs commandes.
 Statistiques en Runtime : Il est plus simple d’accéder aux différents métriques du
serveur à l’aide de la console d’admin.
 4) Déploiement d’artifactes
 Déploiement via le Système de fichier.
 Déploiement via La Web Console d’Admin (Standalone
& Domaine)
 Déploiement via CLI (Standalone & Domaine)
 Déploiement d’une Datasource (Standalone &
Domaine)
 Déploiement d’application
Le déploiement d’application est réalisable via trois outils :

 Une simple copie dans le système de fichier de l’artifact(mode standalone

uniquement)
 Via les interfaces d’administration (La console d’admin ou CLI)
 En utilisant le plugin Maven (Phase développemet )
 Déploiement dans le système de fichier

C’est une approche qui est réalisable uniquement dans le mode standalone, si vous
voulez installer dans un mode domaine il vaut mieux utiliser les interface managements
(la console d’admin ou CLI
WildFly-Lab 15
 Copier l’exemple fourni avec le support de la formation example-war dans le
répertoire $JBOSS_HOME/standalone/deployments

 Voir la log du serveur le déploiement de cet exemple

 Vérifier que l’application web est accessible

Qu’est ce qui s’est passé ? Un process nommé le scanner de déploiement a détecté
qu’une nouvelle application est présente dans le répertoire deployment , il lui a préparé
son environnement de déploiement et l’a installée.
Ce scanner fonctionne selon deux modes différents :

 Auto-deploy : Le scanner surveille le répertoire deployments et installe

automatiquement les nouvelles applications ou les artifats dont le timestamp a
changé.
 Manual deploy : Le scanner ne vas pas surveiller le répertoire deployments mais
plutôt l’existence des fichier marqueurs qui servent à une sorte de commande
demandant au scanner d’installer, désinstaller ou réinstaller une application.
 Par défaut les artifactes packagés utilisent le mode auto-deploy alors que les
artifactes éclatés en répertoire utilisent le mode manual deploy .
Par exemple pour installer l’application manual-deploy.war , nous allons copier le
repertoire manual-deploy .war contenant l’application avec le fichier marqueur
manual-deploy.war.dodeploy

 En cas de réussite d’installation, un fichier marqueur manual-deploy.war.deployed

sera créé sinon en cas d’échec un autre fichier sera créé manual-deploy.war.failed.
 Configurer le scanner de déploiement via CLI
Le scanner de déploiement est un subsystème qu’on peut configurer via CLI :
 scan-enabled : Quad il est à true, le scanner de déploiement est activé/
 path : C’est le répertoire surveillé par le scanner.
 relative-to S’il est défini, c’est la valeur qui sera concaténée à la variable « »Path.
 Scan-interval : le temps entre chaque scan du répertoire.
 auto-deploy-exploded : Quand c’est activé , déployer automatiquement les archives
décompressés(désactivé par défaut).
 auto-deply-zipped : Quand c’est activé , déployer automatiquement les archives
(activé par défaut).
 auto-deploy-xml : Quand c’est activé , déployer automatiquement les ressources
configurées dans les fichiers XML (ex : datasource, resource adapters ).
 deployment-timeout : la durée maximale pour compléter un déploiement
d’application (par défaut 600 secondes ).
 runtime-failure-causes-rollback : Quand c’est activé, un rollback est effectué après un
échec de déploiement.
 Déploiement via la Console d’Admin
 Le moyen le plus recommandé en production.
 Le seul moyen disponible en mode domaine avec CLI
 Déploiement en mode Standalone

Upload Deployment : permet de télécharger un archive compressé(war, ear , jar …)

Unmanaged Deployment : permet de télécharger un répertoire qui contient l’artifact.
Create Empty Deployment : permet de rajouter un artifact vide dans depolyments , pour
en rajouter du contenu ultérieurement.
Enable : activer l’application.
Disable : désactiver l’application.
Replace : remplacer le déploiement par un
autre.
Explode : transformer l’archive compressé en
répertoire.
Remove : supprimer l’application du
repository.
 Déploiement en mode Domaine
Le déploiement en mode domaine demande plus d’étapes
Chaque déploiement en mode domaine passe par :
 Copie dans le repository.
 Assigner à un groupe de serveurs.
 Ajouté l’application au repository.

Séléctionnez le groupe de serveurs où

déployer l’application.
  Déployer l’application

 Vérifier que l’application est disponible dans les trois serveurs du main-server-group

Server-one Server-three

Server-five
 Déploiement via CLI
 Le déploiement via CLI se fait via la commande deploy.
 Voici comment déployer en mode standalone :

 Désinstaller une application en mode standalone :

 Redéployer une application demande de rajouter un flag –f :

 Déployer une application depuis une URL :

 Installer un artifact décompressé :

 Il est possible de transformer un artifact compressé à un autre décompressé :

 Cette opération n’est pas recursive.

 Une fois vous êtes dans un mode décompressé , vous avez la possibilité de rajouter du
contenu dynamiquement à votre application :
 Déployer en mode domaine, comme déjà vu , il faut spécifier le server-group :

 Déployer à tous mes server groups:

 Désinstaller une application sur tous les server groups :

 Désinstaller une application sur un server group particulier :

 Si l’application est présente sur d’autre server group , il ne faut pas supprimer
l’artifcat dans le repository :
 Déploiement de DataSource
 La configuration de DataSource se fait par le subsystème datasource qui utilise la couche
JCA (Java Connector Architecture) du serveur d’application.

 Pour commencer, nous avons besoin d’installer une base de données , pour cela nous
utiliserons une image docker MYSQL:
 Déploiement de DataSource via CLI
en mode Standalone
 La création d’une datasource via CLI est pratique lorsque nous avons besoin de créer
l’arborescence du module du driver.
 CLI est recommandé aussi si nous voulons préparer un script qui sera automatisé.
 La commande suivante installe le module com.mysql

 Ensuite , nous avons besoin d’installer le driver JDBC :

 Enfin, nous allons installer la datasource avec les paramètres suivants

 Déploiement de DataSource via CLI
en mode Standalone
 Vous pouvez vérifier le répertoire du module créé avec le module.xml associé.

 Vous pouvez vérifier que la datasource a été correctement installée par la commande
suivante :
 Déploiement de DataSource via CLI
en mode Domaine
 La commande CLI add module n’est pas disponible en mode domaine, par conséquent, il
est recommandé de créer le module manuellement sur chaque host en copiant le fichier
jar avec son fichier module.xml dans le répertoire modules, par exemple pour le driver
MySQL JBOSS_HOME/modules/com/mysql/main/

 Ensuite installer le driver JDBC dans le profile serveur :

 Enfin, installer la datasource en utilisant la commande data-source qui demande le

paramètre –profile :
 Déploiement de DataSource via La Console Admin
en mode Standalone
 La création d’une datasource via Ia Console Web est plus rapide mais il ne peu être
automatisé comme CLI.
 Il est possible de déployer un driver comme tout autre déploiement.
Déploiement de DataSource via La Console Admin
en mode Standalone
 Déploiement de DataSource via La Console Admin
en mode Standalone
 Ensuite dans l’onglet configuration, vous pouvez rajouter la datasource dans le sub-
système DataSources
 Déploiement de DataSource via La Console Admin
en mode Standalone
 Sélectionnez ensuite le type de la base de données :
Déploiement de DataSource via La Console Admin
en mode Standalone
 Renseignez le nom de la datasource et
son lien JNDI où elle peut être
récupérée

 Sélectionnez le nom du driver et la

classe du driver qui doit être détectée
depuis le jar

 Entrez l’url de la connexion,

l’utilisateur et le mot de passe de la
base de données.
 Déploiement de DataSource via La Console Admin
en mode Domaine
 La création d’une datasource via Ia Console Web en mode domaine est presque la même
qu’en mode Standalone.
 Ajouter le driver dans le repository des déploiements
Déploiement de DataSource via La Console Admin
en mode Domaine
 Déploiement de DataSource via La Console Admin
en mode Domaine
 Ensuite déployer le driver dans le groupe de serveurs souhaité.
 Déploiement de DataSource via La Console Admin
en mode Domaine
 Ensuite créer la datasource dans le profile souhaité.
Déploiement de DataSource via La Console Admin
en mode Domaine
 Renseignez le nom de la datasource et
son lien JNDI où elle peut être
récupérée

 Sélectionnez le nom du driver et la

classe du driver qui doit être détectée
depuis le jar

 Entrez l’url de la connexion,

l’utilisateur et le mot de passe de la
base de données.
Déploiement de DataSource via La Console Admin
en mode Domaine
 Enfin, testez la connexion qui vient d’être créée.
 Déploiement d’une destination JMS
via La Console Admin
 Enfin, testez la connexion qui vient d’être créée.
 Déploiement d’une destination JMS
via La Console Admin
 L’extension messaging n’est pas disponible avec la configuration standard standalone.xml,
nous avons besoin de démarrer WildFly avec une configuration qui prend en compte cette
extension comme standalone-full.xml :

 En mode domaine il faut utiliser le profile full par le groupe de serveurs :

 Déploiement d’une destination JMS
via La Console Admin
 Pour créer une destination (Topic ou Queue) , dans l’onglet configuration sélectionnez
Server > default > Destination > View
 Déploiement d’une destination JMS
via La Console Admin
 Cliquez sur Add, vous devez renseignez au moins le nom et le JNDI valide java:/ ou
java:/jboss
 Déploiement d’une destination JMS
via La Console Admin
 Cliquez sur Add, vous devez renseignez au moins le nom et le JNDI valide java:/ ou
java:/jboss
 Déploiement d’une destination JMS
via La Console Admin
 Vérifier que la Queue a été bien créée :
 5) Configuration du Logging

 Les différents fichiers de log de WildFly

 Les Log Handlers
 Ajouter un Log Handler via la Console Web
 Lire les fichiers logs via CLI
 Configurer Log4J pour les applications
 Les différents fichiers de log de WildFly
 Le Logging de WildFly est basé sur Java UTIL Logging API (JUL) du J2SE.
 Par défaut WildFly envoie ses logs sur la console standard et un fichier de log situé par
défaut dans jboss.server.log.dir ce qui correspond en mode standalone à
JBOSS_HOME/standalone/log et en mode domaine à JBOSS_HOME/domain/log
 En mode standalone Le fichier log par défaut est server.log.
 Il est possible de modifier le répertoire de log :

 En mode domaine , le Host Controller envoie ses logs vers le fichier host-controller.log
 Le Process Controller lancé par le Host Controller envois ses logs vers process-controller.log
 Chaque serveur du domaine envoie ses logs vers
JBOSS_HOME/domain/servers/[servername]/server.log
 Les Log Handlers
 Un Handler reçoit les logs et les exportent vers une destination.
 Il est existe deux Handlers par défaut : le Console Handler qui log vers la console du serveur
et le Periodic Rotation File Handler qui log vers un fichier selon un rotation basée sur le
temps.
 Il existe huit types de handlers :
 Console Handler : log vers la console du serveur.
 File : log vers un fichier sans contraintes de temps ou de taille.
 Periodic : log vers un fichier selon la contrainte de rotation basée sur le temps.
 Size : : log vers un fichier selon la contrainte de rotation basée sur la taille.
 Periodic/Size : log vers un fichier selon la contrainte de rotation basée sur le temps ou
quand le fichier atteint une certaine taille.
 Async : log vers un fichier d’une manière asynchrone , ce qui permet d’optimiser les
performances.
 Custom : Permet d’implémenter sa propre Class de Logging (extends
java.util.logging.Handler)
 SysLog : Permet de logger vers le Syslog (journal d’événements) du système d’opération.
 Les Log Handlers
 Voici les différents Log Handlers configurés par défaut dans la Web Console.
 Les Log Handlers
 La configuration par defaut du Periodic Handler
Ajouter un Log Handler
Size Rotating Handler
 Ajouter un Log Handler
Size Rotating Handler
 Cliquez sur le boutton Add pour ajouter un Size Rotating Log Handler
 Ajouter un Log Handler
Size Rotating Handler
 Renseignez les attributs du Handler et cliquez sur Add :
 Ajouter un Log Handler
Size Rotating Handler
 Associez le log handler ajouté au Root Logger
 Ajouter un Log Handler
Size Rotating Handler
 Vérifiez que le nouveau fichier de log existe bien :
 Lire les fichiers logs via CLI
 Il est possible de lire les fichiers logs du serveur via CLI
 Lire les fichiers logs via CLI
 Une autre option intéressante est de filtrer le contenu du fichier log selon certains
paramètres, comme par exemple lire les 10 premières lignes du log :
 Configurer Log4J pour les applications

 Il existe un module de log4j dans WildFly : org.apache.log4j

 Pour utiliser Log4j dans une application, il faut rajouter la dépendance dans
META-INF/MANIFEST.MF

 Ensuite inclure le fichier log4j.xml dans le classpath de l’application WEB-INF/classes

 5) Monitoring de WildFly

 Runtime statistics via la Web Console

 JConsole
 VisualVM
 Runtime Statistics
 Via la Console Admin , dans l’onglet Runtime , nous avons la possiblité d’avoir les métriques
suivants :

 Les statistiques de la JVM.

 Les connections des datasources.
 Le pool des EJB
 Le temps de processing des requêtes HTTP
 Le temps de processing des requêtes Rest ou Soap
 ….
 Statut de la JVM

Le Pool de connections datasource

 Le Pool EJB

Le temps d’exécution des requêtes HTTP

Le temps d’exécution des requêtes SOAP
 Monitoring par les Outils JDK
 Mise à part la Console Web, il est existe d’autres outils qui permettent de surveiller la JVM
du serveur d’application comme JConsole ou VisualVM.
 La JConsole permet d’avoir des informations utiles sur la JVM du serveur et accéder au
propre Mbean de l’application.
 Utilser la JConsole fournie avec WildFly au lieu de celle de la JDK

 Se connecter à la JConsole via le

Remote Process car WildFly est lancé
dans un conteneur Docker.
JConsole - Overview
JConsole - Memory
JConsole - Threads
JConsole - Classes
JConsole – VM Summary
JConsole – MBean
JConsole – WildFly CLI
 VisualVM - Monitor
 VisualVM fournit plus d’information sur la JVM que JConsole.
 Il se trouve dans JAVA_HOME/bin
 A partir de JDK 9, VisualVM a été remplacé par un autre outil GraalVM d’Oracle.
VisualVM - Threads
VisualVM - Sampler
6) Optimisation de performances

 Le Process du Tuning de la Performance

 JVM Tuning
 Data Access Tuning
 EJB Pool Tuning
 EJB Threads Tuning
 Le Process de Tuning de la Performance

 Data Gathering : Collecter les statistiques et les métriques de l’application en cours

d’exécution.
 Data Analysis : Faire des hypothèses sur la cause du problème de perf en fonction des
statistiques collectés
 Verify Hypothesis : Corriger le problème et vérifier que les performances ont été améliorées
sinon reprendre le processus depuis le début.
 JVM Tuning

 Trouver les paramètres optimales de la JVM pour votre

environnement
 Choisir le bon Garbage Collector
 Visual GC
 JVM – Trouver les bons paramètres
 Le Java Heap est la mémoire alloué à l’application Java, elle partagée entre les threads.
 Quand elle n’est plus utilisée , elle est supprimée par le Grabage Collector.
 Configurée via le –Xms option qui définit la taille initiale du Heap et le –Xmx qui définit la
taille maximale du Heap
 La valeur du Xmx doit être assez suffisante pour éviter que le Garbage Collecor passe
beaucoup de temps de s’exécuter et pénaliser l’exécution de l’application.
 En pratique , observer le Heap de l’application en cours de test de charges, supposons que le
pic atteint est de 1G, alors il faut rajouter de 25% à 30% pour laisser un peu de marge à la
JVM

 Il ne faut pas dépasser 50% de la mémoire physique pour laisser assez de mémoire au
système d’exploitation.
 Dans les systèmes 64 bits , il ne faut pas aller au-delàs de 32 GB car cela réduit la
performance du CPU et pénalise le GC, en règle générale 26GB est la valeur idéale.
 Le Xms a moins d’impact sur la performance, si votre SLA (Service Level Agreement) n’est
pas strict , il est recommandé de lui attribuer la même valeur que Xmx pour éviter le
gaspillage des ressources VM pour augmenter le Heap.
 JVM – Trouver les bons paramètres
 Le Java Heap est la mémoire alloué à l’application Java, elle partagée entre les threads.
 Quand elle n’est plus utilisée , elle est supprimée par le Grabage Collector.
 Configurée via le –Xms option qui définit la taille initiale du Heap et le –Xmx qui définit la
taille maximale du Heap
 La valeur du Xmx doit être assez suffisante pour éviter que le Garbage Collecor passe
beaucoup de temps de s’exécuter et pénaliser l’exécution de l’application.
 En pratique , observer le Heap de l’application en cours de test de charges, supposons que le
pic atteint est de 1G, alors il faut rajouter de 25% à 30% pour laisser un peu de marge à la
JVM

 Il ne faut pas dépasser 50% de la mémoire physique pour laisser assez de mémoire au
système d’exploitation.
 Dans les systèmes 64 bits , il ne faut pas aller au-delàs de 32 GB car cela réduit la
performance du CPU et pénalise le GC, en règle générale 26GB est la valeur idéale.
 Le Xms a moins d’impact sur la performance, si votre SLA (Service Level Agreement) n’est
pas strict , il est recommandé de lui attribuer la même valeur que Xmx pour éviter le
gaspillage des ressources VM pour augmenter le Heap.
 HEAP – Choisir les bon rations

 Young Generation est l’espace où les nouveaux objets sont créés, quand il est plein , une
Minor garbage collecion est déclenchée,
 Une phase très rapide si le taux de mortalité des nouveaux objets est élevé.
 Old Generation est l’espace des anciens objets survivants au plusieurs passages du GC,
quand il est plein une Major garabage collection est déclenchée.
 Cette phase est assez lente car elle concerne tous les objets survivants.
 Metaspace est un espace pour stocker les metadata des classes et methodes.
 Pour les applications Web , il est intéressant de spécifier un espace Young Generation assez
large car la plupart des objets ne survivent pas longtemps (scope request).
 En règle générale du 1/3 à 1/2 du heap est la taille optimale, cela ne doit pas dépasser la
moitié car ça devient improductif.
 Utiliser les options NewSize et MaxNewSize pour spécifier l’espace Youn Gen et
SurvivorRatio pour définir le ratio avec l’espace Youn Gen.
 Choisir le bon Garbage Collector
 Garbage Collector passe par trois étapes :
1. Mark : Définir les objets en vie et les objets morts (non référencés)
2. Sweep/Delete : Supprimer les objets morts.
3. Compacting : Eliminer les fragments et déplacer les objets d’une manière contiguë.

 Il est existe 4 types de GC dans la JVM :

1. Serial
2. Parallel
3. CMS
4. G1

 Le Choix entres les différents GC est en fonction de la latence et le throughput de

l’application.
 Latence / Responsive : Une application doit répondre assez
rapidement à une requête, par exemple une application web qui
répond rapidement suite à une action utilisateur.
 Pour ce genre d’application , il n’est pas acceptable d’avoir une longue
interruption exécution de l’application (longue pause).

 Throughput : Une application doit effectuer le maximum de travail

dans une période de temps, par exemple un batch qui intègre des
données depuis une source externe.
 Ce genre d’application qui s’exécute pendant une longue période
peut accepter des longues pauses et le temps de réponse est peu
considéré.
 Serial Collector : C’est l’implémentation basique de GC qui s’exécute dans un seul thread et
arrête tous les threads des autres applications.
 Il n’est pas recommandé pour les applications client –serveur et multi-threads.
 Acceptable pour les petites applications qui n’ont pas une contrainte de latence.

 Parallel Collector : Il utilise les CPUs de la machine pour s’exécuter en parallèle mais il est
aussi « Stop The World » Colllector car il arrête toutes les autres applications pendant le GC.
 Il se déclenche quand le Heap est à 90% de sa taille maximale.
 Pour l’activer, il faut utiliser l’option suivante :
 -XX:+UseParNewGC : pour une exécution en parallèle.
 -XX:UseParallelGC : Pour les Heap de grande taille (plus que 10 GB)
 Il est recommandé dans pour les applications qui qui tournent sur des machines
multiprocesseurs et demandent un bon Throughput et n’ont pas de contraintes de latence.
 CMS (Concurent Mark Sweep) Garbage Collector : Il utilise plusieurs threads pour s’exécuter
en parallèle avec l’application.
 Réduit juste un peu le temps de réponse mais il dégrade pas la performance globale de
l’application.
 Il n’attend pas que le Heap soit plein car il tourne tout le temps.
 Activé par l’option -XX:+UseConcMarkSweepGC
 Il est recommandé dans les cas suivants :
 La JVM possède assez de mémoire (entre 1 et 16 GB)
 Responsive Applications (Exemple : Applications financières)
 G1 Garbage Collector (Garbage First) : Il est conçu pour les applications qui tournent dans
des machines multi-processor avec un grand Heap, il est inclut à partir de JDK 7u4.
 Il remplace CMS comme collector par défaut à partir de JDK 9.
 Il est le mélange des deux collectors (CMS et Parllel).

 Une première phase de Marking en parallèle pour désigner les objets vivants et les objets
morts.
 Ensuite il commence par supprimer les objets morts (Garbage First) , après il fait une
défragmentation de l’espace (Compacting).
 Pour l’activer , utiliser l’option -XX:+UseG1GC
 Il est recommandé pour les Heaps de plus de 16GB bien qu’il minimise aussi le temps de
réponse/latence.
Plugin Visual GC
 DataSource Tuning
 Ouvrir une connexion à une base de donnée distance coute en terme de temps et
ressources système.
 Pour cette raison chaque serveur d’application doit implémenter un pool de connections
pour minimiser ce cout de création de connexion.
 DataSource Tuning
 Activer les statistiques de datasource:

 Ensuite , il faut surveiller les valeurs suivantes

 Average number of Database Connections :

 Maximum amount of connections :

 Il est recommandé que les paramètres initial-pool-size et min-pool-size égale au Average

number of Database Connections.
 Il est recommandé que le paramètre max-pool-size soit 15-20% supérieure au Maximum
amount of connections.
 EJB Pool Tuning
 Si le composant EJB nécessite une initialisation couteuse en terme de temps et ressource
comme par exemple effectuer un lookup JNDI dans une méthode @PostConstruct alors il est
utile d’avoir un pool EJB, sinon il n’est pas nécessaire.
 Activer les statistiques EJB :
 Récupérer les statistiques à différents intervalles :

Si le peak-concurrent-invocations est
égale à pool-max-size alors il faut
augmenter la valeur slsb-strict-max-
pool ou mdb-strict-max-pool (en
fonction du type de EJB ) :
 EJB Thread Tuning
 Par défaut les EJB sont des composant synchrones mais il est possible de les invoquer d’une
manière asynchrone via un Thread.
 Un Thread EJB utilise un Thread Pool Executor qui alloue un thread pour chaque tâche à
exécuter.
 Un pool de threads a un core size et une queue , quand une tâche arrive, si le nombre de
threads en cours d’exécution est moins que le core size alors une nouveau thread est créé
sinon la tâche est mise dans la queue.
 Voici comment récupérer les statistiques du pool de threads :

Si le largest-thread-count est égale à

max-threads alors il faut augmenter la
valeur maximale du pool de thread :
/subsystem=ejb3/thread-
pool=ThreadsPoolName:write-
. attribute(name="max-threads",
value="50")
 7) Sécurité de WildFly

 Objectifs de la sécurisation.
 Sécurisation des interfaces d’administration.
 Gestion des autorisations et des authentifications pour
les applications.
 Sécurisation des échanges avec SSL.
 Les Objectifs
 L'authentification : L'authentification consiste à assurer l'identité d'un utilisateur,
c'est-à-dire de garantir à chacun des correspondants que son partenaire est bien
celui qu'il croit être. Un contrôle d'accès peut permettre (par exemple par le moyen
d'un mot de passe qui devra être crypté) l'accès à des ressources uniquement aux
personnes autorisées.
 L’autorisation : Limiter l’accès à des ressources à un groupe bien définit
d’utilisateurs ce qui assure que ces derniers possèdent bien les permissions
nécessaires d’effectuer des opérations ou d’accéder à des données.
 La confidentialité : consiste à rendre l'information inintelligible à d'autres
personnes que les seuls acteurs de la transaction.
 L'intégrité : Vérifier l'intégrité des données consiste à déterminer si les données
n'ont pas été altérées durant la communication (de manière fortuite ou
intentionnelle).
 La disponibilité ou La Qualité du Service (QoS) : L'objectif de la disponibilité est de
garantir l'accès à un service ou à des ressources.
 La non-répudiation : La non-répudiation de l'information est la garantie qu'aucun
des correspondants ne pourra nier la transaction.
 Sécurisation des interfaces d’administration

 Security Domain : Il Consiste à une politique de sécurité matérialisée par un

ensemble de configurations nécessaire pour l’authentification , autorisation,
mapping de sécurité et l’audit . Il implémente la spécification JAAS.
 Security Realm : C’est un store ou un repo d’identités qui est responsable de
répondre à une authentification basé sur une username/password. Le store
d’identité peut être un LDAP ou une base de données ou autre moyen qui permet
de stocker les identités.
 Le serveur d’application définit deux SecurityRealm :
 ManagementRealm : Il permet de sécuriser l’accès aux interfaces
d’administration.
 ApplicationRealm : Il permet de sécuriser l’accès aux applications.
 ManagementRealm : Il permet le contrôle d’accès aux outils d’administration du serveur
de l’application, il est basé sur un simple mécanisme d’authentification et d’autorisation qui
utilise deux fichiers :
 mgmt-users.properties : contient les paramètres de connexion de l’utilisateur.
 mgmt-groups.properties : contient les mappings entre les utilisateurs et leurs groupes
de rôles.

 CLI utilise un mecanisme d’authentification local qui ne demande pas de username/pwd

quand l’utilisateur se connecte depuis la machine locale.
 Les clients CLI distants et la Console Admin demande une authentification par
username/pwd.
 Après voir défini le Management Realm , il faut qu’il soit associé l’interface de
management dans le fichier standalone.xml ou host.xml
 Gestion des autorisations et des authentifications
pour les applications
 ApplicationRealm est utilisé pour sécuriser les applications qui exposent des services
comme EJB par exemple

 Les fichiers de properties application-users.properties & application-roles.properties

similaires au ManagementRealm.
 Une fois ApplicationRealm est défini, il peut être utilisé pour les connections
entrantes et sortantes, par exemple les connections Remoting (EJB calls)
 Other Security Domain

 Quand une application est déployée , elle est associée avec le security domain « Other» qui
utilise le ApplicationRealm.
 Remoting login module est utilisé en interne quand une connexion remoting est reçue
(généralement des appels EJB).
 RealmDirect login module est utilisé quand ce n’est pas une Remoting connexion
(généralement une authentification d’une application web).
 RealmDirect module est le plus simple des modules d’authetification et il est utilisé quand la
connexion n’est pas de type Remoting.
 Pas besoin de configuration d’un store d’identité car il repose sur le ApplicationRealm
 Facile à rajouter d’autre utilisateurs via la commande add-user.
 Après avoir définit la sécurité du serveur, il est temps de sécuriser l’application
 La configuration se fait dans deux endroits :

web.xml : mapper les

resources web (url-pattern)
avec le rôle neccessaire à
leurs accès.

jboss-web.xml : pour définir

quel security domain à
utiliser (à mettre dans WEB-
INF)
La Sécurisation des EJB passe soit par la configuration xml ou les annotations JEE comme :
@javax.annotation.security.RolesAllowed et @org.jboss.ejb3.annotation.SecurityDomain

L’annotation peut être mise au niveau de la méthode :

 Sécurisation des échanges avec SSL
 Supposant que vous posséder déjà les certificats qui sont bien copiés and le répertoire
configuration, vous devez maintenant créer un SecurityRealm qui va contenir le keystore et
le trustore.

 Configurer le listener https

 Déclarer le protocole HTTPS dans le fichier web.xml dans votre application :

 MERCI
POUR VOTRE ATTENTION
ET INTERACTIVITE

168