Vous pouvez apporter diverses modifications aux applications et à
leurs modules sans devoir arrêter et redémarrer le serveur. Le fait d'apporter ce type de modifications
s'appelle du déploiement à chaud et rechargement dynamique.
Avant de commencer
La remarque suivante s'applique aux références de fichier xmi dans cette rubrique :
Configurations prises en charge: Pour les
fichiers de liaison et d'extension IBM®, l'extension
de nom de fichier .xmi ou .xml est différente selon que vous utilisiez un module ou une application antérieure à
Java EE 5 ou un module ou une application ultérieure à Java™ EE 5. Un fichier de liaison ou d'extension
IBM porte le nom ibm-*-ext.xmi ou ibm-*-bnd.xmi où * correspond au fichier
d'extension ou de liaison, tel app, application, ejb-jar ou web. Les conditions suivantes s'appliquent :
- Pour une application ou un module qui utilise une version Java EE antérieure à la
version 5, l'extension de fichier doit être .xmi.
- Pour une application ou un module qui utilise Java EE 5 ou version ultérieure, l'extension
de fichier doit être .xml. Si des fichiers .xmi sont inclus dans l'application ou le module, le produit les ignore.
Toutefois, un module Java EE
5 ou version ultérieure peut exister dans une application qui inclut des fichiers
antérieurs à Java EE 5 et utilise l'extension de nom de fichier .xmi.
Les fichiers ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi et ibm-portlet-ext.xmi continuent d'utiliser les extensions de fichier .xmi.
sptcfg
![[Solaris]](../images/solaris.gif)
Restriction : La fonction de déploiement à chaud et de rechargement dynamique n'est pas prise en charge lorsque le produit s'exécute sur ces systèmes d'exploitation. Les fichiers JAR (Java archive) du kit JDK (Java Development Kit) associé sont mappés à la mémoire. Si ces fichiers JAR sont mis à jour par la fonction de déploiement à chaud et de rechargement dynamique lorsqu'ils sont utilisés par la machine virtuelle Java (JVM), les fichiers deviennent incohérents, ce qui entraîne l'arrêt inattendu du serveur d'applications. Lorsque vous apportez des modifications à une application sur ces systèmes d'exploitation, n'utilisez pas la fonction de déploiement à chaud et de rechargement dynamique.
Au lieu de cela, redémarrez l'application pour que les modifications soient prises en compte.
Cette rubrique suppose que vos fichiers d'application sont déployés sur un serveur et que vous souhaitez mettre à niveau les
fichiers.
Voir Méthodes de mise à jour des fichiers d'application d'entreprise et déterminez si le
déploiement à chaud est la mise à jour des fichiers d'application qui convient. D'autres
méthodes sont plus simples et le déploiement à chaud ne s'adresse qu'aux
utilisateurs confirmés.
N'utilisez pas le déploiement à chaud si vous prévoyez
d'exporter votre application, de générer un plug-in à partir de sa configuration ou
d'effectuer d'autres tâches de gestion d'application
dans le futur. Les modifications par déploiement à chaud, apportées aux fichiers d'application,
ne sont reconnues ni par la console d'administration ni par
les fonctions de gestion des applications wsadmin. Ces fonctions ne reconnaissent que les
fichiers d'application que les programmes d'administration, tels que la console ou wsadmin,
présentent lors de l'installation d'application, la mise à jour ou autres fonctions de gestion. Les fonctions de gestion d'application ne reconnaissent pas les fichiers modifiés par déploiement
à chaud.
Important : Ne recourez pas au déploiement à chaud pour
mettre à jour des composants dans une cellule gérée du gestionnaire de
déploiement de production. Le déploiement à chaud est bien adapté au développement et à la mise au point mais fait courir des risques inacceptables aux environnements de production. Une nouvelle synchronisation totale ou partielle peut écraser des composants déployés de façon dynamique. De plus, l'exécution de la commande restoreconfig peut écraser les modifications apportées aux fichiers de l'application développés. De
plus, les composants déployés de façon dynamique ne migrent pas entre les versions
de WebSphere
Application Server. Pour ajouter de nouveaux composants ou modules à une application d'entreprise,
réassemblez le fichier EAR de l'application pour prendre en compte ces
nouvelles ressources, puis redéployez le fichier EAR.
Pourquoi et quand exécuter cette tâche
Le déploiement à chaud consiste à ajouter de nouveaux composants
(tels que des fichiers WAR, des fichiers Jar d'EJB, des beans Java
enterprise, des servlets et des fichiers JSP) à un serveur actif sans
devoir arrêter et redémarrer le serveur d'applications.
Le rechargement dynamique est la possibilité de modifier un
composant existant sans devoir redémarrer le serveur pour que ce
changement prenne effet. Le rechargement dynamique implique :
- Des modifications apportées à l'implémentation du composant
d'une application, par exemple la modification de
l'implémentation d'un servlet
- Des changements de paramétrage de l'application, par exemple la modification du
descripteur de déploiement pour un module Web
A l'opposé des modifications apportées à une application
déployée décrite dans Mise à jour des fichiers d'applications d'entreprise,
les modifications apportées à l'aide du déploiement à chaud ou du
rechargement dynamique n'utilisent pas la console d'administration ou une
commande de script wsadmin. Vous devez manipuler directement les fichiers
d'application sur le serveur sur lequel l'application est déployée.
Si l'application que vous mettez à jour est déployée sur un serveur dont la
règle de chargeur de classe d'application
est associée à la valeur Un seul, il se peut que vous ne puissiez pas
recharger dynamiquement votre application. Vous devrez, au minimum, redémarrez le serveur après la mise à jour de votre application.
Procédure
- Recherchez les fichiers d'application développés.
Ces
derniers se trouvent dans le répertoire que vous avez indiqué lors de
l'installation de l'application ou dans le répertoire cible par
défaut, racine_serveur_app/installedApps/nom_cellule.
Le fichier EAR,
${APP_INSTALL_ROOT}/nom_cellule/nom_application.ear, désigne le répertoire cible. Le fichier variables.xml du noeud
définit ${APP_INSTALL_ROOT}.
Il est très important de connaître l'emplacement des fichiers
d'application développés dans la mesure où, dans le cadre de
l'installation des applications, un serveur d'applications WebSphere
Application Server
décompacte certains éléments du fichier EAR dans le système de
fichiers de la machine sur laquelle l'application sera exécutée. Ces fichiers développés sont consultés par le serveur lors de
l'exécution de l'application. Si vous ne trouvez pas les fichiers
d'applications développés, recherchez l'attribut binariesURL dans le fichier
deployment.xml de l'application. Cet attribut indique l'emplacement où le système
recherche ces fichiers lors de l'exécution.
En ce qui concerne le reste des informations relatives au
déploiement à chaud et au rechargement dynamique,
racine_application représente le répertoire racine des
fichiers d'application étendus.
- Recherchez les fichiers de métadonnées de l'application. Ces derniers
comprennent les descripteurs de déploiement (web.xml, application.xml,
ejb-jar.xml et assimilés), les fichiers de liaison (ibm-web-bnd.xmi,
ibm-app-bnd.xmi et les fichiers d'extensions (ibm-web-ext.xmi,
ibm-app-ext.xmi et assimilés).
Les fichiers XML de métadonnées d'une application peuvent être
chargés à partir d'un ou deux emplacements. Les fichiers de métadonnées peuvent être
chargés à partir du même emplacement que les fichiers binaires d'application
racine_application/META-INF) ou à partir de l'arborescence de
configuration WebSphere, ${CONFIG_ROOT}/cells/nom_cellule/applications
/nom_EAR_application/deployments/nom_application/.
La valeur de l'option useMetadataFromBinary spécifiée lors de
l'installation de l'application détermine l'emplacement utilisé. Lorsque cette valeur est définie, les fichiers de métadonnées sont
chargés à partir du même emplacement que les fichiers binaires
d'application. Lorsqu'elle n'est pas définie, ces fichiers sont
chargés à partir du dossier de déploiement de l'application dans
l'arborescence de configuration.
Important : Vous pouvez configurer useMetadataFromBinaries=true,
modifier une copie extraite de votre application en utilisant le déploiement à chaud et faire
en sorte que vos modifications soient prises en compte à l'exécution en suivant la procédure décrite dans cette
rubrique. Cependant, les modifications que vous apportez aux fichiers de l'application
lorsque vous utilisez le déploiement à chaud ne sont pas reconnues par les
fonctions de gestion d'application de la console d'administration ou de wsadmin. Ces fonctions reconnaissent seulement les fichiers d'application d'origine, et non ceux qui sont
modifiés par le déploiement à chaud. N'utilisez pas le déploiement à chaud si vous prévoyez
d'exporter votre application, de générer un plug-in à partir de sa configuration ou
d'effectuer d'autres tâches de gestion d'application
dans le futur. Le déploiement à chaud est pratique pour modifier rapidement les fichiers
d'une application, mais il ne prend pas en charge le cycle complet de gestion
de l'application.
En ce qui concerne le reste des informations,
racine_métadonnées représente l'emplacement des fichiers de
métadonnées de l'application ou du module indiqué.
- Obligatoire : Si vous exécutez WebSphere
Application Server
sur un groupe de postes utilisant WebSphere
Application Server, Network Deployment et que vous modifiez une
application sur un noeud particulier, désactivez la synchronisation automatique.
- Cliquez sur dans l'arborescence de navigation
de la console.
- A la page de service de synchronisation de fichier,
décochez la case de synchronisation automatique
et cliquez sur OK.
Lorsque vous exécutez WebSphere
Application Server
sur un groupe de postes utilisant WebSphere
Application Server, Network Deployment et que vous modifiez un fichier sur
disque figurant dans le répertoire d'application étendu d'un noeud donné, vous risquez de
perdre ces modifications lors de la prochaine synchronisation des noeuds. Dans l'environnement WebSphere
Application Server, Network Deployment, la configuration stockée par
le gestionnaire de déploiement est la copie principale et toute modification détectée par
rapport à celle-ci dans la copie installée sur une machine donnée déclenche le
téléchargement de la copie principale sur le noeud.
- Facultatif : Examinez les valeurs spécifiées pour les
paramètres Recharger des classes lors de la mise à jour des fichiers d'application
et Intervalle d'interrogation des fichiers mis à jour sur la page de paramètres du chargeur de classes de l'application.
Si le rechargement des classes est activé et que l'intervalle d'interrogation
est supérieur à zéro (0), les fichiers de l'application sont rechargés une fois celle-ci
mise à jour.
Pour les fichiers JavaServer Pages (JSP) dans un module Web, un conteneur Web recharge
les fichiers JSP uniquement si l'extension IBM jspReloadingEnabled dans les attributs jspAttributes
du fichier ibm-web-ext.xmi a la valeur true. Vous pouvez attribuer la valeur true au paramètre
jspReloadingEnabled lorsque vous éditez les descripteurs de déploiement étendus de vos
modules Web dans l'outil d'assemblage.
- Modifiez ou ajoutez comme il convient les composants ou les modules suivants :
- Pour que les modifications prennent effet, vous pouvez être amené à démarrer, arrêter ou relancer une application.
La rubrique
Démarrage ou arrêt d'une application d'entreprise
fournit des informations sur l'utilisation de la console d'administration pour
lancer, arrêter ou relancer une application.
Les rubriques Démarrage d'applications à l'aide de l'outil de scriptage wsadmin et Arrêt d'applications à l'aide de l'outil de scriptage wsadmin fournissent des informations sur l'utilisation de l'outil de scriptage wsadmin.
- Si vous avez désactivé la synchronisation
automatique à l'étape 3, activez-la de nouveau :
- Retournez à la page de
service de synchronisation de fichier.
- Sélectionnez Synchronisation automatique.
- Cliquez sur
OK.
Résultats
Les fichiers de l'application sont mis à jour sur le serveur.
Comme vous avez
manipulé les fichiers de l'application directement sur le serveur, il est possible que vous
ne puissiez plus travailler dessus en utilisant la console d'administration ou les commandes
de scriptage de l'outil wsadmin. Par exemple, si vous essayez d'exporter une application modifiée manuellement via
la commande Exporter sur une page de console d'applications d'entreprise,
les modifications de l'application dans le répertoire installedApps
ne sont pas exportées. Pour exporter ces modifications, vous devez copier et déplacer manuellement les fichiers des
applications.