Modifications liées aux applications

Des différences d'application existent entre Enterprise Server v3 et Enterprise Server v2. Cette rubrique décrit certaines de ces différences.

Option force

La valeur par défaut de l'option force pour le déploiement est false dans Enterprise Server v3. Cette valeur par défaut était true dans Enterprise Server v2. Dans Enterprise Server v3 vous devez explicitement donner à cette option la valeur true pour le redéploiement. Cette option n'est pas définie automatiquement lors du processus de mise à niveau. L'objet de cette modification est d'éviter le remplacement accidentel du contenu d'une application existante. Ceci s'applique à la fois à la console d'administration et à l'utilitaire de ligne de commande.

La commande asadmin redeploy est également une nouveauté de Enterprise Server v3 et est l'équivalent de --force=true. L'option force ne s'applique qu'à la commande deploy (interface de ligne de commande) et à l'écran deploy (console), et non pas à la commande redeploy ni à l'écran redeploy.

Applications et structure de répertoires générée

Enterprise Server v2 dispose de deux sous-répertoires pour le référentiel des applications : applications/j2ee-apps et applications/j2ee-modules. Ces sous-répertoires n'existent pas dans Enterprise Server v3 (il n'existe pas de niveau j2ee-apps ni de niveau j2ee-modules). Le déploiement d'un module autonome tel que foo.war, résidant auparavant dans applications/j2ee-modules/foo dans Enterprise Server v2, s'effectue désormais dans Enterprise Server v3 dans applications/foo. Les applications d'entreprise et les modules autonomes partagent essentiellement le même espace de noms ; la couche de répertoires intermédiaires n'est donc pas nécessaire.

Élément domain.xml application

Les anciens éléments tels que web-module, ejb-module , etc., ont été abandonnés dans Enterprise Server v3 pour être remplacés par le nouvel élément application. Pour plus d'informations sur l'élément application, reportez-vous à application du Sun GlassFish Enterprise Server v3 Domain File Format Reference.

Au cours d'une mise à niveau, les applications Enterprise Server v2 sont redéployées au nouvel emplacement applications/ avec le nouvel élément application du fichier domain.xml. Les nouvelles applications déployées sur Enterprise Server v3 sont déployées avec la nouvelle structure de répertoires et le nouvel élément.

Règles de visibilité plus strictes des fichiers JAR

Java EE 6 impose des règles de visibilité plus strictes des fichiers JAR que Java EE 5. Par conséquent, certaines applications plus anciennes risque de ne pas fonctionner correctement.

Java EE 6 specification impose des règles strictes de visibilité des fichiers JAR à partir d'un fichier EAR (ficher archive d'entreprise). Consultez tout particulièrement la section EE.8.3.3. Les modules client d'application notamment ne doivent avoir accès à aucun fichier JAR EJB à moins que le manifest du fichier JAR de client d'application class-path ne fasse explicitement référence au(x) fichier(s) JAR EJB.

Ceci diffère de Enterprise Server v2 dans lequel les clients d'application avaient automatiquement accès à tous les fichiers JAR EJB dans le fichier EAR, ainsi qu'à tous les fichiers JAR au niveau le plus élevé du fichier EAR. Pour se conformer au langage de spécification plus stricte, Enterprise Server v3 ne peut pas fournir automatiquement aux clients d'application l'accès à ces fichiers JAR.

Ce nouveau comportement plus stricte imposé par Java EE 6 peut être utilisé comme suit :

• Si l'application est déployée sur un domaine Enterprise Server v2, l'outil de mise à niveau préserve le comportement de Enterprise Server v2 de cette application dans ce domaine. Pour plus d'informations sur les mises à niveau, reportez-vous au Sun GlassFish Enterprise Server v3 Upgrade Guide.

• Modifiez le fichier manifeste Class-Path du client afin qu'il réfère explicitement aux fichiers JAR desquels il dépend. Class-Path ne doit pas répertorier les fichiers JAR dans le répertoire de bibliothèque du fichier EAR. De par la spécification , tous les fichiers JAR de ce répertoire sont mis à la disposition de tous les modules du fichier EAR. Ce répertoire est par défaut /lib ; toutefois, vous pouvez définir un autre répertoire à l'aide de library-directory dans le descripteur application.xml.

• Déployez le fichier EAR à l'aide du paramètre facultatif --property compatibility=v2. Ce paramètre permet de préserver le comportement de Enterprise Server v2 pour l'application en question lors de son déploiement sur Enterprise Server v3.

Ce changement de comportement est également abordé dans Chapitre 1, Application Server Compatibility Issues du Sun GlassFish Enterprise Server v3 Upgrade Guide.

Commandes deploy --retrieve et get-client-stubs des clients d'application

Dans Sun GlassFish Enterprise Server v3, l'exécution des commandes deploy --retrieve et get-client-stubs ne télécharge pas un seul fichier JAR dans votre répertoire local comme cela était le cas dans Enterprise Server v2. Bien que la création du répertoire localdir/myAppClient.jar a toujours lieu dans Enterprise Server v3 et qu'il puisse être utilisé comme cible dans la commande appclient, un autre répertoire, localdir/myAppClient , qui peut aussi contenir d'autres fichiers, est également créé.

Si vous avez l'habitude de copier le seul fichier JAR téléchargé de Enterprise Server v2 afin de déplacer les composants des clients d'application d'un emplacement à un autre, cette opération ne fonctionne pas dans Enterprise Server v3. La méthode prise en charge pour cette opération consiste à utiliser la commande asadmin get-client-stubs. Pour plus d'informations sur cette commande, reportez-vous à get-client-stubs(1).

Si vous optez cependant pour la copie, vous devez non seulement copier le fichier localdir/myAppClient.jar (tout comme dans Enterprise Server v2), mais aussi tout le contenu du répertoire localdir/myAppClient.