1.0 Introduction
2.0 Spécifications et logiciels pris en charge
3.0 Modifications par rapport à la version précédente
4.0 Limitations
4.1 Le serveur WebSphere doit avoir la même page de codes
5.0 Problèmes connus
5.1 Configuration des adaptateurs de ressources J2C pour WebSphere v5
5.2 WebSphere Application
Server ne peut pas être créé ou démarré en raison de la présence de caractères invalides
5.3 Les noms de répertoire longs peuvent provoquer des erreurs dans l'essai JSP
5.4 Internet Explorer : désactivez le serveur proxy ou socks en cas d'utilisation d'adresses locales
5.5 Problèmes d'utilisation d'Apache Tomcat en cas de déconnexion d'Internet
5.6 Sécurité de serveur WebSphere
5.7 Exécution d'applications Java se connectant à WebSphere Application Server
5.8 Exécution du client d'administration WebSphere version 4.0 avec la sécurité activée
5.9 Versions de l'environnement de test WebSphere
5.10
Utilisation de constructeurs dans Universal Test Client
5.11 Problème de distinction de casse lors de la publication de serveur version 5 éloigné sous Windows
5.12
URL de fournisseur JNDI par défaut dans Universal Test Client
5.13 Le client J2EE ne peut pas accéder au serveur d'environnement de test sur une machine éloignée
5.14 Message lors de l'application du PTF WebSphere
version 4
5.15 Création de sources de données et de serveurs dans la console d'administration WebSphere v5
5.16 Déplacement des configurations de serveur et renommage des projets de serveur
5.17 Options de chemin d'accès pour serveur WebSphere
5.18 Configuration de Cloudscape 5.1
5.19 La republication du serveur WebSphere dans la machine AIX génère un message d'avertissement
5.20 Prise en charge du débogage à vitesse maximale et du remplacement de méthode à chaud
5.21 Mise à niveau de Cloudscape de la version 5.0 à la version 5.1
5.22 Migration de WebSphere MQ
5.23 Migration des projets de connecteur déployés depuis WebSphere Studio v5.0
5.24 Les serveurs WebSphere ne démarrent pas du fait que le chemin d'accès de l'espace de travail commence par une barre oblique inversée
5.25 Possibilité d'altération
du serveur lors de l'enregistrement de la 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 le client de test universel.
- 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.
Le client de test universel nécessite l'utilisation de Netscape version 6.0 ou ultérieure ou de Microsoft Internet Explorer version 5.0 ou ultérieure
Les outils du serveur prennent en charge le test et la publication de projets vers les serveurs WebSphere sur les machines Windows, Linux et AIX.
Lors d'un test avec les serveurs WebSphere distants, la machine éloignée doit posséder la même page de codes que la machine locale. L'exécution du serveur local et distant avec des pages de codes différentes n'est pas prise en charge et peut entraîner l'altération de la console.
Vous pouvez recevoir un message d'erreur lorsque vous cliquez sur le bouton Ajouter de la page J2C de l'éditeur de configuration du serveur WebSphere v5. Pour résoudre ce problème, configurez le module de connecteur dans un fichier EAR ou exécutez la procédure suivante :
1. Activez la console d'administration WebSphere et démarrez le serveur.
2. Ouvrez la console d'administration et connectez-vous. Sélectionnez Ressources > Adaptateurs de ressources dans la partie gauche.
3. Cliquez sur Nouveau. Entrez le Nom de votre module de connecteur et indiquez le chemin d'accès complet du dossier connectorModule de votre projet. Par exemple, C:\workspace\myConnector\connectorModule.
4. Cliquez sur Appliquer, puis sur Régénérer pour régénérer votre projet de serveur dans l'environnement IDE. Vous pouvez désormais continuer à utiliser l'éditeur de configuration de serveur pour toute autre modification.
Si vous installez WebSphere Studio dans un répertoire dont le nom contient un signe dollar ($) ou tout caractère étrange tel que #, %, + ou *, le serveur WebSphere peut ne pas être créé ou ne sera pas démarré. Pour éviter ce problème, n'installez pas WebSphere Studio dans un répertoire contenant ces caractères.
Lorsque vous créez un serveur WebSphere ou un projet de serveur contenant un serveur WebSphere, n'incluez pas de caractère #, %, & ou * dans le nom. WebSphere Application Server ne les prend pas en charge.
Si vous utilisez un espace de travail dans un répertoire avec un long chemin d'accès ou choisissez des noms longs pour votre projet d'application d'entreprise ou votre projet Web, le message d'erreur suivant peut s'afficher lorsque vous essayez 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 vers un emplacement dont le chemin est plus court, par exemple c:/workspace.
- Renommez votre projet d'application d'entreprise et/ou votre projet Web par un nom plus court.
- Réduisez la profondeur du dossier 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.
Si vous utilisez un serveur proxy ou socks dans Internet Explorer, il doit être désactivé pour les adresses locales. Sinon, des incidents peuvent se produire lorsque vous tentez d'afficher le client de test universel ou une autre application Web avec le navigateur Web interne ou la version de Microsoft Internet Explorer installée.
Le fichier web.xml par défaut qui accompagne Apache Tomcat contient une référence à un fichier DTD 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.
Lorsque vous activez la sécurité pour un serveur, ne lui donnez pas un ID de serveur ayant le même nom que le nom de la machine où WebSphere Application Server est installé. Sinon, le démarrage de WebSphere Application Server peut échouer.
La règle de droits utilisateur pour l'ID utilisateur de serveur peut également accorder à l'utilisateur le privilège Agir en tant que partie du système d'exploitation.
L'une des restrictions de WebSphere Application Server est que toutes les applications Java qui utilisent le client WebSphere pour se connecter à des beans enterprise exécutés sur un serveur WebSphere doivent utiliser le même niveau d'ORB Java IBM que celui ayant été utilisé pour créer 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 Configuration de lancement en sélectionnant les éléments de menus Exécution > Exécuter ou Exécution > Déboguer dans la perspective Débogage.
- Sélectionnez la configuration de lancement d'application Java à éditer.
- Allez à 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 Configuration de lancement en sélectionnant les éléments de menus Exécution > Exécuter ou Exécution > 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 le champ 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.
L'environnement de test de WebSphere version 4 est fondé sur WebSphere version 4.06. L'environnement de test de WebSphere version 5 est fondé sur WebSphere version 5.02. Lorsque vous procédez à la migration de données à partir d'une version antérieure de WebSphere Studio, toutes les corrections électroniques apportées à l'environnement de test WebSphere sont supprimées et vous devez les réinstaller manuellement.
Lorsque vous utilisez le client de test universel, 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.
Si un projet a été publié sur un serveur version 5 éloigné sous Windows et que le projet est ensuite renommé en ne changeant que les majuscules et les minuscules, par exemple "MyEarProject" en "myearproject", vous recevrez peut-être des erreurs Ce fichier n'existe pas au démarrage du serveur. Sous Windows, WebSphere Studio ne fait pas la distinction entre deux projets publiés avec le même nom et des casses différentes. Ce problème peut être éliminé en supprimant manuellement la configuration de serveur publiée du poste éloigné et en republiant le projet.
L'URL de fournisseur JNDI par défaut pour le client de test universel a été changé dans WebSphere Studio version 4.0. La nouvelle URL de fournisseur est "iiop://2809" au lieu de "iiop://900". Si vous lancez le client de test manuellement et que vous avez besoin de l'ancien numéro de port (par exemple, pour accéder à WebSphere v4.0), vous pouvez changer l'URL de fournisseur en utilisant la page Propriétés dans le client de test.
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 résoudre le problème, vous devez configurer le nom d'hôte d'amorce ORB défini dans la configuration de serveur distante. Pour éditer le nom d'hôte d'amorce ORB, allez à la page Ports de l'éditeur du serveur et indiquez le nom d'hôte distant dans le champ Nom d'hôte sous la section de port d'amorce ORB.
Une fois cette modification effectuée, enregistrez les modifications et redémarrez le serveur d'environnement de test pour que les modifications prennent effet.
Lors de l'application du PTF WebSphere version 4, le message "NOTE: Please regenerate the plugin configuration once the server is started in order to update the plugin-cfg.xml file" peut apparaître. Vous pouvez ignorer ce message.
Il se peut qu'une erreur NullPointerException ou autre soit générée lors de l'ajout de sources de données ou lors de la création de serveurs à l'aide de la console d'administration WebSphere version 5 dans WebSphere Studio. Remédiez au problème à l'aide des solutions suivantes :
- Si vous créez une source de données, utilisez l'éditeur de serveur WebSphere version 5 à la place. Vous pouvez ouvrir l'éditeur en double-cliquant sur votre serveur WebSphere version 5 dans la vue Serveurs ou la vue Configurations de serveur. Allez à la page Source de données pour ajouter, éditer ou supprimer des sources de données du serveur.
- Arrêtez le serveur.
- Copiez le répertoire des modèles à partir du répertoire suivant (où rép_install_WS correspond au répertoire dans lequel vous avez installé WebSphere Studio):
rép_install_WS\runtimes\base_v5\config\templates
dans votre espace de travail courant sous :
le dossier rép_espace_travail\projet_serveur\nom_serveur.wsc- Redémarrez le serveur et essayez de nouveau.
L'association entre un serveur et sa configuration de serveur inclut le projet dans lequel la configuration de serveur réside. Lorsque vous renommez un projet de serveur ou déplacez une configuration de serveur vers un projet différent, les associations des serveurs qui utilisent les configurations seront rompues. Pour résoudre ce problème, dans la vue Serveurs, cliquez avec le bouton droit de la souris sur le serveur, puis sélectionnez Switch Configuration > nom_configuration_serveur pour réassocier la configuration avec le serveur.
La fonctionnalité Option du chemin de la page Environnement de l'éditeur de serveur WebSphere ne fonctionne pas. Le chemin entré dans le champ Chemin d'accès à la bibliothèque Java sera ajouté au PATH de serveur existant. Vous n'aurez pas le contrôle sur l'endroit où les données sont ajoutées, par exemple, si les données sont ajoutées au début, à la fin ou en remplacement du PATH de serveur existant.
Pour installer Cloudscape 5.1, exécutez le fichier installCloudscape51.bat sous Windows ou le fichier Cloudscape51.sh sous Linux. Ce fichier est situé dans le répertoire rép_install_WS/runtimes/base_v5/cloudscape51 (où rép_install_WS est le répertoire où vous avez installé WebSphere Studio. Le programme d'installation lance un installateur Cloudscape spécifique pour WebSphere. Lorsque vous êtes invité à indiquer le Nom de répertoire, naviguez jusqu'au répertoire rép_install_WS/runtimes/base_v5 ou entrez son chemin.
Remarque: Une fois que vous avez installé Cloudscape 5.1, vous ne pouvez pas exécuter ou avoir de sources de données définies Cloudscape 5.0. Si vous voulez exécuter Cloudscape 5.0, vous devez d'abord désinstaller Cloudscape 5.1, puis supprimer les sources de données Cloudscape 5.1 ou les remplacer par les sources de données Cloudscape 5.0.
Lors de la republication d'un serveur WebSphere dans une machine AIX, vous pouvez obtenir un message d'avertissement concernant l'échec de la suppression de certains fichiers dans la boîte de dialogue de publication. Vous pouvez ignorer sans risque ces messages d'avertissement.
Le débogage à vitesse maximale et le remplacement de méthode à chaud ne sont pris en charge que lorsque le débogage s'effectue dans l'environnement de test WebSphere V5. Les applications de débogage extérieures à l'environnement de test WebSphere V5 ne sont pas prises en charge.
Si vous effectuez une mise à niveau de Cloudscape de la version 5.0 à la version 5.1, n'oubliez pas que Cloudscape est inclus à la fois dans le serveur d'applications de production et dans le serveur d'applications de WebSphere Studio Site Developer. Vous devez effectuer la mise à niveau des deux instances de Cloudscape vers la version 5.1.
Le composant WebSphere MQ ne prend pas en charge la compatibilité entre les versions. Vous devez vous assurer que la version de WebSphere MQ que vous utilisez est au même niveau de mise à jour 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 de WebSphere MQ installée par WebSphere Studio v5.0 avec un environnement de test WebSphere v5.0.2. Dans cet exemple, vous devez désinstaller WebSphere MQ et installer la version fournie avec WebSphere Studio v5.1.
La migration des espaces de travail créés dans WebSphere Studio v5.0 contenant un projet de connecteur et qui sont déployés vers un environnement de test WebSphere ou vers un serveur WebSphere ne s'effectue pas automatiquement lors de la mise à niveau vers une édition supérieure. Vous pouvez recevoir des erreurs lors de votre tentative de publication des projets de connecteur dans le serveur.
Pour résoudre ce problème, dans la vue Serveurs, cliquez avec le bouton droit de la souris sur le serveur, puis sélectionnez Ajout et suppression de projets. Supprimez le projet EAR du serveur, puis ajoutez-le de nouveau. Cela a pour effet de corriger la configuration du serveur WebSphere de façon à permettre le déploiement des projets de connecteur.
Les serveurs WebSphere peuvent ne pas démarrer lorsque vous utilisez un chemin d'accès d'espace de travail commençant par une barre oblique inversée. Voici quelques exemples de chemin d'accès de l'espace de travail pouvant être à l'origine de l'incident :
\workspaceA\my_workspaces\work1Les chemins d'accès de l'espace de travail commençant par une lettre d'unité ou ne commençant pas par une barre oblique inversée ne provoquent pas cet incident. Si vous avez déjà démarré WebSphere Studio avec un espace de travail commençant par une barre oblique inversée, exécutez la procédure suivante pour permettre aux serveurs WebSphere de démarrer :
- Arrêtez WebSphere Studio.
- Redémarrez WebSphere Studio (utilisez l'indicateur -setworkspace si vous aviez choisi précédemment de masquer la boîte de dialogue de sélection de l'espace de travail au démarrage).
- Lorsque le système vous invite à indiquer l'emplacement de l'espace de travail, ajoutez la lettre d'unité au début du chemin d'accès de l'espace de travail. Par exemple, \workspace1 devient c:\workspace1.
- Vous pouvez désormais démarrer votre serveur WebSphere existant.
Si vous ouvrez l'éditeur de serveur de la version 5, créez et enregistrez une nouvelle entrée d'authentification JAAS sans quitter l'éditeur, puis accédez à 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 que la configuration du serveur ne soit altérée.
Retour au fichier Readme principal
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.