Notes de version de Sun GlassFish Enterprise Server 2.1

Conteneur Web

Cette section décrit les problèmes connus liés au conteneur Web et les solutions associées.

Sous Windows, le déploiement d'une application à l'aide de --precompilejsp=true risque de verrouiller les fichiers JAR de celle-ci, eintraînant ainsi l'échec de l'annulation du déploiement ou du redéploiement ultérieur (5004315)

Description

Si vous devez effectuer une précompilation des pages JSP lors du déploiement d’une application sous Windows, les tentatives ultérieures de redéploiement ou d’annulation de déploiement de cette application (ou de toute autre application contenant le même ID de module) ne fonctionneront pas comme prévu. L’origine de ce problème provient du fait que la précompilation des pages JSP ouvre les fichiers JAR dans votre application, mais ne les referme pas. Windows empêche alors que le processus d’annulation du déploiement ne supprime ces fichiers ou que le processus de redéploiement ne les écrase.

Il est à noter que l’annulation du déploiement réussit partiellement dans la mesure où l’application est supprimée d’Application Server. Notez aussi qu'aucun message d'erreur n'est retourné par l'utilitaire asadmin, mais que le répertoire de l'application et les fichiers jar verrouillés ne sont pas supprimés du serveur. Le fichier journal du serveur contient les messages décrivant l'échec de la suppression des fichiers et du répertoire de l'application.

Toute tentative de redéploiement de l’application suite à l’annulation du déploiement échoue, car le serveur essaie en vain de supprimer le répertoire et les fichiers existants. Cela peut se produire si vous essayez de déployer une application qui utilise le même ID de module que celui de l'application initialement déployée. En effet, le serveur utilise cet ID de module lors de la sélection d'un répertoire destiné à contenir les fichiers de l'application.

Les tentatives de redéploiement de l'application sans annulation préalable du déploiement échouent pour les mêmes raisons.

Diagnostics

Si vous essayez de redéployer l’application ou de la déployer après avoir annulé son déploiement, l’utilitaire asadmin renvoie une erreur similaire à l'erreur ci-dessous.


An exception occurred while running the command. The exception 
message is: CLI171 Command deploy failed : Deploying application in 
domain failed; Cannot deploy. Module directory is locked and can't 
be deleted.

Solution

Ce problème ne se produit pas si vous définissez le paramètre par défaut --precompilejsps=false lors du déploiement d’une application. Lors de sa première utilisation, l'application déclenche la compilation des pages JSP. C'est pour cette raison que le temps de réponse de la première requête est supérieur à celui des requêtes suivantes.

Notez également qu’en cas de précompilation, vous devez arrêter et redémarrer le serveur avant d’annuler le déploiement de l’application ou de redéployer cette dernière. L’arrêt du serveur permet de libérer les fichiers JAR qui étaient verrouillés et d’effectuer correctement les opérations d’annulation du déploiement ou de redéploiement de l’application après le redémarrage.

Impossible de déployer les archives WAR avec le fichier web.xml basé sur Servlet 2.4, contenant un élément <load-on-startup> vide (6172006)

Description

L’élément facultatif load-on-startup inclus dans le fichier web.xml indique que le servlet correspondant doit être chargé et initialisé au démarrage de l'application Web à laquelle il appartient.

Le contenu facultatif de cet élément est un nombre entier précisant en quelle position le servlet doit être chargé et initialisé par rapport aux autres servlets de l'application Web. Lorsque l'élément <load-on-startup> est vide, l'ordre de démarrage du servlet est inutile tant que celui-ci est chargé et initialisé au cours du démarrage de l'application Web dont il dépend.

Le schéma Servlet 2.4 du fichier web.xml ne prend plus en charge les éléments <load-on-startup> vides, ce qui signifie que vous devez obligatoirement indiquer un nombre entier lorsque vous utilisez un fichier web.xml basé sur le composant Servlet 2.4. Si vous laissez l’élément <load-on-startup> vide, tel que <load-on-startup/>, le fichier web.xml ne parvient pas à valider le schéma Servlet 2.4 pour web.xml, provoquant l’échec du déploiement de l’application Web.

Problème de compatibilité ascendante : Vous pouvez néanmoins laisser l'élément <load-on-startup> vide pour un fichier web.xml basé sur le composant Servlet 2.3.

Solution

Définissez la valeur <load-on-startup>0</load-on-startup> lors de l'utilisation d'un fichier web.xml basé sur Servlet 2.4 afin d'indiquer que l'ordre de chargement du servlet n'est pas important.

Impossible de compiler la page JSP sur des serveurs limités en ressources (6184122)

Description

La page JSP est accessible mais ne peut pas être compilée. Le journal du serveur contient le message d’erreur "Impossible d'exécuter la commande" avec le suivi de pile suivant :


at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.
exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute.
launch(Execute.java:416) 
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) 
at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.
executeExternalCompile(DefaultCompilerAdapter.java:448) 
at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute
(JavacExternal.java:81) 
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) 
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) 
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396)

Solution

Définissez le commutateur de compilation JSP fork sur false.

Vous pouvez effectuer cette opération de l'une des deux manières suivantes:

Les deux paramétrages empêcheront ant de générer un nouveau processus pour la compilation javac .

Enterprise Server ne prend pas en charge l'add-on auth-passthrough de Web Server 6.1 (6188932)

Description

Sun GlassFish Enterprise Server 2.1 propose la prise en charge de la fonctionnalité fournie par la fonction du plug-in auth-passthrough disponible sous Sun GlassFish Enterprise Server Enterprise Edition 7.1. Cependant, dans Enterprise Server 2.1, la fonction du plug-in auth-passthrough est configurée différemment.

La fonction du plug-in auth-passthrough, sous Enterprise Server Enterprise Edition 7.1, était couramment utilisée pour les scénarios de déploiement à deux niveaux, où :

Dans de telles architectures réseau, un client se connecte à un serveur Web frontal préalablement configuré pour fonctionner avec la fonction de plug-in service-passthrough et transfère les requêtes HTTP à l'instance d' Application Server pour traitement via un proxy. Cette instance d'Application Server ne peut recevoir de requêtes que via le proxy du serveur Web mais ne peut pas en recevoir directement de la part d'hôtes clients. Par conséquent, toute application déployée sur l'instance d'Application Server qui envoie par proxy des requêtes pour obtenir des informations clientes (l'adresse IP du client par exemple) reçoit l'IP proxy de l'hôte par lequel la requête est relayée.

Solution

Sous Application Server Enterprise Edition 7.1, la fonction du plug-in auth-passthrough pouvait être configurée sur l'instance proxy d'Application Server afin de rendre les informations du client distant directement disponibles à toutes les applications déployées ; comme si l'instance avait directement reçu la requête au lieu de passer par un serveur Web intermédiaire avec l'exécution du plug-in service-passthrough.

Sous Enterprise Server 2.1, la fonction de auth-passthrough peut être activée en définissant la propriété authPassthroughEnabled de l'élément <http-service> dans domain.xml sur TRUE, comme suit :


<property name="authPassthroughEnabled" value="true"/>

Les mêmes considérations de sécurité de la fonction du plug-in auth-passthrough dans Application Server Enterprise Edition 7.1 s'appliquent à la propriété authPassthroughEnabled dans Enterprise Server 2.1. Comme authPassthroughEnabled permet d'écraser des informations pouvant être utilisées à des fins d'authentification (telle que l'adresse IP à partir de laquelle la requête a été lancée, ou le certificat client SSL), il est essentiel que seuls les clients ou serveurs de confiance soient autorisés à se connecter à une instance de Enterprise Server 2.1 avec authPassthroughEnabled défini sur TRUE. Par mesure de précaution, il est recommandé de ne définir la propriété authPassthroughEnabled sur TRUE que pour des serveurs protégés par le pare-feu d'entreprise. Un serveur accessible via Internet ne doit jamais être configuré avec authPassthroughEnabled défini sur TRUE.

Notez que dans le cas où le plug-in service-passthrough a été configuré sur un serveur Web proxy qui relaie les requêtes vers une instance de Enterprise Server pour laquelle la propriété authPassthroughEnabled a été définie sur TRUE, l'authentification cliente SSL peut être activée sur le proxy du serveur Web et désactivée sur celui de l'instance de Enterprise Server. Dans ce cas, l'instance de Enterprise Server utilisant un proxy continue de traiter les requêtes comme si elles étaient authentifiées via SSL et fournit un certificat SSL client aux applications déployées lorsque nécessaire.