Cette section traite des problèmes connus liés à l'administration et les solutions associées.
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.
Effectuez l'une des tâches suivantes :
Laissez domain1 intact et créez vos propres domaines en tenant compte de celui-ci.
Supprimez domain1 et remplacez la valeur à code permanent de domain1 dans $INSTALL/lib/package-appclient.xml par le nouveau nom de domaine. Cette opération devra être répétée à chaque création de domaine, si domain1 n'existe pas.
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.
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 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 :
Sun Java System Application Server Enterprise Edition 8.2 Administration Guide
Sun Java System Application Server Enterprise Edition 8.2 Reference Manual
Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide
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.
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.
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.
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.
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.
Si vous exécutez la commande asadmin restore-domain lorsque vous êtes connecté en tant qu'utilisateur A, les scripts seront dotés des autorisations 744 (rwxr--r--
). Si vous tentez par la suite de démarrer ou d'arrêter un domaine en tant qu'utilisateur B, l'opération risque d'échouer (même si B désigne l'utilisateur root), car les scripts ne peuvent être exécutés que par l'utilisateur A.
Modifiez les autorisations des scripts:
chmod 755 appserv/domains/domain-name/bin/* |
Lors de la configuration de l'équilibreur de charge avec une application dotée d'un module EJB qui exporte l'URL d'un service Web, la racine du contexte du service Web ne figure pas dans le fichier loadbalancer.xml en résultant.
Modifiez le fichier loadbalancer.xml de manière à ajouter le module Web manquant comme suit :
<web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/> |
Remplacez la valeur context-root-name par le nom de la racine de contexte du service Web présenté comme EJB.
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.
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.
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.
Ce problème est dû à une valeur erronée de %CONFIG_HOME%.
Renommez 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.
Si ce fichier n'existe pas dans le répertoire home de l'administrateur, vous pouvez rencontrer de graves bogues lors de la mise à niveau d'applications hébergées sur le serveur.
Si possible, la commande asadmin start-domain domain1 doit être exécutée par l'utilisateur qui a installé le serveur.
Dans le cas contraire, le fichier .asadmintruststore doit être déplacé ou copié du répertoire home de l'utilisateur qui a procédé à l'installation dans le répertoire home de l'utilisateur qui l'exécute.
Notez que si le fichier est déplacé (et non copié) du répertoire home de l'utilisateur "installateur" dans le répertoire home de l'utilisateur "exécuteur", vous pouvez rencontrer des problèmes de mise à niveau de l'application, tels que décrits dans les bogues 6309079, 6310428 et 6312869 car l'utilisateur de mise à niveau/installation (généralement root dans Java ES) ne disposera plus du fichier .asadminstruststore dans son répertoire home.
Le domaine ne démarre pas lorsque le mot de passe principal du domaine contient le caractère %.
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.
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.
Vérifiez que les modifications apportées par le programme d'installation ont été remplacées.