test

Notes de version de Sun Java System Application Server Enterprise Edition 8.2

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 la commande --precompilejsp=true peut verrouiller les fichiers JAR de l’application, entraînant l’échec des redéploiements et annulations de déploiement ultérieurs. (ID 5004315)

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 le composant Servlet 2.4 comprenant un élément <load-on-startup> vide. (ID 6172006)

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, 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. (ID 6184122)

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:

Ces deux paramètres empêcheront ant de générer dynamiquement un nouveau processus pour la compilation javac.

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

La fonction de plug-in auth-passthrough disponible dans Sun Java System Application Server Enterprise Edition 8.2 7.1 est prise en charge par Sun Java System Application Server Enterprise Edition 8.2. Elle est cependant configurée différemment dans Sun Java System Application Server Enterprise Edition 8.2.

La fonction de plug-in auth-passthrough de Application Server Enterprise Edition 7.1 a été utilisée pour des scénarios de déploiement dans les architectures à 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.

Dans Application Server Enterprise Edition 7.1, la fonction de plug-in auth-passthrough peut être configurée sur l'instance d'Application Server utilisant un proxy afin de rendre directement disponibles les informations de clients distants pour n'importe quelle application déployée sur le serveur d'applications. Tout se passe alors comme si l'instance d'Application Server recevait la requête directement au lieu de la recevoir par l'intermédiaire d'un serveur Web exécutant le plug-in service-passthrough.

Dans Application Server Enterprise Edition 8.2, la fonctionnalité auth-passthrough peut être activée en définissant la propriété authPassthroughEnabled de l'élément <http-service> du fichier domain.xml sur true comme suit :


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

Les dispositions de sécurité concernant la fonction de plug-in auth-passthrough de Application Server Enterprise Edition 7.1 s'appliquent de la même manière à la propriété authPassthroughEnabled dans Application Server Enterprise Edition 8.2. La propriété authPassthroughEnabled permettant d'ignorer des informations qui peuvent être utilisées à des fin d'authentification (adresse IP depuis laquelle la requête d'origine a été émise, certificat SSL du client, etc.), il est impératif de faire en sorte que seuls des clients ou des serveurs de confiance soient autorisés à se connecter à une instance Application Server Enterprise Edition 8.2 en ayant défini la propriété authPassthroughEnabled 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. Pour un serveur accessible par Internet, la propriété authPassthroughEnabled ne doit jamais être définie sur TRUE.

Il est à noter 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 d'Application Server 8.1 Update 2 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 d'Application Server 8.1 Update 2. Dans ce cas, l'instance d'Application Server 8.1 Update 2 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.

Le listener HTTP créé avec l'indicateur --enabled=false ne désactive pas le listener. (ID 6190900)

Lorsqu'un httplistener est créé avec l'indicateur --enabled=false , le listener n'est pas désactivé. L'indicateur --enabled n'a aucune incidence lorsqu'il est utilisé pendant la création du listener.

Solution

Créez le listener à l'état activé, puis désactivez-le manuellement ultérieurement.

Échec du redéploiement sous Windows car la commande verify_file_user_exists_common n'est pas exécutée. (ID 6490227)

Sous Windows, lors du redéploiement d'une application créant un utilisateur avant le déploiement, la commande create-file-user échoue car la commande verify_file_user_exists_common n'est pas exécutée (lorsqu'elle est appelée) et n'indique pas que l'utilisateur existe déjà. L'exécution de la cible deploy est suspendue à ce stade et le déploiement ou l'annulation du déploiement échoue.

Solution

Supprimez tout d'abord le ou les utilisateurs de fichiers à l'aide de la cible keydel, puis réexécutez la cible deploy :


asant keydel
asant deploy