test

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

Chapitre 3 Problèmes connus et restrictions

Cette section décrit les problèmes connus relatifs à Sun Java System Application Server Enterprise Edition 8.2 et présente les solutions associées. Si aucune plateformes. Ces informations sont regroupées dans les sections cidessous:

Administration

Cette section traite des problèmes connus liés à l'administration et les solutions associées.

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 :

L'installation du plug-in d'équilibrage de charge remplacera un plug-in existant. (ID 6172977)

Si vous installez le plug-in d'équilibrage de charge sur une installation d'Application Server disposant déjà d'un tel plug-in (7.1EE par exemple), le plug-in 8.2EE remplacera l'équilibreur de charge existant et ce, même si vous avez créé une nouvelle instance de serveur sur laquelle vous exécutez le plug-in.

Les fichiers du plug-in sont installés par défaut dans le répertoire install_dir /plugins/lbplugin, ce qui signifie qu'une seule version d'un plug-in peut être utilisée avec une installation d'Application Server. Notez que le programme d'installation de la console affiche un message indiquant qu'une désinstallation est en cours, mais ce message peut parfois être omis.

Solution

Personne ne rencontrera ce problème. Si vous rencontrez le problème, supprimez l'installation antérieure d'Application Server et procédez à une nouvelle installation plutôt qu'à une mise à niveau.

Plusieurs modifications dans le script asadmin dans JES3 Application Server 8.2 par rapport à JES2 AS7. (ID 6189433, 6189436)

Plusieurs modifications ont été apportées à la commande asadmin dans Application Server 8.2 par rapport à Application Server 7.x. Par exemple, dans 7.x, la commande permettant de démarrer une instance serveur est la suivante :


asadmin start-instance

Dans 8.2, la commande équivalente est la suivante :


asadmin start-domain --user admin domain1

Reportez-vous aux documents suivants pour obtenir des informations complètes sur la syntaxe de la commande asadmin :

Ports par défaut modifiés dans Application Server. (ID 6198555)

Lors d'une mise à niveau de JES2/Application Server 7. x vers JES5/Application Server 8.2, vous pouvez rencontrer des incompatibilités ou des erreurs car les ports par défaut ont changé.

Reportez-vous à la section Autres exigences précédente pour obtenir une liste des ports par défaut utilisés dans Application Server 8.2.

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

Sous UNIX, droits d'exécution trop restrictifs dans les scripts start et stop d'Application Server. (ID 6206176)

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.

Solution

Modifiez les autorisations des scripts: 


chmod 755 appserv/domains/domain-name/bin/*

Le fichier de configuration de l'équilibreur de charge n'est pas créé avec l'URL d'extrémité d'un service Web. (ID 6236544, 6275436)

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.

Solution

  1. 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"/>

  2. Remplacez la valeur context-root-name par le nom de la racine de contexte du service Web présenté comme EJB.

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.

Un redémarrage d'Application Server avec sun-appserv-admin entraîne une erreur LoginException. (ID 6288893)

Ce problème est dû à une valeur erronée de %CONFIG_HOME%.

Solution

  1. Renommez en asant.bak.

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

  3. Modifiez le script copié <as_install> /bin/asant, en remplaçant le jeton %CONFIG_HOME% par <as_install>/config.

  4. En cas de modifications manuelles apportées au fichier asant.bak , fusionnez-les dans le nouveau script asant.

Le fichier .asadmintruststore n'est pas décrit dans la documentation d'Application Server. (ID 6315957)

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.

Solution

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

Modifications de configuration de l'équilibreur de charge dans magnus.conf et obj.conf remplacées. (ID 6394181)

Après la création d'un http-listener sûr et l'installation d'un lbplugin, les fichiers magnus.conf et obj.conf sous webserver_instance_dir/config sont modifiés et le contenu du lbplugin est supprimé.

Le programme d'installation modifie les fichiers de configuration magnus.conf et obj.conf d'Application Server dans le cadre de l'installation du plug-in de l'équilibreur de charge. Si vous vous connectez à la console d'administration d'Application Server et que vous tentez de gérer la configuration d'instance de l'instance sur laquelle l'équilibreur de charge est installé, Application Server renvoie un message d'avertissement indiquant qu'il a détecté une modification manuelle de la configuration. Cet avertissement se rapporte en fait aux modifications apportées par le programme d'installation.

Solution

Vérifiez que les modifications apportées par le programme d'installation ont été remplacées.

Serveur Apache et plug-in de l'équilibreur de charge

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.

Le Guide d'administration de la haute disponibilité contient des instructions erronées sur l'utilisation de openssl avec Apache. (ID 6306784)

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.

Le Guide d'administration de la haute disponibilité ne contient aucune instruction relative à l'utilisation d'un certificat pour Apache 2.0. (ID 6307976)

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.

Démarrage d'Apache Web Server en tant que root obligatoire. (ID 6308021)

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

par


Group nobody

Vous trouverez d'autres informations sur les utilisateurs et les groupes dans le fichier httpd.conf.

Instructions supplémentaires sur l'utilisation de openssl avec Apache Web Server 2.0 sous Solaris. (ID 6308043)

Après avoir installé Apache 2.0 et le plug-in de l'équilibreur de charge, modifiez les fichiers ssl.conf et sll-std.conf de la manière suivante :

Remplacez la ligne :

<VirtualHost _default_:9191>

par

<VirtualHost machine_name:9191>

où machine_name correspond au nom de la machine et 9191 au numéro du port de sécurité.

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.

Pilotes Sun JDBC intégrés

Cette section décrit les problèmes connus du pilote Sun JDBC intégré et les solutions associées.

Les applications utilisant le niveau d'isolement TRANSACTION_SERIALIZABLE avec le pilote Sun intégré pour Microsoft SQL Server risquent de rester bloquées lors de l'utilisation d'une instruction préparée pour la mise à jour si deux transactions parallèles sont en cours d'exécution et que l'une d'entre elles est annulée. (ID 6165970)

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 Enterprise Edition 8.2 Administration Guide pour plus d'informations sur la configuration des pools de connexions.

Erreurs PreparedStatement. (ID 6170432)

Description1

Si une application génère plus de 3000 objets PreparedStatement au cours d'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.

Solution1

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 Enterprise Edition 8.2 Administration Guide pour plus d'informations sur la configuration des pools de connexions.

Description2

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.

Solution2

Augmentez la valeur du paramètre de configuration APPLHEAPSZ pour le serveur DB2. 4096 constitue une valeur correcte.

Description3

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.

Solution3

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 Enterprise Edition 8.2 Administration Guide pour obtenir des instructions.

Problèmes rencontrés lors du paramétrage du niveau d'isolement à l'aide du pilote Sun intégré pour Sybase Adaptive Server. (ID 6189199)

Solution

Aucune pour l'instant.

Sous Solaris 10 et Enterprise Linux 3.0, le pilote intégré JDBC Sun pour Oracle ne permet pas la création d'une connexion. (ID 6247468)

Définissez la propriété ci-dessous dans le pool de connexions JDBC lors de l'utilisation de la source de données Oracle SUN JDBC (com.sun.sql.jdbcx.oracle.OracleDataSource):

<property name="serverType" value="dedicated"/>

La valeur de la propriété dépend de la configuration du listener du serveur Oracle. Si le listener est configuré en mode partagé, la valeur "partagé" qui doit alors s'afficher dans l'exemple ci-dessus doit être remplacée par la valeur "dedicated".

Connecteurs

Cette section décrit les problèmes connus de l'architecture de connecteurs J2EE et les solutions associées.

Après le redémarrage d'une instance DAS, l'annulation du déploiement du module connecteur échoue lorsque l'option en cascade est définie sur false. (ID 6188343)

Dans ce scénario, un module connecteur autonome ou imbriqué est déployé dans l'instance DAS et les pools de connexions du connecteur, et des ressources sont créées pour le module déployé. Après le redémarrage de l'instance DAS, l'annulation du déploiement du connecteur échoue lorsque l'option en cascade est paramétrée sur false et l'exception suivante est générée :

[#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023: Error while unloading application [foo]|#]

Solution

Utilisez l'annulation de déploiement en cascade (en définissant l'option cascade sur true) afin d'annuler le déploiement des connecteurs autonomes et imbriqués après le redémarrage de l'instance DAS.

JMS create-jms-resource ; CLI ne définit pas correctement les valeurs par défaut. (ID 6294018)

Étant donné que vous ne pouvez pas spécifier les tailles de pool minimale et maximale lors de la création d'un nouvelle ressource JMS à partir de la ligne de commande via la commande asadmin create-jms-resource, la commande asadmin est supposée créer la ressource avec les valeurs de taille de pool par défaut (minimale 8, maximale 32). Ce n'est cependant pas le cas. À la place, la création de la ressource à partir de la ligne de commande donne des tailles de pool minimale et maximale par défaut de 1 et 250, respectivement.

Solution

Après la création d'une ressource JMS à partir de la ligne de commande, utilisez la console d'administration pour modifier les valeurs de tailles de pool minimale et maximale.

Documentation

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

Incohérences Javadoc. (Plusieurs ID)

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

L'outil ANT intégré renvoie java.lang.NoClassDefFoundError . (ID 6265624)

L'exception suivante est générée dans le thread principal "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher.

Solution

Il est conseillé de ne pas utiliser l'outil ANT intégré ailleurs que dans Application Server.

Documentation des options de journalisation incorrecte. (ID 6463965)

Le manuel Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide décrit de manière erronée les options de journalisation suivantes :

L'interface utilisateur d'administration propose les deux options de journalisation suivantes :

  • Option 1 – Consigne le contenu stdout ( System.out.print) dans le journal des événements

  • Option 2 – Consigne le contenu stderr ( System.err.print) dans le journal des événements

Ces options de journalisation n'existent plus dans Application Server Enterprise Edition 8.2.

Informations conflictuelles relatives à la fonction de mise en cache de fichier HTTP dans Application Server 8.2. (ID 6474799)

La documentation d'Application Server Enterprise Edition 8.2 décrit une fonction de mise en cache de fichier HTTP, à la section HTTP File Cache du Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide. Cette fonction n'est cependant pas incluse dans Application Server Enterprise Edition 8.2. Notez que cette fonction a été réintroduite dans Application Server 9.0.

La documentation sur la réalisation d'une connexion physique à partir d'une connexion enroulée est désormais erronée (ID 6486123)

Conséquence d'autres défaillances (probablement 6295215), le code fourni dans la section Obtaining a Physical Connection from a Wrapped Connection du Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide du Chapitre 11, Using the JDBC API for Database Access du Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide est désormais erroné. La ligne :


Connection drivercon = ds.getConnection(con);

est maintenant remplacée par :


Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con);

Haute disponibilité

Cette section décrit les problèmes connus de base de données haute disponibilité (HADB) et les solutions associées.

Configuration HADB à double réseau. (Aucun ID)

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:

Échec de la création de la base de données HADB. (Aucun ID)

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.

Solution

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.

Segments de mémoire partagée bloqués et ne pouvant pas évacués. (ID 5052548)

HADB 4.3-0.16 et version ultérieure est configuré pour utiliser une mémoire partagée personnelle lorsqu'il crée et associe ses segments de mémoire partagée (avec l'indicateur SHM_SHARE_MMU). L'utilisation de cet indicateur bloque essentiellement les segments de mémoire partagée d'une mémoire physique et empêche leur évacuation. Ceci entraîne des problèmes dans des installations sur des machines bas de gamme.

Par conséquent, si un développeur dispose d'une machine dotée d'une mémoire de 512 Mo et d'espace de swap disponible et qu'il utilise Application Server7.0 EE, puis la version 7.1 EE ou ultérieure, il rencontrera des problèmes de configuration du cluster clsetup par défaut (qui crée deux nœuds HADB, chacun doté d'une devicesize de 512), ceci entraînant une RAM physique insuffisante pour prendre en charge la mémoire partagée nécessaire aux deux nœuds.

Solution

Vérifiez que vous disposez de la quantité de mémoire recommandée pour accueillir Application Server et HADB. Reportez-vous à la section Configuration requise pour HADB et plates-formes prises en charge pour plus d'informations.

La commande hadbm set ne vérifie pas la disponibilité des ressources (espace disque et mémoire). (ID 5091280)

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.

Solution

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.

Chemins hétérogènes pour packagepath non pris en charge. (ID 5091349)

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.

Solution

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.

Échec de la commande createdomain possible. (ID 6173886, 6253132)

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() ).

Solution

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.

Les répertoires doivent être nettoyés après la suppression d'une instance HADB. (ID 6190878)

Après la suppression d'une instance HADB, les tentatives ultérieures de création de nouvelles instances à l'aide de la commande configure-ha-cluster échouent. Le problème est tel que les anciens répertoires de l'instance HADB d'origine sont conservés dans ha_install_dir/rep/* et dans ha_install_dir/config/hadb/instance_name .

Solution

Veillez à supprimer manuellement ces répertoires après la suppression d'une instance HADB.

Le démarrage, l'arrêt ou la reconfiguration de HADB peut échouer ou être interrompu. (ID 6230792, 6230415)

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.

Solution

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.

L'agent de gestion s'arrête avec l'exception "IPV6_MULTICAST_IF failed". (ID 6232140)

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

Solution

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.

Le processus clu_trans_srv ne peut pas être interrompu. (ID 6249685)

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

Solution

Utilisez la version 32 bits de Red Hat Enterprise Linux 3.0.

La commande hadbm ne prend pas en charge les mots de passe contenant des lettres en majuscules. (ID 6262824)

Les lettres en majuscules sont converties en minuscules lorsqu'un mot de passe est stocké dans hadb.

Solution

N'utilisez pas de mots de passe contenant des lettres en majuscules.

Une mise à niveau inférieur de HADB version 4.4.2.5 vers HADB version 4.4.1.7 entraîne l'échec de la commande ma avec différents codes d'erreur. (ID 6265419)

Lors d'une mise à niveau inférieur d'une version HADB, l'agent de gestion peut échouer avec différents codes d'erreur.

Solution

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.

Installation/suppression et conservation du fichier symlink. (ID 6271063)

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.

Solution

Supprimez le lien symbolique symlink avant l'installation ou après la désinstallation, sauf s'il est en cours d'utilisation.

Il peut y avoir interaction entre les agents de gestion situés dans les zones globales et locales. (ID 6273681)

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.

Solution

N'installez l'agent de gestion que dans une de ces zones.

La commande hadbm/ma doit renvoyer un message d'erreur plus clair lors de l'expiration d'une session et de sa suppression au niveau de l'agent de gestion. (ID 6275103)

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

Solution

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.

Les utilisateurs non root ne peuvent pas gérer HADB. (ID 6275319)

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.

Solution

Connectez-vous toujours en tant que root pour pouvoir gérer la base de données HADB.

L'agent de gestion ne doit pas utiliser d'interface spécialisée. (ID 6293912)

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.

Solution

Lorsque vous utilisez hadbm create sur des hôtes à plusieurs interfaces, spécifiez toujours les adresses IP à l'aide d'une notation DDN.

Échecs de réassemblage sous Windows. (ID 6291562)

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.

Solution

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.

Lorsque vous exécutez hadbm start <db_name>, une partie du mot de passe entré n'est pas masquée. (ID 6303581, 6346059, 6307497)

Il est possible, lorsqu'une machine est en sous-charge, que le mécanisme de masquage échoue et que certains caractères du mot de passe entré soient affichés. Ceci pose un problème mineur de sécurité et le mot de passe doit toujours être masqué.

Solution

Entrez les mots de passe dans les fichiers correspondants (méthode généralement recommandée depuis la version Application Server 8.1) et reportez-vous y avec l'option --adminpassword ou --dbpasswordfile.

JES5 HADB installé dans une zone globale non accessible depuis des zones locales sporadiques. (ID 6460979)

Lorsque Application Server est installé dans une zone globale Solaris dans /usr/SUNWappserver , le composant HADB installé avec cette instance d'Application Server ne sera pas disponible dans des zones locales sporadiques.

Le problème est tel qu'HADB est installé dans /opt/SUNWhadb dans la zone globale, mais ce répertoire n'est pas lisible à partir de zones locales sporadiques. L'ensemble HADB dans JES5 ne peut malheureusement pas être déplacé.

Solution

Étant donné que le composant HADB d'Application Server ne peut pas être déplacé, le composant HADB doit être installé séparément dans chaque zone locale sporadique à partir de laquelle vous souhaitez accéder à HADB.

Installation

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

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

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.

Solution

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, le répertoire imq doit être créé lors de l'installation. (ID 6199697)

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.

Solution

  1. Créez l'emplacement var_home_dir_location avant de créer le courtier :


    $imqbrokerd -varhome var_home_dir_location

    Exemple :


    $imqbrokerd -varhome D:\as\domains\domain1\imq

Vous ne pouvez pas installer le serveur d'application sur RHLAS 3.0 et RHLAS 4.0 sans compat-libstdc++. (ID 6396102)

L'installation de Application Server Enterprise Edition 8.2 sur un système Red Hat Linux Advanced Server (RHLAS) 3.0 ou 4.0 échoue si la bibliothèque compat-libstdc++ n'est pas déjà installée sur le système. Application Server nécessite la bibliothèque compat-libstdc++ sur les systèmes RHLAS mais cette dernière n'est pas installée par défaut. Veuillez noter que ce problème est propre aux systèmes RHLAS.

Solution

Téléchargez et installez le RPM compat-libstdc++ depuis le site http://rpm.pbone.net/index.php3/stat/4/idpl/843376/com/compat-libstdc++-7.3-2.96.118.i386.rpm.html avant d'installer le logiciel Application Server.

La commande lbplugin (libpassthrough.so ) ne peut pas être utilisée lorsque le serveur est exécuté en mode 64 bits. (ID 6480952)

Lorsque vous exécutez Application Server Enterprise Edition 8.2 avec Web Server 7.0 en mode 64 bits, des tentatives d'exécution d'une version 64 bits du plug-in de l'équilibreur de charge échouent avec l'erreur suivante :


failure: CORE2253: Error running Init function load-modules: dlopen 
of /export/home/mareks/opt/webserver7/plugins/lbplugin/bin/libpassthrough.so 
failed (ld.so.1: webservd: fatal: /export/home/mareks/opt/webserver7/plugins/
lbplugin/bin/libpassthrough.so: wrong ELF class: ELFCLASS32)
failure: server initialization failed

Le problème est tel qu'il n'existe pas de plug-in de l'équilibreur de charge 64 bits pour Application Server Enterprise Edition 8.2, et que Web Server 64 bits requiert des plug-ins 64 bits.

Vous pouvez déterminer si Web Server est exécuté en mode 64 bits ou 32 bits à l'aide de la commande suivante :


wadm get-config-prop --user=admin --config=xxx --password-file=xxx platform

Solution

Aucun équilibreur de charge 64 bits n'est prévu pour Application Server Enterprise Edition 8.2. Pour résoudre le problème, utilisez la fonction de proxy inverse de Web Server 7.0 ou configurez l'exécution de Web Server 7.0 en mode 32 bits. Reportez-vous à la documentation de Web Server pour obtenir des instructions.

Impossible d'exécuter asant deploy : “La ligne d'entrée est trop longue” (Windows 2000). (ID 6485174)

Lorsque vous installez Application Server 8.2 à l'emplacement par défaut sous Windows 2000, vous pouvez rencontrer l'erreur suivante lors de l'exécution de la commande asant deploy : 


$ C:/Sun/JavaES5/appserver/bin/asant deploy
The input line is too long.
The syntax of the command is incorrect.

Le problème est tel que les lignes de commande sous Windows 2000 ne peuvent pas dépasser 1000 caractères et que, en fonction de la configuration de votre système, l'environnement ANT_OPTS par défaut peut entraîner une ligne de commande asant deploy trop longue. Ce problème ne se produit que sous Windows 2000.

Solution

Sous Windows 2000, installez Application Server dans un chemin de répertoire court, C:\JES5_AS par exemple.

La documentation sur la réalisation d'une connexion physique à partir d'une connexion enroulée est désormais erronée (ID 6486123)

Conséquence d'autres défaillances (probablement 6295215), le code fourni dans la section Obtaining a Physical Connection from a Wrapped Connection du Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide du Chapitre 11, Using the JDBC API for Database Access du Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide est désormais erroné. La ligne :


Connection drivercon = ds.getConnection(con);

est maintenant remplacée par :


Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con);

Didacticiel J2EE

Pour exécuter le didacticiel J2EE 1.4 sur Sun Java System Application Server Enterprise Edition 8.2, effectuez les tâches suivantes :

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 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\>

Solution

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

L'emplacement de la journalisation/l'instance a changé pour JES3 Application Server. (ID 6189409)

Les emplacements de journalisation et d'instance de serveur par défaut ont changé dans Sun Java System 8.2 par rapport à 7.x.

Pour plus d'informations, reportez-vous au manuel Sun Java System Application Server Enterprise Edition 8.2 Administration Guide ou au manuel Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide.

Message Queue

Cette section décrit les problèmes connus liés aux files d'attente des messages Java et les solutions associées.

Une reconnexion JMS ne se termine pas correctement dans certains cas dépendant de la durée. (ID 6173308, 6189645, 6198481, 6199510, 6208728)

Dans des scénarios faisant appel à la synchronisation, plusieurs causes peuvent être à l'origine de ce problème.

Solution

Pour contourner ces problèmes :

Le comportement du listener de messages asynchrone a été modifié dans le conteneur appclient de la version 8.1 update 2. (ID 6198465)

En raison d'une récente modification, lorsqu'un listener de messages asynchrone est le seul thread actif du conteneur app-client, l'autre machine virtuelle appclient existe en tant que démon. Ce comportement constitue une régression par rapport aux anciennes applications qui effectuent des réceptions asynchrones dans ACC. Ce problème affecte les clients d'application qui installent un listener de messages JMS et quittent le thread principal.

Solution

Ne fermez pas le thread principal. Attendez que le module d'écoute du message avertisse le thread principal avant de fermer ce dernier.

Surveillance

Cette section décrit les problèmes connus liés au contrôle et les solutions associées.

Impossible de modifier le niveau de contrôle du service du connecteur et du pool de connexions du connecteur. (ID 6089026)

Grâce à la page de définition du niveau de contrôle, si vous modifiez le niveau de contrôle du service du connecteur ou du pool de connexions du connecteur en LOW ou HIGH et que vous enregistrez, les deux niveaux ne sont pas modifiés dans le fichier domain.xml du domaine. Toutefois, si vous modifiez le niveau de contrôle du service JMS en LOW ou HIGH et que vous enregistrez, les valeurs du service du connecteur et du pool de connexions du connecteur sont modifiées simultanément. Ce problème ne se produit pas lors de l'exécution des commandes équivalentes à partir de la ligne de commande.

Solution

Utilisez uniquement le composant de service JMS de la page du niveau de contrôle pour modifier les niveaux de contrôle.

Certaines statistiques de contrôle du service HTTP ne contiennent aucune information utile et doivent être ignorées. (ID 6174518)

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 :

Le contrôle de mbean pour un module EJB dont le déploiement est annulé n'est pas supprimé, même si toutes les statistiques regroupées sous ce nom de contrôle sont transférées. (ID 6191092)

Exemple :


EJBModuleMonitorMap().size() = 1  eventhough ejb module is 
undeployed EJBModuleMonitor().getName() = sqe_ejb_s1_01

Cela s'applique aux applications ainsi qu'aux modules EJB. Un mbean de contrôle vide existe même lorsque le contrôle est effectué par le programme (à l'aide de MBeanAPI) ou par les commandes asadmin list/get.

Diagnostics


asadmin list -m "server.applications" shows the following output:
server.applications.MEjbApp
server.applications.__ejb_container_timer_app
server.applications.adminapp
server.applications.admingui
server.applications.com_sun_web_ui
server.applications._export_install_nov-11_domains_domain1_applications
_j2ee-modules_sqe_ejb_s1_01

Vous pouvez consulter les statistiques:


bin/asadmin list -m "server.applications._export_install_nov-11_domains
_domain1_applications_j2ee-modules_sqe_ejb_s1_01"
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01.SQEMessage
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01.TheGreeter

Une fois le déploiement annulé:


_export_install_nov-11_domains_domain1_applications_j2ee-modules_sqe_
ejb_s1_01

Lorsque vous exécutez une commande de liste, l'application est toujours visible:


asadmin list -m "server.applications"
server.applications.MEjbApp
server.applications.__ejb_container_timer_app
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01
server.applications.adminapp
server.applications.admingui
server.applications.com_sun_web_ui

Mais aucune statistique de contrôle n'apparaît :


asadmin list -m "server.applications._export_install_nov-11_domains_
domain1_applications_j2ee-modules_sqe_ejb_s1_01"
Nothing to list at server.applications.-export-install-nov-11-domains-
domain1-applications-j2ee-modules-sqe-ejb-s1-01.

Pour obtenir les noms valides commençant par une chaîne, utilisez le caractère générique (*). Par exemple, pour établir une liste des noms de toutes les entités contrôlables qui commencent par server, indiquez list "server.*".

Solution

Ce problème est sans conséquence. Le module peut être redéployé en toute sécurité. Le Mbean de contrôle root n'est pas supprimé, mais il est vide.

PointBase

Cette section décrit les problèmes connus de PointBase et les solutions associées.

Le paramétrage des niveaux d'isolement pour le pool de connexions d'une application génère des exceptions dans PointBase. (ID 6184797)

Pour un pool de connexions JDBC faisant référence à une installation de base de données PointBase, la définition de l'attribut de pool transaction-isolation-level sur une valeur différente de celle par défaut (Connection.TRANSACTION_READ_COMMITTED) génère une exception. En revanche, pour les pools associés à d'autres bases de données, aucune exception n'est générée lors de la définition de ce même attribut sur des valeurs autres que celles par défaut.

Solution

Ne définissez pas l'attribut transaction-isolation-level pour les pools de connexions JDBC faisant référence à une installation de base de données PointBase.

PointBase génère une exception lorsqu'un serveur réseau est utilisé avec des pilotes imbriqués. (ID 6204925)

Il arrive que la base de données PointBase intégrée renvoie une exception lorsque le pilote du serveur réseau et le pilote imbriqué sont utilisés en même temps.

Solution

N'utilisez pas les deux pilotes simultanément. Choisissez soit le pilote imbriqué, soit le pilote du serveur réseau.

Problème de mise à niveau dans lequel la base de données PointBase par défaut est remplacée. (ID 6264969, 6275448)

Lorsque vous effectuez une mise à jour vers Application Server Enterprise Edition 8.2, le patch de mise à jour écrase la base de données par défaut PointBase.

Solution

Recréez ou entrez à nouveau tout schéma ou toute donnée existants avant la mise à niveau. Si vous avez déployé des applications avec des beans CMP à l'aide de l'option de génération de tables, vous devez annuler le déploiement ou redéployer l'application afin que les tables soient générées à nouveau.

Exemples

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.

Sous Windows, la commande setup-one-machine-cluster reste bloquée tandis que sous Solaris, elle fonctionne correctement ; il faut appuyer sur Ctrl+C pour pouvoir annuler l'exécution de mqfailover, puis la relancer. (ID 6195092)

En cas d'exécution des commandes suivantes dans install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html, :

Si vous avez déjà exécuté asant setup-one-machine-cluster-without-ha ou asant setup-one-machine-cluster-with-ha pour un autre exemple Enterprise Edition, lancez asant configure-mq. Sinon, lancez asant setup-one-machine-cluster-and-configure-mq. La commande semble alors aboutir:


start_nodeagent: [echo] Start the node agent cluster1-nodeagent 
[exec] Command start-node-agent executed successfully.

Néanmoins, le système se bloque pendant une période indéterminée.

Solution

Aucune pour l'instant. Ce problème touche de la même manière tous les exemples des produits Enterprise Edition qui utilisent cette cible ant sous Windows. Pour contourner ce problème, vous pouvez appuyer sur Ctrl+C afin de débloquer le processus avant de le relancer.

Il n'est mentionné nulle part dans la documentation que des ressources JMS doivent être créées avant d'exécuter l'exemple d'application de basculement MQ à l'aide de la commande de déploiement asadmin deploy. (ID 6198003)

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.

Solution

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.

Erreur d'exécution lors de la création de certificats dans les exemples de sécurité/services Web sous Linux. (ID 6198239)

Lors du déploiement de l'exemple install_dir/samples/webservices/security (basicSSl) sous Linux, le certificat '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.

Solution

Effectuez l'une des tâches suivantes :

Documents d'exemples manquants après une mise à niveau de 8.0 Platform Edition vers 8.2 Enterprise Edition

Après une mise à jour de Application Server Platform Edition 8.0 vers Application Server Enterprise Edition 8.2, l'erreur HTTP 404 “Fichier introuvable” peut être renvoyée lors d'une tentative d'accès aux pages d'exemples.

Solution

Copiez les documents d'exemples des domaines 8.0 dans les domaines 8.2.

Échec d'exécution des exemples lors d'une exécution dans une zone locale sporadique. (ID 6460970)

Si Application Server Enterprise Edition 8.2 est installé dans une zone globale Solaris et qu'un domaine Application Server est ensuite installé dans une zone locale sporadique, vous pouvez rencontrer des problèmes d'exécution des applications d'exemples si les autorisations de fichier du domaine de la zone sporadique ne sont pas suffisamment ouvertes lors du processus de déploiement.

Solution

Pendant le processus de déploiement, vérifiez qu'Application Server récupère le fichier JAR client, xmsClient.jar, et copiez-le dans l'emplacement des exemples, (/usr/SUNWappserver/appserver/samples/webservices/security/ejb/apps/xms/xmsClient.jar . Ceci est généralement automatique mais échouera si les autorisations xmsClient.jar ne sont pas ouvertes.

Sécurité

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.

Impossible d'exécuter les applications WebServiceSecurity sur Enterprise Edition avec J2SE 5.0. (ID 6183318)

Les applications WebServiceSecurity ne peuvent être exécutées avec J2SE 5.0 pour les raisons suivantes :

Les membres de l'équipe J2SE ont inclus le message "CR 6190389: Add support for the RSA-PKCS1 and RSA-OAEP wrap/unwrap mechanisms" pour ce bogue.

Solution

Utilisez J2SE1.4.2 avec tout autre fournisseur JCE (autre que celui inclus par défaut). Retenez que cette configuration ne prend pas en charge l'accélération matérielle.

Fin SSL inopérationnelle. (ID 6269102)

Lorsque l'équilibreur de charge (matériel) est configuré pour une fin SSL, Application Server remplace le protocole https par http lors de la redirection.

Solution

Ajoutez un équilibreur de charge logiciel entre l'équilibreur de charge matériel et Application Server.

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 Enterprise Edition 8 en Application Server Enterprise 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.

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 en ligne de commande est utilisé pour procéder à la mise à niveau à son emplacement.

ProcedurePour utiliser le mode d'installation ligne de commande

  1. 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é.

  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.

Le certificat auto-signé n'est pas approuvé pendant et après une mise à niveau de 8.0 Platform Edition (PE) vers 8.1 Enterprise Edition (EE) UR2. (ID 6296105)

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>

Conflit de port après une mise à niveau d'Application Server de JES2 vers JES5

Lorsque vous mettez à jour d'Application Server 7.x en 8.2, vous pouvez rencontrer un conflit de port entre les ancienne et nouvelle installations, principalement avec les ports par défaut 8080 et 8181.

Solution

Modifiez les ports utilisés dans Application Server 8.2 pour résoudre le conflit.

La base de données Derby utilisée par le script exemple est créée à un mauvais emplacement. (ID 6377804)

Ce bogue présente deux aspects :

  1. Lorsque des scripts de configuration d'une application exemple utilisant la base de données Derby sont exécutés, la base de données Derby est créée sous le répertoire en cours ou sous <install_root>/bin.

  2. Le script Ant build exemple crée un fichier password.txt stockant le fichier de mot de passe administrateur sous le répertoire actuel, qui ne sera pas écrit dans des scénarios non root et de zones sporadiques.

Solution

  1. Emplacement de la base de données Derby : utilisez l'option --dbhome avec la commande start-database pour créer la base de données à la valeur spécifiée pour --dbhome. Par exemple, ce qui suit indique la syntaxe de la commande asadmin pour start-database.


    start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] 
[--verbose=false]

  2. Emplacement du fichier password.txt  : le répertoire d'exemples est conçu pour être accessible en écriture puisque toutes les commandes du build comprennent la création d'un fichier password.txt dans ce répertoire. Veillez à installer une copie de travail des exemples à un emplacement accessible en écriture.

LoginException lors d'une mise à niveau de 8.0UR1PE vers 8.2EE ; abandon du processus de mise à niveau. (ID 6445419)

Ce problème apparaît lorsque vous exécutez l'installation de mise à niveau à l'aide d'autorisations d'administration autres que celles par défaut.

Solution

Lorsque vous procédez à une mise à niveau côte à côte à l'aide du programme d'installation à base de fichiers de 8.xPE vers 8.2EE, utilisez les autorisations d'administration du nouveau Application Server:

Après la mise à niveau, vous pouvez changer ces mots de passe si nécessaire.

L'outil de mise à niveau ne détecte pas une entrée de répertoire existante mais non valide dans le champ du répertoire source. (ID 6460122)

L'outil de mise à niveau ne détecte pas une entrée de répertoire existante mais non valide dans le champ du répertoire source et donne l'impression que la configuration du répertoire est correcte.

Un message “Répertoire non valide” devrait s'afficher lorsqu'un chemin incorrect est entré pour le répertoire source. Un message de répertoire non valide s'affiche correctement si /opt/SUNWappserverEE81UR2/ est entré pour le répertoire source. Toutefois, lorsque /opt/SUNWappserverEE81UR2/domains est entré, l'outil poursuit la mise à niveau sans avertissement, même si le chemin n'est pas valide. Ce problème est similaire à l'ID 6440710, si ce n'est que le comportement varie en fonction de la valeur d'entrée.

Solution

Lors d'une mise à niveau de Application Server 7 ou 8.x vers Application Server 8.2, le répertoire source doit tout d'abord être basé sur la valeur indiquée dans la documentation : root de domaine pour des mises à niveau sur place et répertoire de domaine pour des mises à niveau côte à côte.

Ne doit pas valider le nom d'utilisateur/de mot de passe administrateur avec point-virgule (;). (ID 6473341)

L'installation d'Application Server Enterprise Edition 8.2 n'autorise pas les caractères spéciaux dans le nom d'utilisateur administrateur. La création de domaine échouera si un caractère spécial est utilisé. Notez, cependant, que le mot de passe administrateur peut contenir des caractères spéciaux.

Solution

Lors d'une mise à niveau de Application Server 7 vers Application Server 8.2, vérifiez que le nom d'utilisateur administrateur ne contient pas de caractères spéciaux.

Conteneur Web

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

Sous Windows, le déploiement d’une application à l’aide de la commande --precompilejsp=true peut verrouiller les fichiers JAR de l’application, entraînant l’échec des redéploiements et annulations de déploiement ultérieurs. (ID 5004315)

Si vous devez effectuer une précompilation des pages JSP lors du déploiement d’une application sous Windows, les tentatives ultérieures de redéploiement ou d’annulation de déploiement de cette application (ou de toute autre application contenant le même ID de module) ne fonctionneront pas comme prévu. L’origine de ce problème provient du fait que la précompilation des pages JSP ouvre les fichiers JAR dans votre application, mais ne les referme pas. Windows empêche alors que le processus d’annulation du déploiement ne supprime ces fichiers ou que le processus de redéploiement ne les écrase.

Il est à noter que l’annulation du déploiement réussit partiellement dans la mesure où l’application est supprimée d’Application Server. Notez aussi qu'aucun message d'erreur n'est retourné par l'utilitaire asadmin, mais que le répertoire de l'application et les fichiers jar verrouillés ne sont pas supprimés du serveur. Le fichier journal du serveur contient les messages décrivant l'échec de la suppression des fichiers et du répertoire de l'application.

Toute tentative de redéploiement de l’application suite à l’annulation du déploiement échoue, car le serveur essaie en vain de supprimer le répertoire et les fichiers existants. Cela peut se produire si vous essayez de déployer une application qui utilise le même ID de module que celui de l'application initialement déployée. En effet, le serveur utilise cet ID de module lors de la sélection d'un répertoire destiné à contenir les fichiers de l'application.

Les tentatives de redéploiement de l'application sans annulation préalable du déploiement échouent pour les mêmes raisons.

Diagnostics

Si vous essayez de redéployer l’application ou de la déployer après avoir annulé son déploiement, l’utilitaire asadmin renvoie une erreur similaire à l'erreur ci-dessous.


An exception occurred while running the command. The exception 
message is: CLI171 Command deploy failed : Deploying application in 
domain failed; Cannot deploy. Module directory is locked and can't 
be deleted.

Solution

Ce problème ne se produit pas si vous définissez le paramètre par défaut --precompilejsps=false lors du déploiement d’une application. Lors de sa première utilisation, l'application déclenche la compilation des pages JSP. C'est pour cette raison que le temps de réponse de la première requête est supérieur à celui des requêtes suivantes.

Notez également qu’en cas de précompilation, vous devez arrêter et redémarrer le serveur avant d’annuler le déploiement de l’application ou de redéployer cette dernière. L’arrêt du serveur permet de libérer les fichiers JAR qui étaient verrouillés et d’effectuer correctement les opérations d’annulation du déploiement ou de redéploiement de l’application après le redémarrage.

Impossible de déployer les archives WAR avec le fichier web.xml basé sur le composant Servlet 2.4 comprenant un élément <load-on-startup> vide. (ID 6172006)

L’élément facultatif load-on-startup inclus dans le fichier web.xml indique que le servlet correspondant doit être chargé et initialisé au démarrage de l'application Web à laquelle il appartient.

Le contenu facultatif de cet élément est un nombre entier précisant en quelle position le servlet doit être chargé et initialisé par rapport aux autres servlets de l'application Web. Lorsque l'élément <load-on-startup> est vide, l'ordre de démarrage du servlet est inutile tant que celui-ci est chargé et initialisé au cours du démarrage de l'application Web dont il dépend.

Le schéma Servlet 2.4 du fichier web.xml ne prend plus en charge les éléments <load-on-startup> vides, ce qui signifie que vous devez obligatoirement indiquer un nombre entier lorsque vous utilisez un fichier web.xml basé sur le composant Servlet 2.4. Si vous laissez l’élément <load-on-startup> vide, tel que <load-on-startup/>, le fichier web.xml ne parvient pas à valider le schéma Servlet 2.4, provoquant l’échec du déploiement de l’application Web.

Problème de compatibilité ascendante: Vous pouvez néanmoins laisser l'élément <load-on-startup> vide pour un fichier web.xml basé sur le composant Servlet 2.3.

Solution

Définissez la valeur <load-on-startup>0</load-on-startup> lors de l'utilisation d'un fichier web.xml basé sur Servlet 2.4 afin d'indiquer que l'ordre de chargement du servlet n'est pas important.

Impossible de compiler la page JSP sur des serveurs limités en ressources. (ID 6184122)

La page JSP est accessible mais ne peut pas être compilée. Le journal du serveur contient le message d’erreur "Impossible d'exécuter la commande" avec le suivi de pile suivant :


at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.
exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute.
launch(Execute.java:416) 
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) 
at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.
executeExternalCompile(DefaultCompilerAdapter.java:448) 
at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute
(JavacExternal.java:81) 
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) 
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) 
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396)

Solution

Définissez le commutateur de compilation JSP fork sur false.

Vous pouvez effectuer cette opération de l'une des deux manières suivantes:

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

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

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

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

Dans de telles architectures réseau, un client se connecte à un serveur Web frontal préalablement configuré pour fonctionner avec la fonction de plug-in service-passthrough et transfère les requêtes HTTP à l'instance d' Application Server pour traitement via un proxy. Cette instance d'Application Server ne peut recevoir de requêtes que via le proxy du serveur Web mais ne peut pas en recevoir directement de la part d'hôtes clients. Par conséquent, toute application déployée sur l'instance d'Application Server qui envoie par proxy des requêtes pour obtenir des informations clientes (l'adresse IP du client par exemple) reçoit l'IP proxy de l'hôte par lequel la requête est relayée.

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

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


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

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

Il est à noter que dans le cas où le plug-in service-passthrough a été configuré sur un serveur Web proxy qui relaie les requêtes vers une instance d'Application Server 8.1 Update 2 pour laquelle la propriété authPassthroughEnabled a été définie sur TRUE, l'authentification cliente SSL peut être activée sur le proxy du serveur Web et désactivée sur celui de l'instance d'Application Server 8.1 Update 2. Dans ce cas, l'instance d'Application Server 8.1 Update 2 utilisant un proxy continue de traiter les requêtes comme si elles étaient authentifiées via SSL et fournit un certificat SSL client aux applications déployées lorsque nécessaire.

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

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

Solution

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

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

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

Solution

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


asant keydel
asant deploy