|
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 :
-
Conservez domain1 intact et créez vos propres domaines en tenant compte de celui-ci.
-
Supprimez domain1 et remplacez la valeur codée en dur de domain1 dans $INSTALL/lib/package-appclient.xml par le nouveau nom de domaine.
Cette procédure devra être effectuée à chaque création d'un nouveau domaine si domain1 n'est pas présent.
|
|
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
-
Modifiez le fichier loadbalancer.xml de manière à ajouter le module Web manquant comme suit :
<web-module context-root="context-root-name"
disable-timeout-in-minutes="30" enabled="true"/>
|
-
Remplacez la valeur context-root-name par le nom de la racine de contexte du service Web présenté comme EJB.
|
|
6288893
|
Le redémarrage d'serveur d'application à l'aide de sun-appserv-admin génère une erreur LoginException.
Solution
-
Renommez le script existant <as_install> /bin/asant en asant.bak.
-
Copiez le fichier asant.template de <as_install> /lib/install/templates/ee (pour la version SE/EE) dans le répertoire <as_install>/bin/ et renommez-le en asant.
-
Modifiez le script copié <as_install> /bin/asant, en remplaçant le jeton %CONFIG_HOME% par <as_install>/config.
-
En cas de modifications manuelles apportées au fichier asant.bak , fusionnez-les dans le nouveau script asant.
|
|
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.
|
