jeudi 18 mars 2010
15:32 | 
Publié par
Jean FRANCOIS |
Le packaging JEE permet de regrouper le code à exécuter à différents endroits et sous différentes formes, afin de le déployer sur les instances.
Le code peut-être :
ü Des classes d’infrastructure Comme les drivers.
ü Des classes utilitaires ou framework Java commons, struts ou parser XML.
ü Des classes applicatives globales Utilisé par toutes les applications.
ü Des classes applicatives spécifiques À une application.
Le package peut-être :
ü Une classe L’élément le plus simple.
ü Un JAR Un regroupement de classe JAVA.
ü Un JAR lib JEE Un regroupement de composants JEE utilisables par d’autres packages
ü Un RAR Des classes spécifiques à un connecteur JEE.
ü Un EAR Un regroupement de packages JEE.
ü Un JAR EJB Un regroupement d’EJB.
ü Un WAR Un regroupement de composants JEE graphique.
On peut placer ce code à différents endroits selon les besoins de déploiements :
ü Statique Obligation de redémarrer les instances.
ü Dynamique Possibilité de déployer à chaud en version.
ü Global Visible de tout le monde.
ü Spécifique A destination de quelques applications.
EMPLACEMENT
Vous pouvez placer le code (classes JAVA ou package) à différents endroits dans l’environnement JEE avec comme considération pour chaque emplacement :
ü Global / Spécifique
ü Statique / Dynamique
Au niveau du domaine la prise en compte des classes est statique, vous pouvez placer les JAR java dans :
· Le CLASSPATH des scriptes de démarrage
ü Directement dans le CLASSPATH du scripte principal (global).
ü Dans un scripte spécifique via les variables d’environnement (EXT_PRE_CLASSPATH,EXT_POST_CLASSPATH) (spécifique)
${DOMAINE_HOME}\bin\start*.*\CLASSPATH
${DOMAINE_HOME}\config\config.xml\classpath
· Dans le répertoire lib du domaine (pris en compte automatiquement lors du démarrage) (global)
${DOMAINE_HOME}\lib
INSTANCE
Le déploiement sur les instances est une procédure dynamique. Elle permet de déployer des shared JEE lib, EAR, JAR, WAR, RAR. On peut versionner les packages pour référencer les déploiements et utiliser le mode Side By Side pour éviter les interruptions de services (deux versions déployées simultanément).
· Une shared lib JEE permet de centraliser des composants JEE ou JAVA globaux à un ensemble de packages et ne déployer qu’une référence unique plutôt que de les embarquer dans chaque EAR. On pourra les versionner pour déployer de nouvelles versions en parallèle (utilisable simultanément). Il faudra juste y faire référence dans les EAR (global).
· Les autres packages sont spécifiques (sans dépendance externe)
PACKAGE
Les packages sont spécifiques à leurs niveaux. Ils peuvent cependant embarquer des classes ou packages globaux aux sous composant (EAR)
· Un EAR fait référence à des sous composants qui peuvent être des RAR, EJB jar, WAR. On peut placer des JAR java ou classe dans le répertoire APP-INF (lib/classes) visible de tous les sous package de l’EAR (global au package). On peut également placer des JAR à la racine de l’EAR et y faire référence dans chaque sous package via le META-INF/MANIFEST.MF/classpath (deprecated).
· Les RAR et JAR EJB embarquent leurs propres composant JEE et code (spécifique).
· Les WAR peuvent déclarer des JAR java ou classes communes (globale) à tous les composants embarqués dans le répertoire WEB-INF (lib/classes)
STRATEGIE
Pour la stratégie de placement des classes dans les différents conteneurs, vous pouvez suivre ces principes de base.
Classes
Prendre en compte les critères de visibilités des classes et package afin de les placer au bon endroit. Les questions à se poser sont :
ü La classes ou package est-il utilisée par tout le monde ou est locale à l’application (hiérarchie de dépendance).
ü Doit-elle être mises à jour souvent ou très rarement (statique ou dynamique).
ü Le fréquence de modification et de déploiement.
ü La mutualisation sur les projets et application.
Package
Préférer utiliser un EAR même s’il n’y a qu’un sous composant afin de normaliser le format des packages à livrer et pour profiter des options associées aux EAR.
Effectuer systématiquement une pré compilation des packages afin de les valider et d’assurer un déploiement sans erreurs. Versionner ceux-ci pour valider la version déployer et utiliser les options de déploiement Side by Side.
Node Manager
Dans ce cas particulier, et pour garder la facilité d’administration avec cet agent, il est préférable de n’utiliser qu’un mode de déploiement dynamique (lib JEE, EAR, …) et d’embarquer tous les fichiers de paramétrage dans les packages déployés.
PRECOMPILATION
Voir le chapitre PRECOMPILATION JEE
PLAN DEPLOIEMENT
Une des problématiques est de conserver un package unique tous le long de la phase de validation (développement, intégration, pré production, production), et d’externaliser tous les éléments spécifiques à l’environnement (accès vers la base, taille des pools, etc … ).
Pour surcharger les paramètres passés dans les descripteurs JEE sans éclater le package, associer lui des fichiers de plan de déploiement en y spécifiant les paramètres à modifier (procédure à réaliser lors du déploiement).
CLASSLOADER
La visibilité des classes suit la hiérarchie des CLASSLOADER chargés dans le serveur d’applications. Lors du chargement, on va chercher du plus haut de l’arbre vers le bas pour trouver la classe. Si elle n’est pas trouvée, il y a une erreur de type ClassNotFound.
Le problème et de deux natures :
ü La visibilité des classes Un EJB qui cherche à charger une classe d’un WAR ne pourra pas
ü Le conflit de classe Une même classe présente à deux endroits différents sera chargée dans le package de plus haut niveau (type parseur XML)
Pour résoudre les problèmes de conflit de classe en doublon dans l’arbre, on peut utiliser :
ü Au niveau du WAR l’option prefer-web-inf-classes
ü Au niveau de l’EAR l’option prefer-application-packages
WAR : weblogic.xml
EAR : weblogic-application.xml
Pour les librairies JEE le composant est chargé dans le package appelant (dans le class loader de l’EAR)
Libellés :
Inscription à :
Publier les commentaires (Atom)
AUTEUR
- Jean FRANCOIS
- Carrières Sur Sein, Yvelines, France
- Consultant Oracle (Ancien consultant BEA depuis 2001), je m’occupe des expertises sur les produits Oracle : SOCLE (Weblogic, Coherence, JRockit) SOA (Service Bus, SOA Suite, BPM)
MON CV
MAP
CULTURES
LIVRES
0 commentaires:
Enregistrer un commentaire