Notes de version Sun Java System Application Server Enterprise Edition 8.1 2005Q2

Conteneur Web

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

ID du bogue 

Résumé 

5004315 

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.

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. 

6172006 

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.

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, 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.

6184122 

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

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: 

  • De façon globale, en définissant le paramètre fork init de JspServlet inclus dans le fichier ${S1AS_HOME}/domains/domain1/config/default-web.xml sur false :


    <servlet> <servlet-name>jsp</servlet-name>
    <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> 
    .... <init-param>
    <param-name>fork</param-name> <param-value>false</param-value> 
    </init-param> .... </servlet>
  • De façon ponctuelle, en définissant la propriété de configuration JSP fork incluse dans le fichier sun-web.xml sur false :


    <sun-web-app> <jsp-config> <property name="fork" value="false" /> 
    </jsp-config> </sun-web-app>

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

6188932 

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

La fonction de plug-in auth-passthrough disponible dans Sun Java System serveur d'application Environment Enterprise 7.1 est prise en charge par Sun Java System serveur d'application Environment Enterprise 8.1 2005Q2 Update 2. Elle est cependant configurée différemment dans serveur d'application Environment Enterprise 8.1 2005Q2 Update 2.

La fonction de plug-in auth-passthrough de serveur d'application Environment Enterprise 7.1 a été utilisée pour des scénarios de déploiement dans les architectures à deux niveaux où :

  • L'instance d'Application Server est non seulement protégée par un pare-feu d'entreprise mais également par un second pare-feu.

  • Aucune connexion cliente directe à l'instance d'Application Server n'est autorisée.

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 serveur d'application Environment Enterprise 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 serveur d'application Environment Enterprise 8.1 2005Q2 Update 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 serveur d'application Environment Enterprise 7.1 s'appliquent de la même manière à la propriété authPassthroughEnabled dans serveur d'application Environment Enterprise 8.1 2005Q2 Update 2. La propriété authPassthroughEnabled permettant d'ignorer des informations qui peuvent être utilisées à des fins 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 serveur d'application Environment Enterprise 8.1 2005Q2 Update 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.