1.0 Introduction
2.0 Spécifications et logiciels pris en charge
3.0 Modifications par rapport à la version précédente
4.0 Restrictions
4.1 Le serveur WebSphere doit disposer d'une page de codes appropriée
5.0 Problèmes connus
5.1 Configuration des adaptateurs de ressources J2C pour WebSphere v5
5.2 WebSphere Application Server ne peut être créé ou démarré en raison de l'utilisation de caractères non autorisés
5.3 Erreur d'écriture dans le fichier journal due à l'arrêt de l'environnement de test WebSphere V4.0
5.4 Les noms de répertoire longs peuvent provoquer des erreurs de test JSP
5.5 Incidents liés à l'utilisation d'Apache Tomcat sans connexion à Internet
5.6 Exécution d'applications Java qui se connectent à WebSphere Application Server
5.7 Exécution du client d'administration WebSphere V4.0 avec la sécurité activée
5.8 Versions de WebSphere Test Environment
5.9 Utilisation de constructeurs dans Universal Test Client
5.10 Chemin d'accès aux classes du fournisseur JDBC DB2 par défaut sous Linux
5.11 Clients d'application WebSphere version 4.0 sous Linux
5.12 Le client J2EE ne peut pas accéder au serveur d'environnement de test sur une machine éloignée
5.13 Traçage avec WebSphere version 4.0
5.14 Certains fichiers subsistent après la désinstallation de l'environnement d'exécution de WebSphere V4
5.15 Message lors de l'application du module PTF WebSphere version 4
5.16 Création de sources de données et de serveurs dans la console d'administration WebSphere version 5
5.17 Déplacement de configurations serveur et attribution de nouveaux noms aux projets serveur
5.18 Options du chemin pour le serveur WebSphere
5.19 Configuration d'un serveur éloigné pour utiliser Embedded Messaging
5.20 Message indiquant que seul le client Embedded Messaging a été installé dans la vue Console
5.21 Configuration de Cloudscape 5.1
5.22 Une nouvelle publication du serveur WebSphere sur une machine AIX génère un message d'avertissement
5.23 Utilisation d'Embedded messaging avec un serveur éloigné AIX ou Linux
5.24 Débogage à vitesse maximale et support de remplacement de méthode à chaud
5.25 Migration de WebSphere MQ
5.26 Migration de projets de connecteur déployés à partir de WebSphere Studio v5.0
5.27 Corruption du serveur possible lors de la sauvegarde de nouvelle entrée d'authentification JAAS
Les Outils de serveur vous permettent de tester et de publier les applications J2EE dans différents environnements d'exécution locaux et distants. Ce fichier Readme présente les restrictions, les problèmes connus et les solutions associés aux fonctions d'Outils de serveur suivantes :
- Configuration du serveur à l'aide d'un serveur et d'une configuration de serveur. (Les serveurs et les configurations de serveur sont des blocs de construction utilisés par les outils de serveur pour effectuer des tests et des publications dans différents environnements d'exécution.)
- Test des projets J2EE sur IBM WebSphere Application Server ou Apache Tomcat.
- Test des beans enterprise sur Universal Test Client.
- Support de projets Web statiques.
L'aide en ligne associée aux tests et aux publications contient des informations supplémentaires sur les restrictions des Outils de serveur et sur les solutions aux problèmes liés à ce composant.
Reportez-vous au fichier Readme du produit, pour plus d'informations sur les environnements d'exécution pris en charge.
Universal Test Client requiert l'utilisation de Netscape version 4.6 ou de Mozilla version 0.7 ou suivantes.
Les outils serveur prennent en charge le test et la publication des projets sur des serveurs WebSphere installés sous Windows, Linux et AIX.
Lors du test avec des serveurs WebSphere éloignés, la machine éloignée doit disposer de la même page de codes que la machine locale. L'exécution du serveur local et du serveur éloigné avec des pages de codes différentes n'est pas prise en charge et peut provoquer la corruption de la console.
Vous pouvez obtenir une erreur lorsque vous cliquez sur le bouton Ajouter de la page J2C de l'éditeur de configuration du serveur WebSphere v5. Pour éviter ce problème, configurez le module du connecteur dans un EAR ou suivez la procédure ci-après.
1. Activez la console d'administration WebSphere et démarrez le serveur.
2. Ouvrez la console d'administration et connectez-vous à cette dernière. Sélectionnez Ressources > Adaptateurs de ressources dans la partie gauche.
3. Cliquez sur Nouveau. Entrez le Nom du module du connecteur et indiquez le chemin d'accès complet du dossier connectorModule dans votre projet. Par exemple, C:\workspace\myConnector\connectorModule.
4. Cliquez sur Appliquer puis sélectionnez l'option Régénérer pour votre projet de serveur dans l'IDE. Vous pouvez maintenant continuer à utiliser l'éditeur de configuration du serveur pour des modifications supplémentaires.
Si vous installez WebSphere Studio dans un répertoire dont le nom contient le signe dollar ($) ou tout autre caractère spécial (#, %, + ou *), la création ou le démarrage du serveur WebSphere risque d'échouer. Pour éviter de rencontrer ce problème, n'installez pas WebSphere Studio dans un répertoire contenant ce type de caractères.
Lorsque vous créez un serveur WebSphere ou un projet qui doit contenir un serveur WebSphere, veillez à ne pas inclure les caractères #, %, & ou * dans le nom. WebSphere Application Server n'accepte pas ce type de caractères.
Lorsque vous arrêtez l'environnement de test WebSphere 4.0 sous Linux, les erreurs suivantes peuvent apparaître dans la vue de la console :
Unable to obtain Shared Log Lock file /opt/wsappdev/plugins/com.ibm.etools.websphere.runtime/logs/activity.log.lck
Stack trace:
com.ibm.ejs.ras.SharedLogLockException
at com.ibm.ejs.ras.SharedLogBase.acquireHostLock(SharedLogBase.java:251)
at com.ibm.ejs.ras.SharedLogWriter.log(SharedLogWriter.java:255)
...
Previous exception:
Message:
null
Stack trace:
java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:697)
...Cette erreur se produit lorsque le serveur ne parvient pas à écrire des données dans le fichier activity.log. Même si ce message d'erreur s'affiche, le processus serveur s'arrête correctement. Vous pouvez ignorer ces messages d'erreur.
Si vous utilisez un espace de travail dans un répertoire dont le chemin d'accès est long ou que vous choisissez des noms longs pour votre application d'entreprise ou votre projet Web, il est possible que le message d'erreur suivant s'affiche lorsque vous tentez d'exécuter une page JSP :
Message d'erreur : JSPG0113E : Fichier JSP
"Xxx/Yyy_jsp_0.java (nom de fichier trop long" introuvableSi vous recevez ce message d'erreur, effectuez l'une des opérations suivantes :
- Déplacez votre espace de travail dans un répertoire correspondant à un chemin plus court, par exemple c:/workspace.
- Renommez votre projet d'application d'entreprise et/ou votre projet Web en indiquant un nom plus court.
- Réduisez la structure des dossiers de la page JSP dans l'application Web. Par exemple, déplacez les pages JSP dans un dossier commun ou une racine commune du dossier Web Content au lieu de les imbriquer à un niveau inférieur.
Le fichier web.xml par défaut qui accompagne Apache Tomcat contient une référence à un fichier DTD disponible sur Internet. C'est pourquoi les serveurs Tomcat ne démarrent pas s'ils sont déconnectés du réseau Internet. Dans WebSphere Studio, ces références ont été supprimées de la configuration de Tomcat version 3.2 pour que vous puissiez travailler sans connexion à Internet. Si vous importez une configuration de serveur Tomcat à partir d'un élément extérieur à WebSphere Studio ou que vous utilisez Tomcat version 4.0, des incidents se produiront si vous êtes déconnecté du réseau Internet. Dans ce cas, procédez comme suit pour supprimer la référence.
Si le serveur ne démarre pas, vous devrez peut-être vous connecter à Internet et remplacer le fichier web.xml par celui que vous avez sauvegardé et qui contient l'élément DOCTYPE.
- Sauvegardez le fichier web.xml figurant dans la configuration de votre serveur Tomcat.
- Editez le fichier web.xml, contenu dans la configuration de votre serveur Tomcat, à l'aide d'un éditeur de texte.
- Supprimez tout l'élément DOCTYPE dans le fichier.
- Sauvegardez puis fermez l'éditeur.
WebSphere Application Server comporte une restriction selon laquelle toutes les applications Java qui utilisent le client WebSphere pour se connecter aux beans enterprise exécutés sur un serveur WebSphere doivent utiliser le même niveau d'ORB IBM Java que celui qui a été utilisé pour générer le client WebSphere. Si vous n'utilisez pas le même niveau d'ORB, vous pouvez obtenir un message semblable au message d'erreur suivant lors de l'exécution de l'application client :
java.lang.NoClassDefFoundError: com/ibm/rmi/iiop/GIOPVersionException
Pour vérifier que le niveau d'ORB utilisé est correct, vous pouvez exécuter l'application client avec le JRE WebSphere. Pour cela, procédez comme suit :
- Ouvrez la boîte de dialogue Configurations de lancement en cliquant sur Exécuter > Exécuter ou Exécuter > Déboguer dans la perspective Débogage.
- Sélectionnez la configuration de lancement d'application Java à éditer.
- Accédez à la page JRE et sélectionnez le JRE WebSphere approprié dans la zone de liste.
- Validez les modifications.
Vous pouvez aussi exécuter l'application client avec un JRE tant que vous vérifiez que le niveau d'ORB correspondant est utilisé. Pour cela, procédez comme suit :
- Ouvrez la boîte de dialogue Configurations de lancement en cliquant sur Exécuter > Exécuter ou Exécuter > Déboguer dans la perspective Débogage.
- Sélectionnez la configuration de lancement d'application Java à éditer.
- Accédez à la page Arguments et ajoutez ce qui suit dans la zone Arguments VM :
-Xbootclasspath/p:répertoire d'installation WAS\java\jre\lib\ext\ibmorb.jar
où répertoire d'installation WAS est le répertoire qui contient le module d'exécution, par exemple c:\Program Files\IBM\WebSphere Studio\runtimes\aes_v4- Validez les modifications.
La version 4 du client d'administration WebSphere ne peut pas être lancée directement à partir du plan de travail lorsque la sécurité est activée. Pour lancer le client d'administration, suivez la procédure ci-après.
- Démarrez le serveur WebSphere.
- Ouvrez un navigateur Web et entrez l'URL suivante : http://[hôtelocal:8080]/admin, où [hôtelocal:8080] correspond au nom du serveur et au port que vous utilisez.
- Entez l'ID utilisateur et le mot de passe utilisés pour la configuration de la sécurité. Cliquez sur Envoyer.
- Dans la sous-fenêtre de droite, cliquez sur Configuration > Ouvrir.
- Sélectionnez l'option permettant d'entrer le chemin complet du fichier sur le serveur.
- Entrez le chemin complet de la configuration du serveur dans la zone de texte. Par exemple : C:\studio\eclipse\workspace\Servers\was.wsc\server-cfg.xml.
- Cliquez sur OK.
WebSphere Test Environment version 4 dépend de WebSphere version 4.06. WebSphere Test Environment version 5 dépend de WebSphere version 5.02. Lorsque vous procédez à la migration de données à partir d'une version antérieure de WebSphere Studio, tous les correctifs électroniques apportés à l'environnement de test WebSphere sont supprimés et vous devez les réinstaller manuellement.
Lorsque vous utilisez Universal Test Client, vous ne pouvez pas créer d'objets qui utilisent des interfaces comme paramètres dans la page des paramètres. Tous les objets à créer à partir de paramètres de type interface doivent utiliser la section des références de classe.
Commencez par charger et créer un objet de type interface ou abstract. Chargez ensuite la classe contenant le bloc de construction de type abstract/interface. Choisissez l'objet pré-créé dans la page des paramètres.
Sous Linux, le chemin d'accès aux classes du fournisseur JDBC DB2 par défaut correspond à ${DB2_JDBC_DRIVER_PATH}/db2java.zip. Le répertoire d'installation de DB2 ne peut pas être détecté sous Linux. Vous devez donc supprimer manuellement ce chemin d'accès aux classes et ajouter la valeur appropriée dans l'éditeur du serveur si vous souhaitez utiliser une source de données DB2 sous Linux.
Pour accéder aux beans enterprise à partir d'un client d'application exécuté sous WebSphere version 4.0, vous devez indiquer le port d'amorce de la fonction ORB sur le serveur. Pour ce faire, vous pouvez définir l'URL du fournisseur JNDI pour le contexte initial ou, si vous utilisez des beans d'accès, définir le port d'amorce de la fonction ORB à partir de la ligne de commande en ajoutant -CCBootstrapPort=2809 comme argument de programme dans la page Arguments de l'assistant de lancement de la configuration.
Vous recevrez peut-être une erreur org.omg.CORBA.COMM_FAILURE si vous tentez d'accéder à un serveur d'environnement de test sur un client J2EE exécuté sur une machine éloignée. Pour corriger cette erreur, vous devez configurer le nom d'hôte utilisé pour l'amorçage de la fonction ORB, défini dans la configuration du serveur éloigné. Pour modifier le nom d'hôte d'amorce de la fonction ORB, accédez à la page Ports de l'éditeur du serveur et indiquez le nom d'hôte éloigné dans la zone Nom d'hôte de la section du port d'amorce de l'ORB.
Une fois l'opération effectuée, sauvegardez les modifications et redémarrez le serveur d'environnement de test pour les valider.
Si vous désactivez le traçage pour WebSphere version 4.0, vous recevez une exception ConnectionException sur la console et vous ne pouvez pas arrêter le serveur.
A l'issue de la désinstallation de l'environnement d'exécution de WebSphere V4, il est possible que le répertoire RepInstall_WS/runtimes/aes_v4 ne soit pas supprimé. Vous devez supprimer manuellement ce répertoire s'il subsiste. Sinon, des erreurs peuvent se produire dans la prise en charge du serveur WebSphere V4. La même vérification doit être effectuée manuellement si WebSphere Studio est désinstallé puis installé à nouveau au même emplacement.
Lorsque vous appliquez le module PTF de WebSphere 4, il est possible que le système affiche un message indiquant de regénérer la configuration du plug-in lors du démarrage du serveur pour mettre à jour le fichier plugin-cfg.xml s'affiche. Vous pouvez ignorer ce message.
Il est possible qu'une exception NullPointerException ou d'autres erreurs soient générées lorsque vous ajoutez des sources de données ou que vous créez des serveurs à l'aide de la console d'administration WebSphere version 5 au sein de WebSphere Studio. Pour éviter cette erreur, suivez l'une des procédures ci-dessous :
- Si vous créez une source de données, utilisez l'éditeur du serveur WebSphere version 5. Vous pouvez ouvrir l'éditeur en cliquant deux fois sur le serveur WebSphere version 5 dans la vue Serveur ou Configurations de serveur. Accédez à la page Source de données pour ajouter, modifier ou supprimer des sources de données du serveur.
- Arrêtez le serveur.
- Copiez le répertoire templates à partir du chemin suivant (où répertoire_installation_WS correspond au répertoire d'installation de WebSphere Studio) :
répertoire_installation_WS\runtimes\base_v5\config\templates
dans votre espace de travail en cours :
répertoire_espace_de_travail\projet_ serveur\nom_serveur.wsc- Redémarrez le serveur et faites une nouvelle tentative.
L'association entre un serveur et sa configuration serveur inclut le projet dans lequel se trouve la configuration serveur. Lorsque vous renommez un projet serveur ou que vous déplacez une configuration serveur vers un projet différent, toutes les associations du serveur utilisant les configurations seront supprimées. Pour résoudre ce problème, dans la vue Serveur, cliquez à l'aide du bouton droit sur le serveur et sélectionnez Configurer un autocommutateur > nom_configuration_serveur pour associer à nouveau la configuration au serveur.
La fonction Option du chemin disponible dans la page Environnement de l'éditeur du serveur WebSphere n'est pas exploitable. Le chemin indiqué dans la zone Chemin d'accès à la bibliothèque Java est ajouté à la variable PATH du serveur. Vous ne pouvez pas déterminer précisément où les données sont ajoutées (par exemple, au début, à la fin ou en remplacement de la variable PATH).
Dans la rubrique Configuration d'un serveur pour utiliser Embedded Messaging, certaines parties de la section Environnement de test s'appliquent aux instructions de la section Serveur éloigné. Les éléments suivants doivent être définis dans la configuration d'un serveur local ou éloigné : WAS_PUBSUB_ROOT, MQ_INSTALL_ROOT et un gestionnaire de files d'attente du côté serveur. En outre, une entrée doit être définie dans la section ws.ext.dirs de la configuration du serveur pour indiquer le répertoire java/lib où WebSphere MQ est installé.
Les instructions à suivre pour configurer un gestionnaire de files d'attente sont indiquées à la section Environnement de test de la présente section. Le même fichier de commandes createmq existe sur un système WebSphere Application Server autonome, dans le même chemin relatif de la racine d'installation de WebSphere Application Server. Vous devez suivre cette étape si vous déployez à distance le serveur à partir de WebSphere Studio vers un système WebSphere Application Server éloigné.
Remarque : Si vous avez installé Embedded Messaging avec le programme d'installation de WebSphere Studio, il n'est pas nécessaire d'exécuter le fichier createmq.bat ni de définir les données du fichier variables.xml. Il est également inutile de créer un fichier de commandes pour lancer le plan de travail et s'assurer que les données binaires MQ se trouvent dans le chemin du serveur WAS. Vous devez toutefois ajouter les données indiquées à la section ws.ext.dirs sur le serveur. Cette tâche doit être exécutée uniquement si vous avez installé Embedded Messaging avec le programme d'installation de WebSphere Application Server.
Lors du démarrage de WebSphere 5.0 Test Environment, il est possible qu'un message s'affiche dans la vue Console pour vous indiquer que le seul client Embedded Messaging a été installé, même si ce composant facultatif n'a pas été installé lors de la procédure d'installation de WebSphere Studio. Ce message peut être ignoré car il n'indique pas que le composant Embedded Messaging a été installé mais plutôt que certaines variables de configuration du serveur sont définies pour le serveur de test, ce qui génère ce message erroné.
Pour installer Cloudscape 5.1, exécutez le fichier installCloudscape51.bat sous Windows ou le fichier Cloudscape51.sh sous Linux. Ce fichier se trouve dans le répertoire répertoire_installation_WS/runtimes/base_v5/cloudscape51 (où répertoire_installation_WS correspond au répertoire où vous avez installé WebSphere Studio. Le système lance un programme d'installation Cloudscape propre à WebSphere. Lorsque le programme vous invite à indiquer le nom du répertoire, recherchez ou entrez le répertoire répertoire_installation_WS/runtimes/base_v5.
Remarque : A l'issue de l'installation de Cloudscape 5.1, vous ne pouvez pas exécuter ou utiliser de sources de données définies dans Cloudscape 5.0. Si vous souhaitez exécuter Cloudscape 5.0, vous devez d'abord désinstaller Cloudscape 5.1, puis supprime les sources de données de Cloudscape 5.1 ou les convertir en sources de données Cloudscape 5.0.
Lors de la nouvelle publication d'un serveur WebSphere sur une machine AIX, la boîte de dialogue de publication peut afficher des messages d'avertissement indiquant que la suppression de certains fichiers n'a pas abouti. Vous pouvez sans aucun risque ignorer ces messages d'avertissement.
Si vous avez installé Embedded messaging sur un serveur éloigné AIX ou Linux, vous devez suivre la procédure ci-après.
- Dans la page Environnement de l'éditeur de serveurs de WebSphere Studio, à la section ws.ext.dirs, cliquez sur le bouton Ajouter un dossier externe et ajoutez le répertoire contenant les classes d'implémentation Java Embedded messaging.
- Dans la section Chemin d'accès à la bibliothèque Java, entrez le chemin d'accès aux fichiers binaires MQ. Sauvegardez vos modifications.
- Sur la machine éloignée, ajoutez la variable d'environnement WEMPS_REGISTRY au fichier serverconfig.xml à l'emplacement où vous avez installé Agent Controller. Dans le fichier serverconfig.xml, cette variable se trouve dans la section de configuration des applications pour wteRemoteV5.exe. Par exemple :
<Variable name="WEMPS_REGISTRY" position="prepend" value="/var/wemps/registry"></Variable>où /var/wemps/registry correspond au chemin d'accès à cette variable.
Le débogage à vitesse maximale et le remplacement de méthode à chaud sont pris en charge uniquement lors du débogage dans l'environnement de test WebSphere V5. Le débogage des applications hors de l'environnement de test WebSphere V5 n'est pas pris en charge.
Le composant WebSphere MQ ne prend pas en charge la compatibilité inter-versions. Vous devez vous assurer que la version de WebSphere MQ utilisée se trouve au même niveau de fixpack que l'environnement de test WebSphere ou que le serveur WebSphere vers lequel vous effectuez le déploiement.
Par exemple, vous ne devez pas utiliser la version WebSphere MQ installée par WebSphere Studio v5.0 avec un environnement de test WebSphere v5.0.2. A la place, vous devez désinstaller WebSphere MQ et installer la version livrée avec WebSphere Studio v5.1.
Les espaces de travail créés dans WebSphere Studio v5.0 contenant un projet de conteneur qui sont déployés vers un environnement de test WebSphere ou vers un serveur WebSphere ne sont pas automatiquement migrés vers une version ultérieure. Des messages d'erreur peuvent s'afficher lorsque vous tentez de publier les projets de conteneur sur le serveur.
Pour résoudre ce problème : Dans la vue Serveurs, cliquez à l'aide du bouton droit de la souris sur le serveur et sélectionnez Ajouter et supprimer des projets. Supprimez le projet EAR à partir du serveur puis ajoutez-le à nouveau. De cette manière, la configuration du serveur est corrigée afin que les projets de connecteur soient correctement déployés.
Si vous ouvrez un éditeur de serveur V5, créez et sauvegardez une entrée d'authentification JAAS sans quitter l'éditeur et accédez ensuite à l'onglet Source de données et ajoutez une source de données V5, une boîte de dialogue Fichier modifié s'affiche. Vous devez cliquer sur NON pour éviter la corruption de la configuration du serveur.
Retour au fichier Readme principal
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.