Maîtrisez le déploiement d’applications j2ee sous JBoss 7. Identifiez les différents livrables possibles (EAR, WAR, JARs, RAR, SAR). Comprenez les techniques de déploiement en mode ‘standalone’ et en mode ‘domaine’. Comprenez enfin l’approche de classloader Jboss 7 à travers le role des fichiers MANIFEST.MF et jboss-deployment-structure.xml.
Prérequis
Installation JDK 6 (ou supérieur)
Liens utiles
Spécifications JEE 6
Démonstration Log4j avec JBOSS 5 et JBOSS 7.1.1
Guide du développeur JBOSS 7
Guide de l’administrateur JBOSS 7
Sécurité JBOSS 7
Liste dépendances implicites
5 façons de déployer avec Jbos 7
Objectifs
Déployer des livrables dans Jboss
Programme
Introduction
Partie 1 : déploiement dans Jboss 7 Standalone
Partie 2 : déploiement dans Jboss 7 domaine
Partie 3 : chargeur de classe jboss 7
Formation Architecture Java
Soyez prêt pour des projets ambitieux : formation architecture Java Objis
Durée
30min
Formation JBOSS 7
Soyez prêt pour des projets ambitieux :
Introduction
Vous allez ici apprendre à déployer des livrables dans Jboss 7 standalone ainsi que dans un domaine Jboss 7.
Cette compétences nécessite d’identifier les livrables possibles et de savoir gérer les problèmes éventuels de dépendances (Classe introuvable, ou bien mauvaise version de la classe trouvée).
Savoir : identifier livrable
L’administrateur Jboss doit savoir quels type de livrable il peut déployer :
QUESTION 1 : les fichiers xml de configuration des livrables sont’ils obligatoire ?
QUESTION 2 : quel type de livrable déployable dans jboss 7 manque t’il ?
Savoir : gérer les dépendances
L’approche de gestion des librairies et dépendances dans JBOSS 7 est très différente des approches versions précédentes (4/5/6).
Avec Jboss 7 et grace au framework Felix, implémentation de OsGI, il est possible d’avoir plusieurs versions d’un composant disponibles sur le serveur.
Libre au développeur de spécifier , à travers un fichier de configuration à embarquer avec l’application, la version avec laquelle il va travailler.
Partie 1 : Déploiement dans Jboss 7 ‘Standalone’
2 techniques :
— déploiement ‘automatique’ (avec CLI ou webconsole)
— déploiement manuel
Déploiement automatique
Avec cette approche, le service de scanner de Jboss déploit systématiquement les livrables présents dans le répertoire JBOSS_HOMEstandalonedeployments
Copier le livrable hello.war dans le répertoire JBOSS_HOMEstandalonedeployments
Que se passe t’il dans ce répertoire deployments ?
Expliquez la présence du fichier hello.war.deployed.
Que se passe t’il sur la console ?
Expliquez
Aller sur http://localhost:8080/hello
Analysez le fichier standalone.xml , section ‘profile’, sous-section ‘sub-system’
Expliquez
Déploiement dans répertoire spécifique
Expliquez et mettez en oeuvre la configuration suivante :
Configurer le scanner
Expliquez et mettez en oeuvre la configuration suivante :
Déployer avec le CLI
— se connecter
Identifier les paramètres possibles pour la commande ‘deploy’ à travers un deploy –help
— quel est le résultat de la commande ‘deploy’
Expliquez
— Créez un nouveau livrable hello2.war dans c:/formationjboss/livrables et déployez : deploy c:/formationjboss/livrables/hello2.war
Analysez les logs console
Lister à nouveau les déploiements
A VOUS DE JOUER : en utilisant la documentation de ‘deploy’ montrez comment :
déployer ‘sans activer’ ?
‘forcer’ un redéploiement ?
désinstaller une application ?
QUESTION :
Expliquez les commandes CLI suivantes :
/subsystem=deployment-scanner/scanner=default:read-resource
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deployexploded,value=true)
Déployer avec la console d’administration
Expliquez l’écran suivant :
Déployez un nouveau livrable war à travers la console web.
Déploiement manuel
Avec cette approche, le service de scanner de Jboss déploit pas systématiquement les livrables présents dans le répertoire JBOSS_HOMEstandalonedeployments.
Au lieu de cela, il utilise un ensemble de fichiers marqueurs (fichiers vide suffixés : ex emple .dodeploy) qui vont déclencher le redéploiement et capturer le résultat de l’opération.
Cette approche favorise quel que soit l’OS le déploiement de gros livrables
Déployez un répertoire ‘explosé’ nommé hello10.war . Notez comment dans les logs console JBOSS vous recommande de créer un fichier hello10.war.dodeploy
créez alors un fichier hello10.war.dodeploy dans ‘deployment’.
Que se passe t’il ?
Testez.
RAPPELS :
— suffixe à créer à l’admin : .dodeploy , .doskip
— suffixes crées/gérés par jboss 7 : .deployed, .undeployed, .failed, .isdeploying, .isundeploying, .pending
Partie 2 : Déploiement dans Jboss 7 domaine
Pour déploiement dans un domaine, un copier/coller ne suffit pas.
Vous notez qu’il n’y a pas de répertoire ‘deployments’ prédéfini.
Le déploiement se fait avec l’un des deux outils suivants :
— CLI
— Web console
CLI
Identifier à nouveau les paramètres possibles pour la commande ‘deploy’ à travers un deploy –help
Vous pouvez installer/désinstaller:
1) à tous les groupes de serveur (–all-server-groups)
— > deploy ../application.ear –all-server-groups
— > undeploy application.ear –all-relevant-servergroups
2) à un groupe en particulier ou plusieurs
— > deploy application.ear –server-groups=mainserver-
group, other-server-group
— > undeploy demoproject.war –server-groups=mainserver-
group
SYNTHESE COMMANDES :
deploy –all-server-groups Deploie une application à tous les groupes de serveur
deploy –server-groups Deploie une application à un ou plusieurs groupes
undeploy –all-relevant-servergroups désinstalle et supprime une application de tous les groupes de serveur dans lequel l’appli est déployée
undeploy –server-groups désinstalle et supprime une application d’un groupe de serveurs. ECHEC
si l’application est référencé dans un autre groupe
undeploy –server-groups –keepcontent désinstalle une application d’un groupe de serveurs. ECHEC
, sans le supprimer
Chargeur de Classe Jboss 7
Dans Jboss 7, chaque livrable (module) déployés est isolé des autres modules.
Le serveur d’application ajoute des dépendences :
— soit automatiquement pour certaines Classes (dépendances implicites)
— soit à partir des informations de dépendances fournies par le développeur dans la livraison (MANIFEST.MF ou jboss-deployment-structure.xml)
Dépendances implicites
Dépendances explicites
Meilleure pratique : ajouter dans META-INF/MANIFEST.MF la dépendances : Dependencies: [module]
— Exemple 1 : Dependencies:org.apache.log4j
— Exemple 2 : Dependencies:org.apache.log4j,org.apache.velocity
Dépendance vers un livrable particulier
Vos livrables ont un nom préfixé par deployment. (deployment.[nom_archive]]
— Exemple 1 : le livrable hello.war a le nom deployment.hello.war
— Exemple 2 : le livrable hello.war présent dans l’EAR monappli.ear a comme nom deployment.monappli.ear.hello.war
En spécifiant que votre composant dépend de hello.war, vous avez accès aux jars de hello.war
— Exemple 1 : Dependencies:deployment.hello.war
Dépendance globale
Analysez la configuration suivante :
Expliquez .
Quel est l’avantage et l’inconvénient de cette configuration ? Quand l’utiliser ?
Exclure des dépendances implicite
Analysez et expliquer la configuration suivante :
Livrable EAR
Dans le cas de livrable EAR, il est recommandé de mettre en place, à travers un unique fichier (jboss-deployment-structure.xml), votre stratégie de chargement de classes.
Expliquez la configuration suivante :
Standardiser gestion dépendances
Dans le MANIFEST.MF, expliquez la valeur ajoutée de la clé : Classpath :
Isolation
Expliquez la configuration
Formation JBOSS 7
Soyez prêt pour des projets ambitieux :
