© Copyright International Business Machines Corporation 2006. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
L'option Minimiser les fichiers d'application copiés sur le serveur n'est prise en compte qu'à compter de l'édition 6.0.2.5 de WebSphere® Application Server.Cette case est toujours présente dans l'éditeur de serveur, mais elle est sans effet si vous la cochez pour un serveur d'une édition antérieure à la 6.0.2.5 (par exemple, une instance de WebSphere Application Server V6.0).
Si un module EJB (Enterprise JavaBean) est partagé entre plusieurs projets EAR exécutés sur un serveur WebSphere Application Server et que l'un de ces projets est retiré du serveur, les autres projets EAR doivent être redémarrés pour pouvoir accéder à nouveau aux ressources telles que les beans EJB contenues dans le projet EJB.
Si vous ne prenez pas cette mesure, il se peut que vous receviez des messages d'erreur similaires à l'exemple ci-après.Ces erreurs se produisent parce que les noms JNDI (Java Naming and Directory Interface) figurant dans le projet EJB sont supprimés du serveur lorsque le projet EAR est retiré.
Exemple de message d'erreur :
00000028 SystemOut O javax.naming.NameNotFoundException: Context: myCell/nodes/myNode/servers/server1, name: ejb/ejbs/Session20Home: First component in name Session20Home not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249)
at ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50)
at ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80)
at ejbs.Session20AccessBean.foo(Session20AccessBean.java:91)
En raison des différents comportements et des diverses interactions entre les environnements d'exécution Eclipse et WebSphere, vous devez effectuer des étapes supplémentaires lorsque vous exécutez un client d'application WebSphere à unités d'exécution multiples par le biais d'une configuration de lancement. La boîte de dialogue de gestion et de création de configurations de lancement est disponible dans la perspective J2EE, lorsque vous sélectionnez Exécuter > Exécuter sur la barre d'outils du produit. Si votre client utilise plusieurs unités d'exécution (threads) ou repose sur une infrastructure susceptible d'utiliser des unités d'exécution additionnelles (par exemple, Swing), vous devez effectuer les étapes supplémentaires suivantes :
- Dans la boîte de dialogue de gestion et de création de configurations de lancement, sélectionnez l'onglet Arguments.Dans le champ de texte Arguments VM, spécifiez le paramètre suivant :
-Dosgi.noShutdown=true- Assurez-vous que votre client d'application appelle la méthode System.exit()
Si vous ne prenez pas ces mesures, vous risquez de rencontrer des problèmes liés au chargement des classes ou à des JVM qui ne se terminent pas une fois que l'application a cessé de fonctionner.
Supposons que vous ayez un projet (par exemple, un client d'application) configuré comme suit :
- La facette de projet Java est configurée pour la version 1.4.
- L'option Activer le remplacement de méthode à chaud est cochée dans la configuration du serveur utilisé comme environnement d'exécution cible de ce projet.
Dans ces conditions, il se peut que le bouton Reprendre dans la vue Débogage ne fonctionne pas correctement. Par exemple, cela peut arriver lorsque vous exécutez l'application en mode débogage sur le serveur et que vous tentez de changer le code source pendant l'exécution, puis que vous utilisez le bouton Reprendre pour poursuivre le débogage de l'application. Vous constatez alors que vos modifications apportées au code source (remplacement de méthode à chaud) n'ont pas été prises en compte.
Dans ce cas, cliquez à deux reprises sur le bouton Reprendre pour permettre aux modifications d'être appliquées au code en cours d'exécution.
Remarque : Ce problème ne se produit pas lorsque la facette de projet Java est configurée pour la version 5.0.
Le bouton Supprimer de la boîte de dialogue Gestion des serveurs WebSphere partagés ne fonctionne pas correctement.
Conseil : Pour ouvrir la boîte de dialogue Gestion des serveurs WebSphere partagés :
- Sur la barre de menus principale, sélectionnez Fenêtre > Préférences.La boîte de dialogue Préférences s'affiche.
- Dans le volet gauche, sélectionnez Serveur > WebSphere > WebSphere v51.
- Dans le volet droit, cliquez sur le bouton Gérer à droite de l'option Serveurs WebSphere partagés.Vous obtenez la boîte de dialogue Gestion des serveurs WebSphere partagés.
Si vous utilisez le bouton Supprimer dans cette boîte de dialogue, le serveur concerné semble bien être supprimé.Cependant, si vous fermez la boîte de dialogue puis que vous la rouvrez et cliquez sur le bouton Régénérer, le serveur précédemment supprimé réapparaît.
Pour contourner ce problème, vous pouvez supprimer manuellement l'entrée du serveur partagé en procédant comme suit :
- Ouvrez le fichier id.txt situé dans le répertoire suivant :
<répertoire>/plugins/com.ibm.etools.websphere.tools*/properties
où <répertoire> est le répertoire d'installation d'Agent Controller.- Supprimez l'entrée faisant référence au serveur partagé que vous souhaitez supprimer.
- Supprimez le répertoire de déploiement WebSphere qui a été spécifié pour ce serveur partagé durant sa création, ainsi que tous ses sous-répertoires. Par exemple, vous devez supprimer les sous-répertoires config, installedApps, temp ainsi que tous les autres sous-répertoires et fichiers qui se trouvent sous ce répertoire.
- Dans la boîte de dialogue Gestion des serveurs WebSphere partagés, spécifiez un nom d'hôte et cliquez sur le bouton Régénérer pour vérifier que le serveur partagé a bien été supprimé.
Lorsque vous utilisez l'assistant Nouveau serveur, si des serveurs additionnels tels qu'un serveur Web IBM HTTP Server sont installés au sein du même profil WebSphere Application Server v6.x, il est possible que les numéros de port RMI ou SOAP ne soient pas identifiés correctement sur la page Paramètres du serveur WebSphere de l'assistant. Il se peut aussi que le numéro de port de la console d'administration ne soit pas affiché.
Lorsque l'assistant Nouveau serveur ne peut pas obtenir les numéros de port réellement définis pour un serveur, son comportement par défaut est de préremplir les champs correspondants avec les numéros de port par défaut, à savoir 2809 pour RMI et 8880 pour SOAP.
Si des numéros de port incorrects sont définis, il est possible que vous rencontriez les problèmes suivants :
- Connexion impossible au nouveau serveur. Par exemple, vous ne pourrez pas le démarrer ni l'arrêter.
- Ouverture impossible de la console d'administration depuis ce nouveau serveur. La conséquence est que vous recevrez une erreur "port de la console d'administration non défini".
- Exécution impossible d'applications sur ce serveur. Par exemple, la commande Exécuter sur le serveur ne fonctionnera pas.
Solution :
- Déterminez les valeurs de port d'un profil configuré en vous référant à ses fichiers de configuration de serveur. Elles sont stockées dans le fichier serverindex.xml situé dans le répertoire suivant :
<répertoire>\profiles\<nomProfil>\config\cells\<nomCellule>\nodes\<nomNoeud>, où <répertoire> est le répertoire d'installation de WebSphere Application Server.
Utilisez le fichier serverindex.xml pour remplir le tableau ci-après et déterminer ainsi les numéros de port réellement définis pour votre serveur :
Nom du port Description du port Numéro de port par défaut Votre numéro de port SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Console d'administration 9060 WC_defaulthost Transport HTTP 9080 - Pour permettre la connexion au serveur, lorsque vous le créez, spécifiez le numéro de port RMI ou SOAP correct.
- Pour démarrer la console d'administration, utilisez un navigateur Web externe et, dans le champ d'adresse, tapez l'URL d'accès à la console d'administration en veillant à y inclure le bon numéro de port :
http://<nom_machine>:<WC_adminhost>/IBM/console
Par exemple : http://localhost:9060/IBM/console- Pour exécuter une application sur le serveur, utilisez la commande Exécuter sur le serveur. A l'ouverture du navigateur Web, corrigez l'URL en y incluant le numéro de port du transport HTTP défini pour votre serveur.
http://<nom_machine>:<WC_defaulthost>/<RacineContexte>/<page_démarrage_application>
Par exemple : http://localhost:9080/MonApplication/index.jsp
Remarque : Les serveurs définis automatiquement dans la vue Serveurs peuvent ne pas être configurés avec les numéros de port corrects. Dans ce cas, appliquez la procédure ci-dessus pour remédier à la situation.
L'outil Gestion de profil de WebSphere Application Server permet de créer le profil de chaque environnement d'exécution. Vous pouvez le lancer à partir du plan de travail.Cependant, sur les machines à processus 64 bits, cet outil ne fonctionne pas. Utilisez à la place l'outil de ligne de commande manageprofiles fourni par WebSphere Application Server.
Sur les systèmes d'exploitation Windows, si vous utilisez le port RMI (Remote Method Invocation) pour vous connecter à votre serveur WebSphere Application Server v6.x, l'établissement d'une nouvelle connexion au serveur après la perte de connectivité réseau peut être relativement long. Cela peut arriver même si le serveur est installé localement et que la connectivité réseau n'est perdue que temporairement, ce qui n'est pas rare dans les environnements réseau sans fil.
Si vous savez que le serveur est démarré mais que son statut affiché dans la vue Serveurs est Arrêté ou Démarrage, essayez d'établir une connexion en utilisant le port SOAP à la place du port RMI. Le statut du serveur devrait alors passer à Démarrer.Vous disposez de plusieurs options pour établir la connexion à un serveur dans un environnement réseau sans fil :
- L'option la plus simple et la plus sûre est de configurer votre connexion pour qu'elle utilise le port SOAP. Après une perte de connectivité réseau, les connexions SOAP se rétablissent plus rapidement que les connexions RMI.
- Si vous utilisez une connexion RMI, vous pouvez essayer de modifier le paramétrage par défaut de la mise en cache du système de noms de domaine (DNS) sous Windows. Pour plus de détails, consultez l'article suivant du site de support Microsoft :
http://support.microsoft.com/kb/318803
Les systèmes d'exploitation Windows intègrent une fonction de mise en cache DNS qui mémorise les noms d'hôte résolus. Son rôle est d'offrir des temps de réponse plus rapides lors des recherches DNS. Elle a cependant pour inconvénient majeur d'induire des temps de réponse très longs en cas d'échec (réponse négative) d'une recherche DNS.Windows met en cache la réponse négative pour une durée de 300 secondes (5 minutes) par défaut. Par conséquent, même si peu après l'échec le serveur DNS est en mesure de résoudre la recherche, il ne tente pas de nouvelle recherche tant que la durée de mise en cache de la réponse négative n'est pas expirée. Avec ce paramétrage par défaut, le délai d'attente avant une nouvelle recherche peut donc atteindre cinq minutes. En réglant la durée de mise en cache à zéro (0), vous forcez Windows à ne jamais mettre en cache les réponses négatives aux recherches DNS, si bien que la reconnexion peut avoir lieu dès que le DNS est à nouveau disponible.
Voici un exemple montrant comment désactiver la mise en cache DNS des réponses négatives sur les systèmes d'exploitation Windows :
Dans la clé de registre suivante : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Ajoutez l'une des valeurs de registre suivantes :
- Pour Windows XP/2003 :
"MaxNegativeCacheTtl"=dword:00000000- Pour Windows 2000 :
"NegativeCacheTime"=dword:00000000
Republier l'application, la redémarrer ou la désinstaller puis la réinstaller ne sont pas des actions suffisantes pour faire prendre en compte au serveur une variété de changements de ressources effectués sur la page Déploiement de l'éditeur de Descripteur de déploiement d'application. On sait notamment que le serveur ne tient pas compte d'un changement de nom de la base de données associée à une source de données. Il est possible qu'il ignore également d'autres changements.
En guise de solution de rechange, effectuez les étapes suivantes pour appliquer les modifications sur le serveur :
- Arrêtez le serveur.
- Dans la vue Serveurs, cliquez avec le bouton droit sur le serveur et sélectionnez Arrêter.
- Attendez que le statut du serveur devienne Arrêté et passez à l'étape suivante.
- Démarrez le plan de travail.
Remarque : Si le serveur ne démarre pas, vous devez utiliser les fonctions de votre système d'exploitation pour arrêter le processus java dans lequel il s'exécute.Vous pouvez sinon redémarrer le plan de travail, puis essayer à nouveau de démarrer le serveur.- Démarrez le serveur.
- Dans la vue Serveurs, cliquez avec le bouton droit sur le serveur et sélectionnez Démarrer.
- Dans la vue Serveurs, attendez que la republication soit terminée et que le statut Démarré soit indiqué à la fois pour le serveur et l'application, puis passez à l'étape suivante.
- Exécutez votre application sur le serveur (par exemple, à l'aide de la commande Exécuter sur le serveur).Le serveur doit maintenant être en mesure de tenir compte des changements effectués dans l'éditeur Descripteur de déploiement d'application.
Si vous ajoutez un fichier JAR d'utilitaire aux bibliothèques Web d'un projet Web et que vous insérez, dans le code de votre application, des références à des classes contenues dans ce fichier JAR, il est possible que vous receviez une erreur java.lang.NoClassDefFoundError en tentant d'exécuter l'application sur le serveur.
Pour éviter cette erreur, ajoutez le fichier JAR à la liste des dépendances de module J2EE après l'avoir ajouté au module EAR. Voici comment procéder :
- Ajoutez votre fichier JAR d'utilitaire au module EAR.Pour la procédure détaillée, consultez la rubrique d'aide Ajout de fichiers JAR d'utilitaire de projet.
- Cliquez avec le bouton droit sur votre projet Web et sélectionnez Propriétés.La boîte de dialogue Propriétés s'ouvre.
- Sélectionnez Dépendances de module J2EE.
- Sous l'onglet Modules J2EE, dans la colonne JAR/Module, cochez la case de votre fichier JAR d'utilitaire.
Si un serveur WebSphere Application Server V6.1 fonctionne sur une connexion SOAP sécurisée, il n'est pas possible d'établir une autre connexion SOAP sécurisée à un serveur WebSphere Application Server V6.0, sous peine de la faire échouer.Le même problème se manifeste dans le cas inverse, c'est-à-dire si un serveur WebSphere Application Server V6.0 fonctionne sur une connexion SOAP sécurisée et que vous tentez d'établir une autre connexion SOAP sécurisée à un serveur WebSphere Application Server V6.1.Cependant, le problème ne se produit pas si le serveur est défini dans la vue Serveurs et que son statut est vierge (aucune mention dans la colonne Statut).
La solution est d'établir une connexion RMI sécurisée au serveur au lieu d'une connexion SOAP ou d'utiliser une connexion SOAP non sécurisée.
Si le serveur distant est arrêté, l'assistant Nouveau serveur peut tarder à aboutir lorsque vous cliquez sur le bouton Terminer.Une solution consiste à démarrer le serveur distant avant de cliquer sur le bouton Terminer de l'assistant Nouveau serveur.
Si un fichier portant l'extension .war est placé dans le dossier EarContent d'un projet EAR et qu'il n'est pas défini comme module Web dans le fichier application.xml, la publication de l'application d'entreprise sur le serveur échoue avec un message d'erreur de la forme suivante :
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E Impossible d'ouvrir l'archive imbriquée "abc.war" dans "D:\Mon espace de travail\MonApplicationEAR\EarContent"Cette erreur est due au fait que le plan de travail ne peut pas traiter le fichier correctement en tant que module Web.Appliquez l'une des solutions suivantes :
- Si le fichier est un module Web, ajoutez-le comme module à l'application d'entreprise.Pour la procédure détaillée, consultez la rubrique d'aide Ajout de modules à une application d'entreprise.
- Si le fichier n'est pas un module Web, vous pouvez éviter ce problème de publication en remplaçant son extension par quelque chose d'autre que .war (par exemple, .jar).
Lorsque la destination d'une application est un serveur distant WebSphere Application Server V5.1 ou WebSphere Application Server V5.1 Express Edition, si vous changez le répertoire de déploiement et le répertoire de publication dans l'éditeur de serveur et que vous republiez ensuite l'application, celle-ci continue à être publiée vers l'ancienne destination.Vos changements de répertoires de publication et de déploiement ne sont donc pas appliqués. Ce problème se manifeste aussi bien avec la méthode de copie locale que la méthode de transfert FTP.
La solution est de redémarrer le plan de travail.Vos changements de configuration doivent alors être pris en compte.
Dans cette nouvelle version du produit, le stockage des projets bénéficie d'une approche plus souple qui a pour conséquence un changement de technique de publication des applications.Les applications sont maintenant copiées avant d'être publiées sur le serveur. La durée nécessaire à cette opération de copie vient s'ajouter à celle de la publication proprement dite. Si votre application est particulièrement volumineuse (par exemple, plus de 100 méga-octets), vous sentirez une nette augmentation du temps nécessaire à sa publication (par rapport à ce que vous aviez l'habitude de constater dans la version précédente).
Il n'existe pas actuellement de solution. IBM® travaille sur une mise à jour qui supprimera la nécessité de procéder à cette opération de copie dans la plupart des cas.
Si un serveur WebSphere Application Server v6.1 sécurisé est démarré et que, dans l'éditeur de serveur, vous changez le type de connexion à ce serveur (par exemple, vous passez de RMI à SOAP ou l'inverse), il est possible que vous receviez le message d'erreur suivant après avoir enregistré les modifications apportées dans l'éditeur :
La publication n'est pas effectuée car le serveur n'est pas démarré.Démarrez le serveur avant d'effectuer l'opération de publication.
Vous pouvez ignorer cette erreur en toute sécurité.Si besoin est, une fois que le statut du serveur dans la vue Serveurs est Démarré, vous pouvez lancer une commande de publication (dans la vue Serveurs, cliquez avec le bouton droit sur le serveur et sélectionnez Publier).
Lorsque vous tentez de générer une source de données en utilisant l'assistant Créateur de tables et de sources de données, il est possible qu'une erreur TargetInvocationException soit signalée dans la section Détails de la boîte de dialogue Résultats de la création de tables et de sources de données.
L'erreur TargetInvocationException peut se produire si vous importez un projet en utilisant le format d'échange de projets et qu'il contient des sources de données dont les noms JNDI sont en conflit avec ceux de sources existantes dans votre plan de travail.
Pour éviter l'erreur TargetInvocationException, déterminez s'il existe dans votre plan de travail une source de données ayant le même nom JNDI qu'une source présente dans le projet que vous importez.Dans l'affirmative, supprimez-la de la page Déploiement de l'éditeur Descripteur de déploiement d'application et recréez-la en lui attribuant un nom JNDI différent. Chaque source de données doit porter un nom JNDI différent, car JNDI (Java Naming and Directory Interface) est un service de nommage et de recherche utilisé pour lier un bean enterprise à une source de données.
Lorsque vous arrêtez un serveur à partir de la vue Serveurs, il est possible que son arrêt ne soit pas complet.Même si le serveur est signalé comme Arrêté dans la vue Serveurs, il est possible que son processus soit encore dans un état de non-réponse.Cela arrive généralement lorsque des artefacts tels que votre application ou le plan de travail lui-même détiennent encore des références à des classes sur le serveur.Exemples de scénarios pouvant provoquer cet incident :
- Des applications sont dans une boucle sans fin ou une application maintient des références à certaines classes sur le serveur.
- Des applications établissent une connexion à une base de données Cloudscape ou Derby sans la nettoyer (la fermer) lorsqu'elles n'en ont plus l'utilité.
- Dans l'assistant Nouvelle connexion des outils de données, vous avez utilisé le bouton Tester la connexion pour ouvrir une connexion à une base de données Cloudscape ou Derby sans ensuite vous déconnecter de cette base de données.
Restriction : En raison d'une limite de configuration de Cloudscape ou Derby, il n'est pas possible d'établir simultanément plusieurs connexions à une même base de données Cloudscape ou Derby. Si une connexion à une base de données Cloudscape ou Derby est restée ouverte à partir de l'Explorateur de bases de données, le serveur ne pourra pas établir de seconde connexion à cette base de données à travers une source de données. Vous devez donc fermer la connexion établie depuis l'Explorateur de données avant qu'un serveur puisse lui-même établir une connexion à la base de données.
Solution : Utilisez les fonctions de votre système d'exploitation pour arrêter le processus java sur lequel le serveur s'exécute.Une autre solution consiste à redémarrer le plan de travail afin de le forcer à libérer toute référence aux classes sur le serveur.Si vous êtes dans le troisième cas décrit plus haut, vous pouvez utiliser la vue Explorateur de bases de données pour vous connecter à la base de données Cloudscape ou Derby, puis vous en déconnecter.
Lorsque vous publiez une ressource telle qu'un bean enterprise (EJB) sur le serveur et que vous utilisez le client de test universel (UTC) pour la tester, il est possible que le fichier JAR soit verrouillé et ne puisse pas être mis à jour. La conséquence de ce verrouillage est que les éventuelles modifications apportées via le plan de travail ne sont pas prises en compte durant le test de l'EJB. Une fois le fichier JAR d'EJB chargé par le client de test universel, ce fichier demeure verrouillé jusqu'à ce que l'application soit supprimée puis ajoutée de nouveau ou que le serveur soit redémarré.
Solution : Utilisez le client de test universel dans l'environnement de développement, avec les ressources de l'application exécutées en dehors de l'espace de travail, et non pas sur le serveur. Vous pouvez configurer ce mode au moment où vous créez le serveur (via l'assistant Nouveau serveur) ou plus tard, en utilisant l'éditeur de serveur et en sélectionnant l'option Exécuter le serveur et les ressources dans l'espace de travail sous la section Publication. Cela vous permet de mettre à jour individuellement les fichiers du projet EJB, sans avoir à remplacer l'intégralité du fichier JAR d'EJB.
Une fois l'application entièrement testée, vous pouvez la publier sur le serveur en utilisant l'option de publication Exécuter le serveur et les ressources sur le serveur.