IBM Rational Web Developer pour Windows et Linux, version 6.0 - Guide de migration


Contents

Chapter 1. Migration à partir de WebSphere Studio V5.1, 5.1.1 ou 5.1.2

  • Compatibilité avec WebSphere Studio V5.1.x
  • Désactivation de la compatibilité avec WebSphere Studio V5.1.x
  • Mise à jour de ressources d'exécution Faces dans un projet Web
  • Mise à jour de ressources d'exécution Faces client dans un projet Web
  • Migration de projets Web Struts
  • Modifications apportés au débogueur dans la version 6.0
  • Migration WDO vers SDO
  • Mots réservés dans V6.0
  • Chapter 2. Mise à jour des ressources d'exécution Faces pour les projets Web de Rational Web Developer version 6.0

    Chapter 3. Migration des projets J2EE

  • Migration des services Web sécurisés
  • Migration du niveau de spécification J2EE 1.3 vers 1.4
  • Projets Web (niveau de servlet 2.3 vers niveau de servlet 2.4)
  • Projets du connecteur (JCA 1.0 à JCA 1.5)
  • Services Web (J2EE 1.3 vers J2EE 1.4)
  • Migration du niveau de spécification J2EE 1.2 vers 1.4
  • Projets Web (niveau de servlet 2.2 vers niveau de servlet 2.4)
  • Modifications apportées à l'assistant de migration J2EE dans Rational Web Developer V6.0
  • Chapter 4. Modifications apportées aux environnements de test WebSphere



    Chapter 1. Migration à partir de WebSphere Studio V5.1, 5.1.1 ou 5.1.2

    Cette documentation comporte des instructions de migration à partir de WebSphere(R) Studio Site Developer V5.1.x vers Rational(R) Web Developer V6.0.

    Des informations supplémentaires sont disponibles dans les rubriques suivantes :

    Des informations relatives à l'utilisation de Rational Web Developer sont disponibles dans l'aide en ligne.

    Pour obtenir la documentation mise à jour, reportez-vous à la section www.ibm.com/developerworks/rational.

    Pour obtenir plus d'informations sur la migration à partir de versions antérieures de WebSphere Studio vers v5.x ou sur la migration à partir de VisualAge for Java vers WebSphere Studio, accédez au site www.ibm.com/software/awdtools/studioappdev/support/ et recherchez le guide de migration.

    Pour effectuer la migration à partir de WebSphere Studio V5.1.x :

    1. Avant l'installation, lisez les informations relatives à la compatibilité avec Eclipse V2.x et WebSphere Studio V5.1.x. Prenez en compte que la compatibilité en amont n'est pas prise en charge pour les projets d'application de portlet migrés à partir de Portal Toolkit V5.0.2.2 avec WebSphere Studio V5.1.2.
    2. Sauvegardez l'espace de travail WebSphere Studio V5.1.x.
    3. Installez Rational Web Developer. Reportez-vous au guide d'installation (fichier install.html) qui est disponible à la racine du premier CD du produit.
    4. Recommandation : Par défaut, lors du premier démarrage de Rational Web Developer, vous êtes invité à confirmer que vous voulez utiliser un espace de travail appelé rationalsdp6.0\workspace. La boîte de dialogue Programme de lancement de l'espace de travail désigne un répertoire qui n'est pas l'espace de travail WebSphere Studio. Pour explorer le nouvel environnement avant de migrer l'ancien espace de travail, acceptez la valeur par défaut ou spécifiez un nouveau nom de répertoire lors du démarrage de Rational Web Developer. Il est possible de créer un ou deux environnement de test, consulter les nouveautés (Aide -> Bienvenue), suivre les nouveaux tutoriels (Aide -> Galerie de tutoriels) ou de découvrir de nouveaux exemples (Aide -> Galerie d'exemples).
    5. Migrez les projets vers la version 6.0. Les projets créés dans WebSphere Studio V5.1.x peuvent être automatiquement migrés vers la version 6.0 de la manière suivante :
      1. Migration d'un espace de travail : Lorsque vous êtes prêt à migrer l'espace de travail V5.1.x, démarrez Rational Web Developer avec l'ancien espace de travail. Un indicateur de progression confirme que les projets sont automatiquement migrés.

        Remarques : Lors de la migration d'un espace de travail, une boîte de dialogue Incidents s'affiche. Cette boîte de dialogue comporte le message Impossible de restaurer la présentation du plan de travail. Motif : Erreurs lors de la restauration du plan de travail. Les messages d'erreur n'ont aucune influence sur la migration de l'espace de travail. Notez le nom de la perspective qui n'a pas pu être restaurée en cliquant sur le bouton Détails dans la boîte de dialogue des erreurs puis cliquez sur OK pour fermer la boîte de dialogue.

        Pour restaurer la perspective, procédez comme suit :

        1. Fermez la perspective en sélectionnant Fenêtre -> Fermer la perspective
        2. Ouvrez à nouveau la perspective en sélectionnant Fenêtre -> Ouvrir la perspective.
        Note:
        Pour les projets EGL (Enterprise Generation Language) qui utilisaient la perspective Web EGL dans WebSphere Studio V5.1.2 : cette perspective a été supprimée dans Rational Web Developer V6.0. Tous les projets EGL sont migrés sans cette perspective dans Rational Web Developer V6.0. Si vous utilisiez la perspective Web EGL, suivez la procédure ci-après.
        1. Fermez la perspective Web EGL.
        2. Activez les fonctions EGL dans la fenêtre Préférences (Fenêtre -> Préférences). Pour obtenir des détails sur l'activation des fonctions EGL, reportez-vous à l'aide en ligne.
        3. Sélectionnez Fenêtre -> Ouvrir la perspective et choisissez la perspective Web.
      2. Migration de projets chargés à partir d'un système SCM (source code management) : Les projets de WebSphere Studio 5.1.x qui existent dans un système SCM sont automatiquement migrés vers la version 6.0 lors de leur chargement dans Rational Web Developer.
      3. Migration de projets importés à l'aide de Project Interchange : Les projets exportés à partir de WebSphere Studio V5.1.2 ou V5.1.1 et importés dans Rational Web Developer V6.0 à l'aide de la fonction Project Interchange sont automatiquement migrés vers la version 6.0. La fonction Project Interchange était disponible dans WebSphere Studio V5.1.2 et était un plug-in facultatif dans la version 5.1.1.

      Remarques :

      Important :

    6. Le pilote JDBC DB2 Net n'est pas pris en charge dans Rational Web Developer V6.0. Si vous avez créé des connexions JDBC à l'aide du pilote JDBC DB2 Net, vous ne pourrez plus vous connecter à nouveau dans Rational Web Developer V6.0. Vous devez changer la connexion pour utiliser un des pilotes JDBC pris en charge. Pour obtenir plus d'informations sur les pilotes JDBC pris en charge dans la version 6.0, reportez-vous à l'aide en ligne.
    7. Si vous disposez de contenu de fichier Web ou XML migré à partir WebSphere Studio Site Developer V5.1.x qui utilisait le jeu de caractères Shift_JIS et incluait des caractères sélectionnés par le fournisseur, vous devez à la place spécifier le jeu de caractères Windows-31J.
    8. Si vous avez installé les plug-ins du fournisseur avec WebSphere Studio Site Developer V5.1.x, vous devez obtenir les plug-ins correspondants pour la version V6.0 et les installer à nouveau.
    9. Si vous utilisez des fonctions pour lesquelles Agent Controller est requis, mettez-le à niveau en installant la version fournie avec Rational Web Developer. Pour plus de détail, reportez-vous au guide d'installation.
    10. Pour effectuer la migration à partir de VisualAge Generator, reportez-vous au guide relatif à la migration de VisualAge Generator vers EGL (Enterprise Generation Language) disponible au format PDF dans la section relative à la migration et à l'installation de l'aide en ligne sous la rubrique d'aide relative à l'accès au guide de migration de VisualAge Generator vers EGL . La version la plus récente est disponible sur le site http://www.ibm.com/developerworks/rational/library/egldoc.html.

    Compatibilité avec WebSphere Studio V5.1.x

    Lorsque vous ouvrez un espace de travail WebSphere Studio V5.1.x dans Rational Web Developer, il est automatiquement migré. Une fois la migration d'un espace de travail effectuée, vous ne pouvez plus l'ouvrir dans WebSphere Studio Site Developer. Toutefois, les projets de l'espace de travail de la version 6.0 peuvent être partagés avec WebSphere Studio V5.1.x, soit en utilisant un système SCM (source code management), tel que Rational ClearCase, en important et en exportant le projet à l'aide de Project Interchange, soit en important des archives et en exportant des projets. Important : Les applications de portlet de Portal Toolkit V5.0.2.2 migrées vers Portal Tools dans Rational Web Developer V6.0 ne sont pas compatibles en amont.

    Note:
    Les affirmations suivantes ne s'appliquent pas aux projets d'application de portlet.

    Les projets V5.1.x existants chargés dans la version 6.0 à partir d'un système SCM ou d'un autre développeur à l'aide de Project Interchange sont compatibles pour le partage avec V5.1.x si vous n'effectuez pas les actions suivantes :

    Un fichier .compatibility est automatiquement créé dans le répertoire de projets lorsqu'un projet V5.1.x est ouvert dans l'espace de travail Rational Web Developer V6.0. Le fichier .compatibility est utilisé par Rational Web Developer afin d'effectuer le suivi des horodatages des ressources de projet lors de la migration de ces ressources. Vous ne devez pas le modifier ou le supprimer.

    Pour obtenir plus d'informations sur la désactivation de la compatibilité avec WebSphere Studio Site Developer V5.1.x, reportez-vous à la section Désactivation de la compatibilité avec WebSphere Studio V5.1.x.

    Remarques relatives à Eclipse

    Cette version de Rational Web Developer est fondée sur Eclipse V3.0. Si vous développez vos propres plug-ins, vous devez consulter les modifications apportées à la plateforme avant d'effectuer la migration.

    Pour obtenir plus de détails, reportez-vous au fichier readme dans le sous-répertoire eclipse\readme du répertoire d'installation de Rational Web Developer V6.0. Vous trouverez ci-dessous une liste des sections du fichier readme concernant la migration.

    Compatibilité des projets J2EE

    La compatibilité des projets créés dans WebSphere Studio V5.1.x avec Rational Web Developer V6.0 est activée en cas d'ajout de métadonnées aux fichiers .project lors de la migration de l'espace de travail V5.1.x. De la même manière, si vous créez une application ou un module J2EE 1.2 ou 1.3 dans Rational Web Developer V6.0, les métadonnées de création sont automatiquement ajoutées au fichier .project pour la compatibilité avec V5.1.x. Ne modifiez ou ne supprimez pas ces informations directement.

    Note:
    Ces métadonnées de compatibilité génèrent l'affichage ou la journalisation des messages indiquant que des compilateurs manquent lorsqu'une application ou module J2EE 1.2 et J2EE 1.3 créé dans V6.0 est utilisé dans WebSphere Studio Site Developer V5.1.x où les compilateurs V6.0 ne sont pas disponibles. Ces messages sont normaux. Vous pouvez les ignorer.

    Tant que les métadonnées de compatibilité sont présentes, des messages indiquant qu'il manque des compilateurs s'affichent lorsque des projets Rational Web Developer V6.0 sont chargés dans WebSphere Studio V5.1.x. Voici un exemple de message "Compilateur manquant" :

    !ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
    !MESSAGE Absence du compilateur com.ibm.wtp.j2ee.LibCopyBuilder pour le projet Test60EARWeb. 
    Le compilateur est manquant pour l'installation ou il appartient à une nature de projet manquante ou désactivée.
    

    Ces messages sont normaux. Vous pouvez les ignorer. Lorsque vous êtes sûr que vous n'avez plus besoin d'utiliser un projet donné de WebSphere Studio V5.1.x, vous pouvez arrêter les messages en désactivant la compatibilité en amont pour ce projet.

    Important : Les projets de spécification J2EE 1.2 ou 1.3 créés dans la version 6.0 sont compatibles avec WebSphere Studio V5.1.x mais une fois le projet chargé dans WebSphere, vous devez suivre des procédures manuelles requises avant de pouvoir utiliser le projet. Ces procédures sont requises car les cibles d'exécution sur les projets de spécification J2EE 1.2 ou 1.3 créés dans 6.0 ne sont pas directement compatibles en amont sur les serveurs cible dans les versions 5.1.x. Les procédures manuelles à effectuer après le chargement d'un projet V6.0 dans V5.1.x sont les suivantes :

    1. Ouvrez le fichier .classpath de chaque projet J2EE qui a un fichier .classpath.
    2. Supprimez les entrées de chemin d'accès aux classes suivantes du fichier .classpath puis fermez et sauvegardez le fichier.
    3. Assurez-vous que la prise en charge de ciblage du serveur est activée dans la page Préférences J2EE. Sélectionnez Fenêtre -> Préférences -> J2EE et assurez-vous que l'option Activer la prise en charge du ciblage de serveur sous "Support de ciblage de serveur".
    4. Cliquez avec le bouton droit de la souris sur le projet et sélectionnez Propriétés -> J2EE.
    5. Sélectionnez le serveur cible correspondant pour la cible d'exécution sur le projet (par exemple, WebSphere Application Server V5.1 à l'aide de l'environnement d'exécution JDK 1.4) et cliquez sur OK.
    6. Le serveur cible sélectionné est compatible avec Rational Web Developer V6.0 et WebSphere Studio Site Developer V5.1.x. Une fois les modifications validées dans le système SCM, l'interopérabilité des projets J2EE est assurée entre V5.1.x et V6.0 à l'aide d'un système SCM.
      Note:
      Si le serveur cible est défini à nouveau dans Rational Web Developer V6.0, la compatibilité des projets J2EE est perdue et ne sera plus établie.

    Désactivation de la compatibilité avec WebSphere Studio V5.1.x

    La compatibilité avec WebSphere Studio Site Developer V5.1.x peut être totalement supprimée d'un projet d'application d'entreprise crée dans Rational Web Developer V6.0 ou d'un projet d'application d'entreprise migré à partir d'une version antérieure de WebSphere Studio. Vous devez désactiver la compatibilité avec WebSphere Studio V5.1.x uniquement si vous êtes sûr que l'interopérabilité ou la compatibilité du projet d'application d'entreprise ne doit plus être assurée avec la version 5.1.x.

    Pour supprimer la compatibilité avec WebSphere Studio Site Developer V5.1.x, procédez comme suit :

    1. Cliquez à l'aide du bouton droit de la souris sur un projet d'application d'entreprise et dans le menu contextuel, sélectionnez Supprimer la compatibilité.
    2. Une boîte de dialogue s'affiche vous demandant si vous souhaitez vraiment supprimer la compatibilité en amont du projet d'application d'entreprise et de tous les modules et projets d'utilitaire imbriqués sous le projet.
    3. Cliquez sur Oui pour poursuivre l'opération de suppression de compatibilité.

    Une fois l'opération de suppression de compatibilité effectuée, le projet d'application d'entreprise et tous les modules et projets d'utilitaire imbriqués sous le projet d'application d'entreprise ne sont plus compatibles en amont avec WebSphere Studio Site Developer V5.1.x.


    Mise à jour de ressources d'exécution Faces dans un projet Web

    Les ressources d'exécution JavaServer Faces initialement disponibles dans WebSphere Studio Site Developer version 5.1.x ont été mises à jour pour Rational Web Developer version 6.0.1. Si vous souhaitez continuer le développement dans des projets Web créés avec la version précédente du produit, il est recommandé de mettre à niveau les ressources d'exécution Faces.

    Dans Rational Web Developer version 6.0.1, les mises à jour des ressources d'exécution Faces sont automatiquement appliquées lorsqu'un projet Web est importé ou qu'un espace de travail contenant des ressources antérieures est ouvert. A l'issue de l'importation d'un projet Web ou de l'ouverture d'un espace de travail de WebSphere Studio Site Developer version 5.1.x vers Rational Web Developer version 6.0.1, le système vous invite à mettre à niveau les ressources d'exécution Faces.

    Mise à jour automatique des ressources d'exécution

    Pour mettre à jour automatiquement les ressources d'exécution Faces d'un projet Web :

    1. Importez un projet Web (ou un espace de travail) stockant les données Faces de WebSphere Studio Site Developer version 5.1.x. La fenêtre Migration du projet s'affiche.
      Note:
      Si la fenêtre Migration du projet ne s'affiche pas, il est probable que les paramètres de préférences de génération automatique sont désactivés. Dans l'explorateur de projets, cliquez à l'aide du bouton droit de la souris sur un projet Web et sélectionnez Générer -> Projet. Le processus de génération d'un projet entraîne l'affichage de la fenêtre Migration du projet.
    2. Si l'espace de travail comporte d'autres projets Web stockant des données Faces, cochez la case Appliquer cette option aux autres projets à mettre à jour pour mettre à jour tous les projets Web.
    3. Cliquez sur l'une des options suivantes :
    Note:
    Si vous avez créé des pages JSP Faces qui contiennent des composants Faces Client, vous devez mettre à niveau séparément les ressources d'exécution des composants Faces Client. Reportez-vous à la section Mise à jour de ressources d'exécution Faces client dans un projet Web.

    Mise à jour manuelle des ressources d'exécution

    Pour mettre à jour manuellement les ressources d'exécution Faces d'un projet Web :

    1. Importez le projet Web stockant les données Faces dans un environnement Rational Web Developer version 6.0.1.
    2. Créez un projet Web (ou si vous utilisez EGL, créez un projet Web EGL) et appelez-le JSF601. Vous devez utiliser ce projet uniquement comme source pour les artefacts d'exécution les plus récents. Il peut être supprimé une fois que la mise à jour est terminée.
    3. Dans l'explorateur de projets, cliquez à l'aide du bouton droit de la souris sur JSF601 et sélectionnez Propriétés dans le menu.
    4. Cliquez sur Fonctions du projet Web et sélectionnez Ajout des composants de base Faces et Ajout de Faces Client Framework, puis cliquez sur OK.
    5. Si vous utilisez EGL, créez un fichier JSP de la manière suivante :
      1. Cliquez à l'aide du bouton droit de la souris sur le dossier WebContent du nouveau projet Web EGL.
      2. Sélectionnez Nouveau -> Autre -> Fichier JSP Faces.
      Les fichiers eglintdebug.jar et eglintdebugsupport.jar sont ajoutés au projet.
    6. Pour chaque projet Faces à mettre à jour, procédez comme suit :
      1. Dans l'explorateur de projets, développez un projet pour visualiser les fichiers du dossier WebContent/WEB-INF/lib/. Dans ce répertoire, recherchez et supprimez les fichiers JAR suivants :
        • eglintdebug.jar (EGL uniquement)
        • eglintdebugsupport.jar (EGL uniquement)
        • fda.jar (EGL uniquement)
        • fdaj.jar (EGL uniquement)
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • odc-jsf.jar
      2. Recherchez et ouvrez le fichier WebContent/WEB-INF/faces-config.xml. Si nécessaire, ajoutez les éléments suivants à ce fichier de configuration :
        	<lifecycle>
        		<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
        	</lifecycle>
        	
        	<application>
        		<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
        		<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
        	</application>
        
      3. Pour les fichiers JAR supprimés, copiez le fichier JAR portant le même nom dans le répertoire WebContent/WEB-INF/lib du projet JSF601 et collez-le dans le projet d'origine situé au même emplacement. Certaines configurations ne requièrent pas le stockage de tous ces fichiers JAR dans le projet. Ne copiez pas un fichier JAR spécifique s'il ne figure pas dans le projet d'origine.
      4. Ouvrez le descripteur de déploiement web.xml dans le projet d'origine et ajoutez les chaînes suivantes à la configuration :
        	<context-param>
        		<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
        		<param-value>true</param-value>
        	</context-param>
        	<context-param>
        		<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
        		<param-value>true</param-value>
        	</context-param>
        
      5. Si le projet d'origine utilisait des objets WDO (WebSphere Data Object) pour l'accès aux données, suivez la procédure ci-après.
        1. Dans le projet d'origine, cliquez sur Fichier -> Nouveau -> Fichier JSP Faces pour créer un fichier JSP Faces temporaire.
        2. Déplacez un composant de liste d'enregistrements relationnels à partir du tiroir de données sur la palette de la page.
        3. Sélectionnez une connexion et une source de données et cliquez sur Terminer. Les données sélectionnées ne sont pas importantes. Cette procédure génère les configurations nécessaires pour continuer à utiliser les objets WDO dans ce projet.
        4. Supprimez le fichier JSP temporaire.
      6. Si vous utilisez EGL, cliquez avec le bouton droit de la souris sur le nom de chaque projet Web EGL et cliquez sur Générer. Puis, si vous ne créez pas de projets automatiquement, cliquez sur Projet -> Construire tout.
    7. Supprimez le projet JSF601.

    Mise à jour de ressources d'exécution Faces client dans un projet Web

    Les ressources d'exécution JavaServer Faces Client initialement disponibles dans WebSphere Studio Site Developer version 5.1.x ont été mises à jour pour Rational Web Developer version 6.0.1. Si vous souhaitez continuer le développement dans des projets Web créés avec la version précédente du produit, il est recommandé de mettre à niveau les ressources d'exécution Faces Client.

    Dans Rational Web Developer version 6.0.1, les mises à jour des ressources d'exécution Faces Client sont automatiquement appliquées lorsqu'un projet Web est importé ou qu'un espace de travail contenant des ressources antérieures est ouvert. A l'issue de l'importation d'un projet Web ou de l'ouverture d'un espace de travail de WebSphere Studio Site Developer version 5.1.x vers Rational Web Developer version 6.0.1, le système vous invite à mettre à niveau les ressources d'exécution Faces Client.

    Mise à jour automatique des ressources d'exécution

    Pour mettre à jour automatiquement les ressources d'exécution Faces Client d'un projet Web :

    1. Importez un projet Web (ou un espace de travail) stockant les données Faces Client de WebSphere Studio Site Developer V5.1.x. La fenêtre Migration du projet s'affiche.
      Note:
      Si la fenêtre Migration du projet ne s'affiche pas, il est probable que les paramètres de préférences de génération automatique sont désactivés. Dans l'explorateur de projets, cliquez à l'aide du bouton droit de la souris sur un projet Web et sélectionnez Générer -> Projet. Le processus de génération d'un projet entraîne l'affichage de la fenêtre Migration du projet.
    2. Si l'espace de travail comporte d'autres projets Web stockant des données Faces Client, cochez la case Appliquer cette option aux autres projets à mettre à jour pour mettre à jour tous les projets Web.
    3. Cliquez sur l'une des options suivantes :
    4. Dans le dossier Ressources Java -> JavaSource du projet Web, supprimez tous les packages de classe des médiateurs de données client en utilisant la convention de dénomination com.ibm.dynwdo4jsmediators.<nom_données_client>. Ne supprimez PAS le package com.ibm.dynwdo4jsmediators. Ce package contient des métadonnées (fichiers ecore et emap) pour les données client du projet qui seront utilisées pour la regénération des médiateurs.
    5. Dans le dossier Ressources Java -> JavaSource du projet Web, ouvrez le fichier OdysseyBrowserFramework.properties et supprimez les entrées de EMAP_FILES et ECORE_FILES.
    6. Pour chaque objet de données dans la vue Client Data :
      1. A l'aide du bouton droit de la souris, cliquez sur Configure.
      2. Dans l'onglet Avancé, cliquez sur Actualiser à partir des données côté serveur pour actualiser tous les médiateurs des objets de données.

    Mise à jour manuelle des ressources d'exécution

    Pour mettre à jour manuellement les ressources d'exécution Faces Client d'un projet Web :

    1. Effectuez les opérations de mise à jour manuelle des ressources d'exécution indiquées dans Mise à jour de ressources d'exécution Faces dans un projet Web.
    2. Effectuez les opérations 4-6 de la section Mise à jour automatique des ressources de mise à jour ci-dessus.

    Des incidents peut se produire lors de la mise à jour du serveur cible d'un projet contenant des composants Faces Client de WebSphere Application Server 5.1 vers la version 6.0.

    Deux incidents peuvent se produire lors de la modification du serveur cible d'un projet contenant des composants Faces Client de WebSphere Application Server version 5.1 en version 6.0 :

    Mise à niveau vers les processeurs et les gestionnaires Diff :

    Les gestionnaires et processeurs Diff sont désormais automatiquement générés. Si vous concevez des processeurs et des gestionnaires Diff pour les composants Faces Client dans WebSphere Studio version 5.1.x, il est recommandé d'ignorer ce code et d'utiliser les processeurs et les gestionnaires automatiquement générés :

    1. Générez les nouveaux gestionnaires Diff et les processeurs sur chaque objet de données client dans votre projet Web.
      1. Cliquez à l'aide du bouton droit de la souris sur l'objet de données client et sélectionnez Configurer.
      2. Dans l'onglet Avancé, cliquez sur Régénérer tout.
    2. Supprimez le code que vous avez généré pour appeler les processeurs et les gestionnaires Diff, les processeurs et les gestionnaires générés étant appelés automatiquement. Un exemple classique de l'emplacement d'utilisation de ce code concerne l'événement Commande du composant de bouton de commande :
      String Diff = getClientData1().getDiffStr();
      if (DiffProcessor.Synch(getRoot(), Diff) == true)
       return "";
      return "failure";
      
    3. Supprimez les fichiers correspondant aux anciens processeurs et gestionnaires personnalisés que vous avez créés.

    Conservation des processeurs et des gestionnaires Diff personnalisés conçus pour la version 5.1.x :

    Cette action n'est pas recommandée mais si vous décidez de conserver les processeurs et les gestionnaires Diff personnalisés de la version 5.1.x, il est nécessaire de les modifier afin qu'ils fonctionnent dans la version 6.0 étant donné que l'interface DiffHandler et la classe DiffInfo ont été modifiées.

    Modifications apportées aux composants Faces Client dans la version 6.0 :


    Migration de projets Web Struts

    Pour les projets Web Struts crées dans WebSphere Studio version 5.1.x, vous devez apporter une modification mineure au descripteur de déploiement du projet Web pour exécuter le projet EAR dans WebSphere Application Server version 6.0. Vous pouvez également convertir manuellement des projets Struts 1.0.2 ou Struts 1.1 bêta (2 ou 3) en projets Web Struts 1.1.

    Modification du descripteur de déploiement des projets Web Struts existants

    Lorsqu'un projet Struts est créé dans WebSphere Studio version 5.x, le paramètre de configuration (<param-name>config</param-name>) défini dans le descripteur de déploiement du projet Web correspond à WEB-INF/struts-config.xml. WebSphere Application Server version 6.0 requiert que le caractère "/" soit placé devant ce paramètre. Si vous exécutez un projet Web Struts créé dans WebSphere Studio version 5.1.x sur un système WebSphere Application Server version 6.0, une exception java.net.MalformedURLException peut se produire lors du lancement du projet EAR.

    Note:
    Rational Web Developer version 6.0 ajoute le caractère "/" lorsque vous créez un projet Struts. Toutefois, vous devez l'ajouter manuellement lorsque vous effectuez une migration à partir de WebSphere Studio version 5.1x.

    Pour corriger dans la version 6.0 le descripteur de déploiement d'un projet Web Struts Web créé dans WebSphere Studio v5.1.x, procédez comme suit :

    1. Ouvrez le projet Web Struts dans l'explorateur de projets.
    2. Cliquez deux fois sur le fichier Descripteur de déploiement dans l'explorateur de projets. L'éditeur de descripteur de déploiement Web s'affiche.
    3. Cliquez sur l'onglet Source pour ouvrir la page Source.
    4. Remplacez la ligne

      <param-value>WEB-INF/struts-config.xml</param-value> (située dans les balises <servlet></servlet>)

      par

      <param-value>/WEB-INF/struts-config.xml</param-value>.

    5. Sauvegardez le descripteur de déploiement Web.

    L'exception java.net.MalformedURLException ne doit pas se produire lorsque vous relancez le projet EAR.

    Conversion des projets Web Struts 1.1 bêta en projets Web Struts 1.1

    Dans WebSphere Studio 5.1.x, la bibliothèque d'exécution Struts passe de Struts 1.1 bêta (2 ou 3) dans 5.0.x à Struts 1.1 (final). Si vous possédez des projets Web Struts 1.1 bêta (2 ou 3) et que vous souhaitez les convertir pour Struts 1.1 (final), vous pouvez les convertir manuellement. (Remarque : Il est pas obligatoire de convertir les projets Struts 1.1 bêta (2 ou 3) en projets Struts 1.1.)

    Pour convertir des projets Struts 1.1 bêta (2 ou 3) en projets Struts 1.1, procédez comme suit :

    1. Chargez les projets Struts 1.1 bêta dans l'espace de travail Rational Web Developer version 6.0.
    2. Créez un projet Web Struts 1.1 appelé Struts11, par exemple. Vous créez ce projet temporaire pour accéder facilement aux fichiers d'exécution Struts 1.1 dont vous avez besoin pour convertir les projets réels. Vous pourrez supprimer ce projet lorsque vous aurez terminé.
    3. Effectuez les opérations ci-dessous pour chaque projet Struts 1.1 bêta que vous souhaitez convertir pour Struts 1.1 :

      1. Supprimez les fichiers .JAR suivants du répertoire Web Content/WEB-INF/lib du projet :
        • commons-*.jar.
        • struts.jar.
      2. Copiez les fichiers JAR suivants du répertoire Struts11/WebContent/WEB-INF/lib dans le répertoire Web Content/WEB-INF/lib du projet :
        • commons-*.jar.
        • struts.jar.
      3. Supprimez les fichiers TLD (Tag Library Descriptor) suivants stockés dans le répertoire Web Content/WEB-INF du projet : struts-*.tld.
      4. Copiez les fichiers suivants du répertoire Struts11/WebContent/WEB-INF dans le répertoire du projet Web Content/WEB-INF : struts-*.tld.

    Conversion des projets Web Struts 1.0.2 vers des projets Struts 1.1

    Lorsque vous ajoutez le support Struts à un projet Web dans WebSphere Studio 5.1.x (et 5.0.x), vous avez la possibilité de sélectionner Struts 1.0.2. Si vous possédez des projets Web Struts 1.0.2 existants et que vous souhaitez les convertir pour Struts 1.1, vous pouvez les convertir manuellement. (Remarque : Il est pas obligatoire de convertir les projets Struts 1.1 bêta (2 ou 3) en Struts 1.1.)

    Pour convertir des projets Struts 1.0.2 en projets Struts 1.1, procédez comme suit :

    1. Chargez les projets Struts 1.0.2 dans un environnement Rational Web Developer version 6.0.
    2. Créez un projet Web Struts 1.1 appelé Struts11, par exemple. Vous créez ce projet temporaire pour accéder facilement aux fichiers d'exécution Struts 1.1 dont vous avez besoin pour convertir les projets réels. Vous pourrez supprimer ce projet lorsque vous aurez terminé.
    3. Effectuez les opérations ci-dessous pour chaque projet Struts 1.0.2 à convertir vers Struts 1.1
      1. Supprimez les fichiers .JAR struts stockés dans le répertoire Web Content/WEB-INF/lib du projet.
      2. Copiez les fichiers JAR suivants du répertoire Struts11/WebContent/WEB-INF/lib dans le répertoire Web Content/WEB-INF/lib :
        • commons-*.jar.
        • struts.jar.
        • jarkarta-oro.jar.
      3. Supprimez les fichiers TLD (Tag Library Descriptor) suivants du répertoire Web Content/WEB-INF du projet : struts-*.tld.
      4. Copiez les fichiers suivants du répertoire Struts11/WebContent/WEB-INF dans le répertoire du projet Web Content/WEB-INF : struts-*.tld.

    Modifications apportés au débogueur dans la version 6.0

    Plusieurs modifications ont été apportées aux outils de débogage dans Rational Web Developer V6.0. Vous devez les prendre en compte afin de pouvoir utiliser ces outils avec les projets après la migration. Il peut être nécessaire de changer ou de restaurer les paramètres.

    Migration des espaces de travail et des configurations de lancement

    Lorsqu'un espace de travail V5.1.x de WebSphere Studio Site Developer est ouvert dans Rational Web Developer V6.0, les configurations de lancement du débogueur suivantes associées à l'espace de travail ne seront pas automatiquement migrées :

    Vues de débogage

    Les vues Stockage et Mappage de stockage n'existent plus. Elles ont été remplacées par les vues Mémoire et Affichage de la mémoire.

    Débogueur XSLT

    Le débogueur XSLT a changé dans la version 6.0 et un grand nombre de ses vues et de ses actions ont été changées de manière significative. Pour obtenir plus d'informations, reportez-vous à la documentation relative au débogueur XSLT dans le centre de documentation.

    La dépendance de l'environnement JRE installé avec Rational Web Developer V6.0 constitue une des modifications significatives apportées au débogueur XSLT. Si vous migrez un espace de travail à partir de WebSphere Studio Site Developer V5.1.x, vous devez modifier l'environnement JRE afin qu'il désigne l'emplacement correct avant de pouvoir lancer une session de débogage XSLT. Pour cela, vous pouvez effectuer les actions suivantes :


    Migration WDO vers SDO

    Si vous avez créé du code dans un projet Web ciblé vers WebSphere Application Server V5.1 qui utilisait des enregistrements relationnels ou des listes d'enregistrements relationnels WDO (WebSphere Data Objects), lorsque vous ciblez ces applications vers WebSphere Application Server V6.0, vous utilisez des listes d'enregistrements relationnels et des enregistrements relationnels SDO (Service Data Objects). La migration de WDO vers SDO se produit automatiquement lorsque vous changez le serveur cible de l'application, WebSphere Application Server V5.1 en WebSphere Application Server V6.0.

    Il existe deux méthodes permettant de changer le serveur cible :

    Des rubriques d'aide relatives à la modification du serveur cible et à l'utilisation de l'assistant de migration J2EE sont disponibles dans l'aide en ligne de Rational Web Developer.

    Remarques relatives à la compatibilité

    Des erreurs liées à des conflits de type peuvent se produire suite à la migration de WDO vers SDO

    Une fois qu'un projet utilisant WDO est migré vers un projet de type SDO, si vous ajoutez des données SDO à une page JSP existante qui comporte des données WDO, des erreurs de collision de type peuvent se produire. Cette situation est due au fait qu'il existe à la fois des beans d'accès WDO et des API SDO autonomes. Par exemple, vous pouvez voir une erreur de compilation sur le fichier source Java du fichier JSP du type suivant :

    The import com.ibm.websphere.sdo.mediator.exception.MediatorException collides with another imported type
    

    Ces erreurs de collision de type peuvent être corrigées de la manière suivante :

    1. Supprimez l'instruction d'importation incompatible du fichier source Java. A l'aide de l'exemple ci-dessus, vous devez supprimer l'instruction d'importation du fichier source :
      import com.ibm.websphere.wdo.mediator.exception.MediatorException;
      
    2. Modifiez le fichier source Java qui fait référence à ce type pour utiliser le nom de classe complet. En fonction de l'exemple ci-dessus, le type MediatorException doit être modifié en com.ibm.websphere.wdo.mediator.exception.MediatorException. Par exemple, le code source écrit sous la forme
      catch ( MediatorException e1 ) {
      

      doit être modifié en

      catch ( com.ibm.websphere.wdo.mediator.exception.MediatorException e1 ) {
      

    Les modifications apportées à un projet Web après la modification du serveur cible de la version V5.1 en V6.0 (WDO vers SDO)

    Les modifications suivantes sont effectuées automatiquement lorsque le serveur cible est changé, il passe du niveau de la version 5.1 à la version 6.0 :

    Les modifications apportées à un projet Web après la modification du serveur cible de la version 6.0 en V5.1 (SDO vers WDO)

    Les modifications suivantes sont effectuées automatiquement lorsque le serveur cible passe de V6.0 à V5.1 :

    Modifications apportées à un projet Web après la modification du niveau J2EE de l'application de la version 1.3 à la version 1.4

    Outre les modifications effectuées pour la migration de WDO vers SDO en modifiant la cible de serveur en WebSphere Application Server V6.0, la modification du niveau de spécification J2EE de l'application de la version 1.3 vers 1.4 met à jour les références taglib (bibliothèque de balises) dans les pages JSP. Ainsi les bibliothèques de balises JSTL 1.0 WDO sont modifiées en bibliothèques de balises JSTL 1.1/jsp 2.0 SDO. Le tableau suivant affiche les modifications effectuées dans les références taglib JSP lorsque vous passez de J2EE 1.3 à J2EE 1.4.


    Table 1. Références taglib JSP dans J2EE 1.3 et J2EE 1.4.

    Elément J2EE 1.3 (WDO) Elément J2EE 1.4 (SDO)
    http://www.ibm.com/websphere/wdo/core http://www.ibm.com/websphere/sdo/core
    http://java.sun.com/jstl/core http://java.sun.com/jsp/jstl/core
    http://java.sun.com/jstl/fmt http://java.sun.com/jsp/jstl/fmt
    http://java.sun.com/jstl/xml http://java.sun.com/jsp/jstl/xml
    http://java.sun.com/jstl/sql http://java.sun.com/jsp/jstl/sql

    Mots réservés dans V6.0

    Il existe de nouveaux mots réservés dans EGL (Enterprise Generation Language) dans Rational Web Developer.

    Les nouveaux mots réservés sont répertoriés ci-dessous.

    Les programmes EGL de WebSphere Studio V5.1.x qui sont importés et créés dans un espace de travail V6.0 qui utilise ces mots comme variables ou noms de partie seront balisés avec le message suivant :IWN.SYN.2002.e 39/2 Syntax error on input "variableName". Vous pouvez corriger le problème en renommant la variable.


    Chapter 2. Mise à jour des ressources d'exécution Faces pour les projets Web de Rational Web Developer version 6.0

    Les ressources d'exécution JavaServer Faces et Faces Client initialement disponibles dans Rational Web Developer version 6.0 ont été mises à jour pour Rational Web Developer version 6.0.1. Si vous souhaitez continuer le développement dans des projets Web créés avec la version précédente du produit, il est recommandé de mettre à niveau les ressources d'exécution Faces et Faces Client.

    Dans Rational Web Developer version 6.0.1, les mises à jour des ressources d'exécution Faces Client sont automatiquement appliquées lorsqu'un projet Web est importé ou qu'un espace de travail contenant des ressources Faces ou Faces Client antérieures est ouvert. A l'issue de l'importation d'un projet Web ou de l'ouverture d'un espace de travail de Rational Web Developer version 6.0 vers Rational Web Developer version 6.0.1, le système vous invite à mettre à niveau les ressources d'exécution.

    Mise à jour automatique des ressources d'exécution

    Pour mettre à jour automatiquement les ressources d'exécution Faces et Faces Client d'un projet Web :

    1. Importez un projet Web (ou un espace de travail) stockant les données Faces ou Faces Client de Rational Web Developer version 6.0. La fenêtre Migration du projet s'affiche.
      Note:
      Si la fenêtre Migration du projet ne s'affiche pas, il est probable que les paramètres de préférences de génération automatique sont désactivés. Dans l'explorateur de projets, cliquez à l'aide du bouton droit de la souris sur un projet Web et sélectionnez Générer -> Projet. Le processus de génération d'un projet entraîne l'affichage de la fenêtre Migration du projet.
    2. Si l'espace de travail comporte d'autres projets Web stockant des données Faces ou Faces Client, cochez la case Appliquer cette option aux autres projets à mettre à jour pour mettre à jour tous les projets Web.
    3. Cliquez sur l'une des options suivantes :

    Mise à jour manuelle des ressources d'exécution

    Pour mettre à jour manuellement les ressources d'exécution Faces et Faces Client d'un projet Web :

    1. Créez un projet Web (ou si vous utilisez EGL, créez un projet Web EGL) et appelez-le JSF601. Vous devez utiliser ce projet uniquement comme source pour les artefacts d'exécution les plus récents. Il peut être supprimé une fois que la mise à jour est terminée.
    2. Dans l'explorateur de projets, cliquez à l'aide du bouton droit de la souris sur JSF601 et sélectionnez Propriétés dans le menu.
    3. Cliquez sur Fonctions du projet Web et sélectionnez Ajout des composants de base Faces et Ajout de Faces Client Framework, puis cliquez sur OK.
    4. Si vous utilisez EGL, créez un fichier JSP de la manière suivante :
      1. Cliquez à l'aide du bouton droit de la souris sur WebContent du nouveau projet Web EGL.
      2. Sélectionnez Nouveau -> Autre -> Fichier JSP Faces.
      Les fichiers eglintdebug.jar et eglintdebugsupport.jar sont ajoutés au projet.
    5. Pour chaque projet Faces à mettre à niveau, procédez comme suit :
      1. Dans l'explorateur de projets, développez un projet pour visualiser les fichiers du dossier WebContent/WEB-INF/lib/. Dans ce répertoire, localisez et supprimez les fichiers JAR suivants :
        • eglintdebug.jar (EGL uniquement)
        • eglintdebugsupport.jar (EGL uniquement)
        • fda6.jar (EGL only)
        • fdaj6.jar (EGL only)
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • odc-jsf.jar
      2. Pour les fichiers JAR supprimés, copiez le fichier JAR portant le même nom dans le répertoire WebContent/WEB-INF/lib du projet JSF601 et collez-le dans le projet d'origine situé au même emplacement. Certaines configurations ne requièrent pas le stockage de tous ces fichiers JAR dans le projet. Ne copiez pas un fichier JAR spécifique s'il ne figure pas dans le projet d'origine.
      3. Si vous utilisez EGL, cliquez avec le bouton droit de la souris sur le nom de chaque projet Web EGL et cliquez sur Générer. Si vous ne créez pas de projets automatiquement, cliquez ensuite sur Projet -> Construire tout.
    6. Supprimez le projet JSF601.

    Chapter 3. Migration des projets J2EE

    L'assistant de migration J2EE a été mis à jour dans Rational Web Developer V6.0 afin de migrer les projets J2EE vers le niveau de spécification J2EE 1.4. L'assistant de migration J2EE prend en charge la migration à partir des niveaux de spécification J2EE 1.2 et 1.3 vers le niveau de spécification J2EE 1.4 pour tous les types de module J2EE.

    Pour obtenir plus de détails sur la migration des artefacts de niveau de spécification J2EE 1.3 et 1.2 vers le niveau de spécification J2EE 1.4, reportez-vous aux sections Migration du niveau de spécification J2EE 1.3 vers 1.4 et Migration du niveau de spécification J2EE 1.2 vers 1.4.

    Note:
    Avant d'utiliser l'assistant de migration J2EE, il est fortement recommandé de suivre la procédure ci-après.

    Il est possible d'accéder à l'assistant de migration J2EE de la manière suivante :

    1. Dans la vue Hiérarchie J2EE de la perspective J2EE, cliquez avec le bouton droit de la souris sur le projet d'application d'entreprise à migrer.
    2. Dans le menu contextuel, sélectionnez Migrer -> Assistant de migration J2EE.
    3. Suivez les instructions qui s'affichent sur la page de bienvenue de l'assistant de migration J2EE avant de poursuivre le processus de migration.

    Remarque :

    Pour obtenir des informations détaillées sur l'utilisation de l'assistant de migration Java, reportez-vous à l'aide en ligne. Les modifications apportées à l'assistant sont décrites à la section Modifications apportées à l'assistant de migration J2EE dans Rational Web Developer V6.0.

    Pour obtenir des détails sur les modifications apportées aux artefacts de niveau de spécification J2EE 1.3 et 1.2 lors de leurs migration vers J2EE 1.4, reportez-vous aux sections Migration du niveau de spécification J2EE 1.3 vers 1.4 et Migration du niveau de spécification J2EE 1.2 vers 1.4.


    Migration des services Web sécurisés

    Les services Web sécurisés ne sont pas migrés par l'assistant de migration J2EE lorsque les services Web sont migrés de J2EE 1.3 vers J2EE 1.4. Une intervention manuelle est requise pour la migration des services Web sécurisés.

    Après la migration J2EE, les fichiers d'extension et de liaison sécurisés doivent être migrés manuellement vers J2EE 1.4 de la manière suivante :

    1. Cliquez deux fois sur le fichier webservices.xml pour ouvrir l'éditeur de services Web.
    2. Sélectionnez l'onglet Configurations de liaison pour modifier le fichier de liaison.
    3. Ajoutez toutes les configurations de liaison nécessaires sous les nouvelles sections Détails de configuration de liaison du destinataire de la demande et Détails de la configuration de liaison du générateur de réponse.
    4. Sélectionnez l'onglet Extension pour modifier le fichier d'extension.
    5. Ajoutez toutes les configurations d'extension nécessaires sous les nouvelles sections Détails de configuration d'extension du destinataire de la demande et Détails de la configuration d'extension du générateur de réponse.
    6. Sauvegardez et quittez l'éditeur.

    Migration du niveau de spécification J2EE 1.3 vers 1.4

    Il est possible de migrer les projets J2EE à partir du niveau de spécification J2EE 1.3 vers J2EE 1.4. Cette section décrit, pour chaque type de projet J2EE, les artefacts migrés à partir de J2EE 1.3 vers J2EE 1.4 par l'assistant de migration J2EE.

    Projets Web (niveau de servlet 2.3 vers niveau de servlet 2.4)

    Les artefacts d'un descripteur de déploiement Web sont migrés par l'assistant de migration J2EE lorsqu'un projet Web de niveau J2EE 1.3 est migré vers J2EE 1.4.

    Les artefacts d'application Web suivants sont migrés :

    Contraintes d'authentification

    J2EE 1.4 inclut un objet de description qui a deux attributs : language et value. Cet objet Description n'existait pas dans J2EE 1.3. La description était un attribut de la contrainte d'authentification. Ainsi, lorsque les artefacts d'un descripteur de déploiement Web sont migrés vers J2EE 1.4, la valeur de l'objet Description est extrait de l'attribut de description de la contrainte d'authentification.

    Contraintes de sécurité

    De la même manière, dans J2EE 1.3 la description était un attribut de la contrainte de sécurité. Dans J2EE 1.4, il existe un nouvel objet Description avec les attributs language et value. Ainsi, la valeur de l'objet Description est extrait de l'attribut de description de la contrainte de sécurité.

    Application Web

    L'attribut de la chaîne de descriptions de l'objet ContextParam du niveau de spécification J2EE 1.3 a été déplacé vers un objet Description de ParamValue dans J2EE 1.4.

    L'objet TagLib de J2EE 1.3 a été déplacé vers l'objet JSPConfig dans J2EE 1.4. Les objets JSPConfig appartenaient à l'objet racine Web dans in 1.3.

    Projets du connecteur (JCA 1.0 à JCA 1.5)

    L'assistant de migration J2EE migre les artefacts d'un descripteur JCA (J2EE Connector Architecture) 1.0 vers JCA 1.5. Les artefacts migrés sont liés aux éléments de l'objet ResourceAdaptor car deux nouveaux objets, OutboundResourceAdaptor et ConnectionDefinition, ont été ajoutés à l'objet ResourceAdaptor dans les niveaux de spécification J2EE 1.4 pour les projets de connecteur.

    Le mappage des éléments migrés est décrit ci-dessous.

    Services Web (J2EE 1.3 vers J2EE 1.4)

    Via la nouvelle API JAX-RPC 1.0, la spécification J2EE 1.4 comporte une prise en charge pour les services Web.

    L'API JAX-RPC API prend en charge les noeuds finaux de service à l'aide des :

    La spécification J2EE 1.4 prend en charge les services Web pour la spécification J2EE (JSR 109). JSR 109 définit la configuration de déploiement requise pour les services Web et utilise le modèle de programmation JAX-RPC.

    Les arterfacts des services Web suivants sont migrés à l'aide de l'assistant de migration J2EE :

    Migration des descripteurs de déploiement des services Web

    Tout descripteur de déploiement de services Web se trouvant dans les projets J2EE 1.3 migrés vers le niveau de spécification J2EE 1.4 sera migré à partir de JSR-109 V1.0 (pour J2EE 1.3) vers J2EE 1.4.

    Les descripteurs de déploiement de services Web, tels qu'ils sont définis par JSR-109 V1.0, sont composés des fichiers webservices.xml, webservicesclient.xml et de tous les descripteurs de déploiement de mappage référencés par les fichiers webservices.xml et webservicesclient.xml. De la même façon qu'avec les autres descripteurs de déploiement J2EE, la migration modifie la structure des informations se trouvant dans les descripteurs afin qu'elles soient compatibles avec la spécification J2EE 1.4. La modification apportée au mode de représentation des noms qualifiés est une modification structurelle propre aux descripteurs de déploiement de service Web. Dans JSR-109 V1.0, les noms qualifiés sont représentés à l'aide d'une séquence de deux éléments, <namespaceURI> et <localpart>, qui contient l'URI espace de nom et la partie locale du nom, respectivement. Les noms qualifiés dans J2EE 1.4 dépendent du type XMLSchema QName qui utilise des espaces de nom.

    Des informations supplémentaires sur la migration de chaque descripteur de déploiement Web sont disponibles ci-dessous.


    Migration du niveau de spécification J2EE 1.2 vers 1.4

    Les modules J2EE peuvent être migrés à partir du niveau de spécification J2EE 1.2 vers J2EE 1.4. Cette section décrit les artefacts migrés pour les projets J2EE à partir du niveau de spécification J2EE 1.2 vers J2EE 1.4 par l'assistant de migration J2EE.

    Pour obtenir plus de détails sur l'utilisation de l'assistant de migration J2EE, reportez-vous à la section Chapter 3, Migration des projets J2EE.

    Projets Web (niveau de servlet 2.2 vers niveau de servlet 2.4)

    Les artefacts d'un descripteur de déploiement Web sont migrés par l'assistant de migration J2EE lorsqu'un projet Web J2EE 1.2 est migré vers le niveau de spécification J2EE 1.4.

    Les artefacts d'application Web suivants sont migrés :

    Contraintes d'authentification

    J2EE 1.4 inclut un objet de description qui a deux attributs : language et value. Cet objet Description n'existait pas dans J2EE 1.2. La description était un attribut de la contrainte d'authentification. Ainsi, lorsque les artefacts d'un descripteur de déploiement Web sont migrés vers J2EE 1.4, la valeur de l'objet Description est extrait de l'attribut de description de la contrainte d'authentification.

    Contraintes de sécurité

    De la même manière, dans J2EE 1.2 la description était un attribut de la contrainte de sécurité. Dans J2EE 1.4, il existe un nouvel objet Description avec les attributs language et value. Ainsi, la valeur de l'objet Description est extrait de l'attribut de description de la contrainte de sécurité.

    Application Web

    L'attribut de la chaîne de descriptions de l'objet ContextParam du niveau de spécification J2EE 1.2 a été déplacé vers un objet Description de ParamValue dans J2EE 1.4.

    L'objet TagLib de J2EE 1.2 a été déplacé vers l'objet JSPConfig dans J2EE 1.4. Les objets JSPConfig appartenaient à l'objet racine Web dans 1.2.


    Modifications apportées à l'assistant de migration J2EE dans Rational Web Developer V6.0

    Les modifications apportées à l'assistant de migration J2EE dans Rational Web Developer V6.0 s'appliquent à la migration de tous les niveaux de spécification J2EE.

    La migration de la structure des projets est facultative

    Dans WebSphere Studio version 5.1.x à V5.1.2, la migration de la structure de projets se produit en même temps que la migration du niveau de spécification J2EE. La migration de la structure de projets n'est pas facultative lors de la migration des niveaux de spécification J2EE.

    Dans l'assistant de migration J2EE de Rational Web Developer V6.0, l'option de migration de la structure de projets de la section Migrez le niveau de spécification J2EE du projet est une option séparée et facultative. La migration du niveau de spécification J2EE et celle de la structure du projet peuvent être effectuées indépendamment.

    Serveur cible requis

    Dans Rational Web Developer V6.0, les projets J2EE migrés vers un niveau de spécification J2EE supérieur nécessitent qu'un serveur cible soit défini sur le projet. Le ciblage de serveur est le mécanisme par défaut du mode de définition du chemin d'accès aux classes sur un projet J2EE dans V6.0. Pour obtenir plus d'informations sur la définition d'un serveur cible et l'utilisation d'un assistant de migration J2EE, reportez-vous à l'aide en ligne.


    Chapter 4. Modifications apportées aux environnements de test WebSphere

    Dans Rational Web Developer V6.0, les environnements de test WebSphere Application Server inclus dans le produit sont différents de ceux inclus dans les versions précédentes de WebSphere Studio Site Developer.

    Vous trouverez ci-dessous un récapitulatif des modifications apportées aux environnements de test WebSphere Application Server dans Rational Web Developer V6.0 :

    Le tableau suivant affiche les niveaux d'environnement de test WebSphere Application Server inclus avec les différentes versions de WebSphere Studio Site Developer et Rational Web Developer.

    Table 2. Environnements de test WebSphere Application Server dans WebSphere Studio Site Developer et Rational Web Developer


    WebSphere Application Server V4.x AEs Version de base WebSphere Application Server V5.x WebSphere Application Server Express V5.x WebSphere Application Server V6.0
    WebSphere Studio Site Developer V5.1 V4.0.6 V5.0.2 V5.0.2 N/A
    WebSphere Studio Site Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1 V5.0.2 & V5.1 N/A
    WebSphere Studio Site Developer V5.1.2 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1.0.3 V5.0.2 & V5.1.0.3 N/A
    Rational Web Developer V6.0 N/A V5.0.x, V5.1.1 V5.0.2 & V5.1.1 V6.0

    Copyright et remarques