Affichage des articles dont le libellé est DEPLOYMENT. Afficher tous les articles
Affichage des articles dont le libellé est DEPLOYMENT. Afficher tous les articles
mardi 14 décembre 2010
07:10 | 
Publié par
Jean FRANCOIS |
Lors d’un déploiement d’une application dans un domaine SOA 11G, il faut faire attention au paramétrage du domaine sur lequel on cible le déploiement. En effet SOA Suite utilise le produit Coherence pour propager l’application sur le domaine. Ce produit introduit une notion de cluster différente du cluster Weblogic et utilise une IP et un PORT de dialogue non exposé lors de l’installation du domaine.
Si le domaine ne re spécifie pas ces informations et qu’il partage le réseau avec d’autres domaines SOA, l’application risque de se déployer sur les autres domaines si il n’y a pas d’étanchéifiassions du réseau ou si le paramétrage n’est pas customisé.
Prenons l’exemple de deux domaines déployés sur deux machines différentes avec le même nom de domaine est d’instance sur le même réseau. Le paramétrage par défaut du cluster Coherence est 227.7.7.9 sur le port 9778 (vous pouvez le vérifier dans le log de l’instance en cherchant l’occurrence tangosol.coherence.clusteraddress sur les Java system properties)
Donc s’il on déploie une application sur l’instance Managed 1 du cluster du domaine de la machine A, elle sera également propagé aux instances de la deuxième machine car l’adresse cluster Coherence est la Même (problème si se sont deux environnement différents).
Pour éviter ce problème, il faut soit étanchéifier le réseau entre les deux machines pour que la connexion ne s’effectue pas.
-Dtangosol.coherence.clusteraddress=227.7.7.8
-Dtangosol.coherence.clusterport=9978
Ou éviter les rebonds sur les autres machines avec un Time To Live à 0
-Dtangosol.coherence.ttl=0
Libellés :
dimanche 28 mars 2010
Une nouvelle version d’une application peut être déployée en même temps que l’ancienne sans affecter les clients en cours d’utilisation ainsi que les nouveaux clients.
Les clients existants continuent d’utiliser l’ancienne version et les nouveaux clients sont redirigés vers la nouvelle version de l’application. L’ancienne version passe à l’état undeployed une fois que tous les clients en cours sur cette version ont terminé leur travail. Le nombre de versions simultanées est limité à 2.
- Dans le MANIFEST.MF de l’EAR (préconisé)
- Lors du déploiement avec la commande weblogic.Deployer
Weblogic-Application-Version: 1.0.1
java weblogic.Deployer -adminurl t3://localhost:7001 -user weblogic -password weblogic -deploy -name app -source TestSession-1.0.1.ear -targets Server1 -stage -appversion 1.0.1
Ou en utilisant le Deployer avec l’option -listapps :
java weblogic.Deployer -adminurl t3://localhost:7001 -user weblogic -password weblogic -listapps
- La nouvelle version est au statut Active.
- L’ancienne version passe automatiquement du statut Active au statut Stop Running jusqu’à ce qu’il n’y ait plus de sessions clientes sur cette version, puis elle passe au statut Retired.
Ligne de commande pour redéployer une nouvelle version :
java weblogic.Deployer -adminurl t3://localhost:7001 -user weblogic
-password weblogic -redeploy -name TestSession
-source TestSession-1.0.2.ear
-retiretimeout 300
L’option retiretimeout permet de passer automatiquement l’ancienne version au statut Retired après le timeout sans attendre la fin des sessions clientes.
dimanche 21 mars 2010
Cette procédure à pour but de :
ü valider les descripteurs JEE (web.xml, weblogic.xml, ejb-jar.xml, weblogic-ejb-jar.xml, etc … ),
ü précompiler les JSP (génération des .java et compilation)
ü précompiler les EJB (génération des Stub)
Elle permet de s’assurer que l’application J2EE ne générera pas d’incident lors du déploiement, et de diminuer le temps de celui-ci (diminution de l’indisponibilité des services). Elle permet également de valider qu’il n’y a pas de code mort, ou d’erreur dans l’application. Elle évite la phase de compilation qui engendre une charge CPU lors du déploiement ou de l’activation (sur l’ensemble des instances).
MISE EN PLACE
Pour précompiler les fichiers de déploiement J2EE, utiliser la commande appc présenté ci-dessous (en positionnant l’environnement Weblogic) :
Un tag ANT est définit dans la version Weblogic.
Dans le cas ou le ANT utilisé n’est pas un ANT Weblogic, ajouter l’entrer suivante :
WLST ne fournit pas de fonction spécifique, il faut faudra exécuter la commande de façon externe.
VALIDATION
La commande génère des classes compilées dans les packages passés en paramètre de la commande.
ü Pour les WAR, vous devriez trouver un répertoire contenant les JSP compilé sous WEB-INF\classes\jsp_servlet.
ü Pour un JAR EJB, des classes avec des extensions sous les même packages, comme : TestSessionEjb_kih370_ELOImpl.class
PROBLEMES
L’inconvénient de la commande appc (ou l’avantage) et qu’elle compile l’ensemble des JSP sans ce soucier des JSP en include (JSP incomplète pas forcément compilables tel quel, mais valide après intégration dans la JSP principale). Celle entraîne des erreurs qui polluent la sortie de la commande.
index.jsp
include.jsp
Résultat de la commande weblogic.appc
D:\BEA\PerfPack\JSPInclude\exemple\WEB-INF\classes\jsp_servlet\__include.java:122: cannot resolve symbol
symbol : variable hello
location: class jsp_servlet.__include
out.print(String.valueOf(hello)); //[ /include.jsp; Line: 1]
^
1 error
]
at weblogic.appc.compileWAR(appc.java:837)
at weblogic.appc.compileInput(appc.java:472)
at weblogic.appc.runBody(appc.java:186)
at weblogic.utils.compiler.Tool.run(Tool.java:192)
at weblogic.utils.compiler.Tool.run(Tool.java:147)
at weblogic.appc.main(appc.java:1037)
Une solution pour contourner ce problème est de renommer les fichiers include des .jsp en .inc et de modifier les JSP appelant ces pages.
index.jsp
include.inc
jeudi 18 mars 2010
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)
Inscription à :
Articles (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
