test

Notes de version de Sun Java System Application Server Enterprise Edition 8.2 pour Microsoft Windows

Conteneur Web

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

Aucune prise en charge du plug-in de l'équilibreur de charge Apache et IIS

Sun Java ES 5 Application Server ne prend pas en charge Apache et IIS (conteneur Web non Sun) pour le plug-in d'équilibreur de charge. Sun Java ES installe Sun Java System Web Server pour la configuration du plug-in d'équilibreur de charge.

Le déploiement de l'application à l'aide des fichiers --precompilejsp=true peut verrouiller les fichiers JAR (ID 5004315)

Sur une plate-forme Windows, 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. 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. Ce scénario 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 de servlet 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 (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 activer ce paramètre de deux façons :

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. auth-passthrough 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. Étant donné que authPassthroughEnabled active le remplacement des informations susceptibles d'être utilisées à des fins d'authentification (telles que l'adresse IP d'où la requête a été émise ou le certificat client SSL). Par conséquent, seuls les clients ou serveurs de confiance doivent être autorisés à se connecter à une instance Application Server Enterprise Edition 8.2 avec authPassthroughEnabled défini sur TRUE. Par précaution, procédez à la configuration des serveurs uniquement derrière le pare-feu de la société, avec authPassthroughEnabled défini sur TRUE. 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.