Ce chapitre décrit les problèmes connus ainsi que les solutions correspondantes pour le logiciel Sun Java System Application Server 9.1. Si aucune plate-forme particulière n'est spécifiée, le problème s'applique à toutes les plates-formes. Ces informations sont regroupées dans les sections ci-dessous :
Cette section traite des problèmes connus liés à l'administration et les solutions associées.
Par défaut, $INSTALL/lib/package-appclient.xml contient une valeur codée en dur pour la variable AS_ACC_CONFIG de domain1 pointé 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.
Effectuez l'une des opérations suivantes :
Conservez domain1 intact et créez vos propres domaines en tenant compte de celui-ci.
Supprimez domain1 et remplacez la valeur codée en dur de domain1 dans $INSTALL/lib/package-appclient.xml par le nouveau nom de domaine.
Cette procédure devra être effectuée à chaque création d'un nouveau domaine si domain1 n'est pas présent.
La mise en miroir d'un domaine sur la même installation d'Application Server ne peut pas être effectuée à l'aide des commandes backup-domain et restore-domain car il est impossible de restaurer ce domaine en utilisant un autre nom que celui d'origine, même si la commande asadmin restore-domain propose une option de renommage. L'attribution d'un nouveau nom au domaine sauvegardé 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.
Le nom de domaine utilisé pour restore-domain doit être identique à celui utilisé pour la commande d'origine backup-domain. Les commandes backup-domain et restore-domain sur Application Server 8.1 peuvent uniquement être utilisées pour sauvegarder et restaurer le même domaine sur la même machine.
La version J2SE1.4.x, 5.0 ou version ultérieure peut être configurée sur Application Server. La fonction de démarrage d'un agent JMX est intégrée à la plate-forme J2SE 5.0. Un agent est activé lorsque vous définissez explicitement 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 la machine virtuelle d'Application Server. L'un des effets secondaires non désirés de cette opération est que celle-ci nuit aux fonctions d'administration ; la console d'administration d'Application Server et l'interface de ligne de commande peuvent alors produire 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.
Si vous utilisez jconsole (ou tout autre client JMX-compliant), pensez à réutiliser le serveur de connecteurs JMX standard lancé 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'URL JMXService spécifié et exécutez les mêmes opérations de configuration/gestion après avoir fourni des données d'authentification correctes ; 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 manuel Sun Java System Application Server 9.1 Administration Guide .
Si vous exécutez la commande asadmin restore-domain lorsque vous êtes connecté en tant qu'utilisateur A, les scripts seront dotés des autorisations 744 (rwxr--r--
). Si vous tentez par la suite de démarrer ou d'arrêter un domaine en tant qu'utilisateur B, l'opération risque d'échouer (même si B désigne l'utilisateur root), car les scripts ne peuvent être exécutés que par l'utilisateur A.
Modifiez les autorisations des scripts :
chmod 755 appserv/domains/domain-name/bin/* |
Lors de la configuration de l'équilibreur de charge avec une application dotée d'un module EJB qui exporte l'URL d'un service Web, la racine du contexte du service Web ne figure pas dans le fichier loadbalancer.xml en résultant.
Modifiez le fichier loadbalancer.xml de manière à ajouter le module Web manquant comme suit :
<web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/> |
Remplacez la valeur context-root-name par le nom de la racine de contexte du service Web présenté comme EJB.
Renommez le script existant <as_install> /bin/asant en asant.bak.
Copiez le fichier asant.template de <as_install> /lib/install/templates/ee (pour la version SE/EE) dans le répertoire <as_install>/bin/ et renommez-le en asant.
Modifiez le script copié <as_install> /bin/asant, en remplaçant le jeton %CONFIG_HOME% par <as_install>/config.
En cas de modifications manuelles apportées au fichier asant.bak , fusionnez-les dans le nouveau script asant.
Le fichier .asadmintruststore n'est pas présenté dans la documentation d'Application Server. Si ce fichier n'existe pas dans le répertoire home de l'administrateur, vous pouvez rencontrer de graves bogues lors de la mise à niveau d'applications hébergées sur le serveur.
Si possible, la commande asadmin start-domain domain1 doit être exécutée par l'utilisateur qui a installé le serveur.
Dans le cas contraire, le fichier .asadmintruststore doit être déplacé ou copié du répertoire home de l'utilisateur qui a procédé à l'installation dans le répertoire home de l'utilisateur qui l'exécute.
Notez que si le fichier est déplacé (et non copié) du répertoire home de l'utilisateur "installateur" dans le répertoire home de l'utilisateur "exécuteur", vous pouvez rencontrer des problèmes de mise à niveau de l'application, tels que décrits dans les bogues 6309079, 6310428 et 6312869 car l'utilisateur de mise à niveau/installation (généralement root dans Java ES) ne disposera plus du fichier .asadminstruststore dans son répertoire home.
Le mode d'intégration MQ par défaut d'une instance clusterisée d'Application Server est LOCAL. Lorsqu'Application Server est installé dans un emplacement (PATH) long (c'est-à-dire « non court »), imqbrokerscv.exe s'arrête brutalement au démarrage de l'instance clusterisée. Le problème provient d'une allocation de mémoire incorrecte dans imqbrokersvc.
Il est nécessaire de modifier le type de service JMS pour l'instance clusterisée, de la valeur par défaut LOCAL sur REMOTE. Avec cette configuration, toutes les instances pointent vers le courtier DAS. Suivez les instructions ci-dessous pour configurer un cluster en mode REMOTE.
Avec le mode REMOTE, toutes les instances n'utilisent qu'un seul courtier (DAS), par conséquent aucun cluster de courtier n'est créé au démarrage du cluster d'Application Server. Pour plus d'informations, reportez-vous à la section Auto-clustering de la section 4.1, division iii de la page unique sur http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/as-mq-integration-gfv2.txt. La fonctionnalité susmentionnée ne sera pas disponible.
Modifiez le port et le fichier de mots de passe selon votre environnement. Notez que dans les instructions ci-dessous, le nom du cluster est racluster, le port d'administration DAS est 5858 et le port JMS DAS 7676 .
Modifiez la configuration du cluster, en changeant le type JMS sur REMOTE .
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.type=REMOTE |
Créez un hôte JMS correspondant à l'hôte JMS DAS.
$AS91_HOME/bin/asadmin.bat create-jms-host --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file --target racluster --mqhost localhost --mqport 7676 \ --mquser admin --mqpassword admin dashost |
Définissez l'hôte JMS DAS créé à l'étape précédente comme le nouvel hôte JMS par défaut.
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.default-jms-host=dashost |
Accédez à Configurations->nom_cluster-config->Java Message Service->Hôtes JMS.
Cliquez sur Nouveau pour créer un nouvel hôte JMS ; nommez-le dashost.
Entrez les paramètres de configuration correspondant au service JMS pour le DAS ; les valeurs par défaut sont les suivantes :
Nom d'hôte : localhost
Port : 7676
Utilisateur administrateur : admin
Mot de passe : admin
Modifiez ces paramètres au besoin pour votre service JMS DAS.
Retournez à l'onglet Java Message Service, puis modifiez le type de service JMS sur REMOTE (défini sur LOCAL par défaut).
Choisissez dashost à partir de la liste déroulante default-jms-host.
Enregistrez vos modifications, puis démarrez votre agent de nœud ou votre cluster.
Lorsque vous essayez d'afficher un diagramme de la page de contrôle des statistiques de journalisation à l'aide d'un navigateur non pris en charge, le message d'erreur suivant peut s'afficher :
Error loading jmaki.widgets.jmaki.charting.line.Widget : id=form1:jmaki_chart11 Script: http://easqelx5.red.iplanet.com:4848/resources/jmaki/charting/ \ line/component.js (line:5437). Message: area.initialize is not a function |
Utilisez un navigateur pris en charge. Reportez-vous à la section Navigateurs pour obtenir la liste des navigateurs pris en charge par Application Server 9.1.
Dans les trois dernières versions principales d'Application Server, le port d'administration par défaut a été modifié. De manière plus spécifique, les ports d'administration par défaut dans 7.x, 8. x et 9.x sont les suivants :
AS 7.x : 4848
AS 8.x : 4849
AS 9.x : 4848
Il ne s'agit pas d'un bogue mais d'un fait à prendre en compte. Le port d'administration par défaut est simplement une recommandation. Nous pensons d'ailleurs que les prochaines versions d'Application Server conserveront le port 4848.
Cette section décrit les problèmes connus relatifs au serveur Web Apache et au plug-in de l'équilibreur de charge et présente les solutions associées.
Lors de la compilation et de la création de openssl, exécutez les commandes suivantes :
cd openssl-0.9.7e
config
make
En outre, avec Apache 1.3, le nom du répertoire de la source mod_ssl varie en fonction de la version d'Apache utilisée. Par exemple, pour Apache 1.3.33, le nom est mod_ssl-2.8.22-1.3.33.
Pour exécuter la sécurité Apache, vous devez utiliser un certificat. Pour obtenir des instructions sur l'obtention d'un certificat auprès d'une autorité de certification, consultez les informations sur les certificats à l'adresse modssl FAQ.
Sous Solaris, si Application Server a été installé par un utilisateur root, vous devez démarrer le serveur Web Apache en vous connectant en tant qu'utilisateur root. Les installations Java Enterprise System sont effectuées par des utilisateurs root. Avec Apache 2.0, après avoir démarré sous une connexion d'utilisateur root, il bascule et s'exécute sous la connexion utilisateur que vous avez définie. Vous pouvez définir cet utilisateur dans le fichier /conf/httpd.conf. Pour démarrer le serveur en tant qu'utilisateur root, sur la plupart des systèmes, vous devez modifier le fichier httpd.conf afin de définir le groupe approprié. Remplacez la ligne :
Group #-1
avec
Group nobody
Vous trouverez d'autres informations sur les utilisateurs et les groupes dans le fichier httpd.conf.
Cette section décrit les problèmes connus des clients d'application et les solutions associées.
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.
Aucune pour l'instant.
Le client d'application essaie toujours de se connecter à localhost:3700. Le problème vient du fait que plusieurs propriétés système doivent être lues avant que le code client ne soit invoqué.
Définissez les éléments suivants en tant que propriétés système (-D dans votre JAVA_CMD). Ne les définissez pas dans votre code client d'application :
org.omg.CORBA.ORBInitialHost = server_instance_host org.omg.CORBA.ORBInitialPort = server_instance_port |
Sous Linux 64 bits, l'exception suivante est générée au démarrage d'un domaine. sunpkcs11.jar est manquant sous jdk1.5.0_11/jre/lib/ext/.
Il s'agit d'un bogue JDK connu avec Linux 64 bits ; celui-ci sera corrigé dans JDK 1.5.0_13.
Lorsqu'un SocketChannel est enregistré sur plusieurs sélecteurs, socketChannel.keyFor(lastRegisteredSelector) retourne une valeur null au lieu de SelectionKey.
Ce problème est associé au bogue JDK 6562829 et devrait être résolu dans 6.0 U3. Une solution a été incluse dans Application Server 9.1 pour que le sélecteur soit déployé avant que l'API keyFor ne soit appelée. Cela permet à keyFor de fonctionner jusqu'à ce que le bogue JDK soit résolu.
Cette section décrit les problèmes connus du pilote Sun JDBC intégré et les solutions associées.
Si une application génère plus de 3000 objets PreparedStatement dans une transaction, l'erreur suivante peut se produire avec DB2 :
[sunm][DB2 JDBC Driver] No more available statements.Please recreate your package with a larger dynamicSections value.
Ajoutez les propriétés suivantes à la définition de pool de connexions afin que le pilote puisse rééditer les liens des packages DB2 avec une valeur dynamicSections supérieure :
createDefaultPackage=true replacePackage=true dynamicSections=1000
Reportez-vous au manuel Sun Java System Application Server 9.1 Administration Guide pour obtenir des détails sur la configuration des pools de connexions.
En liaison avec l'erreur PrepardStatement mentionnée ci-dessus, le message d'erreur suivant peut également être généré :
[sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available.
Augmentez la valeur du paramètre de configuration APPLHEAPSZ pour le serveur DB2. 4096 constitue une valeur correcte.
Niveau d'isolement TRANSACTION_SERIALIZABLE. Si votre application utilise le niveau d'isolement TRANSACTION_SERIALIZABLE avec l'un des paramètres indiqués ci-dessus, elle peut rester bloquée en tentant d'obtenir la connexion.
Pour définir le niveau d'isolement d'une connexion, le pool de connexions correspondant doit être créé sur le même niveau d'isolement. Reportez-vous au manuel Sun Java System Application Server 9.1 Administration Guide pour obtenir les instructions correspondantes.
La base de données Java DB intégrée n'est pas automatiquement redémarrée après le redémarrage d'un système hôte ou d'une zone Solaris, ou le démarrage d'Application Server. Il ne s'agit pas d'un bogue mais du comportement attendu pour toute application tiers ou intégrée. Le problème réside dans le fait que Java DB doit être démarrée avant l'instance d'Application Server.
Après le redémarrage de la machine hôte ou de la zone Solaris, assurez-vous de démarrer Java DB avant Application Server ; par exemple :
/opt/SUNWappserver/appserver/bin/asadmin start-database |
Reportez-vous à la section "Application Server Administration Tools" du manuel "Sun Java System Application Server 9.1 Quick Start Guide" pour obtenir de plus amples informations sur les options de la commande asadmin.
Cette section décrit les problèmes détectés dans la documentation et les solutions associées.
Une documentation Javadoc est absente ou incorrecte pour plusieurs interfaces et méthodes AMX :
Les méthodes liées au mécanisme d'obtention des statistiques NumConnAcquired et NumConnReleased ne figurent pas dans ConnectorConnectionPoolStats et AltJDBCConnectionPoolStats. Ces méthodes vont être ajoutées dans une version ultérieure en tant que getNumConnAcquired() et getNumConnReleased().
L'appel des méthodes suivantes dans EJBCacheStats renvoie une exception : getPassivationSuccesses(), getExpiredSessionsRemoved(), getPassivationErrors(), getPassivations(). Ce problème sera résolu dans une version ultérieure.
Une fois le serveur démarré, les MBeans AMX nécessitent plusieurs secondes avant d'être tous enregistrés et disponibles. Il vous sera bientôt possible, dans une version ultérieure, de déterminer le moment où les MBeans AMX seront complètement chargés.
La constante XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR est mal orthographiée ("NNN"). Ce problème sera corrigé dans une version ultérieure.
L'exception suivante est générée dans le thread principal "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher.
Il est conseillé de ne pas utiliser l'outil ANT intégré ailleurs que dans Application Server.
Cette section décrit les problèmes connus de base de données haute disponibilité (HADB) et les solutions associées.
Sous Solaris SPARC, les bases de données HADB configurées avec double réseau fonctionnent parfaitement sur deux sous-réseaux. Cependant, du fait de problèmes au niveau du système d'exploitation ou des pilotes réseau sur certaines plates-formes matérielles, les plates-formes Solaris x86 et Linux ne gèrent pas toujours correctement les doubles réseaux. Cela crée les problèmes suivants pour la base de données HADB:
Sous Linux, certains processus HADB sont bloqués lors de l'envoi de messages, entraînant le redémarrage du nœud HADB et le partitionnement du réseau.
Sous Solaris x86, certains problèmes peuvent se produire après une panne réseau, empêchant le basculement vers une autre interface réseau. Bien que cela ne se produise pas tout le temps, il est préférable d'utiliser deux réseaux au lieu d'un. Ces problèmes sont partiellement résolus sous Solaris 10.
L'agrégation n'est pas prise en charge.
Les bases de données HADB ne prennent pas en charge les doubles réseaux sous Windows2003 (ID 5103186).
La création d'une base de données risque d'échouer en générant l'erreur suivante, indiquant que le nombre de segments de mémoire partagée disponibles est insuffisant :
HADB-E-21054: System resource is unavailable: HADB-S-05512: Attaching shared memory segment with key "xxxxx" failed, OS status=24 OS error message: Too many open files.
Vérifiez que la mémoire partagée est correctement configurée. En particulier, sous Solaris 8, inspectez le fichier /etc/system et assurez-vous que la valeur de la variable shmsys:shminfo_shmseg est au moins six fois supérieure au nombre de nœuds par hôte.
Lorsque vous augmentez la taille des périphériques ou du tampon à l'aide de la commande hadbm set, le système de gestion vérifie la disponibilité des ressources lors de la création des bases de données ou de l'ajout de nœuds. Cependant, il ne vérifie pas si un nombre suffisant de ressources est disponible lors de la modification de la taille des périphériques ou du tampon de la mémoire principale.
Vérifiez qu'il y a suffisamment d'espace disque ou de mémoire disponible sur tous les hôtes avant d'augmenter les attributs de configuration devicesize ou buffersize.
Il est impossible d'enregistrer le même package avec le même nom à différents emplacements et sur différents hôtes ; par exemple :
hadbm registerpackage test --packagepath=/var/install1 --hosts europa11 Package successfully registered. hadbm registerpackage test --packagepath=/var/install2 --hosts europa12 hadbm:Error 22171: A software package has already been registered with the package name test. |
La base de données HADB ne prend pas en charge les chemins hétérogènes sur plusieurs nœuds d'un cluster de base de données. Assurez-vous que le répertoire d'installation du serveur HADB (--packagepath) est le même pour tous les hôtes concernés.
Si l'agent de gestion est exécuté sur un hôte avec plusieurs interfaces réseau, la commande createdomain risque d'échouer si toutes les interfaces réseau ne se trouvent pas sur le même sous-réseau :
hadbm:Error 22020: The management agents could not establish a domain, please check that the hosts can communicate with UDP multicast. |
S'ils ne sont pas configurés autrement, les agents de gestion utilisent la première interface pour les multidiffusions UDP (la "première" étant déterminée par le résultat de java.net.NetworkInterface.getNetworkInterfaces() ).
La meilleure solution consiste à indiquer à l'agent de gestion quel sous-réseau utiliser (en définissant ma.server.mainternal.interfaces dans le fichier de configuration, par exemple ma.server.mainternal.interfaces=10.11.100.0). Une autre solution consiste à configurer le routeur entre les sous-réseaux de manière à acheminer les paquets multidiffusions. (L'agent de gestion utilise l'adresse multidiffusion 228.8.8.8.)
Avant de réessayer avec une nouvelle configuration des agents de gestion, vous devrez peut-être nettoyer le référentiel des agents de gestion. Arrêtez tous les agents dans le domaine et supprimez tous les fichiers et répertoires du répertoire du référentiel (identifié par repository.dr.path dans le fichier de configuration des agents de gestion). Cette opération doit être effectuée sur tous les hôtes avant de redémarrer les agents avec le nouveau fichier de configuration.
Sous Solaris 10 Opteron, le démarrage, l'arrêt ou la reconfiguration de HADB à l'aide de la commande hadbm risque d'échouer ou de se bloquer, en générant l'une des erreurs suivantes :
hadbm:Error 22009: The command issued had no progress in the last 300 seconds. HADB-E-21070: The operation did not complete within the time limit, but has not been cancelled and may complete at a later time. |
Cette erreur peut se produire s'il existe des incohérences lors de l'écriture ou de la lecture d'un fichier nomandevice) utilisé par le processus clu_noman_srv. Vous pouvez détecter ce problème en recherchant l'un des messages suivants dans les fichiers de l'historique de HADB :
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 does not respond. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Have not heard from it in 104.537454 sec. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 did not start. |
La solution suivante n'a pas été vérifiée, car le problème n'a pas été reproduit manuellement. Cependant, l'exécution de cette commande pour le nœud affecté devrait résoudre le problème.
hadbm restartnode --level=clear nodeno dbname |
Notez que tous les périphériques associés au nœud seront réinitialisés. Vous devrez peut-être arrêter le nœud avant de le réinitialiser.
Si vous démarrez l'agent de gestion sur un hôte exécutant Solaris 8 et sur lequel plusieurs cartes réseau sont installées et que IPv6 et IPv4 sont activés simultanément, l'agent de gestion s'arrête et génère l'exception "IPV6_MULTICAST_IF failed"."
Paramétrez la variable d'environnement JAVA_OPTIONS sur -Djava.net.preferIPv4Stack=true ; par exemple :
export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true" |
Une autre solution consiste à utiliser Solaris 9 ou ultérieur, qui ne présente pas ce problème.
Il existe un bogue dans la version 64 bits de Red Hat Enterprise Linux 3.0 selon lequel le processus clu_trans_srv passe en mode non interruptible dans le cadre d'une E/S asynchrone. Cela signifie que la commande kill -9 ne fonctionne pas et que le système d'exploitation doit être réinitialisé.
Utilisez la version 32 bits de Red Hat Enterprise Linux 3.0.
Les lettres en majuscules sont converties en minuscules lorsqu'un mot de passe est stocké dans hadb.
N'utilisez pas de mots de passe contenant des lettres en majuscules.
Lors d'une mise à niveau inférieur d'une version HADB, l'agent de gestion peut échouer avec différents codes d'erreur.
Il est possible de mettre la base de données HADB à un niveau inférieur, mais ce n'est pas le cas pour l'agent de gestion si des modifications ont été apportées à des objets du référentiel. Une fois la mise à niveau inférieur effectuée, vous devez continuer à utiliser l'agent de gestion provenant de la version HADB la plus récente.
Lors de l'installation/de la suppression du package c HADB (Solaris : SUNWhadbc, Linux : sun-hadb-c) version <m.n.u-p>, le lien symbolique symlink /opt/SUNWhadb/<m> existant n'est jamais affecté. Il est donc possible qu'un lien symbolique orphelin symlink existe.
Supprimez le lien symbolique symlink avant l'installation ou après la désinstallation, sauf s'il est en cours d'utilisation.
Sous Solaris 10, l'arrêt d'un agent de gestion par le biais du script ma-initd dans une zone globale provoque également l'arrêt de l'agent de gestion de la zone locale.
N'installez l'agent de gestion que dans une de ces zones.
Il peut arriver qu'un problème de conflit d'utilisation des ressources sur un serveur entraîne la déconnexion d'un client de gestion. Lors de la reconnexion, un message d'erreur trompeur, "hadbm:Error 22184: A password is required to connect to the management agent", peut être renvoyé.
Il peut arriver qu'un problème de conflit d'utilisation des ressources sur un serveur entraîne la déconnexion d'un client de gestion. Lors de la reconnexion, un message d'erreur trompeur, "hadbm:Error 22184: A password is required to connect to the management agent", peut être renvoyé.
Vérifiez s'il y a un problème de ressources sur le serveur, prenez les mesures nécessaires (par exemple, ajoutez des ressources) et relancez l'opération.
Une installation par le biais de Java Enterprise System (en tant que root) ne permet pas aux utilisateurs non root de gérer la base de données HADB.
Connectez-vous toujours en tant que root pour pouvoir gérer la base de données HADB.
Les interfaces spécialisées portant des adresses IP comme 0.0.0.0 ne doivent pas être enregistrées comme des interfaces pouvant être utilisées pour des nœuds HADB dans l'agent de gestion. L'enregistrement de telles interfaces peut entraîner des problèmes si des nœuds HADB sont définis sur ces interfaces via une commande utilisateur hadbm create utilisant des noms d'hôtes à la place d'adresses IP. Les nœuds ne pourront plus communiquer, interrompant ainsi la commande create.
Lorsque vous utilisez hadbm create sur des hôtes à plusieurs interfaces, spécifiez toujours les adresses IP à l'aide d'une notation DDN.
Sous Windows, avec certaines configurations et charges, un grand nombre d'échecs de réassemblage peut se produire dans le système d'exploitation. Le problème a été observé avec des configurations de plusieurs vingtaines de nœuds lors de l'exécution de plusieurs analyses parallèles de tables (select *). Les signes peuvent être tels que les transactions sont fréquemment abandonnées, la réparation ou la récupération peut prendre du temps et des délais d'expiration fréquents peuvent se produire dans différentes parties du système.
Pour résoudre le problème, la variable du registre Windows HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters peut être définie sur une valeur supérieure à celle par défaut de 100. Il est recommandé d'augmenter cette valeur à 0x1000 ( 4096). Pour plus d'informations, consultez l' article 811003 sur les pages de support Microsoft.
Les cookies comportant un chemin équivalent à « / » interfèrent avec les cookies d'une application Web hautement disponible déployée sur une racine contexte autre que « / » et utilisant la réplication en mémoire comme type de persistance, ce qui empêche ainsi l'application Web de conserver tout état de session HTTP. Ce problème peut par exemple survenir lorsque vous utilisez le même navigateur pour accéder à l'IG d'administration (déployée sur « / » ) et à l'application Web hautement disponible.
Accédez à l'application Web déployée sur « / » à partir d'un autre navigateur.
SASL32.DLL et ZLIB.DLL sont requis pour que l'équilibreur de charge fonctionne avec Windows IIS 6. Ces fichiers sont actuellement indisponibles sous <appsrver-install> /lib.
Copiez les deux fichiers DLL manuellement vers <appserver-install> /lib. Vous pouvez les télécharger à partir de :
http://download.java.net/javaee5/external/<OS>/aslb/jars/aslb-9.1-MS4-b5.jar |
<OS> correspondant à la plate-forme choisie parmi les valeurs suivantes :
SunOS ;
SunOS_X86
Linux ;
WINNT.
Deux problèmes surviennent lors de l'installation ou de la désinstallation d'Application Server avec des packages haute disponibilité dans une zone globale :
ceux-ci sont installés dans toutes les zones, ce qui peut ne pas être souhaitable.
Lors de la désinstallation, les packages HA, MQ et JDK sont supprimés de toutes les zones, ce qui peut ne pas être souhaitable.
Ce problème ne survient pas lors des opérations d'installation ou de désinstallation à partir d'une zone racine locale.
Effectuez les opérations d'installation et de désinstallation à partir d'une zone racine locale plutôt que d'une zone globale.
Les applications Web hautement disponibles déployées sur « / » ne peuvent pas conserver de sessions HTTP lorsqu'elles utilisent la réplication en mémoire comme type de persistance.
Déployez les applications Web hautement disponibles, utilisant la réplication en mémoire comme type de persistance, vers une racine contexte autre que « / ». Si vous souhaitez qu'une telle application Web soit disponible sur « / », vous pouvez désigner ce dernier en tant que module Web par défaut du serveur virtuel vers lequel l'application Web a été déployée.
Lors de l'installation de l'équilibreur de charge d'Application Server pour Apache sous Solaris, le programme d'installation met à jour le chemin LD_LIBRARY_PATH dans le script apachectl . Cependant, le programme d'installation n'écrit pas correctement le chemin /usr/lib/mps. Sous Solaris, l'instance de sécurité Apache ne pourra pas démarrer sans ce chemin dans LD_LIBRARY_PATH.
Ce problème est particulier aux plates-formes Solaris. Pour le contourner, ajoutez /opt/SUNWappserver/appserver/lib/lbplugin/lib à votre chemin LD_LIBRARY_PATH.
Le bouton Activer l'équilibreur de charge est toujours activé sur la page principale relative à l'instance/au cluster, quel que soit le contenu de domain.xml.
Pour les instances clusterisées, sélectionnez l'onglet Instances, puis cliquez sur l'action Mettre en attente à partir du menu déroulant.
Pour les instances autonomes, assurez-vous que l'instance est en cours d'exécution, puis cliquez sur le bouton Mettre en attente sur l'écran principal de l'instance.
(Solaris uniquement) Une fois Application Server 9.1 installé sous SPARC Solaris 10 avec HADB, vous pouvez recevoir l'erreur suivante après le démarrage d'Application Server et la tentative d'installation de JES 5 UR1 avec Registry Server :
Dependency Error: Installation can not proceed because the version of HA Session Store 4.4.3 detected on this host is incomplete , and a compatible version is required by Servervice Registry Deployment Support. |
Vous ne pouvez pas installer Registry Server à partir de JES 5 UR1 avec l'IFR Application Server 9.1 sur des machines Solaris. Vous devez installer manuellement les packages de Registry Server à l'aide de la commande pkgadd à partir du répertoire de distribution JES5 UR1 suivant :
<path>/<OS>/Products/registry-svr/Packages |
(Internet Explorer 6 uniquement) Lors de la tentative d'exportation du fichier de configuration de l'équilibreur de charge (loadbalancer.xml) à partir d'Internet Explorer 6, le navigateur affiche un message d'erreur indiquant que le fichier DTD sun-loadbalancer_1_2.dtd est introuvable.
Pour enregistrer le fichier, procédez comme suit :
Cliquez sur Exporter sur la page de l'équilibreur de charge sous Internet Explorer.
Le message « La page XML ne peut pas être affichée » s'affiche.
Cliquez sur ce message, puis choisissez Fichier->Enregistrer sous à partir d'Internet Explorer.
Enregistrez le fichier loadbalancer.xml dans le répertoire de votre choix.
Cette section décrit les problèmes connus liés à l'installation et les solutions associées.
Ce problème apparaît 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 Linux Red Hat.
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.
Quittez le programme d'installation en appuyant sur les touches Ctrl+C dans la fenêtre du terminal dans laquelle le programme d'installation a été démarré. 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-ee/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.
Sous Windows, dès qu'Application Server Enterprise Edition est installé, le courtier Message Queue échoue au démarrage et un message indiquant que le répertoire drive:\as\domains\domain1\imq n'existe pas apparaît.
Notez que le problème ne se produit pas si le courtier est démarré après domain1, car le répertoire est créé par Application Server.
Créez l'emplacement var_home_dir_location avant de créer le courtier :
$imqbrokerd -varhome var_home_dir_location |
Par exemple :
$imqbrokerd -varhome D:\as\domains\domain1\imq |
Lors de l'installation du SDK intégré sous Windows Vista, le message d'erreur « Plate-forme d'installation non prise en charge détectée. » peut éventuellement s'afficher. Cependant, cela n'a aucun effet sur la réussite de l'installation.
Il ne s'agit pas véritablement d'un problème. Application Server s'exécute correctement sous Windows Vista et ce message erroné sera supprimé des prochaines versions du produit.
Si le fichier productregistry d'Application Server contient des configurations de composant partagé, le processus de désinstallation d'Application Server ne met pas à jour le fichier productregistry correctement, vous ne serez donc pas en mesure d'utiliser le mode silencieux pour une installation ultérieure à moins que productregistry ne soit renommé ou supprimé. Par défaut, les entrées des composants partagés sont conservées en l'état dans le fichier productregistry, mais cela entraîne une confusion lors d'installations silencieuses ultérieures.
Après avoir vérifié la réussite de la désinstallation via les fichiers journaux correspondants, supprimez le fichier productregistry avant d'exécuter une nouvelle installation. Pour constater la réussite d'un processus de désinstallation antérieur, consultez le fichier appserv_uninstall.class dans <rép_install>. Vous ne trouverez pas ce fichier en cas d'échec de la désinstallation.
Si tel est le cas, ne supprimez pas le fichier productregistry.
Le fichier productregistry se trouve dans /var/sadm/install sous Solaris et dans /var/tmp sous Linux.
Lors de l'installation d'Application Server dans une zone locale fragmentée, le processus échoue si Message Queue (MQ) n'a pas été installé en premier. Le programme d'installation essaie d'installer MQ, ce qui provoque l'échec de l'ensemble du processus.
Il est nécessaire d'installer manuellement MQ dans la zone globale avant d'installer Application Server dans une zone locale fragmentée. Deux solutions vous sont proposées :
Installez MQ 4.1 manuellement dans la zone globale à partir du même média sur lequel l'installation IFR d'Application Server 9.1 a été effectuée afin d'obtenir les derniers packages MQ.
Utilisez le programme d'installation correspondant à votre plate-forme :
mq4_1-installer-SunOS.zip mq4_1-installer-SunOS_X86.zip mq4_1-installer-Linux_X86.zip mq4_1-installer-WINNT.zip |
Décompressez les fichiers et exécutez le programme d'installation.
Ce dernier sera stocké dans le répertoire mq4_1-installer.
Installez tous les composants de l'installation IFR dans la zone globale. Cette opération permet de vérifier la version de MQ dans GZ et, si nécessaire, de la mettre à niveau vers la version intégrée à l'IFR Application Server 9.1. La sélection et l'installation du composant d'exemples d'application permettent de mettre à niveau MQ vers la version IFR.
Exécutez l'installation d'Application Server dans la zone globale mais sélectionnez uniquement les exemples de composant.
L'installation des exemples de composant permet également d'installer MQ et les composants partagés d'Application Server dans toutes les zones.
Exécutez à nouveau l'installation d'Application Server, cette fois-ci dans la zone locale fragmentée.
L'installation doit se dérouler sans aucun problème.
Lorsque vous exécutez le programme d'installation IFR d'Application Server 9.1 avec l'option —console (en mode ligne de commande), vous recevez l'invite suivante :
Do you want to upgrade from previous Application Server version? |
Malheureusement, le programme d'installation IFR ne prend pas en charge de telles mises à niveau, cette invite est donc erronée. Si vous répondez oui à cette invite, l'installation se poursuit normalement mais vous ne recevez aucune confirmation de la réussite de l'installation, ni de la mise à niveau.
Utilisez l'outil de mise à niveau si vous souhaitez mettre à niveau votre installation d'Application Server.
Pour exécuter le didacticiel de Java EE 5 sur Sun Java System Application Server 9.1, effectuez les opérations suivantes :
Lorsque vous modifiez les exemples de fichier /common/build.properties, tel qu'indiqué dans la section “À propos des exemples” du chapitre “À propos de ce didacticiel”, remplacez le numéro de port 4848 par 4849.
Le port d'administration par défaut dans Application Server 9.1 est encore défini sur 4848 . Pour plus d'informations, reportez-vous à la section Changement des ports par défaut dans chaque version principale d'AS (6566481).
Lorsque vous utilisez l'outil de déploiement (deploytool), indiquez localhost:4849 comme adresse de serveur avant de déployer un exemple.
Lorsque vous créez des ressources à l'aide de la console d'administration, utilisez l'onglet Cibles pour indiquer que le serveur est la cible. Si vous utilisez la ligne de commande ou une cible asant, le serveur représente la cible par défaut et aucune autre action n'est requise.
Dans le Chapitre 32, Java EE Examples Using the JMS API du The Java EE 5 Tutorial, à la section An Application Example That Consumes Messages from a Remote Server du The Java EE 5 Tutorial," cet exemple ne fonctionne plus. Le MDB ne parvient pas à recevoir le message. Les deux autres exemples d'envoi de messages entre deux systèmes fonctionnent correctement (Running JMS Client Programs on Multiple Systems du The Java EE 5 Tutorial et An Application Example That Deploys a Message-Driven Bean on Two Servers du The Java EE 5 Tutorial ).
Ce problème sera résolu dans une version ultérieure d'Application Server.
Si l'API java.util.Arrays.asList() est utilisée pour convertir un Object[] en une Collection, JDK retourne une implémentation de java.util.ArrayList non clonable. L'exception suivante est alors générée :
The method invocation of the method [protected native java.lang.Object java.lang.Object.clone() throws java.lang.CloneNotSupportedException] on the object [[pkg.A id = xxx]], of class [class java.util.Arrays$ArrayList], triggered an exception. Internal Exception: java.lang.reflect.InvocationTargetException Target Invocation Exception: java.lang.CloneNotSupportedException: java.util.Arrays$ArrayList |
Ce problème est suivi sur https://glassfish.dev.java.net/issues/show_bug.cgi?id=556.
Créez une autre collection à l'aide de son constructeur ; par exemple :
myCollection = new ArrayList(java.util.Arrays.asList(a)) |
Cette section décrit les problèmes connus de gestion du cycle de vie et les solutions associées.
Après avoir défini minimum-delivery-interval de la propriété ejb-timer-service sur 9000, la tentative de définition de redelivery-interval-in-mills sur 7000 pour ejb-timer-service entraîne l'échec de la commande set avec l'erreur suivante :
[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. |
minimum-delivery-interval correspond à l'intervalle de temps minimal entre chaque distribution d'une même horloge.
redelivery-interval-in-mills indique le délai pendant lequel le service d'horloge attend avant d'effectuer une nouvelle tentative de distribution suite à l'expiration de la valeur ejbTimeout.
La relation entre la propriété de l'intervalle de redistribution et celle de l'intervalle de livraison minimal n'étant pas logique, il vous est impossible d'utiliser l'interface graphique (IG) ou l'interface de ligne de commande (CLI) pour définir un intervalle de livraison minimal supérieur à celui de redistribution.
minimum-delivery-interval-in-millis doit toujours être égal ou supérieur à redelivery-interval-in-millis pour la propriété ejb-timer-service. Cependant, un contrôle de validité erroné s'effectue dans Application Server pour vérifier que la valeur de redelivery-interval-in-millis est supérieure à la valeur de minimum-delivery-interval-in-millis.
Utilisez les valeurs par défaut suivantes :
minimum-delivery-interval(default)=7000 redelivery-interval-in-millis(default)=5000 |
Toute autre valeur provoquera une erreur.
Si vous essayez d'afficher les destinations physiques JMS à l'aide de default-config, un message d'erreur apparaîtra.
Ce comportement est normal. Dans Application Server 9.1, default-config est un modèle d'informations de configuration, par conséquent, les opérations JMS (telles quelist et create) ne peuvent pas être exécutées pour default-config. En revanche, ces opérations peuvent être exécutées pour la configuration de vos instances autonomes ou clusterisées.
(Windows 2003 uniquement) Des fuites de mémoire se produisent sur les systèmes Windows 2003 lors de l'exécution de fonctions richaccess. Ce problème est dû à la croissance continue du pool non paginé Win32, qui peut provoquer une panne de la pile TCP/IP complète. Une fois l'erreur générée, la pile TCP/IP demeure dans un état récupérable, et la seule manière de la restaurer est de redémarrer le système Windows 2003.
Il s'agit d'un bogue Microsoft (numéro : SRX070906600011), pour lequel un correctif logiciel est disponible. Pour plus d'informations, contactez le support Microsoft.
Vous disposez de deux solutions, en plus du correctif susmentionné.
Utilisez le mode de blocage Grizzly en configurant l'attribut http-listener de domain.xml , blocking-enabled="true" ou ajoutez la propriété http-listener suivante :
<property name="blocking" value="true"/> |
Utilisez Windows Vista ou Windows XP.
Cette section décrit les problèmes connus de consignation et les solutions.
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 apparaît, 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> |
Aucune pour l'instant. Évitez de paramétrer cet indicateur.
Cette section décrit les problèmes connus liés aux files d'attente des messages Java et les solutions associées.
Dans des scénarios faisant appel à la synchronisation, plusieurs causes peuvent être à l'origine de ce problème.
Pour contourner ces problèmes :
Redémarrez les courtiers concernés.
Redémarrez les instances d'Application Server concernées.
Après avoir créé un domaine avec un profil de cluster sur un système Linux, il se peut que vous rencontriez une erreur java.lang.OutOfMemoryError: Java heap space et que l'instance du serveur ne parvienne pas à redémarrer suite au blocage du démarrage du courtier MQ. Il est impossible de récupérer le système après cette condition. Ce problème provient d'une configuration incorrecte du fichier /etc/hosts ; de manière plus spécifique, le nom d'hôte du serveur pointe vers l'adresse de loopback 127.0.0.1.
Un cluster du courtier MQ ne peut pas démarrer lorsque le périphérique réseau est configuré pour pointer vers l'adresse de loopback. Il ne s'agit pas d'un bogue. La solution est de vous assurer que le fichier /etc/hosts de l'hôte d'Application Server ne pointe pas vers 127.0.0.1.
Cette section décrit les problèmes connus liés au contrôle et les solutions associées.
Des valeurs affichées dans les statistiques de contrôle de certains éléments du service HTTP ne correspondent pas aux valeurs actuelles ou sont égales à 0. Notamment les statistiques de service HTTP suivantes, car elles ne comportent pas d'informations applicables à Application Server et doivent donc être ignorées :
http-service
load1MinuteAverage
load5MinuteAverage
load15MinuteAverage
rateBytesTransmitted
rateBytesReceived
pwc-thread-pool (the element)
Ces contrôles seront supprimés dans les versions ultérieures et remplacés par des informations mieux adaptées.
De nombreuses exceptions sont générées lorsque le navigateur JNDI est ouvert à partir de l'IG d'administration.
Aucune pour l'instant.
Cette section décrit les problèmes connus liés au code de l'exemple compris dans le produit Application Server 9.1 ainsi que les solutions associées.
La documentation ne signale pas, de façon explicite, que vous devez créer des ressources JMS avant d'exécuter l'exemple d'application de basculement MQ suivant les instructions de déploiement de asadmin.
L'erreur générée est la suivante :
/opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name MQFailoverTestClient -textauth -user j2ee -password j2ee Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: NAM0006: JMS Destination object not found: jms/durable/TopicA Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: javax.naming.NameNotFoundException javax.naming.NameNotFoundException |
La documentation n'indique pas, de façon explicite, que des ressources JMS doivent être créées manuellement lorsque vous procédez au déploiement manuel à l'aide de la commande asadmin deploy, ni que vous devez utiliser les cibles ant fournies pour déployer l'exemple d'application.
Utilisez la cible asant deploy pour le script build.xml afin de créer les ressources JMS nécessaires à l'exécution de l'application.
Lors du déploiement de l'exemple rép_install/samples/webservices/security (basicSSl) sous Linux, le certificat n'est pas créé et une erreur similaire à celle présentée ci-dessous est générée :
generate_certs: [echo] ***Exporting certificate from NSS database [exec] Result: 1 [echo] ***Generating Java Keystore from generated certificate [exec] keytool error: java.lang.Exception: Input not an X.509 certificate [exec] Result: 1 [echo] ***Generating Java trust store from generated certificate [exec] keytool error: java.lang. Exception: Input not an X.509 certificate [exec] Result: 1 . . . generate_certs: [echo] ***Exporting server certificate from NSS database to a PKCS12 certificate file [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/ libnss3.so: version `NSS_3.9' not found (required by /opt/sun/appserver/lib/ pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.6' not found (required by /opt/sun/appserver/lib/pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.7' not found (required by /opt/sun/appserver/lib/pk12util) [exec] Result: 1 |
Le problème est que les bibliothèques NSS ne se trouvent pas dans les mêmes emplacements sous Linux et Solaris. Lors du déploiement sous Linux, assurez-vous que le chemin LD_LIBRARY_PATH correspond à celui des bibliothèques NSS appropriées. Définissez la variable LD_LIBRARY_PATH dans votre environnement ou dans le script wrapper install_dir/bin/asant.
Effectuez l'une des opérations suivantes :
Définissez LD_LIBRARY_PATH=/opt/sun/private/lib.
Ajoutez la ligne ci-dessous au script install_dir/bin/asant :
LD_LIBRARY_PATH=$AS_NSS:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH |
Sous Windows, après la mise à niveau d'Application Server 9.1, les exemples de base et ceux du portail JES5 entrent en conflit sur le port Derby 1527. D'une manière plus spécifique, Application Server 9.1 lance automatiquement JavaDB sur le port 0.0.0.0:1527 avec APP:APP, cependant JavaDB du portail JES5 cherche également à s'associer au hostnameIP:1527 avec portal:portal.
Ce problème a déjà été soulevé pour JES 5, sous la référence n° 6472173. La solution correspondante est présentée dans le Sun Java Enterprise System 5 Installation Guide for Microsoft Windows.
Démarrez la base de données Derby à l'aide de la commande suivante :
<JES installation dir>\appserver\bin\asadmin start-database --dbhome <JES installation dir>\portal\data\derby |
Cette section décrit les problèmes connus liés aux certificats et à la sécurité des applications Web sous Application Server ainsi que les solutions associées.
La terminaison SSL ne fonctionne pas ; lorsque l'équilibreur de charge (matériel) est configuré pour la terminaison SSL, Application Server passe du protocole https à http au cours de la redirection.
Ajoutez un équilibreur de charge logiciel entre l'équilibreur de charge matériel et Application Server.
À cause d'un bogue JVM, un problème de fuite survient avec certaines versions JDK lorsque security-enabled est défini sur true sur un listener HTTP. Les étapes de reproduction de ce bogue sont les suivantes :
Définissez security-enabled sur true sur le listener HTTP :
<http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server="server" enabled="true" family="inet" id=" http-listener-1" port="8080" security-enabled="true" server-name="" xpowered-by="true"> |
Commentez l'arrêt du domaine à la fin des tests quicklook.
Exécutez les tests quicklook.
Vérifiez l'utilisation du socket :
netstat -an | grep 8080 |
Les éléments suivants doivent être utilisés :
*.8080 *.* 0 0 49152 0 LISTEN *.8080 *.* 0 0 49152 0 BOUND |
Ce problème est suivi sur le site de Glassfish à l'adresse suivante : https://glassfish.dev.java.net/issues/show_bug.cgi?id=849.
Procédez à une mise à niveau vers la dernière version de JDK.
Cette section décrit les problèmes connus de l'utilitaire de mise à niveau et les solutions associées.
Les domaines créés dans un chemin personnalisé autre que le répertoire rép_install /domains ne sont pas directement mis à niveau lors de la mise à niveau d'Application Server Enterprise Edition 8 vers Application Server Enterprise Edition 8.1.
Lors de l'exécution de l'utilitaire de mise à niveau et de l'identification de rép_install comme répertoire d'installation source, le processus de mise à niveau met uniquement à niveau les domaines créés sous le répertoire rép_install/domains. Les domaines créés à d’autres emplacements ne sont pas mis à niveau.
Avant de lancer le processus de mise à niveau, copiez tous les répertoires de domaines de leurs différents emplacements vers le répertoire rép_install/domains .
Ce problème a été observé sur plusieurs systèmes Linux, en particulier sur Java Desktop System 2, mais également sur les distributions Red Hat.
Après avoir cliqué sur le bouton Start Upgrade Tool (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.
Ce problème ne survient pas lorsque le mode d'installation en ligne de commande est utilisé pour procéder à la mise à niveau à son emplacement.
Si vous effectuez la mise à niveau à son emplacement en mode d'interface graphique (IG) et que le problème apparaît, quittez le programme d'installation en appuyant sur les touches Ctrl+C dans la fenêtre du terminal dans laquelle le programme d'installation a été démarré.
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.
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-ee/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.
Supprimez les entrées suivantes de la cible domain.xml (après la mise à niveau) et redémarrez le serveur :
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot} /config/keystore.jks</jvm-options>- <jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot} /config/cacerts.jks</jvm-options>
L'outil de mise à niveau écrase tout fichier index.html existant pour toutes les instances du serveur.
Sauvegardez vos fichiers index.html existants avant d'exécuter l'outil de mise à niveau, puis restaurez-les ultérieurement.
Lors de la mise à niveau d'Application Server 8.0PE vers 9.1, une erreur est générée signalant que le serveur ne dispose pas d'un connecteur système appelé null, et des informations utilisateur incorrectes s'affichent dans sbs-manual. Même si les valeurs codées en dur sont modifiées, ce message d'erreur s'affiche. Cela se produit car le fichier domain.xml a été modifié entre les versions 8.0 et 9.1.
Ce bogue apparaît uniquement pour la mise à niveau de 8.0 PE vers 9.1. Il vous suffit donc de procéder d'abord à une mise à niveau vers 8.1, 8.2 ou 9.0, puis vers 9.1.
Lorsque vous exécutez une mise à niveau en place, au cas où la source contienne plusieurs domaines, le programme d'installation invoque l'outil de mise à niveau bien que le processus soit interrompu. Cela se produit lorsque l'outil est invoqué en mode IG.
Procédez à une installation en place en mode CLI, puis quittez le programme d'installation lorsque vous êtes invité à sélectionner l'outil de mise à niveau à la fin du processus. Aucun des domaines contenus dans le répertoire des domaines n'est alors supprimé. L'outil de mise à niveau doit être invoqué manuellement à partir du répertoire bin.
Lors de votre installation en place en mode IG, sauvegardez les domaines se trouvant dans la racine des domaines afin de ne pas en perdre au cours du processus. À la fin du processus d'installation, quittez le programme lorsque vous êtes invité à invoquer l'outil de mise à niveau. Copiez les domaines sauvegardés dans le répertoire des domaines si ceux-ci ont été supprimés. Lancez ensuite manuellement l'outil de mise à niveau pour terminer le processus.
Lors de la mise à niveau d'AS 8.2 vers 9.1, le mot de passe principal de l'installation 8.2 n'est pas hérité dans l'installation 9.1. Cela crée, par conséquent, une erreur d'authentification à la prochaine connexion de l'administrateur.
Le mot de passe administrateur par défaut dans Application Server 9.1 est changeit. Pour éviter tout problème lors de la connexion au serveur 9.1 après la mise à niveau de 8.2, optez pour l'une des trois solutions suivantes :
Modifiez le mot de passe administrateur de la version 8.2 sur changeit avant d'exécuter la mise à niveau.
N'acceptez pas le mot de passe administrateur par défaut du processus de mise à niveau, préférez saisir un mot de passe personnalisé.
Connectez-vous au serveur 9.1 avec le mot de passe par défaut, puis modifiez-le directement.
L'outil de mise à niveau n'est pas destiné à mettre à niveau les bases de données ou les tables de base de données quelle qu'en soit la forme, il ne prend d'ailleurs pas ce processus en charge. Les configurations des références de ressource sont alors transférées et Application Server continue à utiliser la base de données et les tables d'origine. Si vous souhaitez changer de base de données ou transférer les tables de base de données, utilisez les outils fonctionnant avec les bases de données utilisées.
Pour migrer le magasin MQ, procédez comme suit :
Observez les étapes suivantes APRÈS la fermeture d'AS 8.2 et APRÈS l'exécution de l'outil de mise à niveau d'AS9.1 mais AVANT le PREMIER démarrage de ce dernier. Si vous avez déjà démarré AS 9.1 après l'installation/la mise à niveau IFR, ne suivez PAS les étapes suivantes car elles peuvent éventuellement déstabiliser la mémoire de messages MQ.
Copiez le sous-répertoire domains/domain1/imq complet du répertoire domains d'AS 8.x vers le répertoire domains d'AS 9.1.
Vérifiez que la propriété du répertoire et des fichiers est identique à celle de l'utilisateur chargé d'exécuter Application Server.
Une fois ces étapes exécutées, vous pouvez démarrer Application Server 9.1. Le magasin MQ, dans le répertoire domains d'Application Server 9.1, sera migré du format JES5 U1 vers le format MQ 4.1. Notez que le magasin MQ JES5 U1 d'origine sous AS 8.2 est préservé et n'est pas modifié par cette procédure ou par MQ4.1 au démarrage d'AS 9.1
Lors de la mise à niveau de JES5 (Application Server 8.2) vers Application Server 9.1, l'exemple de communauté Portal Server ne fonctionne plus ; de nombreuses erreurs javax.faces.application.ApplicationFactory sont alors générées.
La mise à niveau d'Application Server 8.2 vers 9.1 n'est pas prise en charge si Application Server 8.2 a été installé avec JES5 Portal Server. Il est nécessaire de mettre Portal Server à niveau vers Java ES 5 Update 1 avant la mise à niveau d'Application Server vers 9.1.
Lors de la mise à niveau d'Application Server 8.2 vers 9.1 à l'aide du programme d'installation IFR sur des plates-formes Linux, avec l'option Installer JDK sélectionnée, et une fois l'installation terminée, la plupart des composants JES ne fonctionnent plus.
Ce problème affecte uniquement l'installation IFR d'Application Server 9.1 sur des plates-formes Linux, et seulement lorsque l'option Installer JDK est sélectionnée. Pour résoudre ce problème, immédiatement après l'installation, associez /usr/jdk/entsys-j2se au répertoire /usr/java/jdk1.5.0_12 .
Lors de l'exécution d'une mise à niveau IFR d'Application Server 9.1 sous Windows, la sauvegarde en place n'est pas correctement intégrée aux valeurs de formulaire asupdate.bat. De manière plus spécifique, si vous entrez des informations incorrectes dans un écran IG ASupdate.bat , puis que vous cliquez sur le bouton Suivant, le programme d'installation de la mise à niveau essaie de détecter s'il s'agit d'une mise à niveau en place. Si tel est le cas, domain1 est déplacé vers un répertoire de sauvegarde avant la mise à niveau. Lors de l'exécution de la mise à niveau, un message d'erreur s'affiche en raison de la saisie d'informations incorrectes. Si vous essayez de corriger l'erreur immédiatement, une erreur de chemin est générée car domain1 a déjà été déplacé.
Modifiez le répertoire source sur domain1_ {horodatage} dans {chemin source actuel}/backup ou quittez le programme d'installation en cliquant sur Annuler puis réessayez.
(Windows uniquement) Si une version antérieure d'Application Server a été installée en utilisant des caractères spéciaux ou des noms courts de style DOS dans le chemin du répertoire programme, les futures mises à niveau de remplacement vers Application Server 9.1 échoueront si les mêmes noms sont utilisés.
Par exemple, si Application Server 8.2 a été installé sous :
C:\Program Files (x86)\dirs\appserver c:\progra~2\dirs\appserver |
Toute tentative de mise à niveau de remplacement vers 9.1 échouera car le programme d'installation n'est pas en mesure de convertir les noms courts ou les caractères spéciaux vers le format de nom long requis.
Il est fortement déconseillé d'installer Application Server en utilisant un nom de chemin contenant des caractères spéciaux ou un nom court abrégé de style DOS (tel que progra~2) car cela empêche l'installation d'autres mises à niveau. Si vous disposez déjà d'une telle installation, recommencez l'installation en utilisant des noms de chemin longs avant de procéder à une mise à niveau ou installez la nouvelle version d'Application Server dans un nouveau répertoire.
Après une mise à niveau d'Application Server, la balise <jsp:forward> ne fonctionne pas comme prévu dans Authenticate.jsp. L'appel de <jsp:forward> génère une erreur dans les fichiers journaux du serveur et une page blanche s'affiche sur l'IU Web. Le problème s'explique par le fait que <jsp:forward> dans Authenticate.jsp requiert un attribut de page, tel que <jsp:forward page="${pageRedirection}"/>, cependant la valeur transférée est un chemin relatif, tel que /registry/thin/{nompage}.jsp, non valable même si Authenticate.jsp est une page JSP pure.
Une fois Application Server mis à niveau, utilisez l'outil asadmin pour exécuter les commandes suivantes en vue de définir <auth-realm> dans domain.xml :
Accédez à <appserver9.1-install-dir>/bin et exécutez la commande suivante :
./asadmin delete-auth-realm --host localhost --port 6489 certificate |
L'ancien certificat auth-realm est alors supprimé, le cas échéant.
Exécutez la commande suivante :
./asadmin create-auth-realm --terse=false --echo=true --interactive=true \ --user admin --host localhost --port 6489 --classname \ com.sun.enterprise.security.auth.realm.certificate.CertificateRealm \ --property assign-groups=have.client.cert certificate |
Le nouveau certificat <auth-realm> est créé avec la propriété assign-groups .
Arrêtez puis redémarrez le domaine registry d'Application Server.
Lors de l'exécution de l'IG asupgrade dans une langue autre que l'anglais, l'aide en ligne correspondante n'est pas localisée pour la langue sélectionnée.
Aucune pour l'instant. Il est prévu que l'aide en ligne soit localisée dans toutes les langues cibles non anglaises.
Cette section décrit les problèmes connus liés au conteneur Web et les solutions associées.
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.
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. |
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.
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.
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.
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) |
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> |
Les deux paramétrages empêcheront ant de générer un nouveau processus pour la compilation javac .
Sun Java System Application Server 9.1 propose la prise en charge de la fonctionnalité fournie par la fonction du plug-in auth-passthrough disponible sous Sun Java System Application Server Enterprise Edition 7.1. Cependant, dans Application Server 9.1, la fonction du plug-in auth-passthrough est configurée différemment.
La fonction du plug-in auth-passthrough, sous Application Server Enterprise Edition 7.1, était couramment utilisée pour les scénarios de déploiement à 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.
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 Application Server 9.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 considérations de sécurité relatives à la fonction du plug-in auth-passthrough sous Application Server Enterprise Edition 7.1 s'appliquent également à la propriété authPassthroughEnabled sous Application Server 9.1. Étant donné que authPassthroughEnabled permet d'ignorer des informations pouvant être utilisées à des fins d'authentification (telles que l'adresse IP de provenance de la requête ou le certificat client SSL), il est primordial que seuls les clients ou serveurs autorisés puissent se connecter à une instance d' Application Server 9.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.
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.
Ce problème survient uniquement lorsque vous utilisez Sun Java System Web Server avec Application Server 9.1 et l'équilibreur de charge sur un système Linux. Dans ce cas, après avoir installé Application Server et un équilibreur de charge, Web Server risque de ne pas démarrer car libicui18n.so.2 et libicuuc.so.2 sont en conflit. Ces bibliothèques se trouvent dans les répertoires /opt/sun/private/lib et /opt/sun/appserver/lib.
Les bibliothèques à utiliser sont celles stockées dans /opt/sun/appserver/lib car lbplugin en dépend. Une fois les deux bibliothèques supprimées de /opt/sun/private/lib, Web Server devrait démarrer sans aucun problème.
Sinon, si vous ne voulez pas supprimer les bibliothèques de /opt/sun/private/lib , vous pouvez ajouter /opt/sun/appserver/lib avant /opt/sun/private/lib dans le chemin LD_LIBRARY_PATH du script startserv de Web Server ; c'est-à-dire, remplacez :
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="${SERVER_LIB_PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH}: /opt/sun/appserver/lib:/opt/sun/appserver/lbplugin/lib"; export LD_LIBRARY_PATH |
par :
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="/opt/sun/appserver/lib:/opt/sun/appserver/lbplugin/lib: ${SERVER_LIB_PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH}"; export LD_LIBRARY_PATH |
Cette section décrit les problèmes connus liés au conteneur Web et les solutions associées.
Vous pouvez rencontrer ce problème à l'exécution des tests JAX–WS avec JDK 1.6 inclus dans Java EE SDK b33d. Les tests sont immédiatement interrompus avec le message d'erreur suivant :
[wsimport] Exception in thread "main" java.lang.NoClassDefFoundError: \ com/sun/tools/ws/WsImport |
Cette erreur se produit même si le fichier webservices-tools.jar contient les classes com/sun/tools/ws/WsImport.class, com/sun/tools/ws/ant/WsImport.class et com/sun/tools/ws/ant/WsImport2.class. En outre, cet espace de travail test fonctionne normalement avec 1.5.0-10 JDK.
Copiez le fichier webservices-api.jar vers $JAVA_HOME/jre/lib/endorsed avant d'exécuter les tests JAX-WS.
JAXR utilise SAAJ pour envoyer des messages soap au registre. Sans IFR, les classes impl SAAJ se trouvent dans lib/webservices-rt.jar . Avec IFR, les classes SAAJ se trouvent toujours dans lib/webservices-rt.jar . En outre, le fichier saaj-impl.jar est stocké dans le répertoire /usr/share/lib. Ce fichier jar est récupéré par Application Server et est prioritaire par rapport aux classes de webservices-rt.jar . Il ne dispose pas des autorisations de sécurité nécessaires pour envoyer des messages soap au registre des services Web. Le package doit être modifié afin que les fichiers jar disposent des autorisations nécessaires sous le répertoire /usr/share/lib ou que ceux-ci ne dépendent pas des fichiers jar de /usr/share/lib.
Ajoutez les éléments suivants au fichier server.policy :
grant codeBase "file:/usr/share/lib/saaj-impl.jar" { permission java.security.AllPermission; }; |