Pour déployer une application, utilisez la page Déployer des applications ou des modules.
Cette page contient les options ci-après pour toutes les applications. Des options supplémentaires apparaissent uniquement après avoir renseigné le champ Emplacement de l'application.
Emplacement de l'archive de l'application que vous déployez.
Les options suivantes indiquent les points d'accès à l'archive et précisent si cette dernière est un fichier ou un répertoire.
L'archive est contenue dans un fichier stocké sur l'ordinateur client ou accessible à partir de celui-ci.
L'ordinateur client est l'hôte sur lequel vous visualisez la Console d'administration via un navigateur.
L'archive est un fichier stocké sur l'ordinateur serveur ou une application non packagée contenue dans un répertoire éclaté.
L'ordinateur serveur est l'hôte qui exécute le serveur d'administration de domaine GlassFish Server.
Type de l'application. Les choix disponibles sont les suivants :
Application Web
Application d'entreprise
Client d'application
Module connecteur
Fichier JAR EJB
Autre
Clusters et instances autonomes sur lesquels déployer l'application ou le module. Déplacez les cibles souhaitées dans la colonne Cibles sélectionnées à l'aide des boutons Ajouter et Tout ajouter. Déplacez toutes les cibles inutiles dans la colonne Cibles disponibles à l'aide des boutons Enlever et Tout enlever.
Cette option apparaît uniquement si des clusters ou des instances autonomes ont été créés dans le domaine.
D'autres options, relatives aux différents types d'application, sont décrites dans les sections ci-après.
Dans le cas d'une application Web, les options suivantes apparaissent.
Chemin d'accès à l'application. Dans l'URL de l'application Web, la racine du contexte suit immédiatement le numéro de port (http://
host:
port/
context-root/...
). La racine du contexte doit commencer par une barre oblique, par exemple /hello
.
Nom de l'application.
Le nom peut être suivi d'un identificateur de version facultatif dont il est séparé par un signe deux-points (:
). L'identificateur de version doit commencer par une lettre ou un chiffre. Il peut contenir des caractères alphanumériques, des traits de soulignement (_
), des tirets (-
) et des points (.
). Pour plus d'informations sur les versions des modules et des applications, reportez-vous à Module and Application Versions dans le manuel Oracle GlassFish Server Application Deployment Guide.
Serveurs virtuels associés à cette application.
L'option Serveurs virtuels apparaît si seule l'instance de serveur par défaut, server
, existe. S'il existe des clusters ou d'autres instances de serveur autonomes, vous pouvez sélectionner des serveurs virtuels après le déploiement. Ouvrez la page Modifier une application, sélectionnez l'onglet Cible, puis Gérer les serveurs virtuels pour la cible de votre choix.
Si cette option est sélectionnée, l'application est activée. Cette option est sélectionnée par défaut.
Si la case Activé est cochée, la haute disponibilité est activée pour la réalisation de points de reprise et éventuellement la passivation des sessions Web et des beans Session avec conservation de statut (SFSB). Si la valeur est False (valeur par défaut), tous les enregistrements de session Web et la réalisation de points de reprise SFSB sont désactivés pour l'application, l'application Web ou le module EJB spécifié. Si cette valeur est True, l'application ou le module spécifié est activé pour la haute disponibilité. Définissez cette option sur True seulement si la haute disponibilité est configurée et activée à des niveaux supérieurs, tels que les niveaux serveur et conteneur.
Cette option apparaît si des clusters ou des instances de serveur autonomes existent en plus de l'instance de serveur par défaut (server
).
Si cette option est sélectionnée, les fichiers JSP (Java Server Pages) sont précompilés. Si cette option est désactivée, les fichiers JSP sont compilés au moment de l'exécution, lors de leur premier accès. Cette option est désactivée par défaut.
Si cette option est sélectionnée, les descripteurs de déploiement sont vérifiés avant le déploiement. En cas d'échec de la vérification, le déploiement n'a pas lieu. Le vérificateur examine la structure et le contenu des descripteurs de déploiement. La vérification d'applications volumineuses est souvent une tâche qui demande du temps. Cette option est désactivée par défaut.
Les packages du vérificateur doivent être installés à partir de l'outil de mise à jour ; sinon, un avertissement est consigné et cette option est ignorée.
Si cette option est sélectionnée, l'application est redéployée si elle a déjà été déployée. Si cette option n'est pas sélectionnée, toute tentative de déploiement d'une application déjà déployée génère une erreur. Cette option est désactivée par défaut.
Cette option détermine si les sessions Web, les instances SFSB et les horloges EJB créées de façon persistante sont conservées entre les redéploiements.
Cette option est désactivée par défaut. Elle n'est prise en charge que sur l'instance de serveur par défaut, nommée server
. Elle n'est pas prise en charge et est ignorée pour toute autre cible.
Certaines modifications apportées à une application entre des redéploiements empêchent cette option de fonctionner correctement. Par exemple, ne modifiez pas l'ensemble des variables d'instance dans la classe de bean SFSB.
Pour les applications Web, cette fonctionnalité n'est applicable que si, dans le fichier glassfish-web-app.xml
, l'attribut persistence-type
de l'élément session-manager
est file
.
Pour les instances SFSB, le type de persistance sans haute disponibilité est défini dans le serveur (option Type de persistance SFSB) et doit avoir la valeur file
, qui est la valeur par défaut recommandée.
En cas d'échec de la conservation ou de la restauration d'une session Web, d'une instance SFSB ou d'une horloge EJB active, aucune d'entre elles ne sera disponible une fois le redéploiement terminé. Toutefois, le redéploiement se poursuit et un avertissement est consigné.
Pour conserver les données d'état actives, GlassFish Server sérialise les données et les enregistre dans la mémoire. Pour restaurer les données, le chargeur de classe de l'application qui vient d'être redéployée désérialise les données précédemment enregistrées.
Si cette case est cochée, le système conserve les ressources de niveau application et les restaure pendant le redéploiement. Cette option n'est pas cochée par défaut.
Ordre de déploiement de l'application.
Les applications ayant le numéro le plus faible sont chargées en premier au démarrage du serveur. Une application ayant un ordre de déploiement de 102 est chargée avant une application ayant un ordre de déploiement de 110. Si l'ordre de déploiement n'est pas indiqué au moment où une application est déployée, l'ordre de déploiement par défaut de 100 est affecté. Si deux applications ont le même ordre de déploiement, l'application qui a été déployée en premier est chargée en premier. La spécification d'un ordre de déploiement s'avère utile si l'application a des dépendances et doit être chargée dans un certain ordre.
Liste des fichiers JAR de bibliothèque (séparés par des virgules) propres à ce module ou à cette application. Les chemins peuvent être absolus ou relatifs. Un chemin relatif est relatif à domain-dir/lib/applibs
. Si le chemin est absolu, le serveur d'administration de domaine (DAS) doit pouvoir y accéder, ce qui signifie qu'il doit se trouver sous domain-dir. Les bibliothèques sont mises à la disposition de l'application selon l'ordre dans lequel elles sont spécifiées.
Description de l'application.
Dans le cas d'une application d'entreprise, les options suivantes apparaissent.
Nom de l'application.
Le nom peut être suivi d'un identificateur de version facultatif dont il est séparé par un signe deux-points (:
). L'identificateur de version doit commencer par une lettre ou un chiffre. Il peut contenir des caractères alphanumériques, des traits de soulignement (_
), des tirets (-
) et des points (.
). Pour plus d'informations sur les versions des modules et des applications, reportez-vous à Module and Application Versions dans le manuel Oracle GlassFish Server Application Deployment Guide.
Serveurs virtuels associés à cette application.
L'option Serveurs virtuels apparaît si seule l'instance de serveur par défaut, server
, existe. S'il existe des clusters ou d'autres instances de serveur autonomes, vous pouvez sélectionner des serveurs virtuels après le déploiement. Ouvrez la page Modifier une application, sélectionnez l'onglet Cible, puis Gérer les serveurs virtuels pour la cible de votre choix.
Si cette option est sélectionnée, l'application est activée. Cette option est sélectionnée par défaut.
Si la case Activé est cochée, la haute disponibilité est activée pour la réalisation de points de reprise et éventuellement la passivation des sessions Web et des beans Session avec conservation de statut (SFSB). Si la valeur est False (valeur par défaut), tous les enregistrements de session Web et la réalisation de points de reprise SFSB sont désactivés pour l'application, l'application Web ou le module EJB spécifié. Si cette valeur est True, l'application ou le module spécifié est activé pour la haute disponibilité. Définissez cette option sur True seulement si la haute disponibilité est configurée et activée à des niveaux supérieurs, tels que les niveaux serveur et conteneur.
Cette option apparaît si des clusters ou des instances de serveur autonomes existent en plus de l'instance de serveur par défaut (server
).
Si cette option est sélectionnée, l'accès à Java Web Start est autorisé pour un module client d'application. Cette option est désactivée par défaut.
Si cette option est sélectionnée, les fichiers JSP (Java Server Pages) sont précompilés. Si cette option est désactivée, les fichiers JSP sont compilés au moment de l'exécution, lors de leur premier accès. Cette option est désactivée par défaut.
Si cette option est sélectionnée, les descripteurs de déploiement sont vérifiés avant le déploiement. En cas d'échec de la vérification, le déploiement n'a pas lieu. Le vérificateur examine la structure et le contenu des descripteurs de déploiement. La vérification d'applications volumineuses est souvent une tâche qui demande du temps. Cette option est désactivée par défaut.
Les packages du vérificateur doivent être installés à partir de l'outil de mise à jour ; sinon, un avertissement est consigné et cette option est ignorée.
Si cette case est cochée, le système utilise les exigences de visibilité JAR de GlassFish Server version 2 pour les applications au lieu des exigences Java EE 6 plus strictes implémentées dans les versions ultérieures de GlassFish Server, y compris 4.0. Cette option n'est pas cochée par défaut.
La spécification de la plate-forme Java EE 6 impose des exigences plus strictes que Java EE 5 quant aux fichiers JAR visibles dans divers modules au sein d'un fichier EAR. Plus particulièrement, les clients d'application ne doivent pas avoir accès aux fichiers JAR EJB ou à d'autres fichiers JAR dans le fichier EAR, sauf si les références utilisent les mécanismes Java SE standard (les extensions, par exemple) ou le mécanisme library-directory de Java EE. La sélection de cette case enlève ces restrictions Java EE 6.
Si cette option est sélectionnée, l'application est redéployée si elle a déjà été déployée. Si cette option n'est pas sélectionnée, toute tentative de déploiement d'une application déjà déployée génère une erreur. Cette option est désactivée par défaut.
Cette option détermine si les sessions Web, les instances SFSB et les horloges EJB créées de façon persistante sont conservées entre les redéploiements.
Cette option est désactivée par défaut. Elle n'est prise en charge que sur l'instance de serveur par défaut, nommée server
. Elle n'est pas prise en charge et est ignorée pour toute autre cible.
Certaines modifications apportées à une application entre des redéploiements empêchent cette option de fonctionner correctement. Par exemple, ne modifiez pas l'ensemble des variables d'instance dans la classe de bean SFSB.
Pour les applications Web, cette fonctionnalité n'est applicable que si, dans le fichier glassfish-web-app.xml
, l'attribut persistence-type
de l'élément session-manager
est file
.
Pour les instances SFSB, le type de persistance sans haute disponibilité est défini dans le serveur (option Type de persistance SFSB) et doit avoir la valeur file
, qui est la valeur par défaut recommandée.
En cas d'échec de la conservation ou de la restauration d'une session Web, d'une instance SFSB ou d'une horloge EJB active, aucune d'entre elles ne sera disponible une fois le redéploiement terminé. Toutefois, le redéploiement se poursuit et un avertissement est consigné.
Pour conserver les données d'état actives, GlassFish Server sérialise les données et les enregistre dans la mémoire. Pour restaurer les données, le chargeur de classe de l'application qui vient d'être redéployée désérialise les données précédemment enregistrées.
Si cette case est cochée, le système conserve les ressources de niveau application et les restaure pendant le redéploiement. Cette option n'est pas cochée par défaut.
Ordre de déploiement de l'application.
Les applications ayant le numéro le plus faible sont chargées en premier au démarrage du serveur. Une application ayant un ordre de déploiement de 102 est chargée avant une application ayant un ordre de déploiement de 110. Si l'ordre de déploiement n'est pas indiqué au moment où une application est déployée, l'ordre de déploiement par défaut de 100 est affecté. Si deux applications ont le même ordre de déploiement, l'application qui a été déployée en premier est chargée en premier. La spécification d'un ordre de déploiement s'avère utile si l'application a des dépendances et doit être chargée dans un certain ordre.
Liste des fichiers JAR de bibliothèque (séparés par des virgules) propres à cette application. Indique un chemin absolu ou relatif. Un chemin relatif est relatif à domain-dir/lib/applibs
. Si le chemin est absolu, le serveur d'administration de domaine (DAS) doit pouvoir y accéder, ce qui signifie qu'il doit se trouver sous domain-dir. Les bibliothèques sont mises à la disposition de l'application selon l'ordre dans lequel elles sont spécifiées.
Description de l'application.
Dans le cas d'un client d'application, les options ci-après apparaissent.
Nom de l'application.
Le nom peut être suivi d'un identificateur de version facultatif dont il est séparé par un signe deux-points (:
). L'identificateur de version doit commencer par une lettre ou un chiffre. Il peut contenir des caractères alphanumériques, des traits de soulignement (_
), des tirets (-
) et des points (.
). Pour plus d'informations sur les versions des modules et des applications, reportez-vous à Module and Application Versions dans le manuel Oracle GlassFish Server Application Deployment Guide.
Si cette option est sélectionnée, l'accès à Java Web Start est autorisé pour un module client d'application. Cette option est désactivée par défaut.
Si cette option est sélectionnée, les descripteurs de déploiement sont vérifiés avant le déploiement. En cas d'échec de la vérification, le déploiement n'a pas lieu. Le vérificateur examine la structure et le contenu des descripteurs de déploiement. La vérification d'applications volumineuses est souvent une tâche qui demande du temps. Cette option est désactivée par défaut.
Les packages du vérificateur doivent être installés à partir de l'outil de mise à jour ; sinon, un avertissement est consigné et cette option est ignorée.
Si cette option est sélectionnée, l'application est redéployée si elle a déjà été déployée. Si cette option n'est pas sélectionnée, toute tentative de déploiement d'une application déjà déployée génère une erreur. Cette option est désactivée par défaut.
Ordre de déploiement de l'application.
Les applications ayant le numéro le plus faible sont chargées en premier au démarrage du serveur. Une application ayant un ordre de déploiement de 102 est chargée avant une application ayant un ordre de déploiement de 110. Si l'ordre de déploiement n'est pas indiqué au moment où une application est déployée, l'ordre de déploiement par défaut de 100 est affecté. Si deux applications ont le même ordre de déploiement, l'application qui a été déployée en premier est chargée en premier. La spécification d'un ordre de déploiement s'avère utile si l'application a des dépendances et doit être chargée dans un certain ordre.
Description de l'application.
Dans le cas d'un module connecteur, les options ci-après apparaissent.
Nom de l'application.
Le nom peut être suivi d'un identificateur de version facultatif dont il est séparé par un signe deux-points (:
). L'identificateur de version doit commencer par une lettre ou un chiffre. Il peut contenir des caractères alphanumériques, des traits de soulignement (_
), des tirets (-
) et des points (.
). Pour plus d'informations sur les versions des modules et des applications, reportez-vous à Module and Application Versions dans le manuel Oracle GlassFish Server Application Deployment Guide.
Si cette option est sélectionnée, l'application est activée. Cette option est sélectionnée par défaut.
Si cette option est sélectionnée, les descripteurs de déploiement sont vérifiés avant le déploiement. En cas d'échec de la vérification, le déploiement n'a pas lieu. Le vérificateur examine la structure et le contenu des descripteurs de déploiement. La vérification d'applications volumineuses est souvent une tâche qui demande du temps. Cette option est désactivée par défaut.
Les packages du vérificateur doivent être installés à partir de l'outil de mise à jour ; sinon, un avertissement est consigné et cette option est ignorée.
Si cette option est sélectionnée, l'application est redéployée si elle a déjà été déployée. Si cette option n'est pas sélectionnée, toute tentative de déploiement d'une application déjà déployée génère une erreur. Cette option est désactivée par défaut.
Si cette case est cochée, le système conserve les ressources de niveau application et les restaure pendant le redéploiement. Cette option n'est pas cochée par défaut.
Ordre de déploiement de l'application.
Les applications ayant le numéro le plus faible sont chargées en premier au démarrage du serveur. Une application ayant un ordre de déploiement de 102 est chargée avant une application ayant un ordre de déploiement de 110. Si l'ordre de déploiement n'est pas indiqué au moment où une application est déployée, l'ordre de déploiement par défaut de 100 est affecté. Si deux applications ont le même ordre de déploiement, l'application qui a été déployée en premier est chargée en premier. La spécification d'un ordre de déploiement s'avère utile si l'application a des dépendances et doit être chargée dans un certain ordre.
Description de l'application.
Dans le cas d'un fichier JAR EJB, les options ci-après apparaissent.
Nom de l'application.
Le nom peut être suivi d'un identificateur de version facultatif dont il est séparé par un signe deux-points (:
). L'identificateur de version doit commencer par une lettre ou un chiffre. Il peut contenir des caractères alphanumériques, des traits de soulignement (_
), des tirets (-
) et des points (.
). Pour plus d'informations sur les versions des modules et des applications, reportez-vous à Module and Application Versions dans le manuel Oracle GlassFish Server Application Deployment Guide.
Si cette option est sélectionnée, l'application est activée. Cette option est sélectionnée par défaut.
Si la case Activé est cochée, la haute disponibilité est activée pour la réalisation de points de reprise et éventuellement la passivation des sessions Web et des beans Session avec conservation de statut (SFSB). Si la valeur est False (valeur par défaut), tous les enregistrements de session Web et la réalisation de points de reprise SFSB sont désactivés pour l'application, l'application Web ou le module EJB spécifié. Si cette valeur est True, l'application ou le module spécifié est activé pour la haute disponibilité. Définissez cette option sur True seulement si la haute disponibilité est configurée et activée à des niveaux supérieurs, tels que les niveaux serveur et conteneur.
Cette option apparaît si des clusters ou des instances de serveur autonomes existent en plus de l'instance de serveur par défaut (server
).
Si cette option est sélectionnée, les descripteurs de déploiement sont vérifiés avant le déploiement. En cas d'échec de la vérification, le déploiement n'a pas lieu. Le vérificateur examine la structure et le contenu des descripteurs de déploiement. La vérification d'applications volumineuses est souvent une tâche qui demande du temps. Cette option est désactivée par défaut.
Les packages du vérificateur doivent être installés à partir de l'outil de mise à jour ; sinon, un avertissement est consigné et cette option est ignorée.
Si cette case est cochée, le système utilise les exigences de visibilité JAR de GlassFish Server version 2 pour les applications au lieu des exigences Java EE 6 plus strictes implémentées dans les versions ultérieures de GlassFish Server, y compris 4.0. Cette option n'est pas cochée par défaut.
La spécification de la plate-forme Java EE 6 impose des exigences plus strictes que Java EE 5 quant aux fichiers JAR visibles dans divers modules au sein d'un fichier EAR. Plus particulièrement, les clients d'application ne doivent pas avoir accès aux fichiers JAR EJB ou à d'autres fichiers JAR dans le fichier EAR, sauf si les références utilisent les mécanismes Java SE standard (les extensions, par exemple) ou le mécanisme library-directory de Java EE. La sélection de cette case enlève ces restrictions Java EE 6.
Si cette option est sélectionnée, l'application est redéployée si elle a déjà été déployée. Si cette option n'est pas sélectionnée, toute tentative de déploiement d'une application déjà déployée génère une erreur. Cette option est désactivée par défaut.
Cette option détermine si les sessions Web, les instances SFSB et les horloges EJB créées de façon persistante sont conservées entre les redéploiements.
Cette option est désactivée par défaut. Elle n'est prise en charge que sur l'instance de serveur par défaut, nommée server
. Elle n'est pas prise en charge et est ignorée pour toute autre cible.
Certaines modifications apportées à une application entre des redéploiements empêchent cette option de fonctionner correctement. Par exemple, ne modifiez pas l'ensemble des variables d'instance dans la classe de bean SFSB.
Pour les applications Web, cette fonctionnalité n'est applicable que si, dans le fichier glassfish-web-app.xml
, l'attribut persistence-type
de l'élément session-manager
est file
.
Pour les instances SFSB, le type de persistance sans haute disponibilité est défini dans le serveur (option Type de persistance SFSB) et doit avoir la valeur file
, qui est la valeur par défaut recommandée.
En cas d'échec de la conservation ou de la restauration d'une session Web, d'une instance SFSB ou d'une horloge EJB active, aucune d'entre elles ne sera disponible une fois le redéploiement terminé. Toutefois, le redéploiement se poursuit et un avertissement est consigné.
Pour conserver les données d'état actives, GlassFish Server sérialise les données et les enregistre dans la mémoire. Pour restaurer les données, le chargeur de classe de l'application qui vient d'être redéployée désérialise les données précédemment enregistrées.
Si cette case est cochée, le système conserve les ressources de niveau application et les restaure pendant le redéploiement. Cette option n'est pas cochée par défaut.
Ordre de déploiement de l'application.
Les applications ayant le numéro le plus faible sont chargées en premier au démarrage du serveur. Une application ayant un ordre de déploiement de 102 est chargée avant une application ayant un ordre de déploiement de 110. Si l'ordre de déploiement n'est pas indiqué au moment où une application est déployée, l'ordre de déploiement par défaut de 100 est affecté. Si deux applications ont le même ordre de déploiement, l'application qui a été déployée en premier est chargée en premier. La spécification d'un ordre de déploiement s'avère utile si l'application a des dépendances et doit être chargée dans un certain ordre.
Liste des fichiers JAR de bibliothèque (séparés par des virgules) propres à ce module ou à cette application. Indique un chemin absolu ou relatif. Un chemin relatif est relatif à domain-dir/lib/applibs
. Si le chemin est absolu, le serveur d'administration de domaine (DAS) doit pouvoir y accéder, ce qui signifie qu'il doit se trouver sous domain-dir. Les bibliothèques sont mises à la disposition de l'application selon l'ordre dans lequel elles sont spécifiées.
Description de l'application.
Dans le cas d'un autre type d'application, les options ci-après apparaissent.
Nom de l'application.
Le nom peut être suivi d'un identificateur de version facultatif dont il est séparé par un signe deux-points (:
). L'identificateur de version doit commencer par une lettre ou un chiffre. Il peut contenir des caractères alphanumériques, des traits de soulignement (_
), des tirets (-
) et des points (.
). Pour plus d'informations sur les versions des modules et des applications, reportez-vous à Module and Application Versions dans le manuel Oracle GlassFish Server Application Deployment Guide.
Serveurs virtuels associés à cette application.
L'option Serveurs virtuels apparaît si seule l'instance de serveur par défaut, server
, existe. S'il existe des clusters ou d'autres instances de serveur autonomes, vous pouvez sélectionner des serveurs virtuels après le déploiement. Ouvrez la page Modifier une application, sélectionnez l'onglet Cible, puis Gérer les serveurs virtuels pour la cible de votre choix.
Si cette option est sélectionnée, l'application est activée. Cette option est sélectionnée par défaut.
Si la case Activé est cochée, la haute disponibilité est activée pour la réalisation de points de reprise et éventuellement la passivation des sessions Web et des beans Session avec conservation de statut (SFSB). Si la valeur est False (valeur par défaut), tous les enregistrements de session Web et la réalisation de points de reprise SFSB sont désactivés pour l'application, l'application Web ou le module EJB spécifié. Si cette valeur est True, l'application ou le module spécifié est activé pour la haute disponibilité. Définissez cette option sur True seulement si la haute disponibilité est configurée et activée à des niveaux supérieurs, tels que les niveaux serveur et conteneur.
Cette option apparaît si des clusters ou des instances de serveur autonomes existent en plus de l'instance de serveur par défaut (server
).
Si cette option est sélectionnée, elle indique un module OSGi/Java-EE hybride. Cette option apparaît uniquement si le type sélectionné est Autre.
Si cette option est sélectionnée, les fichiers JSP (Java Server Pages) sont précompilés. Si cette option est désactivée, les fichiers JSP sont compilés au moment de l'exécution, lors de leur premier accès. Cette option est désactivée par défaut.
Si cette option est sélectionnée, les descripteurs de déploiement sont vérifiés avant le déploiement. En cas d'échec de la vérification, le déploiement n'a pas lieu. Le vérificateur examine la structure et le contenu des descripteurs de déploiement. La vérification d'applications volumineuses est souvent une tâche qui demande du temps. Cette option est désactivée par défaut.
Les packages du vérificateur doivent être installés à partir de l'outil de mise à jour ; sinon, un avertissement est consigné et cette option est ignorée.
Si cette option est sélectionnée, l'application est redéployée si elle a déjà été déployée. Si cette option n'est pas sélectionnée, toute tentative de déploiement d'une application déjà déployée génère une erreur. Cette option est désactivée par défaut.
Cette option détermine si les sessions Web, les instances SFSB et les horloges EJB créées de façon persistante sont conservées entre les redéploiements.
Cette option est désactivée par défaut. Elle n'est prise en charge que sur l'instance de serveur par défaut, nommée server
. Elle n'est pas prise en charge et est ignorée pour toute autre cible.
Certaines modifications apportées à une application entre des redéploiements empêchent cette option de fonctionner correctement. Par exemple, ne modifiez pas l'ensemble des variables d'instance dans la classe de bean SFSB.
Pour les applications Web, cette fonctionnalité n'est applicable que si, dans le fichier glassfish-web-app.xml
, l'attribut persistence-type
de l'élément session-manager
est file
.
Pour les instances SFSB, le type de persistance sans haute disponibilité est défini dans le serveur (option Type de persistance SFSB) et doit avoir la valeur file
, qui est la valeur par défaut recommandée.
En cas d'échec de la conservation ou de la restauration d'une session Web, d'une instance SFSB ou d'une horloge EJB active, aucune d'entre elles ne sera disponible une fois le redéploiement terminé. Toutefois, le redéploiement se poursuit et un avertissement est consigné.
Pour conserver les données d'état actives, GlassFish Server sérialise les données et les enregistre dans la mémoire. Pour restaurer les données, le chargeur de classe de l'application qui vient d'être redéployée désérialise les données précédemment enregistrées.
Ordre de déploiement de l'application.
Les applications ayant le numéro le plus faible sont chargées en premier au démarrage du serveur. Une application ayant un ordre de déploiement de 102 est chargée avant une application ayant un ordre de déploiement de 110. Si l'ordre de déploiement n'est pas indiqué au moment où une application est déployée, l'ordre de déploiement par défaut de 100 est affecté. Si deux applications ont le même ordre de déploiement, l'application qui a été déployée en premier est chargée en premier. La spécification d'un ordre de déploiement s'avère utile si l'application a des dépendances et doit être chargée dans un certain ordre.
Liste des fichiers JAR de bibliothèque (séparés par des virgules) propres à ce module ou à cette application. Indique un chemin absolu ou relatif. Un chemin relatif est relatif à domain-dir/lib/applibs
. Si le chemin est absolu, le serveur d'administration de domaine (DAS) doit pouvoir y accéder, ce qui signifie qu'il doit se trouver sous domain-dir. Les bibliothèques sont mises à la disposition de l'application selon l'ordre dans lequel elles sont spécifiées.
Description de l'application.