6171458 

Le script package-appclient ne fonctionne pas si le domaine domain1 n'existe pas.

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.

Solution

Effectuez l'une des opérations suivantes :  

1. Conservez domain1 intact et créez vos propres domaines en tenant compte de celui-ci.

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

6196993 

Impossible de restaurer un domaine enregistré sous un autre nom 

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.

Solution

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.

6200011 

Le démarrage d'Application Server avec un agent JMX supplémentaire n'est pas pris en charge 

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.

Solution

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 journallog. 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 obtenir de plus amples informations, reportez-vous au manuel Administration Guide.

6206176 

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

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/*

6236544, 6275436 

Le fichier de configuration de l'équilibreur de charge n'est pas créé avec l'URL d'extrémité d'un service Web. 

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.

6288893 

Le redémarrage d'serveur d'application à l'aide de sun-appserv-admin génère une erreur LoginException.

Solution

1. Renommez le script existant <as_install> /bin/asant 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.

6315957 

Le fichier .asadmintruststore n'est pas présenté dans la documentation d'serveur d'application. 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

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

6407140 

Les instances de serveur lancées avec la commande start-node-agent ne comprennent pas les contenus de synchronisation les plus récents.

La commande asadmin start-node-agent démarre automatiquement les instances de serveur distant sans les synchroniser avec DAS.

Solution

Si vous installez une instance de serveur distant synchronisée avec le référentiel central géré par DAS, spécifiez l'option --startinstances=false avec la commande asadmin start-node-agent. Utilisez ensuite la commande asadmin start-instance pour démarrer l'instance de serveur distant.

6654726 

La fonctionnalité de la console d'administration permettant de sélectionner les suites de chiffrement ne fonctionne pas correctement. Lorsque vous sélectionnez "Prendre en charge toutes les suites de chiffrement" pour les listeners http, les cases sont décochées. Elles sont cochées de nouveau lorsque la page est actualisée, même si la case "Prendre en charge tout..." est cochée. Même si ceci peut générer un problème, une fois que vous avez saisi le pseudonyme du certificat et cliqué sur Enregistrer, les modifications sont apportées à la configuration.  

Solution

Aucune action n'est requise. Les modifications ont été enregistrées. 

6306784 

Le manuel High-Availability Administration Guide contient des instructions erronées sur l'utilisation de openssl avec Apache.

Solution

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.

6307976 

Le manuel High-Availability Administration Guide ne contient aucune instruction relative à l'utilisation d'un certificat pour Apache 2.0. 

Solution

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.

6308021 

Démarrage du serveur Web Apache uniquement en tant qu'utilisateur root. 

Solution

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.

6308043 

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

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

6193556 

La bibliothèque JAR fournie avec les archives du client d'application écrase le fichier manifeste 

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. 

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. 

6165970 

Les applications utilisant le niveau d'isolement TRANSACTION_SERIALIZABLE avec le pilote Sun intégré de Microsoft SQL Server risquent de s'interrompre 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.

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. Pour obtenir plus d'informations sur la configuration des pools de connexions, reportez-vous au manuel Administration Guide. 

Solution

Aucune pour l'instant. 

6170432 

Erreurs PreparedStatement.

Description #1

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.

Solution #1

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

Pour obtenir plus de détails sur la configuration des pools de connexions, reportez-vous au manuel Administration Guide.

Description #2

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.

Solution #2

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

Description #3

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.

Solution #3

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. Pour obtenir des instructions, reportez-vous au manuel Administration Guide.

6189199 

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

• Les applications utilisant le niveau d'isolement TRANSACTION_SERIALIZABLE avec le pilote Sun intégré pour Sybase Adaptive Server peuvent s'interrompre 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. L'annulation de la connexion échoue avec le message ci-dessous et les connexions annulées ne peuvent plus être utilisées :

  java.sql.SQLException: [sunm][Sybase JDBC Driver]Request cannot be submitted due to wire contention

• Sybase Adaptive Server ne prend pas en charge le niveau d'isolement TRANSACTION_REPEATABLE_READ. Cependant, lors de l'interrogation de DatabaseMetaData, le pilote Sun intégré indique que ce niveau d'isolement est pris en charge par la base de données. Les applications utilisant ce niveau d'isolement vont échouer.

• Les applications utilisant le pilote Sun intégré ne peuvent pas définir le niveau d'isolement TRANSACTION_READ_UNCOMMITTED. L'application génère l'exception suivante lors du premier accès à DataBaseMetaData :

  java.sql.SQLException: [sunm][Sybase JDBC Driver][Sybase]The optimizer could not find a unique index which it could use to perform an isolation level 0 scan on table 'sybsystemprocs.dbo.spt_server_info'.

Solution

Aucune pour l'instant. 

6247468 

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. 

Solution

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

6554602 

Le démarrage avec les pilotes JDBC 10.2 , comprenant plusieurs fichiers jar JDBC dans CLASSPATH, peut entraîner une exception java.lang.SecurityException: Sealing violation exception.

Pour de plus amples informations, reportez-vous à l'ID du document Oracle suivant : 

Remarque : 405446
Objet : Le pilote JDBC 10.2 utilise les fichiers JAR verrouillés et peut entraîner une 
violation de verrouillage pour l'exception de sécurité

Solution

(conseillé par Oracle) Assurez-vous que CLASSPATH ne comprend qu'un seul fichier JAR pour le pilote JDBC.

6188343 

Après avoir redémarré une instance DAS, l'annulation du déploiement du module connecteur échoue lorsque l'option en cascade est définie sur false 

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. 

Plusieurs ID 

Incohérences dans Javadoc. 

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.

6265624 

L'outil ANT intégré génère l'exception java.lang.NoClassDefFoundError.

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 serveur d'application.  

6486123 

La documentation sur la réalisation d'une connexion physique à partir d'une connexion enroulée est désormais erronée. 

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.1 2005Q2 Developer’s Guide du Chapitre 11, Using the JDBC API for Database Access du Sun Java System Application Server Enterprise Edition 8.1 2005Q2 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);

Aucun ID 

Configuration HADB avec double réseau 

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

Aucun ID 

Échec de la création de la base de données HADB 

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.

5052548 

Segments de mémoire partagée bloqués et ne pouvant pas être évacués. 

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 serveur d'application7.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.

5091280 

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

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.

5091349 

Les chemins hétérogènes pour packagepath ne sont pas pris en charge.

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.

6173886, 6253132 

La commande createdomain peut échouer.

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.

6190878 

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

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. 

6230792, 6230415 

Le démarrage, l'arrêt ou la reconfiguration de HADB risque d'échouer ou de se bloquer. 

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. 

6232140 

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

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. 

6249685 

Le processus clu_trans_srv ne peut pas être interrompu.

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. 

6262824 

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

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. 

6265419 

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. 

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. 

6271063 

Conservation du lien symbolique symlink en cas d'installation/de suppression.

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.

6273681 

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

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. 

6275103 

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.

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. 

6275319 

Les utilisateurs non root ne peuvent pas gérer la base de données HADB. 

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. 

6293912 

L'agent de gestion ne doit pas utiliser d'interfaces spécialisées. 

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.

6291562 

Défaillances de réassemblage sous Windows. 

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.

6303581, 6346059, 6307497 

Lorsque la commande hadbm start <db_name> est exécutée, une partie de mot du passe saisi s'affiche.

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 serveur d'application 8.1) et reportez-vous y avec l'option --adminpassword ou --dbpasswordfile.

5009728 

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

Ce problème se produit sur plusieurs systèmes Linux. Il apparaît le plus souvent sur Java Desktop System 2, mais il a également été observé sur les distributions 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. 

6199697 

Sous Windows, le répertoire imq doit être créé lors de l'installation. 

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

   Par exemple :

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

6297837 

Le programme d'installation de serveur d'application affiche la date incorrecte de mise sur le marché du produit dans le nom du produit, "Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q4." 

Solution

La date ou le nom approprié du produit est le suivant "Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q2." 

6396045 

serveur d'application ne prend pas en charge Network File System (NFS). 

Solution

aucune. 

6193449 

Après avoir défini l'intervalle minimum-delivery-interval de la propriété ejb-timer-service sur 9000, la tentative pour définir l'intervalle redelivery-interval-in-mills de la propriété ejb-timer-service sur 7000 entraîne l'échec de la commande set avec l'erreur ci-dessous :

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

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. 

6180095 

Le paramétrage d'une instruction de débogage pour access,failure entraîne un blocage au démarrage d'Application Server.

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. 

6173308, 6189645, 6198481, 6199510, 6208728 

Du fait de la synchronisation, la reconnexion JMS ne s'établit pas toujours correctement 

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

Solution

Pour contourner ces problèmes : 

• Redémarrez les courtiers concernés.

• Redémarrez les instances d'Application Server concernées.

6198465 

Le comportement du listener de messages asynchrone a été modifié dans le conteneur appclient de la version 8.0 vers la version 8.1 Update 2.

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. 

6174518 

Certaines statistiques de contrôle du service HTTP ne contiennent aucune information utile et doivent être ignoré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)

Solution

Ces contrôles seront supprimés dans les versions ultérieures et remplacés par des informations mieux adaptées. 

6191092 

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. 

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

6184797 

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

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.

6204925 

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

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. 

6264969, 6275448 

Problème de mise à niveau lorsque la base de données PointBase est écrasée.  

Lorsque vous effectuez une mise à jour vers serveur d'application Environment Enterprise 8.1 2005Q2 Update 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. 

6195092 

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.

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

• Console1

  cd install_dir\samples\ee-samples asant start-mq-master-broker1

• Console2

  cd install_dir\samples\ee-samples asant start-mq-cluster-broker1

• Console3

  cd install_dir\samples\ee-samples asant start-mq-cluster-broker2

• Console4

  cd install_dir\samples\ee-samples asadmin start-domain domain1

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.

6198003 

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.

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.

6198239 

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

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 rép_install/bin/asant.

Solution

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

6183318 

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

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

• J2SE5.0 PKCS11 ne prend pas en charge le mode UNWRAP

• J2SE 5.0 PKCS11 ne prend pas en charge RSA/ECB/OAEPWithSHA1AndMGF1Padding avec PKCS11

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. 

6269102 

La terminaison SSL ne fonctionne pas ; lorsque l'équilibreur de charge (matériel) est configuré pour la terminaison SSL, serveur d'application passe du protocole https à http au cours de la redirection.

Solution

Ajoutez un équilibreur de charge logiciel entre l'équilibreur de charge matériel et serveur d'application. 

6165528 

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.

Solution

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 .

6207337 

Sur certains systèmes Linux, le programme d'installation effectuant la mise à niveau à son emplacement ne parvient pas à démarrer l'outil de mise à niveau après avoir cliqué sur le bouton Démarrer l'assistant de mise à niveau. 

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. 

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. 

1. Si vous effectuez la mise à niveau à son emplacement en mode d'interface graphique (IG) et que le problème se produit, quittez le programme d'installation en appuyant sur les touches Ctrl+C dans la fenêtre 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-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. 

6296105 

Le certificat autosigné n'est pas approuvé au cours de et après la mise à niveau de 8.0 Platform Edition (PE) vers 8.1 Enterprise Edition (EE) UR2. 

Solution

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>

5004315 

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

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

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

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

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

Diagnostics

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

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

Solution

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

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

6172006 

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

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

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

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

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

Solution

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

6184122 

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

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

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

Solution

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

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

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

  <servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> .... <init-param> <param-name>fork</param-name> <param-value>false</param-value> </init-param> .... </servlet>

• De façon ponctuelle, en définissant la propriété de configuration JSP fork incluse dans le fichier sun-web.xml sur false :

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

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

6188932 

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

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

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

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

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

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

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

Dans serveur d'application Environment Enterprise 8.1 2005Q2 Update 2, la fonctionnalité auth-passthrough peut être activée en définissant la propriété authPassthroughEnabled de l'élément <http-service> du fichier domain.xml sur TRUE comme suit :

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

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

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