Migration à partir de WebSphere Studio "Classic" vers IBM
WebSphere Studio Site Developer
| Important |
|---|
|
Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à la section Remarques. |
LE PRESENT DOCUMENT EST LIVRE "EN L'ETAT". IBM DECLINE TOUTE RESPONSABILITE, EXPRESSE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE QUALITE MARCHANDE OU D'ADAPTATION A VOS BESOINS. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.
Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial.
Vous pouvez également consulter les serveurs Internet suivants :
Compagnie IBM France
(C) Copyright IBM France 2003. Tous droits réservés.
© Copyright International Business Machines Corporation 2000, 2003. All rights reserved.
Note to U.S. Government Users -- Documentation related to restricted rights -- Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule contract with IBM Corp.
Chapitre 1. Présentation du guide de migration de WebSphere Application Server - Express
Chapitre 2. Migration du serveur de production
Chapitre 3. Migration à partir d'IBM WebSphere Studio Site Developer version 5.1
Chapitre 4. Migration à partir d'IBM WebSphere Studio Site Developer version 5.0.1
Chapitre 5. Migration à partir d'IBM WebSphere Studio Site Developer version 4.0.x
Chapitre 7. Migration à partir de VisualAge for Java vers IBM WebSphere Studio Site Developer
Chapitre 10. Exemples de migration
La version IBM WebSphere Application Server - Express version 5.1 permet d'effectuer une migration de code à partir de :
WebSphere Application Server - Express 5.1 comprend WebSphere Application Server 5.1 et WebSphere Studio Site Developer 5.1.1. Le premier chapitre traite de la migration de la fonctionnalité du serveur de WebSphere Application Server - Express. Les autres chapitres du guide de migration expliquent la migration du code à partir de différentes versions de WebSphere Studio Site Developer.
Remarque importante relative à la migration du serveur :
La migration de la configuration du serveur est judicieuse uniquement si vous gérez le serveur à l'aide de la console d'administration (en général dans un environnement de production). Dans ce mode de fonctionnement, la configuration du serveur et les applications déployées sont stockées dans le répertoire config sur le serveur. Le processus de migration effectue la migration de ces fichiers de configuration et d'applications à votre place. Cependant, si vous utilisez WebSphere Studio Site Developer pour configurer et déployer des applications sur votre serveur distant, il n'est pas nécessaire de procéder à la migration des fichiers de configuration du serveur, car les fichiers de configuration et d'applications sont tous conservés dans l'espace de travail de Studio Site Developer. Studio Site Developer fera migrer l'espace de travail. Vous pourrez ensuite définir une nouvelle instance de serveur WebSphere Application Server - Express 5.1 et continuer de configurer et de déployer vos applications à partir de Studio Site Developer.
Le présent guide se compose des chapitres suivants :
Migration à partir de WebSphere Studio "Classic" vers IBM
WebSphere Studio Site Developer
Vous trouverez des informations concernant l'utilisation de WebSphere Application Server - Express dans le Guide d'initiation et l'aide en ligne du produit. Avant d'installer WebSphere Application Server - Express, lisez le Guide d'installation. Après avoir installé WebSphere Application Server - Express, lisez le Guide d'initiation et exécutez les tutoriels associés. Ces derniers présentent le plan de travail, le développement pour Java et les services Web. Après avoir exécuté les tutoriels, lisez le présent guide qui décrit la migration des ressources de l'application dans WebSphere Application Server - Express.
Le présent guide est disponible aux formats HTML et Acrobat PDF dans le répertoire /readme. Les deux formats contiennent des informations identiques. Le fichier migrate.html peut être lu dans n'importe quel navigateur Web. Pour ouvrir le fichier migrate.pdf, vous devez installer le logiciel Acrobat Reader, qu'il est possible de télécharger à l'adresse www.adobe.com/products/acrobat/readstep2.html.
Le présent Guide de migration utilise les conventions Windows. Par exemple, "RépInstall_WS\" sous Windows équivaut à "RépInstall_WS/" sous Linux.
Pour obtenir les prochaines mises à jour, connectez-vous au site www.ibm.com/websphere/developer/zones/studio/transition.html.
La migration est une activité qui permet de profiter du matériel existant. Les tâches et les outils de migration vous aident à mettre à niveau le produit et ses conditions requises, à réutiliser des composants d'application existants, si possible, et à transférer les configurations administratives à partir de votre version précédente vers la version actuelle.
La migration des produits WebSphere Application Server consiste à exploiter les applications et les environnements existants et à les modifier de sorte qu'ils soient compatibles avec la version du produit la plus récente.
Les fonctions de migration du produit sont fournies par les outils de migration dans IBM WebSphere Application Server - Express, version 5.1. Ces derniers prennent en charge la migration à partir de :
L'assistant d'installation du produit détecte les versions précédentes d'IBM WebSphere Application Server - Express et vous propose de lancer les outils de migration lors de l'installation de la version 5.1. Pour procéder à la migration à partir d'IBM WebSphere Application Server version 3.5, vous devez lancer ces outils directement.
Redbook - Migration
Le document Migrating to WebSphere V5: An End-to-End Migration Guide est disponible sur le site Web des redbooks à l'adresse suivante : http://www.ibm.com/redbooks. Pour trouver le redbook, recherchez le numéro de document SG24-6910-00. Il couvre plus largement la fonction de migration que cet article et contient des informations détaillées relatives à la planification de la migration d'applications et des exemples et outils de WebSphere Studio Application Developer.
Migration de la version 3.5 : Vers le modèle J2EE
Les utilisateurs de la version 3.5.x qui passent à la version 5 vont utiliser une plateforme compatible avec les spécifications J2EE. La technologie J2EE différencie clairement le développement et la création d'applications de l'administration, du déploiement et de la gestion de ces applications. La migration à partir de la version 3.5 implique la modification des structures, du développement et du déploiement des applications.
Les outils de migration aident l'utilisateur à passer de la version 3.5.x à la version 5 en effectuant la migration des configurations système et en créant des artefacts J2EE ainsi que le mappage des rôles de sécurité J2EE. Ils créent des applications d'entreprise J2EE initiales en fonction des configurations de la version 3.5.x. Toutefois, étant donné les modifications considérables apportées aux structures des applications, prévoyez de tester et d'optimiser soigneusement les applications migrées à l'aide des outils de développement et de déploiement, afin de déterminer exactement le mode de fonctionnement des applications dans le nouvel environnement.
Le modèle J2EE permet de développer des applications indépendamment de leur environnement de déploiement final. Cette séparation des tâches simplifie le processus de promotion d'une application du développement initial à la production, ou le processus de déplacement d'une application d'un serveur à un autre. L'idée est de modifier uniquement les paramètres de déploiement de l'application et non son code.
Avant de commencer, déterminez si une version de WebSphere Application Server est déjà installée sur la machine sur laquelle vous prévoyez d'installer la version 5.1 du produit. Si tel est le cas, vous devez envisager de copier la configuration et les applications de la version précédente vers la nouvelle version, c'est-à-dire de procéder à la migration. La migration ne désinstalle pas la version précédente. Cette dernière restera opérationnelle. Si vous l'exécutez en même temps que l'installation de la version 5.1, les deux version coexisteront. Pour pouvoir exécuter les deux versions simultanément, vous devez configurer les ports de sorte qu'ils n'entrent pas en conflit. L'opération de migration effectue la migration des définitions de port telles quelles, ce qui signifie qu'elles sont identiques pour les deux versions. WebSphere Application Server contient des outils de migration qui composent la fonction de migration. L'assistant de migration appelle les outils de migration. Vous pouvez également les appeler manuellement ultérieurement.
Globalement, la migration à partir d'IBM WebSphere Application Server - Express version 5.0.x vers la version 5.1 est très simple. Vous pouvez utiliser le programme d'installation pour procéder à la migration et avoir peu de réglages à effectuer après la migration, voire aucun. Vous pouvez aussi utiliser les outils de migration manuellement pour sauvegarder les données de configuration des versions 5.0.0, 5.0.1 ou 5.0.2, désinstaller les versions 5.0.0, 5.0.1 ou 5.0.2, installer la version 5.1 et restaurer les données de configuration.
En résumé, la migration à partir d'IBM WebSphere Application Server version 3.5 vers IBM WebSphere Application Server - Express version 5.1 implique des modifications significatives dans les structures, le développement et le déploiement des applications. Les outils de migration aident l'utilisateur à faire la transition en effectuant la migration des configurations système et en créant des artefacts J2EE ainsi qu'en mappant les paramètres de sécurité précédents aux rôles de sécurité J2EE. Ces mappages de sécurité permettent d'accéder aux éléments migrés lors de la transition. Les outils de migration créent des applications d'entreprise J2EE initiales en fonction des configurations de la version 3.5.X. Toutefois, étant donné les modifications considérables apportées aux structures des applications, prenez soin de tester et d'optimiser les applications migrées à l'aide des outils de développement et de déploiement.
La migration sauvegarde les fichiers énumérés ci-dessous dans le répertoire backup.
La présente section décrit les outils de migration fournis par WebSphere Application Server. Tous les outils de migration se trouvent dans le répertoire /migration sur le CD-ROM du produit. Il est important d'utiliser les outils de migration de la version d'Application Server que vous installez. Les outils sont modifiés au fur et à mesure des versions. Ceux qui figurent sur le CD-ROM du produit fournissent la fonction nécessaire à la migration d'une version précédente d'Application Server vers la version figurant sur le CD-ROM. Les outils du CD-ROM correspondent au produit figurant sur le CD-ROM. Si vous utilisez les outils de migration d'une version antérieure d'Application Server, vous risquez de rencontrer des erreurs lors de la migration.
Le script WASPreUpgrade.sh (ou WASPreUpgrade.bat) est un outil de migration de la configuration et des applications des versions ou des éditions précédentes vers la version 5.1 d'Application Server - Express.
Le fichier de la commande se trouve dans le sous-répertoire AppServer/bin du répertoire principal de l'installation après l'installation. Vous pouvez également y accéder directement à partir du sous-répertoire migration figurant sur le CD.
Syntaxe
WASPreUpgrade répertoireSauvegarde répertoireWasActuel
[nomNoeudAdmin]
[-nameServiceHost nom_hôte [-nameServicePort numéro_port ]]
[-traceString spéc_trace [-traceFile nom_fichier ]]
Paramètres
Les deux premiers arguments sont requis est positionnels.
Certains arguments pris en charge sont décrits ci-dessous.
Journalisation
L'outil WASPreUpgrade affiche son statut sur l'écran lors de son exécution. Il sauvegarde également un ensemble d'informations de journal plus large dans le répertoire backup. Vous pouvez ouvrir le fichier WASPreUpgrade.log avec un éditeur de texte.
Le script WASPostUpgrade.sh (ou WASPostUpgrade.bat) est un outil de migration de la configuration et des applications des versions ou des éditions précédentes vers la version 5.1 d'Application Server - Express.
Le fichier de la commande se trouve dans le répertoire AppServer/bin du répertoire principal de l'installation.
L'outil WASPostUpgrade installe toutes les applications migrées dans le répertoire AppServer/installedApps de l'installation de la version 5.1. Il inclut des applications provenant du répertoire de sauvegarde créé par l'outil WASPreUpgrade. L'outil WASPreUpgrade copie les applications du répertoire installedApps et d'autres répertoires de la version ou de l'édition précédente.
Syntaxe
WASPostUpgrade répertoireSauvegarde
[-serverName nom_serveur]
[-webModuleAdditionalClasspath chemin_classes]
[-documentRootLimit nombre]
[-substitute "clé1=valeur1[;clé2=valeur2;[...]]"]
[-portBlock numéro_départ_port]
[-backupConfig true | false]
[-replacePorts true | false]
[[-traceString spéc_trace [-traceFile nom_fichier]]
Paramètres
Le premier argument est obligatoire. Certains arguments pris en charge sont décrits ci-dessous.
Dans le fichier de données XML en entrée, chaque clé apparaît sous la forme $clé$ pour la substitution. Cet argument remplace toute occurrence de $NODE_NAME$ par noeud-admin et de $APP_SERVER$ par serveur_défaut dans le fichier XML des entrées.
Si la chaîne de substitution contient des points-virgules, utilisez $semiColon$ pour les distinguer du délimiteur ";". Sur les plateformes UNIX, ajoutez un caractère d'échappement devant chaque signe dollar ($) dans la chaîne de substitution (exemple : \$semiColon\$).
Ce paramètre est valable pour les configurations sauvegardées à partir de Advanced Edition, version 3.5.x.
Journalisation
L'outil WASPostUpgrade affiche son statut sur l'écran lors de son exécution. Il sauvegarde également un ensemble plus large d'informations de journal dans le répertoire logs. Vous pouvez ouvrir le fichier WASPostUpgrade.log avec un éditeur de texte.
La présente section décrit les modifications apportées lors de la migration, qui implique toujours une machine unique, comme un environnement de développement sur une machine autonome.
Consultez le fichier WASPostUpgrade.log pour obtenir des informations détaillées sur les beans enterprise migrés. Le modèle de programmation J2EE spécifie une architecture précisant le mode de création et de déploiement des applications. Etant donné que les applications de la version 3.5.x ne sont pas construites selon la même architecture, l'outil WASPostUpgrade les crée à nouveau. Il crée toutes les ressources Web et les beans enterprise migrés dans des applications J2EE. Il mappe toutes les applications d'entreprise de l'installation de la version 3.5.x vers les applications J2EE du même nom, déployées sur le même serveur.
L'outil WASPostUpgrade mappe les ressources Web qui ne font pas partie d'une application d'entreprise vers une application J2EE par défaut qui comporte le nom du serveur. L'outil mappe les applications Web vers des fichiers WAR J2EE. Il combine les ressources dans un fichier EAR J2EE qu'il déploie dans la configuration de la version 5.
Vous pouvez utiliser le fichier datasources.xml d'une version 3.5.x pour multiplier les paramètres de configuration de la source de données. La version 3.5.x stocke le fichier dans le répertoire properties. Les outils de migration procèdent à la migration d'un fichier datasources.xml existant en fusionnant les propriétés du fichier dans la configuration du pilote JDBC et de la source de données.
Les entrées enterprise-application dans la version 3.5.x sont facultatives. Elles permettent, le plus souvent, d'assembler des ensembles d'objets pour les définitions de sécurité. Les parties web-application et bean enterprise de l'entrée enterprise-application renvoient à leurs entrées respectives dans d'autres parties du fichier xml. Chaque entrée enterprise-application est traitée en vue de créer une application J2EE du même nom. Les entrées de bean enterprise et Web-application sont utilisés comme pointeurs vers les définitions des beans enterprise et des applications Web. Les détails de ces entrées sont ensuite utilisés pour créer une application J2EE.
Dans les fichiers de beans enterprise, la définition JAR-file permet de trouver les fichiers JAR en vue de leur redéploiement et de leur ajout à l'application J2EE. Les entrées Web-application document-root permettent de trouver les ressources utilisées dans l'application Web (HTML, pages JSP, etc). Ces fichiers sont copiés dans le fichier WAR de l'application J2EE. Les entrées du chemin d'accès Web-application permettent de trouver les servlets et les fichiers JAR qui sont copiés dans le fichier WAR de l'application J2EE.
Les applications d'entreprise sont créées lors de la migration à partir de la version 3.5.x. Elles sont compatibles avec la spécification J2EE 1.2 et contiennent les modules de niveau JSP 1.1 et de niveau de servlet 2.2. La compatibilité qui en résulte est simple et permet l'interopérabilité avec des versions antérieures de WebSphere Application Server.
Le modèle d'autorisation de sécurité de la version 3.5.x repose sur la notion d'application d'entreprise et de groupes de méthodes. Le résultat de l'association de l'application d'entreprise et des groupes de méthodes est un droit d'accès WebSphere Application Server. La spécification J2EE inclut un modèle d'autorisation fondé sur les rôles.
Pour convertir le modèle d'autorisation de WebSphere Application Server version 3.5.x en modèle d'autorisation fondé sur les rôles de la version 5, les outils de migration créent un mappage un-à-un entre l'autorisation WebSphere Application Server et un nouveau rôle associé à cette application. Ainsi, pour chaque application d'entreprise et pour chaque groupe de méthodes de la version 3.5.x, les outils de migration créent un rôle dans la version 5 défini dans le descripteur de déploiement de l'application J2EE. Les sujets autorisés pour chaque rôle sont définis dans la table d'autorisations disponible dans la liaison de l'application J2EE.
La spécification J2EE inclut un modèle d'autorisation fondé sur les rôles. WebSphere Application Server interprète le rôle sous la forme d'une série d'autorisations permettant d'accéder à une ressource. Lors de l'appel d'une méthode de bean enterprise, l'autorisation d'accéder à la méthode sur un bean particulier est définie par un droit d'accès à la méthode. Ce droit d'accès à la méthode est associé à un ou plusieurs rôles dans le descripteur de déploiement du fichier JAR du bean.
Lors de l'accès aux ressources Web, le droit d'accéder à un URI Web et d'appeler une méthode HTTP sur cet URI est défini sous la forme de collections de ressources Web et de contraintes de sécurité dans la spécification J2EE. Le descripteur de déploiement du fichier WAR de l'application Web contient les contraintes de sécurité et les collections de ressources Web.
La version 5 exécute les objets JSP 1.0 et JSP 1.1 comme des objets JSP 1.2, qui est le seul niveau pris en charge.
La version 5 ne prend pas en charge le redirecteur de servlet des versions précédentes. Les outils de migration ignorent ces objets.
Si la configuration de la version 3.5.x définit le servlet SimpleFileServlet, la migration du servlet n'est pas effectuée. Les outils de migration associent la valeur true à l'attribut FileServingEnabled dans le fichier ibm-web-ext.xmi du module Web.
Si la configuration de la version 3.5 définit le servlet InvokerServlet, la migration du servlet n'est pas effectuée. Les outils de migration associent la valeur true à l'attribut ServeServletsByClassnameEnabled dans le fichier ibm-web-ext.xml du module Web.
Si la configuration de la version 3.5 définit le servlet DefaultErrorReporter, la migration du servlet est effectuée dans le fichier web.xml du module Web. La migration utilise le nouveau module pour définir le nom de la classe.
Le type de transfert par défaut du moteur de servlet dans la version 3.5.x correspond à la technologie OSE (Open Servlet Engine). Dans la mesure où la version 5 ne prend plus en charge le transfert OSE, les outils de migration mappent ces transferts vers les transferts HTTP en affectant les mêmes ports. Vous devez ajouter manuellement les entrées d'alias VirtualHost pour chaque port.
Vous pouvez effectuer la migration des configurations d'administration à l'aide de l'assistant d'installation ou manuellement, conformément aux instructions ci-après. Si vous optez pour une migration manuelle, ne cochez pas la case de migration dans le panneau de migration de l'assistant d'installation.
Si vous utilisez une version antérieure de WebSphere Application Server, il se peut que l'administrateur système ait déjà optimisé plusieurs paramètres de serveur et d'application pour votre environnement. Il est important d'élaborer une stratégie de migration de ces paramètres avec une efficacité maximale et une perte minimale.
Vous pouvez effectuer une migration manuelle progressive en appelant les outils de migration plusieurs fois et en spécifiant à chaque fois un fichier de configuration différent. Plusieurs raisons justifient l'existence de fichiers de configuration multiples. Quel que soit le cas, la migration des fichiers de configuration un par un permet de tester les applications de manière progressive avant de passer au fichier de configuration suivant.
Avant d'utiliser les outils de migration, consultez le document Notes sur l'édition version 5.x pour déterminer les correctifs à appliquer aux versions antérieures. L'application de ces correctifs à une version antérieure peut également affecter les fichiers ayant un rôle dans la migration. Appliquez tous les correctifs pour que la migration des configurations et des applications soit la plus efficace possible.
La migration manuelle permet une approche plus progressive de la migration que la migration totale effectuée à l'aide de l'assistant d'installation. IBM met à disposition un ensemble d'outils de migration pour la migration des configurations d'administration vers le produit WebSphere Application Server - Express à partir de n'importe quelle édition des versions 3.5.x ou 5.0.x. Le processus global de migration consiste à sauvegarder la configuration actuelle et les fichiers nécessaires avec l'outil de migration WASPreUpgrade, à désinstaller l'édition précédente, à installer la version 5 du produit sans sélectionner l'option de migration automatique et à restaurer la configuration de l'édition précédente avec l'outil de migration WASPostUpgrade.
Sélectionnez l'un des scénarios de migration suivants pour plus d'informations sur la migration des données de configuration vers un noeud de base WebSphere Application Server :
Vous pouvez utiliser les outils de migration pour effectuer la migration des données de configuration à partir de la version 3.5 de WebSphere Application Server vers la version 5.1 de WebSphere Application Server - Express.
A priori, vous utilisez les outils de migration WASPreUpgrade et WASPostUpgrade de la version 5.1 de WebSphere Application Server pour procéder à la mise à niveau à partir de la version 3.5 vers la version 5.1 sur la même machine. Si votre scénario inclut la migration d'une configuration de version 3.5, se trouvant sur une certaine machine, vers WebSphere Application Server - Express version 5.1, sur une autre machine, suivez la procédure décrite à la section Migration de la version 3.5.x vers une version 5.1 sur une machine éloignée.
La présente section décrit l'utilisation des outils de migration de la version 5.1 en vue de la migration de :
L'outil WASPreUpgrade sauvegarde la configuration de la version 3.5 existante dans un répertoire sauvegarde-spécifique-migration. L'outil WASPostUpgrade utilise ce répertoire pour ajouter les anciens paramètres de configuration au nouvel environnement de la version 5.1.
Etapes de la procédure
Sur ce CD se trouve le répertoire migration/bin. Il contient un environnement spécial que vous pouvez utiliser pour lancer l'outil WASPreUpgrade sans installer la version 5.1.
Sauvegardez la configuration dans le répertoire sauvegarde-spécifique-migration :
WASPreUpgrade /usr/tmp/sauvegarde-spécifique-migration /usr/websphere/appserver nomDeVotreNoeud
Vérifiez que le serveur d'administration de l'environnement existant est en cours d'exécution. L'outil WASPreUpgrade indique son statut à l'écran et dans des fichiers journaux dans le répertoire sauvegarde-spécifique-migration. Les noms de fichiers journaux ASCII commencent par le texte WASPreUpgrade et comprennent un horodatage.
L'outil WASPreUpgrade enregistre tous les fichiers à partir des répertoires ci-dessous dans la configuration de la version 3.5.x existante dans le répertoire de sauvegarde.
L'outil WASPreUpgrade sauvegarde les fichiers sélectionnés dans le répertoire /bin de la version 3.5.x. Il exporte également la configuration du serveur d'applications existante à partir du référentiel de la version 3.5.x. L'outil WASPreUpgrade appelle XMLConfig en vue de l'exportation du référentiel de la version 3.5 existant dans le fichier websphere_backup.xml du répertoire sauvegarde-spécifique-migration.
Si des erreurs surviennent lors de l'exécution de l'outil WASPreUpgrade, il se peut que vous deviez appliquer des correctifs à l'installation de la version 3.5 pour que l'étape d'exportation se termine correctement. Consultez la page de support IBM pour obtenir la liste des derniers correctifs applicables. Si vous affichez ces informations à partir de l'infocenter, cliquez sur Support pour ouvrir la page de support IBM.
Ne sélectionnez pas l'option de migration, si elle apparaît.
Après chaque utilisation de WASPostUpgrade, vérifiez les paramètres du port de la version 5 dans les deux fichiers ci-dessous.
Si le port BOOTSTRAP_ADDRESS de la version précédente est 900, le processus de migration le mappe à 7809. Si le port BOOTSTRAP_ADDRESS de la version précédente n'est pas 900, le processus de migration mappe la valeur à server1 dans une migration Advanced Edition, ou au nom du serveur actuel dans une migration Advanced Single Server Edition.
Le traitement WASPostUpgrade ajoute les ports de transfert HTTP de la version précédente au fichierserver.xml de la version 5. Cela signifie que server1 comporte des attributions de port du transfert HTTP doubles, provenant à la fois du panneau de coexistence et du serveur par défaut de la version précédente.
L'outil WASPostUpgrade effectue la migration des informations de configuration de la version 3.5.x créées par l'outil WASPreUpgrade vers l'installation de la version 5.1. Etant donné que la version 5.1 est conforme au modèle de programmation J2EE, ce qui n'est pas le cas de la version 3.5, d'importantes modifications sont nécessaires pour appliquer la configuration de la version 3.5.x à une installation de la version 5.
L'outil WASPostUpgrade n'effectue pas la migration des exemples ou de l'application de la console d'administration car la version 5.1 en prévoit déjà.
L'outil WASPostUpgrade enregistre les informations détaillées spécifiques de chaque bean enterprise qu'il déploie, dans le fichier WASPostUpgrade.log.
La configuration de WebSphere Application Server après la migration permet de vérifier les résultats des outils de migration. Vous pouvez également consulter la rubrique Mappage de configuration lors de la migration pour vérifier les résultats de la migration. Elle comporte une description détaillée de la façon dont les outils de migration font migrer les objets et des points à vérifier.
Vous pouvez utiliser les outils de migration pour effectuer une migration manuelle entre deux machines.
A priori, vous utilisez les outils de migration WASPreUpgrade et WASPostUpgrade de la version 5.1 de WebSphere Application Server - Express pour procéder à la mise à niveau à partir de la version 3.5 vers la version 5.1 sur la même machine.
Toutefois, dans certains cas, il est nécessaire d'effectuer la migration d'une configuration de version 3.5 à partir d'une machine, vers une version 5.1 située sur une autre machine. L'un des scénarios consiste à installer de nouvelles machines pour votre environnement de version 5.1 le plus récent et de procéder à la migration de votre configuration de version 3.5 existante sur d'autres machines.
La présente section décrit l'utilisation des outils de migration de la version 5.1 en vue de la migration de :
L'outil WASPreUpgrade sauvegarde la configuration de la version 3.5 existante dans un répertoire sauvegarde-spécifique-migration. L'outil WASPostUpgrade utilise ce répertoire pour ajouter les anciens paramètres de configuration au nouvel environnement de la version 5.1.
Etapes de la procédure
Sur ce CD se trouve le répertoire migration/bin. Il contient un environnement spécial que vous pouvez utiliser pour lancer l'outil WASPreUpgrade sans installer la version 5.1.
Sauvegardez la configuration dans le répertoire sauvegarde-spécifique-migration sur la machine de la version 3.5 :
WASPreUpgrade /opt/tmp/sauvegarde-spécifique-migration /opt/websphere/appserver nomNoeudAdmin
Vérifiez que le serveur d'administration de l'environnement existant est en cours d'exécution.
L'outil WASPreUpgrade indique son statut à l'écran et dans des fichiers journaux dans le répertoire /sauvegarde-spécifique-migration. Les noms de fichiers journaux ASCII commencent par le texte WASPreUpgrade et comprennent un horodatage.
L'outil WASPreUpgrade sauvegarde les fichiers sélectionnés dans le répertoire /bin de la version 3.5.x. Il exporte également la configuration du serveur d'applications existante à partir du référentiel de la version 3.5.x. L'outil WASPreUpgrade appelle XMLConfig en vue de l'exportation du référentiel de la version 3.5 existant dans le fichier websphere_backup.xml du répertoire sauvegarde-spécifique-migration.
Si des erreurs surviennent lors de l'exécution de l'outil WASPreUpgrade, il se peut que vous deviez appliquer des correctifs à l'installation de la version 3.5 pour que l'étape d'exportation se termine correctement. Consultez la page de support IBM pour obtenir la liste des derniers correctifs applicables. Si vous affichez ces informations à partir de l'infocenter, cliquez sur Support pour ouvrir la page de support IBM.
Utilisez ftp, un emplacement de stockage partagé ou un autre mécanisme pour copier le fichier sur la nouvelle machine.
Effectuez les opérations ci-dessous sur la machine sur laquelle est installé la version 5.1 de WebSphere Application Server - Express.
Vous copiez le fichier afin de pouvoir modifier la version originale à l'étape suivante.
Apportez les modifications ci-dessous au fichier.
Si vous utilisez le nom de noeud de la configuration originale de la version 3.5 pour la machine de la version 5.1, ne modifiez pas le nom. Dans les autres cas, vous devez remplacer toutes les occurrences du nom de noeud de la version 3.5 par le nom de noeud que vous utilisez pour WebSphere Application Server version 5.1. Le nom de noeud apparaît dans plusieurs sections XML du fichier. Si vous ne modifiez pas toutes les occurrences, la migration des données sera incomplète.
Le fichier de configuration renvoie aux noms des chemins dans plusieurs sections XML du fichier. Mettez à jour toute référence à un fichier se trouvant hors de la structure de répertoires de la version 3.5 en indiquant le répertoire équivalent sur la nouvelle machine, même si vous devez créer ce dernier. Si vous configurez un environnement correspondant, vous devrez sans doute copier le répertoire d'origine sur la machine hébergeant la version 5.1. Il se peut aussi que vous deviez installer le logiciel approprié.
Vous devez corriger les spécifications des chemins s'ils différent de ceux qui fonctionnent sur la machine exécutant la version 5.1. Par exemple, si vous passez de la version 3.5 sur une plateforme Windows à la version 5.1 sur une plateforme Linux, remplacez les chemins spécifiques de Windows dans le fichier de configuration par le style de chemin de Linux. Remplacez "c:\mon_répertoire\un_chemin" par "/opt/mon_répertoire/un_chemin".
Il se peut que vous deviez changer les ID utilisateur et les mots de passe s'ils ne sont pas identiques à ceux utilisés sur la machine hébergeant la version 5.1.
Pour remplacer un mot de passe codé par un mot de passe apparaissant en clair, remplacez <password>{xor}LCoxayht</password> par <password>mon_mot_de_passe</password>.
La configuration peut renvoyer à d'autres produits logiciels ou à d'autres configurations n'existant pas sur la nouvelle machine. L'ancienne machine, par exemple, peut disposer d'une base de données. La configuration de la version 5.1 doit, si possible, continuer de référencer la base de données sur l'ancienne machine. Modifiez la source de données de sorte qu'elle pointe vers la base de données située sur la machine hébergeant la version 3.5.
Utilisez l'outil WASPostUpgrade situé dans le répertoire AppServer/bin du répertoire principal d'installation de la version 5.1 pour ajouter la configuration de la version 3.5 à la configuration de la version 5.1.
WASPostUpgrade /opt/tmp/sauvegarde-spécifique-migration
L'outil WASPostUpgrade enregistre les informations détaillées spécifiques de chaque bean enterprise qu'il déploie dans le fichier /migration-specific-backup/WASPostUpgrade.log.
Vous pouvez utiliser le programme d'installation de la version 5.1 pour effectuer la migration à partir de la version 5.0.x de WebSphere Application Server - Express vers la version 5.1.
Etapes de la procédure
Utilisez le script stopServer.sh (ou stopServer.bat) situé dans le répertoire AppServer/bin du répertoire principal de l'installation :
stopServer.sh server1
Vous pouvez procéder à la migration d'un noeud de version 5.0.x sans l'arrêter. Cependant, l'exécution du noeud lors de la migration de sa configuration n'est pas requise. Les outils de migration peuvent extraire toutes les données de configuration lorsque le noeud est arrêté. Vous devez arrêter le noeud pour pouvoir redémarrer le noeud de version 5.1 en cours d'installation. Vous pouvez donc arrêter le noeud maintenant.
Sélectionnez l'option de migration, lorsqu'elle apparaît.
Utilisez l'outil Premiers pas lorsqu'il apparaît à la fin du processus d'installation du produit ou lancez le test de vérification de l'installation vous-même, si l'outil Premiers pas n'est pas disponible.
Vous pouvez désinstaller, si vous le voulez, la version 5.0.x du serveur.
Vous pouvez utiliser les outils de migration pour effectuer une migration entre deux machines.
Etapes préalables
A priori, vous utilisez les outils de migration WASPreUpgrade et WASPostUpgrade de la version 5.1 de WebSphere Application Server pour procéder à la mise à niveau à partir de la version 5.0.x vers la version 5.1 sur la même machine.
Toutefois, dans certains cas, il est nécessaire d'effectuer la migration d'une configuration de version 5.0.x à partir d'une machine, vers une version 5.1 située sur une autre machine. L'un des scénarios consiste à installer de nouvelles machines pour votre environnement de version 5.1 le plus récent et de procéder à la migration de votre configuration de version 5.0.x existante sur d'autres machines.
La présente section décrit l'utilisation des outils de migration de la version 5.1 en vue de la migration.
L'outil WASPreUpgrade sauvegarde la configuration de la version 5.0.x existante dans un répertoire sauvegarde-spécifique-migration. L'outil WASPostUpgrade utilise ce répertoire pour ajouter les anciens paramètres de configuration au nouvel environnement de la version 5.1.
Etapes de la procédure
Sur ce CD se trouve le répertoire migration/bin. Il contient un environnement spécial que vous pouvez utiliser pour lancer l'outil WASPreUpgrade sans installer la version 5.1.
Sauvegardez la configuration dans le répertoire sauvegarde-spécifique-migration sur la machine de la version 5.0.x :
WASPreUpgrade /opt/tmp/sauvegarde-spécifique-migration /opt/websphere/appserver
L'outil WASPreUpgrade indique son statut à l'écran et dans des fichiers journaux dans le répertoire /sauvegarde-spécifique-migration. Les noms de fichiers journaux ASCII commencent par le texte "WASPreUpgrade" et comprennent un horodatage.
Utilisez ftp, un emplacement de stockage partagé ou un autre mécanisme pour copier le fichier sur la nouvelle machine.
Utilisez l'outil WASPostUpgrade situé dans le répertoire AppServer/bin du répertoire principal d'installation de la version 5.1 pour ajouter la configuration de la version 5.0.x à la configuration de la version 5.1.
WASPostUpgrade /opt/tmp/sauvegarde-spécifique-migration
L'outil WASPostUpgrade enregistre les informations détaillées spécifiques de chaque bean enterprise qu'il déploie dans le fichier /migration-specific-backup/WASPostUpgrade.log.
Apportez les modifications ci-dessous.
Il se peut que vous deviez changer les ID utilisateur et les mots de passe s'ils ne sont pas identiques à ceux utilisés sur la machine hébergeant la version 5.0.x.
La configuration peut renvoyer à d'autres produits logiciels ou à d'autres configurations n'existant pas sur la nouvelle machine. L'ancienne machine, par exemple, peut disposer d'une base de données. Modifiez la source de données de sorte qu'elle pointe vers la base de données située sur l'ancienne machine.
Vous pouvez procéder à la migration d'une version antérieure de WebSphere Application Server version 3.5.x ou version 5.0.x qui fonctionne sur un système d'exploitation non pris en charge par la version 5.1.
Etapes de la procédure
Deux options sont possibles. Vous pouvez exécuter cette commande depuis le répertoire migration\bin (ou migration/bin) dans le répertoire répertoire_principal_plateforme du CD-ROM de la version 5.1. Vous pouvez également copier les fichiers du répertoire du CD-ROM dans un répertoire que vous créez sur votre disque dur.
Identifiez votre version (3.5.x ou 5.0.x) et spécifiez un répertoire de sauvegarde dans lequel la commande stockera les fichiers de configuration et les applications à faire migrer à partir de la version antérieure. Reportez-vous à la section WASPreUpgrade pour connaître la syntaxe de la commande.
Identifiez le répertoire de sauvegarde et l'emplacement des fichiers de configuration.
unité_CD :\WASPreUpgrade répertoireSauvegarde cheminFichiers \WebSphere\AppServer nomDeVotreNoeud
Si cette procédure aboutit, passez à l'étape 4. Dans le cas contraire, suivez les instructions des étapes 2B à 2F.
Modifiez les variables suivantes :
Identifiez le répertoire de sauvegarde et l'emplacement des fichiers de configuration.
votre_répertoire_de_migration\WASPreUpgrade répertoireSauvegarde cheminFichiers \WebSphere\AppServer nomDeVotreNoeud
Si possible, conservez le même nom et les mêmes mots de passe que pour l'ancien système. Placez les fichiers de base de données associés aux applications que vous migrez dans le même chemin que sous l'ancien système. En règle générale, essayez de conserver les mêmes chemins. Toutefois, n'installez pas la version 5.1 dans le même répertoire que la version précédente. Si vous modifiez les chemins et les noms, vous pouvez éditer les fichiers de configuration XML pour y répercuter les modifications. Apportez ces modifications avant d'exécuter la commande WASPostUpgrade ci-dessous.
Spécifiez le répertoire de sauvegarde (et les noms des fichiers de configuration non standard du répertoire) créés par la commande WASPreUpgrade. Consultez la section WASPostUpgrade pour connaître la syntaxe de la commande.
répertoire_principal_installation\bin\WASPostUpgrade WAS_HOME\migration
Le présent chapitre se compose des sections suivantes :
IBM WebSphere Studio Site Developer version 5.1.1 comporte une nouvelle fonction de ciblage du serveur. Elle est désactivée par défaut mais vous pouvez l'activer dans la page des préférences J2EE en sélectionnant Fenêtre > Préférences > J2EE. Vous trouverez des détails relatifs à la fonction de ciblage du serveur dans la documentation en ligne deIBM WebSphere Studio Site Developer. Lorsque la fonction est activée, vous pouvez cibler un serveur d'applications particulier. Elle prend en charge JDK 1.4, qui correspond à l'environnement d'exécution Java (JRE) de WebSphere Application Server version 5.1 livré avec IBM WebSphere Studio Site Developer version 5.1.1. Les projets J2EE qui prennent en charge la fonction de ciblage du serveur ne sont pas compatibles en amont avec les versions antérieures d'IBM WebSphere Studio Site Developer, et par conséquent ne peuvent pas être partagés avec les membres d'une équipe travaillant sur des versions antérieures d'IBM WebSphere Studio Site Developer (exemple : IBM WebSphere Studio Site Developer version 5.1, IBM WebSphere Studio Site Developer version 5.0.1). IBM WebSphere Studio Site Developer permet la compatibilité en amont lorsque cette fonction, décrite dans la section "Compatibilité en amont avec fonction de prise en charge du ciblage de serveur activée" est activée. L'incompatibilité est due au fait que la fonction de ciblage de serveur modifie le fichier .classpath d'un projet J2EE et que les versions antérieures de WebSphere Application Server - Express ne reconnaissent pas les nouvelles entrées du fichier .classpath.
Lorsqu'elle est activée, vous pouvez faire en sorte que les projets J2EE ciblés sur un serveur cessent d'utiliser la fonction de prise en charge du ciblage de serveur en sélectionnant l'option de serveur cible Aucun serveur cible spécifié disponible dans la boîte de dialogue Modification du serveur cible. Vous pouvez ouvrir cette fenêtre à partir du menu contextuel (Serveur cible > Modifier) d'un projet J2EE dans le navigateur de ressources ou dans la perspective J2EE. Vous pouvez aussi modifier le serveur cible en sélectionnant l'option Aucun serveur cible spécifié à partir de la page des propriétés J2EE (Propriétés > J2EE) pour les projets EAR, EJB, de client d'application et de connecteur. Le paramètre du serveur cible d'un projet Web se trouve dans la page des propriétés Web (Propriétés > Web). Vous trouverez des détails relatifs à la modification du ciblage de serveur dans la documentation d'IBM WebSphere Studio Site Developer. Lorsque l'option Aucun serveur cible spécifié est sélectionnée, le fichier .classpath reprend le style compatible avec les versions antérieures d'IBM WebSphere Studio Site Developer et le fichier .server est supprimé du projet.
En raison d'une modification apportée au JDK 1.4, l'utilisateur doit spécifier un package Java lors de l'utilisation des assistants Pages Web de base de données et Pages Web de bean Java pour générer des pages à exécuter sur IBM WebSphere Studio Site Developer version 5.1.1. Ce problème survient si le modèle de bean View est utilisé pour l'assistant Pages Web de bean Java ou le modèle Beans d'accès aux données IBM - Modèle maître de détail. Il se produit également pour les projets contenant des pages et des fichiers .java générés précédemment par ces assistants, et pour lesquels aucun package n'a été spécifié lors de la création. Pour le code précédemment généré, déplacez les fichiers .java dans un package. Ensuite, mettez à jour les fichiers .jsp ainsi que les instructions d'importation et les informations relatives aux classes. Dans le fichier web.xml du projet, mettez à jour l'entrée servlet-class.
Le présent chapitre se compose des sections suivantes :
IBM WebSphere Studio Site Developer version 5.1.1, repose sur le nouveau plan de travail Eclipse WebSphere Studio Workbench (WSWB) 2.1.2. Il existe des différences entres les versions 2.1.2 et 2.0.3 ou 2.0.2. Pour plus de détails sur ces différences, consultez le fichier readme situé dans le répertoire RépInstall_WS\eclipse\readme (où RépInstall_WS correspond au chemin d'installation d'IBM WebSphere Studio Site Developer).
IBM WebSphere Studio Site Developer version 5.0 reposait sur le plan de travail Eclipse WSWB 2.0.2 et IBM WebSphere Studio Site Developer version 5.0.1 sur le plan de travail Eclipse WSWB 2.0.3. Il n'existe pas de différence fondamentale entre les versions 2.0.2 et 2.0.3. L'édition d'IBM WebSphere Studio Site Developer version 5.0.1 était un correctif d'Update Manager installé sur IBM WebSphere Studio Site Developer version 5.0.
Lors du premier démarrage d'IBM WebSphere Studio Site Developer version 5.1.1 avec un espace de travail existant d'IBM WebSphere Studio Site Developer version 5.0, une boîte de dialogue apparaît et indique comment procéder à la migration à partir de la version 5.0. Cliquez sur OK pour effectuer la migration de l'espace de travail de la version 5.0 ou cliquez sur Annuler pour arrêter le lancement d'IBM WebSphere Studio Site Developer.
Même si vous avez procédé à la migration de l'espace de travail, vous pouvez l'utiliser dans la version 5.0 car les métadonnées des caractéristiques de nouveau projet sont ignorées et peuvent être lues par la version 5.0. Toutefois, dans la version 5.0, vous ne pouvez apporter aucune modification aux projets de l'espace de travail affectant ou remplaçant les métadonnées des caractéristiques de nouveau projet des projets.
La migration de projets Java à partir de la version 5 ou de la version 5.0.1 est simple et automatique. Une fois les projets chargés dans l'espace de travail de la version 5.1.1, aucune métadonnée n'est modifiée dans les fichiers .classpath ou .project, sauf si vous utilisez l'une des nouvelles fonctions disponibles dans la version 5.1.1.
Une attention particulière est requise lorsqu'un projet de référentiel coopératif est chargé et utilisé par des développeurs à l'aide d'IBM WebSphere Studio Site Developer version 5 et IBM WebSphere Studio Site Developer version 5.1.1. En effet, l'existence, le contenu et l'interprétation des fichiers de métadonnées dans les espaces de travail sont susceptibles d'être spécifiques à la version de la fonction ou du plug-in et peuvent varier d'une version à l'autre. La compatibilité des espaces de travail n'est garantie que dans les cas dans lesquels tous les développeurs mettent à niveau leur espace de travail IBM WebSphere Studio Site Developer pendant le verrouillage. Dans ces cas, les métadonnées ne génèrent aucun incident. Cependant, ce n'est pas le cas lorsque certains développeurs utilisent IBM WebSphere Studio Site Developer version 5.1.1 alors que d'autres utilisent IBM WebSphere Studio Site Developer version 5. Cette section indique quelles sont les actions recommandées et déconseillées.
En général, l'utilisateur d'IBM WebSphere Studio Site Developer version 5.1.1 remarque l'incompatibilité. Les métadonnées de la version 5.1.1 sont perdues lorsque l'utilisateur de la version 5 sauvegarde des modifications puis valide les fichiers de métadonnées mis à jour dans le référentiel. Voici certaines actions à ne pas effectuer :
Il convient d'apporter une attention particulière aux éléments ci-après lorsque le projet doit être partagé entre des utilisateurs d'IBM WebSphere Studio Site Developer version 5.1.1 et version 5 ou 5.0.1.
Cette prise en charge a été ajoutée dans IBM WebSphere Studio Site Developer version 5.1.1. Les informations concernant les ressources liées sont enregistrées dans le fichier .project.
Conseil : N'utilisez pas cette fonction. Il est conseillé de désactiver les ressources liées dans la page des préférences Plan de travail > Ressources liées.
Les informations concernant les compilateurs d'outils externes sont enregistrées dans le fichier .project. Le format de ces informations a été modifié entre la version 5 et la version 5.1.1. Les compilateurs créés ou modifiés dans la version 5.1.1 utilisent le nouveau format, qui n'est pas interprété dans l'espace de travail de la version 5. Les compilateurs créés dans la version 5 utilisent l'ancien format et peuvent être utilisés dans la version 5.1.1.
Conseil : Créez ou éditez les compilateurs d'outils externes à partir d'un espace de travail de la version 5.
Cette prise en charge a été ajoutée. Ces informations sont enregistrées dans le fichier .classpath.
Conseil : Ne spécifiez pas de modèles d'exclusion. Il est conseillé de désactiver les modèles d'exclusion dans la page des préférences Java > Compilateur > Chemin de compilation.
Cette prise en charge a été ajoutée. Ces informations sont enregistrées dans le fichier .classpath.
Conseil : Ne spécifiez pas d'autre dossier de sortie que celui par défaut (totalité du projet). Il est conseillé de désactiver les emplacements multiples de sortie dans la page des préférences Java > Compilateur > Chemin de compilation.
Lorsqu'un fichier ZIP source est associé à une bibliothèque JAR dans le chemin d'accès de compilation Java, le préfixe du chemin racine de la source est déduit automatiquement. Dans la version 5, il était possible de définir explicitement ce préfixe dans l'interface utilisateur et de l'enregistrer dans le fichier .classpath. Ainsi, un projet Java créé dans un espace de travail de la version 5.1.1 est susceptible de ne pas trouver la source jointe.
Utilisez la version 5 pour spécifier le chemin racine de la pièce jointe source. La version 5.1.1 permet une plus grande flexibilité concernant les pièces jointes source. Vous pouvez indiquer un dossier au lieu d'un fichier JAR ou ZIP comme pièce jointe source et associer la source à un dossier de fichier de classe. Cette fonctionnalité n'est pas disponible dans la version 5 (les informations de la version 5.1.1 sont ignorées).
PDE utilisant des conteneurs de chemin d'accès aux classes a été ajouté. Les conteneurs de chemin d'accès aux classes sont enregistrés dans le fichier .classpath. Si les conteneurs de chemin d'accès aux classes PDE sont utilisés, les entrées du chemin d'accès aux classes de l'espace de travail de la version 5 ne seront pas résolues et la majorité des fonctionnalités Java (compilation, recherche, exécution, débogage) ne généreront pas les résultats attendus.
Conseil : Assurez-vous que le paramètre d'utilisation des conteneurs de chemin d'accès aux classes sur la page des préférences Développement de plug-in > Contrôle du chemin de compilation Java est désactivé avant de créer de nouveaux projets de plug-in (ou de fragment).
Les noms de dossier sont Java Source et Web Content. Il est possible de configurer les noms de dossier par défaut des nouveaux projets Web dans la page des préférences (Fenêtre > Outils Web > Nouveau projet). Les noms par défaut sont désormais JavaSource et WebContent. Ces noms par défaut seront utilisés uniquement pour les nouveaux projets Web. Les projets Web créés dans des versions antérieures à cette édition continueront à fonctionner avec les anciens noms. Ceci est également vrai pour les projets Web statiques.
Si vous souhaitez modifier les noms des dossiers source des projets des versions 4.0.x et 5.0 dans la version 5.1.1, utilisez l'option Renommer du menu en incrustation dans la vue Navigateur. Cette option permet de renommer les dossiers et de corriger le chemin de compilation Java des projets Web des versions 4.0.x et 5.0.x.
Dans le cas du dossier JavaSource, l'option Renommer fonctionne dans les vues Navigateur de projets et Packages. Dans le cas du dossier WebContent, l'option Renommer est disponible dans les vues du navigateur de ressources et du navigateur de projets.
Si un projet Web d'une version antérieure à cette édition est enregistré dans un référentiel SCM, puis chargé dans cette édition, il conservera l'ancienne structure composée des dossiers source et webApplication. L'une ou l'autre structure sera correctement compilée.
Le contexte d'exécution des outils Struts est passé de la version 1.1 bêta 2 dans la version 5 à la version 1.1. Dans IBM WebSphere Studio Site Developer version 5 (disponibilité générale), lorsque vous créez un projet Web, vous pouvez choisir d'ajouter le support Struts à votre projet. Vous avez le choix entre Struts 1.0.2 et Struts 1.1 bêta 2. Dans IBM WebSphere Studio Site Developer version 5.1.1, le dernier choix est remplacé par Struts 1.1. Si vous avez créé des projets Web avec Struts 1.1 bêta 2 dans IBM WebSphere Studio Site Developer version 5, vous pouvez les convertir vers Struts 1.1, mais cette opération n'est pas obligatoire car Struts 1.1 bêta 2 demeure pris en charge. Pour convertir des projets Web créés avec Struts 1.1 bêta 2 vers Struts 1.1, procédez comme indiqué ci-après.
Toutes les indications ci-dessus sont également valables si vous convertissez un projet Web Struts 1.1 bêta 3 de IBM WebSphere Studio Site Developer version 5.0.1 vers Struts 1.1.
Les outils des services Web disposent de deux nouveaux protocoles d'exécution d'IBM WebSphere Application Server version 5.0.2 qui s'exécutent uniquement sur WebSphere Application Server version 5.0.2. Aucune migration n'est nécessaire puisque IBM WebSphere Studio Site Developer version 5.1.1 et WebSphere Application Server version 5.0.2 prennent en charge les anciens et les nouveaux protocoles. IBM WebSphere Studio Site Developer génère et déploie trois protocoles d'exécution des artefacts de service Web : l'ancien protocole d'exécution "IBM SOAP" qui s'exécute sur WebSphere Application Server versions 4.x et 5.x ; le nouveau protocole d'exécution "IBM WebSphere 5.0.2 runtime" qui s'exécute uniquement sur WebSphere Application Server version 5.0.2 ; et le nouveau protocole d'exécution "Apache Axis 1.0" qui s'exécute uniquement sur WebSphere Application Server version 5.0.2.
Vous pouvez réutiliser les projets de la version 5 ainsi que les fichiers WAR et EAR associés aux services Web sans qu'il soit nécessaire de les modifier dans la version 5.1.1. Pour convertir les clients et les services Web vers le nouveau protocole d'exécution IBM WebSphere 5.0.2 et bénéficier des normes JSR 101, 109, WS-I et WS-Security, vous devez les regénérer via l'assistant de services Web. L'explorateur de services Web continue automatiquement à lire les préférences de l'utilisateur même si le fichier de données physique est déplacé automatiquement vers un nouvel emplacement.
Lorsque vous effectuez la migration d'un espace de travail à partir de la version 5, le message d'erreur "Erreurs lors de la restauration du plan de travail" s'affiche. Ce message apparaît si la perspective Profilage est ouverte lors de la migration et si la vue Mémoire dynamique ou Statistiques d'instances est visible dans la perspective Profilage. En effet, les vues Mémoire dynamique et Statistiques d'instances qui existaient dans la version 5 ont été supprimées. Ce message apparaît également si la perspective Profilage est ouverte dans l'espace de travail lors de la migration. Ignorez ce message d'erreur et cliquez sur OK.
Afin de pouvoir utiliser un modèle personnalisé créé dans la version 5, vous devez le charger, le reconnecter à la base de données et le sauvegarder. Lors du chargement suivant du modèle personnalisé sauvegardé, la connexion est vérifiée.
Il est possible que les artefacts J2EE générés dans cette édition ne puissent pas être lus par IBM WebSphere Studio Site Developer version 4.0.3, ni exécutés dans les environnements de test de la version 4.0.3. Puisque l'assistant de modèle n'était pas fourni avec la version 4.0.3, la compatibilité amont n'est pas conservée dans cette version.
Les applications modèles générées dans cette édition peuvent être exécutées dans la version 5 si, dans les préférences du projet Web, le dossier de la source Java est appelé "Java Source" et que le dossier du contenu Web est appelé "Web Content".
Le présent chapitre explique comment effectuer une migration à partir d'IBM WebSphere Studio Site Developer version 4.0.x vers la version 5.
Pour migrer un projet IBM WebSphere Studio Site Developer de la version 4.0.x vers la version 5, vous pouvez utiliser l'une des deux méthodes décrites en détail ci-après.
La migration de la version 4 à la version 5 ne modifie pas automatiquement le niveau J2EE des projets car la version 5 peut continuer à compiler et à déployer des applications dans WebSphere Application Server version 4. Il est possible de migrer tous les types de projet J2EE, dont les projets Web, à l'aide de l'assistant de migration J2EE, disponible dans IBM WebSphere Studio Site Developer. Pour accéder à l'assistant de migration J2EE, cliquez avec le bouton droit de la souris sur le projet de type J2EE et sélectionnez ensuite Migrer > Assistant de migration J2EE.
Liste partielle des améliorations par rapport à la version 4.0.x :
L'InfoCenter WebSphere [www.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/ index.html] contient les informations ci-après.
Le manuel Migrating to WebSphere V5.0 An End-to-End Migration Guide fournit des informations sur la migration à partir de la version 3.5 et de la version 4.0 vers la version 5 [www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246910.pdf].
La page de téléchargements de WebSphere Application Server [www14.software.ibm.com/webapp/download/product.jsp?s=p&id=TDUN-49EVRT&type=s&dt=DIAGNOSTIC+TOOL] donne accès à des outils de conversion d'applications :
Si votre projet contient des dépendances circulaires, la version 5 signale une erreur de compilation. Vous pouvez sélectionner Fenêtre > Préférences > Java > Compilateur, cliquer sur l'onglet Chemin de compilation et désélectionner l'option Annuler la compilation en cas d'erreurs dans le chemin de compilation. Cela ne provoque plus l'arrêt de la compilation mais entraîne l'affichage d'une ou plusieurs erreurs de type 'dépendance en boucle' dans la vue Tâches (même si la compilation est par ailleurs réussie). Dans ce cas, vous pouvez modifier ces erreurs en avertissements en sélectionnant l'onglet Autre, puis en modifiant la préférence dans la liste déroulante Dépendances circulaires.
Dans IBM WebSphere Studio Site Developer version 5, la structure interne des projets a été modifiée par rapport à la version 4.0.3. Il est possible d'importer un fichier WAR Web J2EE version 5, exporté avec du code source Java, dans IBM WebSphere Studio Site Developer version 4. Le dossier du code source est alors automatiquement converti avec le nom approprié et la compilation se déroule normalement. De même, le projet Web s'exécute correctement sur WebSphere Application Server version 4 lorsqu'un projet de la version 4 est importé dans la version 5, car le dossier du code source est automatiquement converti avec le nom approprié. Pour plus d'informations sur les modifications du nom des dossiers, voir "Structures des projets Web IBM WebSphere Studio Site Developer".
La structure interne des projets Web dans IBM WebSphere Studio Site Developer version 5 est différente de ce qu'elle était dans IBM WebSphere Studio Site Developer version 4.0.x. Cette différence n'est pas liée au passage de J2EE 1.2 en J2EE 1.3, mais plutôt à une modification d'utilisation de l'outil.
Dans la version 4, les projets Web sont par défaut des projets Web dynamiques et ils apparaissent dans le vue Navigateur avec un dossier source et un dossier webApplication. Dans la version 5, si vous créez un projet Web dynamique, celui-ci apparaît avec un dossier Java Source à la place du dossier source et un dossier Web Content à la place du dossier webApplication.
Toutefois, si un projet Web de la version 4 est enregistré dans un référentiel SCM, puis chargé dans la version 5, il conservera l'ancienne structure avec les dossiers source et webApplication. L'une ou l'autre structure sera correctement construite dans la version 5.
La version 5 permet de créer des projets Web statiques, ainsi que des projets Web dynamiques.
Les projets Web statiques contiennent uniquement des ressources statiques comme des éléments HTML, des éléments Java Scripts, des images, du texte, etc., mais ne renferment aucun contenu dynamique. Les projets Web statiques peuvent être exécutés et servis par un serveur Web HTTP traditionnel et ne nécessitent pas de serveur d'applications Web.
Les projets Web dynamiques contiennent, outre des ressources statiques, des ressources J2EE dynamiques comme les servlets, les pages JSP, les filtres et les métadonnées associées. Lorsque vous créez des projets Web dynamiques, vous pouvez inclure des feuilles de style en cascade et des bibliothèques de balises JSP pour pouvoir commencer le développement avec un plus grand ensemble de ressources de projet. Les projets Web dynamiques sont toujours imbriqués dans les projets d'application enterprise et ne peuvent être exécutés que sur des serveurs d'applications Web.
Cette méthode est recommandée pour déplacer des espaces de travail de la version 4.0.x vers IBM WebSphere Studio Site Developer version 5. Cette méthode est la seule qui permette de migrer la totalité des informations, y compris celles relatives au chemin de compilation d'un projet.
Conseil : Dans la version 4, le répertoire de l'espace de travail se trouve par défaut dans le répertoire d'installation. Dans la version 5, il correspond par défaut à un répertoire appelé workspace dans le répertoire My Documents. Pour modifier le répertoire de stockage de vos fichiers de travail, exécutez la commande avec l'option -data lorsque vous lancez le plan de travail.
Pour ClearCase : Utilisez un espace de travail version 5 nettoyé et, pour chaque projet à charger, sélectionnez Fichier > Importer > Projet WebSphere Studio 4.x ClearCase existant dans l'espace de travail.
Remarques à prendre en compte après la migration :
Le projet n'a pas été compilé en raison d'erreurs dans le chemin de classe (incomplet ou impliqué dans un cycle). Dossier source requis manquant : /MyHomePageExample403/source.
Les fichiers d'extension d'application EAR IBM et les fichiers de configuration du serveur version 4 contenaient des références de chemins d'accès absolus. Après avoir migré ces fichiers dans la version 5, vous devez les ouvrir à l'aide de l'éditeur approprié (qui remplace automatiquement les anciennes références de chemin d'accès absolu par des références de chemin relatif).
Le fichier d'extensions IBM contient des chemins absolus déconseillés. Cette erreur peut être corrigée automatiquement et doit être sauvegardée. Les chemins seront supprimés du fichier à la première opération. Voulez-vous procéder à la correction automatique ?
D'autres fournisseurs SCM fournissent des plug-ins SCM pour IBM WebSphere Studio Site Developer. Vous pouvez consulter la liste des fournisseurs à l'adresse suivante : www.ibm.com/software/ad/studioappdev/partners/scm.html. Dans le cadre de la validation Ready for IBM WebSphere Studio software [www.developer.ibm.com/websphere/ready.html], tous les fournisseurs SCM de plug-in pour la version 4 se sont assurés que les étapes de migration précédentes (sauvegarde à partir de la version 4 vers le référentiel SCM, chargement à partir du référentiel dans la version 5) s'appliqueront également à leurs systèmes.
Cette approche n'est pas prise en charge entièrement et la migration effectuée n'est pas complète. Les paramètres de l'interface utilisateur, de débogage et la plupart des options de préférences sont perdus. Seuls le nom, les fichiers sources et le chemin de compilation Java de chaque projet (chemin d'accès aux classes) sont conservés. Aucune garantie n'est fournie pour les autres informations. Adoptez cette approche uniquement si aucun système SCM pris en charge n'est utilisé et s'il est indispensable de conserver les informations sur le chemin de compilation d'un projet (ce chemin est perdu lorsque vous importez un projet qui a été exporté à partir de la version 4). Vous pouvez utiliser l'espace de travail existant en version 4.0.x en procédant comme suit :
Reportez-vous aux opérations à effectuer après la migration décrites à la section Suppression des références de chemin d'accès absolu dans les fichiers EAR et les fichiers de configuration serveur après la migration.
Les incidents suivants peuvent se produire si vous tentez d'effectuer une migration en ouvrant un espace de travail en version 4.0 dans IBM WebSphere Studio Site Developer version 5.
Pour redéfinir la variable du chemin d'accès aux classes JRE_LIB et indiquer un emplacement valide, procédez aux opérations ci-après. Redéfinissez cette variable même si sa valeur vous paraît correcte lorsque vous ouvrez la fenêtre Préférences pour la première fois.
Si vous n'effectuez pas cette opération, la valeur de JRE_LIB risque d'être erronée et de générer de nombreuses erreurs de compilation dans les fichiers Java.
Pour plus de sécurité, vérifiez également la valeur de toutes les autres variables de chemin d'accès aux classes.
La prise en charge de l'environnement coopératif a été fortement modifiée entre Eclipse 1.0 et 2.0. La méthode de partage des projets au sein du référentiel a également changé.
Par défaut, les projets sont créés dans le répertoire de l'espace de travail. Si vous avez redéfini la valeur par défaut pour créer les projets dans un autre répertoire, vous devez ouvrir tous les projets avant de fermer le plan de travail. Cette option permet de placer le fichier .project dans l'emplacement approprié. Si vous ne pouvez pas ouvrir un projet dont le répertoire se trouve hors de l'espace de travail, un projet masque le projet réel, avec un seul fichier .project.
Vous devez supprimer tous les points d'arrêt JSP et les redéfinir dans l'espace de travail migré de la version 5.
Pour effectuer la migration des données relationnelles à partir des projets 4.0.3 d'IBM WebSphere Studio Site Developer, procédez aux opérations ci-après.
Les artefacts de données relationnelles seront restaurés.
Si vous avez importé un fichier de services Web à partir d'une version 4.0.x, les messages d'erreur suivants peuvent apparaître :
Erreur Le composant 'result' comporte une valeur incorrecte 'anyElement' définie pour son type. Les déclarations de type doivent désigner des valeurs valides définies dans un schéma. Erreur Le composant 'return' comporte une valeur incorrecte 'findPatientResult' définie pour son élément. Les déclarations d'élément doivent désigner des valeurs valides définies dans un schéma. Erreur Le composant 'response' comporte une valeur incorrecte 'findPatientResponse' définie pour son élément. Les déclarations d'élément doivent désigner des valeurs valides définies dans un schéma.
Pour corriger ces erreurs :
Pour accéder à l'assistant de migration J2EE de la version 5, procédez comme indiqué ci-après.
Le présent chapitre décrit la procédure de migration à partir de WebSphere Studio version 4.0 (Advanced et Professional Edition) vers IBM WebSphere Studio Site Developer. La migration à partir de WebSphere Studio "Classic" version 4.0 vers IBM WebSphere Studio Site Developer version 5.0 comprend les étapes suivantes :
La fonction avancée de publication (mappage de fichiers à différentes étapes de la publication) et la fonction Page Detailer (analyse des pages Web) de WebSphere Studio "Classic" n'est pas disponible dans IBM WebSphere Studio Site Developer. Certaines fonctions disponibles dans le coffret de CD-ROM de la version 4.0.x ne sont plus disponibles. Par exemple, la fonction Page Detailer pour l'analyse des pages Web, la fonction HotMedia pour les types de media enrichis, l'éditeur Voice XML (déplacé dans WebSphere Everyplace Toolkit et Portal Toolkit) et DataBaseWizard pour les unités mobiles.
Vous devez prendre en compte les limitations ci-après avant d'effectuer la migration de vos données WebSphere Studio.
Lors de la procédure de migration décrite ci-après, WebSphere Studio crée un fichier JAR contenant tous les fichiers des projets, les fichiers publiables et les fichiers source pour un serveur unique. Tous les fichiers visibles dans la vue Publication du serveur par défaut sont regroupés dans le fichier JAR. Vous pouvez ensuite importer le fichier JAR dans IBM WebSphere Studio Site Developer.
Toutes les informations de planification et de publication sont perdues lors de la migration des projets. Si la planification comporte plusieurs serveurs, seuls les fichiers publiés sur le serveur par défaut sont conservés. Pour la migration, il convient donc de créer une planification comportant un seul serveur.
Si la planification en cours comporte plusieurs serveurs, créez une nouvelle planification, appelée Migration, qui ne comporte qu'un seul serveur. Pour cela, procédez comme indiqué ci-après.
Le nom par défaut du fichier descripteur de configuration Web est nomServeur_web.xml (localhost_web.xml dans notre scénario). A moins que vous n'ayez indiqué un autre répertoire, le fichier .xml est enregistré dans le répertoire WEB-INF.
Vous pouvez à présent tester votre application. Pour effectuer cette opération sur le serveur de test par défaut, procédez comme indiqué ci-après.
Pour tester l'application dans d'autres environnements d'exécution de serveur, reportez-vous à l'aide en ligne de la fonction Outils de serveur.
Le présent chapitre décrit la procédure à suivre pour effectuer la migration à partir de VisualAge for Java Professional Edition ou VisualAge for Java Enterprise Edition vers IBM WebSphere Studio Site Developer.
Instantiations, Inc., Partenaire Commercial IBM, distribue un produit,
CodePro Studio, qui permet d'améliorer la productivité dans VisualAge for
Java et WebSphere Application Server - Express et offre des fonctions de
migration et de coexistence. Pour aider les clients VisualAge for Java
à commencer la migration, Instantiations offre une fonction d'exportation
VisualAge for Java vers IBM WebSphere Studio Site Developer gratuite et à
usage illimité, avec la copie d'évaluation de CodePro Studio, utilisable
pendant une durée limitée. Vous pouvez télécharger la copie
d'évaluation à partir du site www.instantiations.com/vaj-migrate.
Pour plus d'informations sur la prise en charge avancée des fonctions de
migration et de coexistence, comprenant l'importation/exportation
bidirectionnelle complète de fichiers, la création d'ensembles
d'exportation/importation, la synchronisation de projets et
l'automatisation des tâches, accédez au site Instantiations, Inc.
à l'adresse http://www.instantiations.com/codepro/ws.
Vous trouverez ci-après une liste succincte des améliorations apportées depuis VisualAge for Java.
La procédure ci-après explique comment effectuer une migration à partir de VisualAge for Java. Chaque étape est détaillée plus loin.
La migration en vrac des projets et des ressources versionnés à partir du référentiel VisualAge for Java n'est pas prise en charge. Vous pouvez uniquement migrer des projets et des ressources qui se trouvent dans votre espace de travail VisualAge for Java. Pour effectuer la migration d'une copie versionnée d'un projet ou d'une ressource dans IBM WebSphere Studio Site Developer, placez celle-ci dans l'espace de travail VisualAge for Java et procédez ensuite à la migration.
Exportez les projets dans un fichier JAR en procédant comme indiqué ci-après.
Démarrez IBM WebSphere Studio Site Developer puis créez les projets appropriés. Les instructions générales concernant la migration présentées ci-dessous vous aident à déterminer le type de projet IBM WebSphere Studio Site Developer dans lequel vous devez importer les fichiers :
Si l'application utilise des servlets, vous devez définir les correspondances entre les servlets et les URL dans le fichier web.xml. Procédez comme indiqué ci-après.
Vous devez enregistrer les paramètres de VisualAge for Java et les définir dans IBM WebSphere Studio Site Developer :
Chemin d'accès à la classe du projet
Dans VisualAge for Java, vous définissez le chemin d'accès aux classes du projet dans la page Ressources de la fenêtre Options (Fenêtre > Options > Ressources). Après avoir migré les projets dans IBM WebSphere Studio Site Developer , vous pouvez définir le chemin d'accès à la classe du projet dans le fenêtre Propriétés du projet. (Cliquez avec le bouton droit sur le projet et sélectionnez Propriétés > Chemin de compilation Java. Cliquez sur l'onglet Bibliothèques.) Vous pouvez également définir les variables de chemin d'accès aux classes dans la fenêtre Préférences (Fenêtre > Préférences > Java > Variables d'accès aux classes.)
Associations de ressources
Si vous définissez une association entre un type de fichier et un exécutable, vous pouvez ouvrir un fichier dans le plan de travail même si celui-ci ne s'y trouve pas.
Dans VisualAge for Java, vous définissez les associations de ressources dans la fenêtre Options (Fenêtre > Options > Ressources > Associations de ressources). Après avoir migré les fichiers de ressources dans IBM WebSphere Studio Site Developer, vous pouvez définir les associations de ressources dans la fenêtre Préférences (Fenêtre > Préférences > Plan de travail > Association de fichier).
Outil de formatage du code
Dans VisualAge for Java, vous définissez les options de formatage du code dans la page Module de formatage de la fenêtre Options (Fenêtre > Options > Codage > Module de formatage). Après avoir migré le code vers IBM WebSphere Studio Site Developer, vous pouvez définir le formatage du code dans la fenêtre Préférences (Fenêtre > Préférences > Java > Outil de formatage du code).
Configuration WTE
Dans VisualAge for Java, les paramètres d'exécution de l'environnement de test WebSphere et WebSphere Application Server sont définis dans plusieurs fichiers de propriétés figurant dans le répertoire suivant : RépInstallVisualAge\ide\project_resources\IBM WebSphere Test Environment\properties, où RépInstallVisualAge est le répertoire d'installation du produit.
Si, par exemple, vous avez activé la réécriture des URL dans le fichier de propriétés session.xml en attribuant la valeur true à la propriété comme indiqué ci-après, <url-rewriting-enabled>true</url-rewriting-enabled>, vous pouvez configurer cette propriété dans l'environnement de test d' IBM WebSphere Studio Site Developer , version 4.0. (Dans la perspective du serveur, ouvrez la vue Configuration de serveur, cliquez avec le bouton droit de la souris sur le serveur que vous voulez utiliser et sélectionnez Ouvrir. Cliquez sur l'onglet Web et cochez la case Activer la réécriture des URL).
Fichiers Java et fichiers de ressources du projet
Le fichier de propriétés default.servlet_engine contient la racine du contexte <root-uri> des applications Web VisualAge for Java. Lors de la création d'un projet Web dans IBM WebSphere Studio Site Developer, la boîte de dialogue Créer un projet Web contient une zone Racine du contexte réservée à ces données.
Les paramètres de l'application Web figurant dans des fichiers, tels que RépInstallVisualAge\ide\project_resources\IBM WebSphere Test Environment\hosts\default_host\default_app\servlets\default_app.webapp que vous avez personnalisés doivent être migrés dans le fichier Votre_projet_Web\Web Content\WEB-INF\web.xml dans IBM WebSphere Studio Site Developer. Par exemple, si vous avez modifié les noms de servlet et les chemins d'accès aux servlets dans le fichier default_app.webapp, vous devez effectuer les modifications correspondantes dans le fichier web.xml.
Si l'application est un projet Java, vous pouvez utiliser le support normal d'exécution ou de débogage d' IBM WebSphere Studio Site Developer des projets Java pour tester l'application.
Si l'application utilise WebSphere Application Server, vous devez la tester à l'aide du système WebSphere Application Server intégré. Il faut pour cela créer et démarrer un serveur de test par défaut. Dans le cas d'un projet Web, cliquez avec le bouton droit sur la page HTML principale et sélectionnez Exécuter sur le serveur pour lancer le navigateur web.
Pour plus d'informations sur le test d'autres types de projet, consultez l'aide en ligne.
Si vous utilisez WebSphere Application Server en tant qu'environnement d'exécution, déployez les applications à l'aide de la fonction Outils de serveur de IBM WebSphere Studio Site Developer.
Les projets d'IBM WebSphere Studio Site Developer (et leurs paramètres) peuvent être partagés entre les développeurs. Pour ce faire, enregistrez un projet sur le serveur SCM (Software Configuration Management) d'IBM WebSphere Studio Site Developer et procédez à son extraction sur le système d'un membre d'une autre équipe IBM WebSphere Studio Site Developer.
Pour plus d'informations sur le support de développement coopératif dans IBM WebSphere Studio Site Developer version 4.0, consultez l'article suivant : www.ibm.com/websphere/developer/library/techarticles/0108_karasiuk/ 0108_karasiuk.html
Le guide d'installation et l'aide en ligne contiennent également des informations sur le support de développement coopératif dans IBM WebSphere Studio Site Developer.
Le présent chapitre décrit les instructions à suivre pour migrer des applications créées dans l'éditeur de composition visuelle VisualAge for Java vers Visual Editor for Java dans WebSphere Application Server - Express :
Cette étape n'est pas obligatoire mais il est fortement conseillé de l'exécuter (en particulier si l'application comporte des connexions) pour les raisons ci-après.
Pour sauvegarder les informations avancées relatives aux métadonnées avant la migration, procédez comme indiqué ci-après.
Vous pouvez à présent importer vos classes dans WebSphere Application Server - Express. Voir Chapitre 7, "Migration à partir de VisualAge for Java vers IBM WebSphere Studio Site Developer". Après avoir importé vos programmes sources Visual Composition Editor dans WebSphere Application Server - Express, vous pouvez les mettre à jour dans Visual Editor for Java.
La structure du présent chapitre est la suivante :
Pour obtenir des explications détaillées concernant les éléments impliqués, reportez-vous à l'article relatif au chargement des classes J2EE J2EE Class Loading Demystified (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer.html) (modules J2EE et chemin d'accès aux classes) et au développement de fichiers JAR d'utilitaire J2EE (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer2.html) (fichiers JAR Java dans les modules J2EE). Vous y trouverez des informations techniques et des conseils très intéressants.
Pour utiliser un fichier JAR tiers dans un projet Web, il convient de l'importer dans le dossier des bibliothèques du projet (en le conservant en tant que fichier JAR). Cette méthode d'utilisation d'un fichier JAR est la seule méthode J2EE compatible qui évite d'effectuer des modifications lors du déploiement sur un autre serveur.
Pour utiliser un fichier JAR externe dans un seul projet Web, suivez la procédure ci-dessous. Si vous devez utiliser le fichier JAR dans plusieurs projets Web, suivez plutôt la procédure présentée à la section "Méthode recommandée en cas d'utilisation d'un fichier JAR tiers dans plusieurs projets Web" .
Pour utiliser un fichier JAR tiers dans plusieurs projets Web, il convient de l'importer dans le projet EAR (en le conservant en tant que fichier JAR). Cette méthode d'utilisation d'un fichier JAR est la seule méthode J2EE compatible qui évite d'effectuer des modifications lors du déploiement sur un autre serveur.
Pour utiliser un fichier JAR externe avec plusieurs projets Web, suivez la procédure ci-dessous. Si vous devez uniquement utiliser le fichier JAR dans un seul projet Web, suivez les étapes présentées à la section précédente.
Vous pouvez laisser le fichier JAR en dehors de WebSphere Application Server - Express et l'ajouter dans le chemin de compilation Java et dans le chemin d'accès aux classes de l'instance du serveur. Cette solution n'est pas conseillée car elle rend difficile la portabilité de votre application. Lorsque vous devez effectuer un transfert vers un autre serveur, il est nécessaire de mettre à jour le chemin d'accès aux classes du serveur. De même, vous devez vérifier que vos fichiers de classes n'entrent pas en conflit avec d'autres versions de fichiers de classes similaires déjà définis dans le chemin d'accès aux classes du serveur (ces fichiers sont requis par le serveur et d'autres applications de ce dernier). Si vous optez pour cette procédure, procédez comme indiqué ci-après.
La fonction d'auto-compilation de WebSphere Application Server - Express peut ralentir la vitesse d'exécution de compilations de plusieurs projets complexes. Vous pouvez contrôler ces auto-compilations à l'aide de fichiers dépendants, en activant ou en désactivant des projets, ou en utilisant des projets au format source ou JAR. Ces options peuvent toutefois être complexes à mettre en oeuvre. Pour plus d'informations sur ces options et sur l'optimisation de la compilation, reportez-vous à l'article WebSphere Developer Domain "Optimizing Multi-Project Builds Using dependent Project JARs in WebSphere Studio Application Developer" (www.ibm.com/websphere/developer/library/techarticles/0204_searle/searle.html).
Vous pouvez utiliser Ant avec WebSphere Application Server - Express pour automatiser des compilations de production. Un article complet sur ce sujet explique les points suivants :
Consultez l'article "Using Ant with WebSphere Studio Application Developer" dans le domaine WebSphere Developer (www.ibm.com/websphere/developer/library/techarticles/0203_searle/searle1.html).
Le présent chapitre contient des exemples de migration destinés à vous aider à en savoir plus sur la migration de VisualAge for Java et WebSphere Studio "Classic" vers WebSphere Application Server - ExpressIBM WebSphere Studio Site Developer.
Description
Il s'agit de l'exemple FindTheLeapYears fourni avec VisualAge for Java version 4.0. Vous trouverez des informations le concernant dans l'aide en ligne de VisualAge for Java (Exemples > Environnement de développement JSP/Servlet).
Migration - Généralités
Vous pouvez exécuter la procédure suivante pour migrer l'exemple de VisualAge for Java vers IBM WebSphere Studio Site Developer. Ces étapes sont présentées en détail ci-dessous :
Importez les fichiers source Java dans le répertoire source du projet LeapYear en procédant comme indiqué ci-après.
Importez les fichiers de ressources dans le projet LeapYear situé dans le répertoire WebContent en procédant comme indiqué ci-après.
Vous devez maintenant apporter les modifications nécessaires aux applications en raison d'un léger changement de structure de l'application/source.
A ce stade, l'exemple a été migré vers IBM WebSphere Studio Site Developer. Il suffit maintenant de créer un projet serveur IBM WebSphere Studio Site Developer et de tester l'exemple dans l'environnement de test WebSphere.
Vous devez maintenant définir le projet EAR dans la configuration du serveur.
Description
Pour cet exemple, vous devez utiliser WebSphere Studio "Classic" version 4.0.x.
L'exemple que vous allez utiliser s'appelle YourCo. Pour y accéder, ouvrez l'aide en ligne (Aide > WebSphere Studio 4.0 > Procédures > Utilisation des exemples > Généralités). Pour charger cet exemple, suivez les instructions fournies à la rubrique Ouverture des exemples Studio (pour WebSphere Application Server 4.0) et chargez YourCo.war.
Etapes préalables
Etapes de la migration
Pour migrer cet exemple à partir de WebSphere Studio "Classic" vers IBM WebSphere Studio Site Developer, suivez la procédure ci-dessous. Chaque étape est décrite en détail ci-dessous.
(Facultatif) Il convient normalement de créer une phase de migration mais, pour les besoins de cet exemple, vous devez utiliser la phase de test incluse dans WebSphere Studio "Classic". En procédant ainsi, il n'est pas nécessaire de modifier manuellement les mappages de servlets comme indiqué à l'étape 8.
Pour plus d'informations sur la création d'une phase de migration, reportez-vous à la section "Migration à partir de WebSphere Studio "Classic" vers IBM WebSphere Studio Site Developer"
a. com.ibm.db requiert le fichier databeans.jar, b. com.ibm.webtools.runtime requiert le fichier webtlsrn.jar, c. com.ibm.ejs.ns.jndi requiert le fichier ns.jar, d. com.ibm.websphere.advanced.cm.factory requiert le fichier cm.jar, e. com.ibm.ejs.models.base.extensions.webappext.ServletExtensions requiert le fichier ws-base-extensions.jar
Pour résoudre cet incident, vous devez modifier le chemin de compilation Java du projet Web.
A ce stade, l'exemple a été migré vers IBM WebSphere Studio Site Developer. Il suffit maintenant de créer un projet serveur IBM WebSphere Studio Site Developer et de tester l'exemple dans l'environnement de test WebSphere.
Vous devez maintenant définir le projet EAR dans la configuration du serveur.
Vous pouvez consulter les informations les plus récentes sur la migration et d'autres sujets sur le site suivant : www.ibm.com/websphere/developer/zones/studio/transition.html
Les publications et les pages Web suivantes fournissent des informations utiles concernant l'utilisation de WebSphere Application Server - Express :
Autres références bibliographiques :
Note to U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Le présent document peut contenir des informations ou des références concernant certains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plus de détails, reportez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial IBM. Toute référence à un produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit d'IBM. Il est de la responsabilité de l'utilisateur d'évaluer et de vérifier lui-même les installations et applications réalisées avec des produits, logiciels ou services non expressément référencés par IBM.
IBM peut détenir des brevets ou des demandes de brevet couvrant les produits mentionnés dans le présent Document. La remise de ce document ne vous donne aucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirez recevoir des informations concernant l'acquisition de licences, veuillez en faire la demande par écrit à l'adresse suivante :
IBM EMEA Director of Licensing
Les informations sur les licences concernant les produits utilisant un jeu de caractères double octet peuvent être obtenues par écrit à l'adresse suivante :
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans aucune obligation de sa part, tout ou partie des informations qui lui seront fournies.
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun pays dans lequel il serait contraire aux lois locales : LE PRESENT DOCUMENT EST LIVRE "EN L'ETAT"; IBM DECLINE TOUTE RESPONSABILITE, EXPLICITE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE VALEUR MARCHANDE OU D'ADAPTATION A VOS BESOINS. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. Il est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut modifier sans préavis les produits et logiciels décrits dans ce document.
Les licenciés souhaitant obtenir des informations permettant : (i) l'échange des données entre des logiciels créés de façon indépendante et d'autres logiciels (dont celui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresser leur demande à :
Lab Director
IBM Canada Ltd. Laboratory
8200 Warden Avenue
Markham, Ontario, Canada L6G 1C7
Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans ce document et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux termes du Contrat sur les produits et services IBM, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.
Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer l'exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoir aucune réclamation concernant des produits non IBM. Toute question concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.
Les références à des sites Web non IBM sont fournies à titre d'information uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils contiennent. Les éléments figurant sur ces sites Web ne font pas partie des éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule responsabilité.
Le présent document peut contenir des exemples de données et de rapports utilisés couramment dans l'environnement professionnel. Ces exemples mentionnent des noms fictifs de personnes, de sociétés, de marques ou de produits à des fins illustratives ou explicatives uniquement. Toute ressemblance avec des noms de personnes, de sociétés ou des données réelles serait purement fortuite.
LICENCE SUR LES DROITS D'AUTEURS :
Le présent logiciel contient des exemples de programmes d'application en langage source destinés à illustrer les techniques de programmation sur différentes plateformes d'exploitation. Vous avez le droit de copier, de modifier et de distribuer ces exemples de programmes sous quelque forme que ce soit et sans paiement d'aucune redevance à IBM, à des fins de développement, d'utilisation, de vente ou de distribution de programmes d'application conformes aux interfaces de programmation des plateformes pour lesquels ils ont été écrits ou aux interfaces de programmation IBM. Ces exemples de programmes n'ont pas été rigoureusement testés dans toutes les conditions. Par conséquent, IBM ne peut garantir expressément ou implicitement la fiabilité, la maintenabilité ou le fonctionnement de ces programmes. Vous avez le droit de copier, de modifier et de distribuer ces exemples de programmes sous quelque forme que ce soit et sans paiement d'aucune redevance à IBM, à des fins de développement, d'utilisation, de vente ou de distribution de programmes d'application conformes aux interfaces de programmation IBM.
Toute copie totale ou partielle de ces programmes exemples et des oeuvres qui en sont dérivées doit comprendre une notice de copyright, libellée comme suit :
(C) (nom de la société) (année). Des segments de code sont dérivés des Programmes exemples d'IBM Corp. (C) Copyright IBM Corp. 2000, 2003. All rights reserved.
Les informations relatives aux interfaces de programmation sont destinées à vous aider à créer des applications à l'aide de ce programme.
L'interface de programmation générique permet à l'utilisateur d'écrire des applications qui obtiennent des services de ce programme.
Toutefois, cette interface de programmation générique peut également contenir des aides au diagnostic, à la modification et à l'optimisation. Ces dernières ont pour but de vous assister dans le débogage de votre application.
Avertissement : N'utilisez pas ces aides comme une interface de programmation car elles sont susceptibles d'être modifiées.
Les termes qui suivent sont des marques d'International Business Machines Corporation aux Etats-Unis et/ou dans certains autres pays :
Java et toutes les marques et logos incluant Java sont des marques de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
ActiveX, Microsoft, Windows, Windows NT et le logo Windows sont des marques de Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays.
UNIX est une marque enregistrée de The Open Group aux Etats-Unis et/ou dans certains autres pays.
D'autres sociétés sont propriétaires des autres marques, noms de produits ou logos qui pourraient apparaître dans ce document.