Préparation des paramètres pour la mise à jour de l'application

Cette page permet de mettre à jour des applications d'entreprise, des modules et des fichiers déjà installés sur un serveur.

Pour afficher cette page de la console d'administration, procédez comme suit :
  1. Cliquez sur Applications > Types d'application > Applications d'entreprise WebSphere.
  2. Sélectionnez l'application ou le module installés à mettre à jour.
  3. Cliquez sur Mettre à jour.
Lorsque vous cliquez sur Mettre à jour, une page vous permettant de mettre à jour les fichiers de l'application déployée dans la cellule s'affiche. Vous pouvez mettre à jour l'application complète, un seul module, un seul fichier ou une partie de l'application. Si un nouveau fichier ou module possède le même chemin d'accès relatif qu'un autre sur le serveur, il remplace ce dernier. Si en revanche le nouveau fichier ou module n'existe pas encore sur le serveur, il est ajouté à l'application déployée.
Application à mettre à jour

Indique le nom de l'application installée (ou déployée) que vous avez sélectionnée dans la page Applications d'entreprise.

Remplacement de la totalité de l'application

Sous Options de mise à jour de l'application, demande le remplacement de l'application déjà installée sur le serveur par un nouveau fichier (mis à jour) d'applications d'entreprise .ear.

Après avoir sélectionné cette option, procédez comme suit :

  1. Précisez si le fichier .ear se trouve sur le système de fichiers local ou distant, ainsi que le chemin d'accès complet de l'application. Le chemin désigne l'emplacement du fichier .ear mis à jour avant installation.

    Choisissez Système de fichiers local si le navigateur et les fichiers ou modules mis à jour se trouvent sur la même machine, quel que soit l'emplacement du serveur. Système de fichiers local est disponible pour toutes les options de mise à jour.

    Utilisez Système de fichiers éloigné si le fichier d'application réside sur un noeud du contexte de cellule actuel.

    Dans le cas d'applications multiserveurs, à l'aide de l'option Système de fichier distant, vous pouvez parcourir le système de fichiers complet d'un noeud si l'agent de noeud ou le gestionnaire de déploiement s'exécute sur le noeud sélectionné. Seuls les fichiers .ear, .jar, .sar ou .war apparaissent lors de l'exploration.

    Utilisez également l'option Système de fichier distant pour spécifier un fichier d'application résidant déjà sur la machine exécutant le serveur d'applications. Par exemple, la valeur de la zone peut être racine_installation_serveur_applications/installableApps/test.ear. Si vous installez un module WAR autonome, indiquez aussi la racine de contexte.

    Conseil : Lors de l'installation de l'application, les fichiers de l'application sont téléchargés d'un poste client exécutant un navigateur vers le poste serveur exécutant la console d'administration afin d'y être déployés. Dans de tels cas, utilisez le navigateur Web exécutant la console d'administration pour sélectionner les modules à télécharger sur la machine serveur. Toutefois, dans certains cas, les fichiers d'application se trouvent dans le système de fichiers d'un noeud d'une cellule. Pour que le serveur d'applications installe ces fichiers, utilisez l'option Système de fichiers distant.
  2. Si vous installez une application Web autonome (WAR) ou un module (SAR) Session Initiation Protocol (SIP), indiquez la racine de contexte du fichier WAR ou SAR.

    La racine du contexte est combinée avec le mappage de servlet défini (à partir du fichier WAR) pour composer l'URL complète que les utilisateurs saisissent pour accéder au servlet. Par exemple, si la racine de contexte est /gettingstarted et si le mappage de servlet est MySession, l'URL est http://host:port/gettingstarted/MySession.

  3. Cliquez sur Suivant pour ouvrir un assistant de mise à jour des fichiers d'application. Cet assistant, semblable à celui d'installation, comporte des zones d'entrée et d'édition pour les informations de liaison de l'application. Exécutez les étapes dans cet assistant, comme requis.

Si l'application complète est mise à jour, l'ancienne application est désinstallée et la nouvelle la remplace. Une fois les modifications de configuration sauvegardées, puis synchronisées, les fichiers d'application sont développés sur le noeud sur lequel l'application s'exécute. Si l'application est en cours d'exécution sur le noeud pendant la mise à jour, elle est arrêtée, ses fichiers sont mis à jour et elle est redémarrée.

Remplacement ou ajout d'un module unique

Sous Options de mise à jour de l'application, demande le remplacement ou l'ajout d'un module à une application installée.

Il peut s'agir d'un module Web (fichier .war), d'un module de bean enterprise (fichier .jar EJB), d'un module SIP (fichier .sar) ou d'un module d'adaptateur de ressource (fichier .rar de connecteur).

Une fois cette option sélectionnée, précisez si le module se trouve sur un système de fichiers local ou distant, ainsi que le chemin d'accès complet du module. Le chemin indique l'emplacement du module mis à jour avant installation. Pour plus d'informations sur les options Système de fichiers local et Système de fichiers éloigné, voir la description précédente de l'option Remplacer la totalité de l'application.

Pour remplacer un module, le chemin relatif spécifié (URI du module) doit correspondre au chemin du module à mettre à jour dans l'application installée.

Pour ajouter un nouveau module à l'application installée, le chemin relatif spécifié ne doit pas correspondre au chemin d'un module dans l'application installée. La valeur précise le chemin souhaité pour le nouveau module.

Si vous installez un module Web ou SIP autonome, entrez une valeur pour Racine de contexte. La racine du contexte est combinée avec le mappage de servlet défini (à partir du fichier .war) pour composer l'URL complète que les utilisateurs entrent pour accéder au servlet. Par exemple, si la racine de contexte est /gettingstarted et si le mappage de servlet est MySession, l'URL est http://host:port/gettingstarted/MySession.

Puis indiquez si seules les options d'installation nécessitant que vous fournissiez des informations doivent être affichées ou si toutes les options d'installation doivent être affichées.

Une fois les informations requises entrées dans le module, cliquez sur Suivant pour afficher un assistant de mise à jour des fichiers d'application. Cet assistant, semblable à celui d'installation, comporte des zones d'entrée et d'édition pour les informations de liaison de module. Exécutez les étapes dans cet assistant, comme requis.

Après l'ajout ou la mise à jour d'un module unique, une fois les modifications de configuration sauvegardées, le module ajouté ou mis à jour est stocké dans l'application déployée dans le référentiel de configuration. Lorsque ces modifications sont synchronisées avec le noeud, le module est ajouté ou mis à jour sur le système de fichiers du noeud. Si l'application est en cours d'exécution sur le noeud lorsque le module est ajouté ou mis à jour, l'un des événements suivants se produit :
  • Pour les mises à jour d'un module Web, le module Web en cours d'exécution est arrêté, les fichiers du module Web sont mis à jour, puis le module Web est démarré.
  • Pour les ajouts de module, le module ajouté est démarré sur les serveurs d'applications sur lesquels l'application est en cours d'exécution après son déploiement sur le noeud. Le redémarrage de l'application n'est pas nécessaire.
  • Si la règle de chargeur de classe de l'application est définie à Un seul, de sorte que tous les modules partagent un chargeur de classe, l'application entière est arrêtée, puis redémarrée pour les modifications au niveau du module.
  • Si le fournisseur de sécurité configuré avec le produit ne prend pas en charge les mises à jour dynamiques, toute l'application est arrêtée et redémarrée pour appliquer les modifications au niveau du module.
  • Pour toutes mes autres mises à jour d'un module, l'application entière est arrêtée, les fichiers du module sont mis à jour et l'application est redémarrée.
Remplacement ou ajout d'un fichier unique

Sous Options de mise à jour de l'application, demande le remplacement d'un fichier ou l'ajout d'un fichier à une application installée.

Cette option permet de mettre à jour un fichier utilisé par l'application et qui n'est pas de type .ear, .war, .sar,.rar ou, dans certains cas, .jar. Vous pouvez utiliser cette option pour ajouter ou mettre à jour des fichiers .jar non définis comme modules dans l'application. Pour mettre à jour un fichier .ear, utilisez l'option Remplacer la totalité de l'application. Pour mettre à jour un fichier .war, .sar, .rar ou .jar défini en tant que module dans l'application, utilisez l'option Remplacer ou ajouter un module unique.

Une fois cette option sélectionnée, précisez si le module se trouve sur un système de fichiers local ou distant, ainsi que le chemin d'accès complet du module. Le chemin indique l'emplacement du fichier mis à jour avant installation. Pour plus d'informations sur les options Système de fichiers local et Système de fichiers éloigné, voir la description de l'option Remplacer la totalité de l'application.

Pour le chemin relatif (URI du module), spécifiez celui du fichier qui commence à la racine du fichier .ear. Par exemple, si le fichier se trouve dans com/company/greeting.class, dans le module hello.jar, entrez le chemin relatif hello.jar.

Pour remplacer un fichier, le chemin relatif doit correspondre au chemin relatif du fichier à mettre à jour dans l'application installée.

Pour ajouter un nouveau fichier à l'application installée, le chemin relatif ne doit pas correspondre au chemin relatif d'un fichier existant dans l'application installée. La valeur précise le chemin souhaité pour le nouveau fichier.

Après avoir indiqué le système de fichiers et les chemins relatifs, cliquez sur Suivant.

Une fois qu'un fichier est ajouté ou mis à jour, lorsque les modifications de configuration sont sauvegardées, il est stocké dans l'application déployée dans le référentiel de configuration du produit. Lorsque ces modifications sont synchronisées avec le noeud, le fichier est ajouté ou mis à jour sur le système de fichiers du noeud. Si l'application est en cours d'exécution sur le noeud lorsque le fichier est ajouté ou mis à jour, l'un des événements suivants se produit :
  • Lorsque des fichiers sont ajoutés au niveau des métadonnées de l'application (répertoire META-INF) ou mis à jour au niveau de l'application ou dans des modules non Web, l'application entière est arrêtée, le fichier est ajouté ou mis à jour, puis l'application est redémarrée.
  • Lorsque des fichiers sont ajoutés au niveau des non métadonnées de l'application (en dehors du répertoire META-INF, mais dans aucun module), les modifications sont sauvegardées dans le système de fichiers sans redémarrer l'application en cours d'exécution.
  • Lorsque des fichiers sont ajoutés ou mis à jour dans les métadonnées d'un module Web (répertoire META-INF ou WEB-INF), le module Web en cours d'exécution est arrêté, le fichier de module Web est ajouté ou mis à jour, puis le module Web est redémarré.
  • Pour tous les autres fichiers contenus dans des modules Web, le fichier est ajouté ou mis à jour dans le système de fichiers du noeud sans arrêter l'application ou l'un de ses composants.
Remplacement, ajout ou suppression de plusieurs fichiers

Sous Options de mise à jour de l'application, demande la mise à jour de plusieurs fichiers d'une application installée en téléchargeant un fichier compressé. En fonction du contenu de ce dernier, cette option peut permettre de remplacer des fichiers, d'en ajouter de nouveaux et d'en supprimer de l'application installée. Chaque entrée dans le fichier compressé est traitée comme un fichier unique et le chemin d'accès depuis la racine du fichier compressé est traité comme chemin relatif dans l'application installée.

Une fois cette option sélectionnée, précisez si le fichier compressé se trouve sur un système de fichiers local ou distant, ainsi que le nom du chemin d'accès complet du fichier compressé. Vous utiliserez probablement l'option Système de fichiers local, car vous téléchargez un fichier compressé et l'exploration à distance ne fonctionne que pour les fichiers .ear, .sar, .war ou .jar. Indiquez un format de fichier compressé valide, tel que .zip ou .gzip. Le chemin indique l'emplacement du fichier compressé avant installation. Cette option dézippe le fichier compressé dans le répertoire de l'application installée.

Choisissez Système de fichiers local si le navigateur et les fichiers ou modules mis à jour se trouvent sur la même machine, quel que soit l'emplacement du serveur. Système de fichiers local est disponible pour toutes les options de mise à jour.

Pour remplacer un fichier, l'un de ceux dans le fichier compressé doit avoir le même chemin relatif que celui à mettre à jour dans l'application installée.

Pour ajouter un nouveau fichier à l'application installée, un fichier dans le fichier compressé doit avoir un chemin relatif différent des fichiers dans l'application installée.

Le chemin d'accès relatif à un fichier dans l'application installée est formé par la concaténation du chemin d'accès relatif du module (si le fichier se trouve dans un module) et de celui du fichier à partir de la racine du module séparés par /.

Pour supprimer un fichier de l'application installée, indiquez les métadonnées dans le fichier compressé, à l'aide d'un fichier nommé META-INF/ibm-partialapp-delete.props dans n'importe quelle portée d'archive. Le fichier ibm-partialapp-delete.props doit être un fichier ASCII répertoriant les fichiers à supprimer dans cette archive, avec une entrée par ligne. L'entrée peut contenir un modèle de chaîne tel qu'une expression régulière identifiant plusieurs fichiers. Les chemins des fichiers à supprimer doivent être relatifs par rapport au chemin de l'archive comportant le fichier META-INF/ibm-partialapp-delete.props.
Niveau de fichiers à supprimer Fichier .props de métadonnées à inclure dans un fichier compressé
Application Incluez META-INF/ibm-partialapp-delete.props au fichier compressé. Dans le fichier .props de métadonnées, identifiez les fichiers à supprimer. Les chemins de fichiers sont relatifs pour l'emplacement du fichier META-INF/ibm-partialapp-delete.props.

Par exemple, pour supprimer un fichier nommé utils/config.xmi de la racine du fichier my.ear, entrez la ligne utils/config.xmi dans le fichier META-INF/ibm-partialapp-delete.props.

Module Incluez uri_module/META-INF/ibm-partialapp-delete.props dans le fichier compressé.

Pour supprimer un fichier à partir d'un module, incluez le chemin d'accès relatif au module dans le fichier .props de métadonnées. Par exemple, pour supprimer a/b/c.jsp du module my.jar, incluez a/b/c.jsp dans le fichier my.jar/META-INF/ibm-partialapp-delete.props du fichier compressé.

Pour supprimer plusieurs fichiers d'un module, identifiez-les dans le fichier .props de métadonnées avec une entrée sur chaque ligne. Par exemple, pour supprimer tous les fichiers JavaServer Pages (.jsp) du fichier my.war, ajoutez la ligne .*jsp au fichier my.war/META-INF/ibm-partialapp-delete.props. La ligne utilise une expression régulière, .*jsp, pour identifier tous les fichiers .jsp de my.war.

Vous pouvez utiliser un seul fichier d'application partielle pour ajouter, supprimer et mettre à jour plusieurs fichiers.

Après avoir indiqué un chemin du système de fichiers, cliquez sur Suivant.

Après la mise à jour d'une application partielle, une fois les changements de configuration sauvegardées, le module ajouté ou mis à jour est stocké dans l'application déployée dans le référentiel de WebSphere Application Server. Lorsque ces modifications sont synchronisées avec le noeud, les fichiers sont ajoutés ou mis à jour sur le système de fichiers du noeud. Comme l'option de l'application partielle met à jour plusieurs fichiers, les composants d'application redémarrés sont déterminés à l'aide de fichiers individuels dans l'application partielle.

Exemple

Exemple des entrées d'un fichier compressé d'application partielle :

util.jar
META-INF/ibm-partialapp-delete.props
foo.jar/com/mycomp/xyz.class
xyz.war/welcome.jsp
xyz.war/WEB-INF/web.xml
webmod.war/META-INF/ibm-partialapp-delete.props

Pour cet exemple, le fichier META-INF/ibm-partialapp-delete.props contient les fichiers .*.dat et tools/test.jar. Le fichier webmod.war/META-INF/ibm-partialapp-delete.props contient les fichiers com/test/.*.jsp et WEB-INF/test.xmi.

L'option de mise à jour d'application partielle effectue les opérations suivantes :
  • Ajoute ou remplace util.jar dans l'application déployée.
  • Ajoute ou remplace com/mycomp/xyz.class dans le fichier foo.jar de l'application déployée.
  • Supprime les fichiers *.dat de l'application, mais pas des modules.
  • Supprime tools/test.jar de l'application.
  • Ajoute ou remplace welcome.jsp dans le module xyz.war de l'application déployée.
  • Remplace WEB-INF/web.xml dans le module xyz.war de l'application déployée.
  • Supprime com/test/*.jsp du module webmod.war.
  • Supprime WEB-INF/test.xmi du module webmod.war.

Utilise le caractère d'échappement pour les métacaractères d'expression régulière dans le fichier META-INF/ibm-partialapp-delete.props. Par exemple, pour supprimer les classes internes de la classe Abc, utilisez l'expression régulière Abc\$.*, où $ est un métacaractère d'expression régulière qui utilise la barre oblique inverse (\) comme caractère d'échappement.

Un fichier META-INF/ibm-partialapp-delete.props peut contenir le texte suivant :

.*.dat

webmod.war/META-INF/ibm-partialapp-delete.props:
com/test/.*.jsp
WEB-INF/test.xmi



Les liens marqués (en ligne) requièrent un accès à Internet.

Concepts associés
Tâches associées
Référence associée
Collection d'applications d'entreprise


Nom du fichier : urun_rapp_update.html