Méthodes de mise à jour des fichiers d'application d'entreprise
Vous pouvez mettre à jour les fichiers d'application Java EE (Java™ Platform, Enterprise Edition) déployés sur un serveur ou un cluster de plusieurs manières.
Option | Méthode | Commentaires | Démarrage après mise à jour |
---|---|---|---|
Assistant de mise à jour de la console d'administration Voir Mise à jour des applications d'entreprise avec la console. Pour supprimer un fichier unique d'un module ou d'une application Java EE, consultez la rubrique relative à la suppression des fichiers d'entreprise. |
En résumé, procédez comme suit :
|
Dans la page
Préparation à la mise à
jour de l'application, procédez comme suit :
|
Dans la page Applications d'entreprise, sélectionnez l'application mise à jour et cliquez sur Démarrer. |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() En cas d'installation dans un répertoire surveillé de gestionnaire de déploiement, le produit ne démarre pas automatiquement l'application ou le module qui viennent d'être installés ou mis à jour si l'agent de noeud ou le serveur n'est pas lancé. |
![]() ![]() |
![]() ![]()
|
![]() ![]() |
![]() ![]() En cas d'installation dans un répertoire surveillé de gestionnaire de déploiement, le produit ne démarre pas automatiquement l'application ou le module qui viennent d'être installés ou mis à jour si l'agent de noeud ou le serveur n'est pas lancé. |
Scripts wsadmin Consultez la rubrique relative à la mise à jour des applications installées à l'aide de l'outil de scriptage wsadmin. |
Utilisez la commande update ou la commande updateInteractive dans un script ou à une invite de commande. Pour plus d'informations sur les commandes update et updateInteractive, consultez la rubrique relative aux commandes de l'objet AdminApp. | La rubrique Initiation à l'outil de scriptage wsadmin fournit des généralités sur wsadmin. | Démarrez l'application à l'aide de la commande invoke et de l'attribut startApplication. Pour plus d'informations sur la commande invoke, consultez la rubrique relative aux commandes de l'objet AdminControl. |
Interfaces de programmation d'application Java Voir la rubrique sur l'utilisation des programmes d'administration (JMX). |
Mettez à jour les applications déployées en suivant la procédure décrite dans la rubrique relative à la gestion des applications par programmation. | Mettez à jour une application en procédant comme suit :
|
Appelez la méthode startApplication sur un bean ApplicationManager MBean à l'aide d'AdminControl. |
Outils de déploiement rapide Voir les rubriques situées sous Déploiement rapide d'applications J2EE. |
En résumé, procédez comme suit :
|
Les outils de déploiement rapide procurent les avantages suivants :
|
Utilisez l'une des options précédentes pour démarrer l'application. L'option la plus simple consiste à cliquer sur Démarrer dans la page Applications d'entreprise. |
Déploiement à chaud et rechargement dynamique | En résumé, procédez comme suit :
|
Si vous découvrez WebSphere
Application Server,
utilisez la console
d'administration pour mettre à jour des applications. Cette option est
plus simple. Le déploiement à chaud et le rechargement dynamique sont plus compliqués à exécuter. Vous devez manipuler directement l'application ou le fichier du module sur le serveur sur lequel l'application est déployée. En particulier, les nouvelles fonctions qui utilisent des annotations peuvent interagir de manière notable avec le déploiement à chaud. Consultez les informations sous L'attribut metadata-complete pour plus d'informations sur ces interactions lors du déploiement d'applications à chaud. |
Utilisez l'une des options précédentes pour démarrer l'application. L'option la plus simple consiste à cliquer sur Démarrer dans la page Applications d'entreprise. |
Vous pouvez mettre à jour un fichier .ear, .jar de bean enterprise, .war de module Web, SIP (Session Initiation Protocol) (.sar), .rar de connecteur, .jar de client d'application ou tout autre fichier utilisé par une application installée.
Si l'application est mise à jour pendant son exécution, WebSphere Application Server l'arrête automatiquement, en met à jour la logique et la redémarre. En revanche, si l'application ne démarre pas automatiquement, démarrez-la manuellement à l'aide de l'une des options de démarrage. Pour plus d'informations sur le redémarrage d'applications mises à jour, voir "Fine-grained recycle behavior" dans IBM® WebSphere Developer Technical Journal: System management for WebSphere Application Server V6 -- Part 5 Flexible options for updating deployed applications.
Si vous mettez à jour les métadonnées du module pendant l'exécution de l'application, le redémarrage de l'application peut ne pas suffire pour appliquer les modifications. Par exemple, si vous modifiez des descripteurs d'applications Java EE 6 en cours d'exécution qui utilisent des annotations, vous devez réinstaller l'application. Si vous modifiez des classes qui introduisent, suppriment ou affectent les hiérarchies de classes d'une application et que ces modifications n'affectent pas les classes annotées, vous devez également réinstaller l'application.
Attribut metadata-complete
- Si l'élément metadata-complete a pour valeur false, deux nouveaux fichiers sont créés : web_merged.xml, contenant les résultats fusionnés de web.xml avec des métadonnées d'annotations, et un nouveau fichier, ibm-metadata.xml,, contenant d'autres données relatives aux annotations ne pouvant pas être stockées dans web_merged.xml. Le fichier web_merged.xml contient aussi d'autres métadonnées qui sont lues depuis web-fragment.xml dans les fichiers JAR situés sous le répertoire WEB-INF/lib du fichier WAR.
- Si l'élément metadata-complete a pour valeur true, web_merged.xml n'est PAS généré, et ibm-metadata.xml n'est PAS créé. Le fichier ibm-metadata.xml n'est généré que si le fichier web_merged.xml l'est aussi.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2011/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3.0.xsd"
version="3.0" metadata-complete="true">
<display-name>TestServlet30</display-name>
</web-app>
Les fichiers web.xml et web_fragment.xml doivent être mis à jour, s'ils régissent la mise à jour du déploiement à chaud. Si seul le fichier web_merged.xml est mis à jour, les modifications du déploiement à chaud sont perdues lorsqu'une action administrative le régénère.Le traitement de web.xml dans un fichier WAR et celui de ejb-jar.xml dans un fichier EJBJAR sont identiques, web.xml étant créé pour un fichier WAR si web.xml est absent ou contient l'attribut metadata-complete avec la valeur false, ejb-jar_merged.xml étant créé pour un fichier EJBJAR si ejb-jar.xml est absent ou contient l'attribut metadata-complete avec la valeur false.
Dans les deux cas, un fichier ibm-metadata.xml est créé lorsqu'un fichier XML fusionné est créé. (Et uniquement si le XML fusionné est créé.)
Si le déploiement fait passer la valeur de metadata-complete de false à true, le fichier XML (web.xml ou ejb-jar.xml) est créé ou remplacé, le fichier XML fusionné n'est pas créé, et le fichier ibm-metadata.xml n'est pas créé non plus.
- L'attribut metadata-complete défini dans le fichier web.xml interagit avec le traitement EJB-IN-WAR.
- En l'absence de contenu EJB dans le fichier WAR, le traitement EJB-IN-WAR n'a pas lieu.
- Le déploiement peut faire passer la valeur de metadata-complete de false à true de manière indépendante pour le fichier web.xml ou ejb-jar.xml.
- Le fichier ibm-metadata.xml est créé lorsque l'un ou l'autre des fichiers XML fusionnés est créé. (Il ne l'est pas lorsqu'aucun fichier XML fusionné n'est créé.)
Comme pour EJB-IN-WAR, les règles suivantes s'appliquent :
- Lorsque l'attribut metadata-complete défini dans le fichier web.xml a pour valeur true et que le fichier ejb-jar.xml n'existe pas, le traitement EJB-IN-WAR n'a pas lieu, même si le fichier WAR contient des annotations EJB.
- Lorsque le fichier web.xml contient la valeur metadata-complete avec la valeur false (ou lorsque web.xml n'existe pas) et que le fichier ejb-jar.xml n'existe pas, le traitement EJB-IN-WAR n'a lieu que si le fichier WAR contient des annotations EJB.
- Lorsqu'un fichier ejb-jar.xml est présent, le paramètre metadata-complete du fichier web.xml n'est pas utilisé pour identifier le traitement EJB effectué. Dans ce cas, le traitement EJB-IN-WAR est déterminé par le paramètre metadata-complete du fichier ejb-jar.xml.