Notes de version Sun Java System Application Server Platform Edition 8.2

Chapitre 3 Problèmes connus et restrictions

Cette section décrit les problèmes connus relatifs à Sun Java System Application Server Platform Edition 8.2 et présente les solutions associées. Si le récapitulatif ne mentionne aucune plate-forme particulière, cela signifie que le problème s'applique à toutes les plates-formes. Ces informations sont regroupées dans les sections cidessous:

Administration

Le script package-appclient ne fonctionne pas si domain1 n'existe pas. (ID 6171458)

Par défaut, une valeur à code permanent dans $INSTALL/lib/package-appclient.xml pour la variable AS_ACC_CONFIG de domain1 est pointée par asenv.conf. Si domain1 est supprimé et qu'un autre domaine est créé, la variable AS_ACC_CONFIG n'est pas mise à jour avec le nouveau nom de domaine, ce qui provoque l'échec du script package-appclient.

Solution

Effectuez l'une des tâches suivantes :

Impossible de restaurer un domaine enregistré sous un autre nom. (ID 6196993)

La mise en miroir d'un domaine sur la même installation d'Application Server peut être effectuée à l'aide des commandes backup-domain et restore-domain car le domaine ne peut pas être restauré sous un nom autre que celui d'origine, même si la commande asadmin restore-domain permet de renommer le domaine. L'attribution d'un nouveau nom au domaine enregistré semble avoir été correctement effectuée, mais les tentatives de démarrage de ce domaine n'aboutissent pas, car les entrées liées à la configuration du domaine n'ont pas été modifiées et les commandes startserv et stopserv utilisent toujours le nom de domaine d'origine pour définir les chemins.

Solution

Le nom de domaine utilisé pour restore-domain doit être le même que celui utilisé pour la commande d'origine backup-domain. Les commandes backup-domain et restore-domain d'Application Server 8.2 permettent de sauvegarder et de restaurer le même domaine sur le même ordinateur uniquement.

Le démarrage d'Application Server avec un JMX Agent supplémentaire n'est pas pris en charge. (ID 6200011)

J2SE 1.4.x, version 5.0 ou ultérieure, peut être configuré sur Application Server. La fonction de démarrage d'un agent JMX est intégrée à la plate-forme J2SE 5.0. Pour l'activer, il vous suffit de définir de manière explicite les propriétés système lors du démarrage du serveur.

Voici quelques exemples de valeurs:

name="com.sun.management.jmxremote" value="true"
name="com.sun.management.jmxremote.port" value="9999"
name="com.sun.management.jmxremote.authenticate" value="false"
name="com.sun.management.jmxremote.ssl" value="false"

Une fois les propriétés JMX configurées et le serveur démarré, un nouveau serveur jmx-connector est démarré dans Application Server VM. Un aspect négatif réside dans le fait que les fonctions d'administration sont affectées et que l'interface utilisateur et de ligne de commande d'administration d'Application Server peuvent renvoyer des résultats inattendus. Le problème provient du fait qu'il existe des conflits entre le serveur jmx connector intégré et le nouveau serveur jmx-connector.

Solution

Si vous utilisez la console jconsole (ou tout autre client compatible JMX), vous pouvez réutiliser le serveur JMX Connector Server standard exécuté au démarrage d'Application Server.

Lorsque le serveur démarre, une ligne similaire à celle indiquée ci-dessous s'affiche dans le journaldu serveur. Vous pouvez vous connecter à l'adresse JMXServiceURL et effectuer les mêmes opérations de gestion/configuration une fois les informations d'authentification indiquées. Par exemple :

[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1|javax.enterprise.
system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the 
JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/
rmi-jmx-connector]. This is where the remote administrative clients should 
connect using the JSR 160 JMX Connectors.|#]

Pour plus d'informations, reportez-vous au Sun Java System Application Server 8.2 Administration Guide.

Impossible de redéployer ou d'annuler le déploiement du module Web, module par défaut de tout serveur virtuel. (ID 6204799)

Si le module Web est désigné comme étant le module Web par défaut d'un serveur virtuel et que vous tentez de le redéployer ou d'annuler son déploiement, l'erreur suivante est retournée :

Trying to undeploy application from domain failed; Virtual Servers [server] 
have <WEB-MODULE-NAME\> as default web module. Please remove the default web
module references first. ; requested operation cannot be completed Virtual 
Servers [server] have <WEB-MODULE-NAME\> as default web module. Please
remove the default web module references first.

À ce stade, domain.xml constitue une erreur et la console d'administration peut ne pas afficher le tableau indiquant les applications Web déployées. Cette condition demeure même si le domaine est arrêté et redémarré.

Solution

Changez le module Web par défaut.

ProcedurePour changer le module Web par défaut

Étapes
  1. Via la console d'administration, accédez à la page du serveur virtuel et videz la valeur du module Web par défaut ou indiquez-en un autre.

  2. Via l'interface de ligne de commande, annulez le déploiement du module Web en indiquant domain comme cible.


    # asadmin undeploy --target domain <WEB-MODULE-NAME\>

    La console d'administration doit désormais s'afficher correctement et vous pouvez redéployer le module Web si vous le souhaitez.

Exception FrameworkError après le déploiement d'un serveur WAR et JAR en serveur PE via l'API AMX dans l'interface utilisateur d'Application Server. (ID 6201462)

Lorsqu'une application est déployée sur PE à l'aide de l'API AMX et qu'elle n'est pas référencée, l'interface utilisateur d'Application Server renvoie des erreurs lors de l'affichage de cette application. Vous devez gérer des références pour vos applications dans AMX . Par exemple, lorsqu'une application est déployée, DeployedItemRefConfig doit être créé. Pour simplifier le processus de déploiement, des références sont supposées exister dans PE, posant ainsi problème avec l'interface utilisateur d'Application Server.

Solution

Créez toujours la référence à une ressource une fois celle-ci créée.

Le paramètre d'accueil Java dans la configuration ne s'applique pas. (ID 6240672)

Les domaines/serveurs d'Application Server n'utilisent pas le kit JDK pointé par l'attribut java-home de l'élément de configuration associée java-config.

Solution

Le kit JDK utilisé par les processus d'Application Server pour tous les domaines d'un serveur donné est déterminé par le fichier appserver-installation-dir /config/asenv.conf. La propriété AS_JAVA incluse dans ce fichier détermine le kit JDK utilisé et est définie pendant l'installation. Si un autre kit JDK doit être utilisé par les processus d'Application Server une fois l'installation terminée, vous pouvez modifier cette valeur pour désigner un autre kit JDK. Notez que tous les domaines de cette installation seront concernés par la modification.


Remarque –

Les modifications manuelles apportées au fichier asenv.conf ne sont pas vérifiées pour validation ; apportez-les donc avec précaution. Consultez la documentation du produit pour connaître les exigences de version JDK minimales lorsque vous modifiez la valeur de AS_JAVA.


Selector.select() renvoie IOException . Échec de démarrage d'Application Server. (ID 6322825)

Dans le code JDK actuel, le sélecteur /dev/poll alloue un ensemble de 8192 entrées pollfd utilisées par le sélecteur. Ceci dépasse la valeur nofiles ulimit, entraînant donc un échec avec une erreur du type “invalid argument” (argument incorrect). Ceci entraîne alors un échec du service de socket d'Application Server connecté à MQ au démarrage et renvoie IOException car selector.select() est interrompu.

Solution

Augmentez la limite du descripteur de fichier pollfd. Deux méthodes sont possibles :

  1. Exécutez la commande ulimit -n 8193 sur le shell en tant que racine.

  2. Augmentez la limite permanente du nombre de descripteurs de fichiers à 8193 ou plus :

    1. Vérifiez la limite permanente à l'aide de la commande ulimit -n -H.

    2. Si la valeur est inférieure à 8193, modifiez le fichier /etc/system , en ajoutant la commande set rlim_fd_max=8193.

    3. Redémarrez l'ordinateur.

Échec de démarrage du domaine lorsque le mot de passe principal de création de domaine comporte des caractères spéciaux. (ID 6345947)

Le domaine ne démarre pas lorsque le mot de passe principal du domaine contient le caractère %.

Solution

Le mot de passe principal du domaine ne doit pas contenir de caractère %. Ceci s'applique à la création d'un nouveau domaine ou à la modification du mot de passe principal pour un domaine existant.

Des propriétés spécifiques de Java System ne sont pas gérées correctement au démarrage d'AS 8.2. (ID 6372759)

L'ajout des éléments suivants aux paramètres proxy JVM entraîne l'échec du démarrage du serveur :


<jvm—options>-Dhttp.proxyHost=webcache.east.sun.com</jvm—options>
<jvm—options> -Dhttp.proxyPort=8080</jvm—options>
<jvm—options>-Dhttp.nonProxyHosts="mssp.ctu.gov|*.ctu.gov|localhost"
</jvm—options>

L'insertion d'un caractère * renvoie une erreur No Class Def Found (Exception dans le thread main java.lang.NoClassDefFoundError: com/sun/enterprise/security/store/IdentityManager ). L'insertion d'un caractère | entraîne un délai d'attente du script de démarrage pour le démarrage du serveur.

Cette fonctionnalité est critique pour prendre en charge des déploiements d'Application Server (et de Portal) situés derrière un pare-feu et nécessite d'accéder aux serveurs externe et interne. Par exemple, Portal Server URL Scraper. Ces paramètres sont nécessaires pour permettre à URL Scraper de récupérer du contenu de sources externes.

Solution

Modifiez le fichier install-dir/config/asenv.conf, en remplaçant la ligne AS_NATIVE_LAUNCHER="true" par AS_NATIVE_LAUNCHER="false" .

Client d'application

Cette section décrit les problèmes connus des clients d'application et les solutions associées.

La bibliothèque JAR fournie avec les archives du client d'application écrase le fichier manifeste. (ID 6193556)

Si vous possédez un fichier JAR de niveau supérieur dans votre JAR client (dans notre cas, reporter.jar), le fichier manifeste de ce JAR écrase celui du JAR client lorsque vous déployez ce dernier.

Solution

Aucune pour l'instant.

La technologie de contenu dynamique comme CGI-bin et la fonctionnalité SHTML n'est pas prise en charge. (ID 6373043)

Les technologies de contenu dynamique, comme CGI-bin et SHTML, ne sont plus prises en charge.

Solution

Utilisez plutôt des technologies JSP et services Web.

Pilote de base de données

Cette section décrit les problèmes connus du pilote de base de données et les solutions associées.

La connexion de DB2 Server est croissante après un délai d'attente d'inactivité avec le pilote DB2 Type II (ID 2082209/5022904)

Après avoir migré des applications d'un autre serveur d'applications, des connexion physiques ne sont pas fermées correctement après le délai d'attente. Ce problème est observé avec la version DB2 8.1.x du pilote de bibliothèques client (Type II) par rapport à un même serveur de bases de données DB2 7.1.x.

Solution

Paramétrez une valeur identique pour SteadyPoolSize et MaxPoolSize et paramétrez le délai d'attente Idle Connection sur 0 (zéro) également. Le délai d'attente de connexions inactives est alors désactivé et l'utilisateur disposera de toutes les connexions disponibles.

Outil de déploiement

Cette section décrit les problèmes connus liés à l'outil de déploiement et les solutions associées.

L'outil de déploiement ne crée généralement pas d'éléments message-destination dans les descripteurs de déploiement Sun suivants (ID 6197393) :

Solution

Pour modifier un nom JNDI existant de destination des messages :

ProcedurePour modifier un nom JNDI existant

Étapes
  1. Supprimez le nom JNDI existant en laissant le champ texte correspondant vide et en appuyant sur Entrée.

  2. Saisissez le nouveau nom JNDI et appuyez sur Entrée.

  3. Vérifiez le descripteur Sun en cliquant sur Outils\>Afficheur de descripteur>Descripteur Application Server.

  4. Enregistrez l'application en cliquant sur Fichier>Enregistrer.

    Si le nom JNDI n'est pas enregistré pour le descripteur Sun :

  5. Redémarrez l'outil de déploiement.

  6. Dans l'onglet Destinations des messages, sélectionnez une destination ou ajoutez-en une nouvelle.

  7. Saisissez le nom JNDI de la destination des messages dans le champ texte correspondant spécifique à Sun, puis appuyez sur Entrée.

  8. Vérifiez le descripteur Sun en cliquant sur Outils\>Afficheur de descripteur>Descripteur Application Server.

  9. Enregistrez l'application en cliquant sur Fichier>Enregistrer.

    Répétez les étapes ci-dessus chaque fois qu'une valeur doit être saisie dans le champ du nom JNDI spécifique à Sun de l'onglet Destination des messages, sauf si une valeur a été saisie dans le champ texte du nom JNDI pendant une session d'outil de déploiement.

“Home” traduit de manière inappropriée comme “installation directory” dans l'outil de déploiement en chinois simplifié. (ID 6203658)

Lorsque vous créez un bean entreprise dans l'outil de déploiement et que vous accédez à l'onglet Transaction ou Sécurité du nœud bean, “Local Home” et “Remote Home” ne sont pas traduits correctement comme “Local Installation Directory” et “Remote Installation Directory.”

Documentation

Cette section décrit les problèmes détectés dans la documentation et les solutions associées.

Certains fonctionnalités de contrôle documentées ne s'appliquent pas à Platform Edition. (ID 6202255)

La documentation d'AMX (Application Server Management eXtenstions) ne mentionne pas certaines fonctionnalités de contrôle non disponibles dans Application Server Platform Edition 8.2. Plus particulièrement, les composants ne pouvant pas être contrôlés dans Platform Edition sont les suivants :

Solution

Aucune requise. Ces statistiques ne s'appliquent pas à Platform Edition.

AppservPasswordLoginModule référencé comme étant AbstractPasswordLoginModule dans la documentation (ID 6229682)

La section Realm Configuration du Sun Java System Application Server Platform Edition 8.2 Developer’s Guide, Chapitre 2, Securing Applications du Sun Java System Application Server Platform Edition 8.2 Developer’s Guide dans le Sun Java System Application Server Platform Edition 8.2 Developer’s Guide fait référence de manière incorrecte à com.sun.appserv.AbstractLoginModule. Cependant, cette classe est désormais appelée com.sun.appserv.AppservLoginModule.

Solution

Consultez com.sun.appserv.AppservLoginModule au lieu de com.sun.appserv.AbstractLoginModule.

Option courte -W incorrecte pour --passwordfile dans les pages de manuel 8.2 PE. (ID 6373588)

--passwordfile ne doit pas contenir d'option courte. -W --passwordfile est actuellement indiqué dans les pages de manuel. Ceci est incorrect.

Solution

N'utilisez pas l'option —W avec --passwordfile pour Application Server 8.2 Platform Edition. L'option courte sera ajoutée dans une version ultérieure d'Application Server.

Une documentation Javadoc est absente ou incorrecte pour plusieurs interfaces et méthodes AMX (plusieurs ID) :

Installation

Cette section décrit les problèmes connus liés à l'installation/désinstallation et les solutions associées.

Échec intermittent pour rendre le bouton de navigation Suivant accessible sur l'écran de bienvenue du programme d'installation et de désinstallation. (ID 4977191)

Ce problème a été signalé de manière intermittente sur la plate-forme Solaris x 86, mais il peut également concerner les plates-formes Solaris SPARC et Linux.

Le problème est tel que le premier écran installer\qs ou uninstaller\qs affiche correctement le texte complet et les boutons Aide et Annuler, mais le bouton Suivant nécessaire pour passer à l'écran suivant n'apparaît pas. Même si le bouton n'apparaît pas, la zone est active et si vous cliquez dessus, vous passez normalement à l'écran suivant. Un problème intermittent de retraçage de l'interface utilisateur J2SE en est la cause.

Solution

Une solution consiste à cliquer sur la zone située à gauche du bouton Suivant. Une autre solution consiste à forcer un retraçage de l'écran en le redimensionnant légèrement ou en réduisant la fenêtre du programme d'installation. Après retraçage, le bouton Suivant manquant apparaît.

Blocage lors de l'arrêt de l'installation sur certains systèmes Linux après avoir cliqué sur le bouton Terminer. (5009728)

Ce problème se produit sur plusieurs systèmes Linux. Il apparaît le plus souvent sur Java Desktop System 2, mais il a également été observé sur les distributions RedHat.

Lorsque vous cliquez sur le bouton Terminer du dernier écran, le programme d'installation ne parvient pas à ouvrir de fenêtre de navigation dans laquelle est affichée la page À propos de ou celle concernant l'enregistrement du produit. Il se bloque alors pour une période indéterminée, sans renvoyer d'invite de commande.

Solution

Quittez le programme d'installation en appuyant sur Ctrl+C dans la fenêtre à partir de laquelle le programme d'installation a été lancé. Ceci devrait lancer l'affichage de la page À propos de ou de la page concernant l'enregistrement du produit dans la fenêtre du navigateur. Si ce n'est pas le cas, lancez le navigateur et saisissez l'URL suivant afin de vérifier la page À propos de :

file://install_dir/docs/about.html

Si vous avez également sélectionné l'option d'enregistrement du produit lors de l'installation, suivez le lien vers la page d'enregistrement disponible sur la page À propos de.

Problèmes de détection et d'initialisation intermittents de J2SE dans le wrapper d'installation sur Linux. (6172980)

L'exécutable setup qui lance le programme d'installation Linux est parfois interrompu. Plutôt que de résoudre l'emplacement de J2SE et de lancer l'assistant d'installation, le wrapper est interrompu et renvoie les messages suivants :

Chcking available disk space....
Checking Java(TM) 2 Runtime Environment....
Extracting Java(TM) 2 Runtime Environment....
Deleting temporary files.....

Ce problème n'est rencontré que dans certaines versions de Linux et semble dépendre des paramètres d'environnement, notamment la présence de la variableJAVA_HOME.

Solutions

Pour résoudre ce problème :

ProcedurePour résoudre les problèmes d'initialisation sur Linux

Étapes
  1. Annulez le paramétrage de la variable JAVA_HOME en exécutant unset ou unsetenv en fonction de votre shell.

  2. Exécutez setup avec l'option -javahome pour spécifier la variable JAVA_HOME utilisée par le programme d'installation.

Gestion du cycle de vie

Cette section décrit les problèmes connus de gestion du cycle de vie et les solutions associées.

Après avoir paramétré la propriété ejb-timer-service minimum-delivery-interval sur 9000, une tentative de paramétrage de la propriété ejb-timer-service redelivery-interval-in-mills sur 7000 entraîne un échec de la commande set et renvoie l'erreur suivante : (ID 6193449)

[echo] Doing admin task set
[exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery-
Interval (7,000) should be greater than or equal to Minimum-delivery-
interval-in-millis (9,000)]
[exec] CLI137 Command set failed.

Solution

Utilisez les valeurs par défaut suivantes :

minimum-delivery-interval(default)=7000
redelivery-interval-in-millis(default)=5000

Toute autre valeur provoquera une erreur.

Enregistrement

Cette section décrit les problèmes connus de consignation et les solutions.

Le paramétrage de l'instruction de débogage pour access.failure entraîne une interruption du démarrage d'Application Server. (ID 6180095)

Le paramétrage de l'option java.security.debug pour JVM entraîne un blocage du démarrage de l'instance du serveur. Ce problème se produit, par exemple, lorsque vous définissez les paramètres ci-dessous dans le fichier domain.xml.

<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>

Solution

Aucune pour l'instant. Évitez de paramétrer cet indicateur.

Exemples d'applications

Cette section décrit les problèmes connus liés au code de l'exemple compris dans le produit Application Server 8.2 ainsi que les solutions associées.

L'exemple managementws doit mettre à jour des références MANIFEST.MF de castor-0.9.3.9-xml.jar en castor-0.9.9.1.jar. (ID 6363339)

Lorsque vous exécutez le vérificateur sur <install_dir>/samples/webservices/jaxrpc/apps/managementws , les avertissements suivants sont retournés :


[exec] WARNING: /var/tmp/exploded20051214111425/managementws/ \
managementwsEjb_jar contains library/castor-0.9.3.9-xml.jar in Class-Path 
manifest attribute, but it is not found in ear file
[exec] Dec 14, 2005 11:14:30 AM Archive getBundledArchives
[exec] WARNING: /var/tmp/exploded20051214111425/managementws/ \
managementwsEjb_jar contains library/castor-0.9.3.9-xml.jar in Class-Path
manifest attribute, but it is not found in ear file

Le fichier Castor jar a été mis à jour dans la version Application Server 8.2. Toutes les références à l'ancien fichier castor-0.9.3.9-xml.jar doivent donc être changées pour pointer sur le nouveau fichier castor-0.9.9.1.jar. Plus particulièrement, vous devez modifier les références dans les fichiers MANIFEST.MF pour utiliser le fichier castor-0.9.9.1.jar au lieu de l'ancien fichier castor-0.9.3.9-xml.jar .

Solution

Modifiez les références suivantes à l'ancien fichier Castor jar pour pointer sur le nouveau fichier Castor jar :

Ancien :


src/conf/MANIFEST.MF:Class-Path: library/castor-0.9.3.9-xml.jar
src/conf/MANIFEST.MF:Name: library/castor-0.9.3.9-xml.jar
managementws-ejb/src/conf/MANIFEST.MF:Class-Path: \
library/castor-0.9.3.9-xml.jar

Nouveau :


src/conf/MANIFEST.MF:Class-Path: library/castor-0.9.9.1.jar
src/conf/MANIFEST.MF:Name: library/castor-0.9.9.1.jar
managementws-ejb/src/conf/MANIFEST.MF:Class-Path: \
library/castor-0.9.9.1.jar

Nettoyez ensuite le fichier build.xml afin qu'il ne copie pas le fichier Castor .jar dans install_dir /lib pendant le déploiement et supprimez-le pendant l'annulation du déploiement. Ce qui suit représente les différences entre l'ancien et le nouveau fichier build.xml.

% cvs diff build.xml Index: build.xml
===================================================================
RCS file: /m/jws/samples/samples8x/webservices/jaxrpc/apps/managementws/ \
managementws-standalone-client/ Attic/build.xml,v retrieving revision \
1.1.2.3
diff -r1.1.2.3 build.xml
80,89d79
<   <target name="remove_castor_from_classpath">
<       <delete file="${com.sun.aas.installRoot}/lib/castor-0.9.9.1.jar"/>
<   </target>
<   <target name="add_castor_to_classpath">
<       <delete file="${com.sun.aas.installRoot}/lib/castor-0.9.9.1.jar"/>
<       <copy file="../lib/castor-0.9.9.1.jar" \
            todir="${com.sun.aas.installRoot}/lib" />
<   </target>
<
<   <target name="setup" depends="add_castor_to_classpath, restart.server"/>
<  jbenoit/galapago 196 >pwd
/net/galapago.east/files/share/8.2ws/samples/samples8x/webservices/jaxrpc \
/apps/managementws/managementws-standalone-client
jbenoit/galapago 197 >cd ..
jbenoit/galapago 198 >cvs diff build.xml
Index: build.xml
===================================================================
RCS file: /m/jws/samples/samples8x/webservices/jaxrpc/apps/managementws/ \
Attic/build.xml
v retrieving revision 1.1.2.4
diff -r1.1.2.4 build.xml
28,36d27
<   <target name="setup">
<       <ant antfile="build.xml" inheritAll="true" dir="${sample.name}$ \
{standalone-client-dir-suffix}" target="setup"/>
<   </target>
<   
<   <target name="unsetup">
<       <ant antfile="build.xml" inheritAll="true" dir="${sample.name}$ \
{standalone-client-dir-suffix}" target="remove_castor_from_classpath"/>
<   </target> 
<
<
53,54c44,45
<   <target name="deploy"   depends="select_binary_common, deploy_common, 
    setup" />
<   <target name="undeploy" depends="init,  undeploy_common, unsetup"/>
---
>   <target name="deploy"   depends="select_binary_common, deploy_common" />
>   <target name="undeploy" depends="init,  undeploy_common"/>

Sécurité

Cette section décrit les problèmes connus de sécurité et les solutions.

Le conteneur WS security: appclient n'est pas correctement intégré au temps d'exécution client JAXRPC. (ID 6325469)

L'application client ne transmet pas le nom d'utilisateur et le mot de passe à un autre client de services Web.

Solution

Transférez la combinaison nom d'utilisateur/mot de passe, si nécessaire, au programme client comme suit :

((Stub)yourWSPort)._setProperty(Stub.USERNAME_PROPERTY, "yourUsername");
((Stub)yourWSPort)._setProperty(Stub.PASSWORD_PROPERTY, "yourPassword");

Utilitaire de mise à niveau

Cette section décrit les problèmes connus de l'utilitaire de mise à niveau et les solutions associées.

Les domaines créés dans custom-path autres que le répertoire install_dir /domains ne sont pas directement mis à niveau pendant une mise à niveau de Application Server Platform Edition 8 en Application Server Platform Edition 8.2. (ID 6165528)

Lors de l'exécution de l'utilitaire de mise à niveau et de l'identification de install_dir comme répertoire d'installation source, seuls les domaines créés sous le répertoire install_dir/domains sont mis à niveau par le processus de mise à niveau. Les domaines créés à d’autres emplacements ne sont pas mis à niveau.

Solution

Avant de lancer le processus de mise à niveau, copiez tous les répertoires de domaine à leurs emplacements respectifs pour les placer dans le répertoire install_dir/domains.

Conflit de port lors du démarrage du domaine domain1 ou samples après une mise à niveau de 8.0 Platform Edition en 8.2 Platform Edition. (ID 6202188)

Après la mise à niveau d'un Application Server 8.0 comprenant plusieurs domaines, ces derniers peuvent ne pas démarrer simultanément en raison d'un numéro de port identique configuré pour le connecteur JMX.

Solution

Changez la valeur du port.

ProcedurePour changer la valeur du port

Étapes
  1. Vérifiez l'entrée suivante du fichier install dir /domains/domain1/config/domain.xml :


    <jmx-connector accept-all="false" address="0.0.0.0" auth-realm-name=
    "admin-realm" enabled="true" name="system" port="8686" protocol="rmi_jrmp" 
    security-enabled="false"/\>" -- and in file <as 8.1 install dir\>
    /domains/domain1/samples/config/domain.xml, notice it used the same port 
    "8686", so it failed to start domain due to port conflict.
  2. Remplacez la valeur du port 8686 par 8687, puis redémarrez domain1.

Le programme d'installation exécutant une mise à niveau en place ne démarre pas l'outil de mise à niveau sur certains Linux après avoir cliqué sur le bouton Démarrer l'assistant de mise à niveau. (6207337)

Ce problème a été observé sur plusieurs systèmes Linux. Bien qu’il soit plus fréquent sur Java Desktop System 2, il se produit également sur des distributions RedHat.

Après avoir cliqué sur le bouton Démarrer l'outil de mise à niveau qui se trouve sur l'écran final du programme d'installation, l'outil de mise à niveau n'est pas lancé et le programme d'installation se bloque pendant une période indéterminée, sans renvoyer d'invite de commande.

Solution

Ce problème ne survient pas lorsque le mode d’installation ligne de commande est utilisé pour procéder à la mise à niveau à son emplacement.

ProcedurePour utiliser le mode d'installation ligne de commande

Étapes
  1. Si vous effectuez la mise à niveau à son emplacement en mode d’interface graphique (IG) et que le problème se produit, quittez le programme d’installation en appuyant sur les touches Ctrl+C dans la fenêtre de terminal dans laquelle le programme d’installation a été démarré.

  2. Démarrez l'outil de mise à niveau à partir de la fenêtre du terminal en utilisant la commande suivante:


    install_dir/bin/asupgrade --source install_dir/domains --target install_dir 
    --adminuser adminuser--adminpassword adminpassword --masterpassword changeit

    Les valeurs adminuser et adminpassword doivent correspondre à celles utilisées pour l'installation que vous mettez à niveau.

  3. Une fois le processus de mise à niveau terminé, vous pouvez également démarrer votre navigateur Web et saisir l'URL suivant afin d'afficher la page À propos de :

    file://install_dir/docs/about.html

    Si vous avez également sélectionné l'option d'enregistrement du produit lors de l'installation, suivez le lien vers la page d'enregistrement disponible sur la page À propos de.

Des caractères altérés s'affichent dans le panneau de résultats après la mise à niveau (ID 6376140)

Lors d'une mise à niveau de la version multilingue de Application Server 8.2 vers une version ultérieure utilisant plusieurs langues, le panneau de résultats ainsi que le fichier /opt/SUNWappserver/domains/upgrade.log risquent d'afficher des caractères altérés.

Solution

Aucune pour l'instant. Ce problème sera résolu dans une version ultérieure de Application Server.

Conteneur Web

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

Le déploiement d'une application utilisant --precompilejsp=true peut verrouiller des fichiers JAR de l'application, entraînant ainsi l'échec d'une future annulation du déploiement ou d'un futur redéploiement (Windows uniquement). (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'utilitaireasadmin, mais que le répertoire application\qs et les fichiers jar verrouillés ne sont pas supprimés du serveur. Le fichier journal server\qs contient les messages décrivant l'échec de la suppression des fichiers et du répertoire application\qs.

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 application\qs.

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\qt be deleted

Solutions

Ce problème ne surviendra pas si vous spécifiez --precompilejsps=false (valeur par défaut) lorsque vous déployez une application. Sachez que, lors de sa première utilisation, l’application déclenche la compilation des pages JSP. C'est pourquoi 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 WAR avec web.xml basé sur Servlet 2.4 contenant 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 application\qs 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 "Unable to execute command" 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:

Détérioration des performances sur des ordinateurs multi-CPU. (ID 6194026)

La configuration par défaut d'Application Server PE n'est pas optimale sur des ordinateurs multi-CPU. Un compromis est appliqué pour que le démarrage soit plus rapide, mais ceci peut affecter les performances d'applications Web.

Solution

Configurez Application Server de façon à définir la propriété JVM suivante :

-Dcom.sun.enterprise.server.ss.ASQuickStartup=false

Des documents Fast Infoset malformés reçus peuvent désactiver la prise en charge de Fast Infoset pour des services déployés JAX-RPC. (ID 6368670)

Si un message SOAP codé en Fast Infoset non conforme est envoyé à un service JAX-RPC, le service sera alors à juste titre défaillant en réponse. Cependant, d'autres messages SOAP codés en Fast Infoset conformes envoyés au même service ou à un service déployé avec le même temps d'exécution JAX-RPC peuvent être défaillants de manière inappropriée.

Solution

Les solutions suivantes sont possibles :