IBM Rational Application 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 Application Developer version 6.0

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

    Chapter 4. Migration des projets J2EE

  • Migration des services Web sécurisés
  • Migration du niveau de spécification J2EE 1.3 vers 1.4
  • Projets EJB (EJB 2.0 à EJB 2.1)
  • 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
  • Migration de projets EJB (EJB 1.1 vers EJB 2.1)
  • Projets Web (niveau de servlet 2.2 vers niveau de servlet 2.4)
  • Modifications apportées à l'assistant de migration J2EE dans Rational Application Developer V6.0
  • Chapter 5. Migration vers les outils de portail dans Rational Application Developer V6.0

  • Migration des portlets WebSphere Portal V4.2 vers V5.x
  • Mise à jour de ressources d'exécution Faces dans un projet de portlet
  • Chapter 6. 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 Application Developer V5.1.x vers Rational(R) Application Developer V6.0.

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

    Des informations relatives à l'utilisation de Rational Application 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 Application 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 Application 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 Application 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 Application 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 Application Developer V6.0. Tous les projets EGL sont migrés sans cette perspective dans Rational Application 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 Application 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 Application 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 Application 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 Application 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 Application 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 Application Developer V5.1.x, vous devez obtenir les plug-ins correspondants pour la version V6.0 et les installer à nouveau.
    9. Si vous avez installé des environnements de test d'unité WebSphere V5.x de niveau antérieur lors de l'installation de Rational Application Developer et si vous utilisez le service de messagerie intégré, installez ce dernier en installant la version fournie avec Rational Application Developer. Pour obtenir des informations sur l'installation du service de messagerie intégré, reportez-vous au guide d'installation.
    10. Si vous utilisez des fonctions pour lesquelles Agent Controller est requis, mettez-le à niveau en installant la version fournie avec Rational Application Developer. Pour plus de détail, reportez-vous au guide d'installation.
    11. 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 Application 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 Application 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 Application 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 Application Developer V6.0. Le fichier .compatibility est utilisé par Rational Application 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 Application 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 Application 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 Application 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 Application 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 Application 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 Application 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 Application 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 Application Developer V6.0 et WebSphere Studio Application 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 Application Developer V6.0, la compatibilité des projets J2EE est perdue et ne sera plus établie.

    Compatibilité du diagramme UML

    Les diagrammes UML qui existaient dans WebSphere Studio Application Developer V5.1.x sont compatibles en amont et peuvent être ouverts en mode lecture seule dans Rational Application Developer V6.0. Dans la version V6.0, l'assistant de migration J2EE migre automatiquement les diagrammes UML créés dans les projets J2EE V5.1.x lors de la migration de la structure de projets J2EE. Une fois migrés, les diagrammes UML peuvent être modifiés dans Rational Application Developer V6.0.

    Note:
    Les diagrammes UML d'un espace de travail migrés vers Rational Application Developer V6.0 ou créés dans ce dernier ne peuvent pas être ouverts dans WebSphere Studio Application Developer V5.1.x.

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

    La compatibilité avec WebSphere Studio Application Developer V5.1.x peut être totalement supprimée d'un projet d'application d'entreprise crée dans Rational Application 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 Application 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 Application 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 Application Developer version 5.1.x ont été mises à jour pour Rational Application 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 Application 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 Application Developer version 5.1.x vers Rational Application 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 Application 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 Application 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 Application Developer version 5.1.x ont été mises à jour pour Rational Application 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 Application 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 Application Developer version 5.1.x vers Rational Application 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 Application 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 Application 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 Application 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 Application 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 Application 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 Application Developer est ouvert dans Rational Application 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 Application 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 Application 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 Application 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 Application 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 Application Developer version 6.0

    Les ressources d'exécution JavaServer Faces et Faces Client initialement disponibles dans Rational Application Developer version 6.0 ont été mises à jour pour Rational Application 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 Application 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 Application Developer version 6.0 vers Rational Application 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 Application 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. Mise à jour des ressources d'exécution Faces pour les projets de portlet de Rational Application Developer version 6.0

    Les ressources d'exécution JavaServer Faces et Faces Client initialement disponibles dans Rational Application Developer version 6.0 ont été mises à jour pour Rational Application Developer version 6.0.1. Si vous souhaitez continuer le développement dans des projets de portlet 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 Application Developer version 6.0.1, les mises à jour des ressources d'exécution Faces Client sont automatiquement appliquées lorsqu'un projet de portlet 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 de portlet ou de l'ouverture d'un espace de travail de Rational Application Developer version 6.0 vers Rational Application 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 de portlet :

    1. Importez un projet de portlet (ou un espace de travail) stockant les données Faces ou Faces Client de Rational Application 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 de portlet 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 de portlet 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 de portlet.
    3. Cliquez sur l'une des options suivantes :
    4. Pour mettre à jour les ressources d'exécution Faces propres au portlet, jsf-portlet.jar et jsf-wp.jar, vous devez suivre les instructions de mise à jour manuelle ci-après :

    Mise à jour manuelle des ressources d'exécution

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

    1. Créez un projet de portlet 1.1 appelé JSFP601. 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 JSFP601 et sélectionnez Propriétés dans le menu.
    3. Cliquez sur Fonctions du projet Web et sélectionnez Ajout de Faces Client Framework pour le projet de portlet, puis cliquez sur OK.
    4. Pour chaque projet de portlet 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, recherchez et supprimez les fichiers JAR suivants :
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.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 JSFP601 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.
        • Si le projet de portlet utilise l'API de portlet IBM(R) ou un composant de lien personnel, copiez le fichier jsf-wp.jar dans le projet d'origine.
        • Si vous copiez le fichier odc-jsf.jar, copiez également le fichier odc-jsf-portlet.jar.
    5. Supprimez le projet de portlet JSFP601.

    Chapter 4. Migration des projets J2EE

    L'assistant de migration J2EE a été mis à jour dans Rational Application 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 Application 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 EJB (EJB 2.0 à EJB 2.1)

    L'assistant de migration J2EE prend en charge la migration des descripteurs de déploiement de bean enterprise à partir de la ressource EJB au niveau de spécification J2EE 1.3 vers J2EE 1.4. Les beans session sans état et les beans gérés par messages sont migrés vers J2EE 1.4.

    Migration des beans session

    L'assistant de migration J2EE migre les beans session sans état définis comme interfaces SEI (Service Endpoint Interface) dans le descripteur webservices.xml d'un projet EJB du niveau de spécification J2EE 1.3 vers J2EE 1.4 en définissant des interfaces SEI sur le bean session sans état.

    La spécification J2EE 1.4 nécessite qu'une interface SEI soit définie sur un bean session sans état si le bean session doit être utilisé comme noeud final de services Web. Lors de la migration d'un fichier JAR EJB, le noeud final de service de tous les beans session du projet EJB a le nom utilisé dans le descripteur webservices.xml du projet EJB. Vous trouverez ci-dessous un exemple de l'aspect des métadonnées d'un projet EJB avant et après la migration vers le niveau de spécification J2EE 1.4.

    Projet EJB dans J2EE 1.3 : descripteur webservices.xml avec un bean session sans état utilisé comme interface SEI avant la migration

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN" 
    "http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd">
       <webservices id="WebServices_1084831328093">
          <webservice-description id="WebServiceDescription_1084831328093">
             <webservice-description-name>EchoEJBService</webservice-description-name>
             <wsdl-file>META-INF/wsdl/EchoEJB.wsdl</wsdl-file>
             <jaxrpc-mapping-file>META-INF/EchoEJB_mapping.xml</jaxrpc-mapping-file>
             <port-component id="PortComponent_1084831328103">
                <port-component-name>EchoEJB</port-component-name>
                <wsdl-port id="WSDLPort_1084831328103">
                   <namespaceURI>http://test</namespaceURI>
                   <localpart>EchoEJB</localpart>
                </wsdl-port>
                <service-endpoint-interface>test.EchoEJB</service-endpoint-interface>
                <service-impl-bean id="ServiceImplBean_1084831328103">
                   <ejb-link>EchoEJB</ejb-link>
                </service-impl-bean>
             </port-component>
          </webservice-description>
       </webservices>
    

    Les balises <service-endpoint-interface> et <service-impl-bean> dans l'exemple précédent définissent le bean session sans état "EchoEJB" comme noeud final de service dans le descripteur webservices au niveau de spécification J2EE 1.3 avant la migration.

    Projet EJB dans J2EE 1.4 : descripteur de déploiement EJB pour le même bean session sans état "EchoEJB" avec interface SEI créée par le processus de migration

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ejb-jar>
    <ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
    	<display-name>
    	EchoEJBProject</display-name>
    	<enterprise-beans>
    		<session id="EchoEJB">
    			<ejb-name>EchoEJB</ejb-name>
    			<home>test.EchoEJBHome</home>
    			<remote>test.EchoEJB</remote>
    			<service-endpoint>test.EchoEJB</service-endpoint>
    			<ejb-class>test.EchoEJBBean</ejb-class>
    			<session-type>Stateless</session-type>
    			<transaction-type>Container</transaction-type>
    		</session>
    	</enterprise-beans>
    </ejb-jar>
    

    La balise <service-endpoint> de l'exemple précédent définit "EchoEJB" comme noeud final de service dans le niveau de spécification J2EE 1.4 après la migration.

    Migration des beans gérés par messages

    L'assistant de migration J2EE prend en charge la migration des beans gérés par messages EJB 2.0 vers les beans gérés par messages EJB 2.1.

    Les beans gérés par messages ont été introduits dans EJB 2.0 afin de prendre en charge le traitement de messages asynchrones à partir d'un service JMS Java Message Service). La spécification EJB 2.1 développe la définition du bean géré par messages afin qu'il puisse prendre en charge tout système de messagerie, et non uniquement JMS.

    Note:
    Les beans gérés par messages migrés du niveau de spécification EJB 2.0 au niveau de spécification EJB 2.1 et déployés dans WebSphere Application Server version 6 doivent être déployés dans un adaptateur de ressource JCA 1.5 au lieu d'un port d'écoute (comme dans WebSphere Application Server version 5). Vous devez utiliser l'éditeur de descripteur de déploiement pour modifier le paramètres Liaisons de Websphere afin de permettre aux beans gérés par messages d'utiliser un adaptateur de ressource. Voir Configuration d'un bean géré par message EJB 2.1 pour utiliser un adaptateur JCA.

    Les artefacts du bean géré par messages EJB 2.O migrés sont les suivants :

    Certains des beans gérés par messages EJB 2.0 ont été remplacés par les propriétés activation-config. Les noms et les valeurs des propriétés utilisés dans la propriété activation-config pour décrire le service de messagerie dépendent du type du service de messagerie utilisé. Toutefois, EJB 2.1 définit un ensemble de propriétés fixes pour les beans gérés par messages de type JMS.

    L'exemple suivant compare les éléments d'un bean exemple dans EJB 2.0 avec l'aspect dans EJB 2.1.

    Exemple d'éléments de bean géré par message dans EJB 2.0 :

    <message-driven id="Mdb20">
    	  <ejb-name>Mdb</ejb-name>
    	  <ejb-class>ejbs.MdbBean</ejb-class>
    	  <transaction-type>Bean</transaction-type>
    	  <message-selector>mdbMessage</message-selector>
    	  <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
    	  <message-driven-destination>
    		<destination-type>javax.jms.Topic</destination-type>
    		<subscription-durability>Durable</subscription-durability>
    	   </message-driven-destination>
    </message-driven>
    

    Exemple de bean géré par message dans EJB 2.1 :

        <message-driven id="Mdb21">
      <ejb-name>Foo/ejb-name>
      <ejb-class>ejbs.FooBean</ejb-class>
       <messaging-type>javax.jms.MessageListener</messaging-type>
       <transaction-type>Bean/transaction-type>
       <message-destination-type>javax.jms.Topic</message-destination-type>
        <activation-config>
    	  <activation-config-property>
    	   <activation-config-property-name>destinationType</activation-config-property-name>
    	   <activation-config-property-value>javax.jms.Topic</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    	   <activation-config-property-name>subscriptionDurability</activation-config-property-name>
    	     <activation-config-property-value>Durable</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    	     <activation-config-property-name>acknowledgeMode</activation-config-property-name>
    	     <activation-config-property-value>AutoAcknowledge</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    		<activation-config-property-name>messageSelector</activation-config-property-name>
    		<activation-config-property-value>fooSelector</activation-config-property-value>
    	  </activation-config-property>
    </activation-config>
    </message-driven>
    

    Configuration d'un bean géré par message EJB 2.1 pour utiliser un adaptateur JCA

    Les beans gérés par message migrés du niveau de spécification EJB (Enterprise Java Bean) 2.0 vers le niveau de spécification EJB 2.1 et déployés sur un système WebSphere Application Server version 6 doivent être déployés sur un adaptateur de ressource JCA (Java) 1.5 au lieu d'un port d'écoute.

    Les étapes ci-dessous indiquent comment modifier le descripteur de déploiement des beans gérés par message EJB 2.1 pour utiliser un adaptateur JCA :

    1. Ouvrez le projet EJB 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 d'EJB s'affiche.
    3. Cliquez sur l'onglet Bean pour ouvrir la page Bean.
    4. Effectuez les opérations ci-dessous pour chaque bean géré par message EJB 2.1 :
      1. Sélectionnez le bean géré par message EJB 2.1 dans la liste des beans située dans la partie gauche de la page Bean.
      2. Dans la section Liaisons WebSphere, cliquez sur le bouton Adaptateur JCA.
      3. Indiquez les propriétés de déploiement des liaisons :
        1. Nom JNDI ActivationSpec.

          Entrez le nom JNDI de la spécification d'activation J2C qui doit être utilisé pour déployer ce bean géré par message. Ce nom doit correspondre au nom de la spécification d'activation J2C que vous définissez auprès de WebSphere Application Server.

        2. Alias d'autorisation ActivationSpec.

          Nom d'un alias d'authentification J2C utilisé pour l'authentification des connexions établies avec l'adaptateur de ressource JCA. Un alias d'authentification J2C définit l'ID utilisateur et le mot de passe utilisés pour authentifier la création d'une connexion à l'adaptateur de ressource JCA.

        3. Nom JNDI de la destination.

          Entrez le nom JNDI que le bean géré par message utilise pour rechercher la destination JMS dans l'espace de nom JNDI.

    5. Sauvegardez les modifications et fermez l'éditeur de descripteur de déploiement.

    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 4, Migration des projets J2EE.

    Migration de projets EJB (EJB 1.1 vers EJB 2.1)

    La migration d'un projet EJB vers le niveau de spécification EJB 1.1 vers EJB 2.1 est décrite dans cette section.

    La migration d'un projet EJB d'EJB 1.1 vers EJB 2.1 implique la migration des beans entity CMP.

    Aucune modification n'a été apportée aux beans entity entre le niveau de spécification J2EE 1.3 et J2EE 1.4. La migration des beans entity CMP du niveau de spécification EJB 1.1 vers EJB 2.1 est effectuée de la même manière que la migration d'un bean entity à partir d'EJB 1.1 vers EJB 2.0. Il est nécessaire de suivre les étapes ci-après pour la migration des beans entity gérés par conteneur du niveau de spécification EJB 1.1 vers EJB 2.x.

    1. Conversion du projet EJB d'EJB 1.1 en EJB 2.x.
    2. Migration du code EJB à partir d'EJB 1.1 vers EJB 2.x.
    3. Migration des références d'EJB 1.1 définies par l'utilisateur vers les références locales dans EJB 2.x.

    Conversion des projets d'EJB 1.1 en EJB 2.x

    Il est possible de convertir un projet EJB 1.1 en un projet EJB 2.x à l'aide de l'assistant de migration J2EE.

    Ou, si vous souhaitez conserver le projet EJB 1.1 d'origine, vous pouvez créer un projet 2.x puis importer le fichier JAR du projet dans le projet (Fichier -> Importer -> JAR EJB).

    Bien que le projet est un projet EJB 2.x, les beans entity CMP (container-managed persistence) existants (ou importés) restent des beans EJB 1.1. Cela signifie que les beans entity CMP ne sont pas convertis en EJB 2.x.

    L'assistant de migration J2EE migre les beans enterprise dans un projet EJB 2.x de la version 1.1 vers 2.x. Si vous optez pour la migration des beans entity CMP 1.1 vers 2.x, tous les beans du projet 2.x doivent être migrés. Vous pouvez toutefois choisir d'ajouter de manière sélective des vues de client local à ces beans 2.x migrés).

    Note:
    Si certaines associations sont mappées, des associations d'EJB 2.x vont être créées pour les associations elles-mêmes, mais les mappages de rôles de ces associations ne seront plus valides. Si vous exécutez la validation, une erreur est générée. Pour éviter cette situation, ouvrez tout d'abord l'éditeur de mappage et sauvegardez le mappage. Les mappages de rôle seront supprimés. Vous pouvez ensuite exécuter de nouveau la validation et mapper une nouvelle fois les rôles.

    Migration du code EJB 1.1 vers EJB 2.x

    Il est nécessaire de suivre une procédure pour migrer le code EJB 1.1 vers EJB 2.x pour les projets convertis d'EJB 1.1 à EJB 2.x.

    Note:
    Les beans EJB 2.x sont pris en charge uniquement dans un projet EJB 2.x (bien qu'un projet 2.x prenne également en charge les beans 1.1).

    1. Pour chaque bean CMP 1.1, remplacez chaque zone CMP avec des méthodes getXXX et setXXX abstraites. (La classe de bean doit être abstraite.)
    2. Pour un bean CMP, créez une méthode getXXX et setXXX abstraite pour la clé primaire.
    3. Pour toute méthode de localisation CMP 1.1, créez une méthode EJBQL (EJB Query Language).
      Note:
      EJB Query Language comporte les limitations suivantes dans Rational Application Developer version 6.0 :
      • Les demandes EJB Query Language impliquant des EJB avec des clés constituées de relations avec d'autres EJB apparaissent comme étant non valides et provoquent des erreurs lors du déploiement.
      • Le support IBM EJB Query Language développe la spécification EJB 2.x de différentes manières. Certaines restrictions sont moins strictes et un plus grand nombre de fonctions DB2 sont prises en charge, par exemple. Si la portabilité entre les différentes bases de données ou les outils de déploiement EJB constitue un point important, il est nécessaire de rédiger les demandes EJB Query Language en respectant strictement les instructions apparaissant dans le chapitre 11 de la spécification EJB 2x.
    4. Pour une méthode de localisation (finder) CMP 1.1, renvoyez java.util.Collection au lieu de java.util.Enumeration.
    5. Pour un bean CMP 1.1, modifiez toutes les occurrences de this.field = value en setField(value) dans ejbCreate() et partout ailleurs dans le code.
    6. Mettez à jour le traitement des exceptions (comportement de la fonction d'annulation) pour les exceptions ne concernant pas des applications :
    7. Mettez à jour le traitement des exceptions (comportement de la fonction d'annulation) pour les exceptions ne concernant pas des applications :
    8. Mettez à jour les valeurs par défaut propres à un paramètre CMP afin qu'elles soient comprises dans une méthode ejbCreate (sans utiliser de variables globales dans la mesure où les conteneurs EJB 1.1 affectent à toutes les zones des valeurs par défaut génériques sans appeler ejbCreate dans le but de remplacer les valeurs par défaut propres à l'application précédente).

    Migration de références d'EJB pour les relations EJB 1.1

    Lors de la création des relations d'EJB 1.1, les références d'EJB sont créées sur la vue du client distant. Au cours de la migration d'un projet EJB 1.1 via l'assistant de migration J2EE, ces références éloignées d'EJB des relations d'EJB 1.1 sont supprimées et remplacées par les références locales d'EJB. Les références locales pour les références d'EJB définies par l'utilisateur doivent être créées à nouveau manuellement.

    Note:
    Dans EJB 2.x, les relations d'EJB peuvent être créées uniquement si la vue du client éloigné est définie sur les beans et si les références locales d'EJB sont créées pour les relations d'EJB 2.x.

    Dans le cas de références d'EJB définies par l'utilisateur, la migration n'est pas effectuée par l'assistant de migration J2EE. Vous devez cependant suivre les étapes ci-après pour configurer les références locales.

    1. Supprimez les références éloignées d'EJB existantes dans la page Références de l'éditeur de descripteur de déploiement.
    2. Ajoutez une référence locale d'EJB dans la page Références de l'éditeur de descripteur de déploiement.

    Les éléments des méthodes sont fusionnés lors de la migration des structures de projets

    Au cours de la migration de la structure du projet via l'assistant de migration J2EE, les éléments de méthode (qui incluent l'identité de sécurité, la transaction de conteneur, les autorisations de méthodes, la tentative d'accès et le niveau d'isolement) du même type pour tous les beans sont fusionnés et regroupés de manière logique.

    Vous trouverez ci-après un exemple des éléments de méthode avant et après la migration de la structure du projet.

    Voici un exemple de l'autorisation de méthode dans la page source de l'éditeur du descripteur de déploiement avant la migration de la structure du projet.

    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getEJBMetaData</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getHomeHandle</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-namae>remove</method-name>
    				<method-params>
    					<method-param>java.lang.Object</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>javax.ejb.Handle</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Remote</method-intf>
    				<method-name>isIdentical</method-name>
    				<method-params>
    					<method-param>javax.ejb.EJBObject</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    

    Voici un exemple de l'autorisation de méthode dans la page source de l'éditeur du descripteur de déploiement après la migration de la structure du projet.

    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getEJBMetaData</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getHomeHandle</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>>java.lang.Object</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>javax.ejb.Handle</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Remote</method-intf>
    				<method-name>isIdentical</method-name>
    				<method-params>
    					<method-param>javax.ejb.EJBObject</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    
    Note:
    Lorsque la migration de bean CMP 1.x vers CMP 2.x est également sélectionnée avec la migration de la structure du projet dans l'assistant de migration J2EE, la tentative d'accès et le niveau d'isolement sont supprimés, mais les autres éléments sont fusionnés au cours de la migration. La tentative d'accès et le niveau d'isolement sont supprimés car ils ne sont plus valides en raison des modifications apportées au modèle des extensions. Dans le nouveau modèle, la tentative d'accès et le niveau d'isolement sont définis dans la tentative d'accès et il existe une tentative d'accès au niveau des beans et une tentative d'accès au niveau des méthodes. Il est toujours conseillé d'utiliser la tentative d'accès au niveau des beans plutôt que la tentative d'accès au niveau des méthodes.

    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 Application Developer V6.0

    Les modifications apportées à l'assistant de migration J2EE dans Rational Application 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 Application 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 Application 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 5. Migration vers les outils de portail dans Rational Application Developer V6.0

    Les projets Portal Toolkit V5.0.2.2 seront migrés automatiquement vers Rational Application Developer V6.0 Portal Tools en migrant l'espace de travail Portal Toolkit ou en chargeant le projet à partir d'un système SCM (Source Code Management) ou en important le projet à l'aide de la fonction Project Interchange. Si vous effectuez la migration à partir de versions antérieures de Portal Toolkit, vous devez exporter les projets de portlet vers les fichiers WAR et importer les fichiers WAR dans les outils de portail de Rational Application Developer V6.0.

    Avant la migration des applications de portail, vous devez installer la fonction des outils de portail de Rational Application Developer V6.0. Reportez-vous au guide d'installation.

    Note:
    La compatibilité en amont des projets de portlet n'est pas prise en charge.

    La migration automatique est prise en charge uniquement pour les projets créés dans Portal Toolkit V5.0.2.2 avec WebSphere Studio V5.1.2. Pour obtenir plus de détails sur la migration, reportez-vous à la section Chapter 1, Migration à partir de WebSphere Studio V5.1, 5.1.1 ou 5.1.2.

    Si le projet de type portlet est associé à un projet d'application d'entreprise, vous devez définir le serveur cible approprié sur le projet EAR. Vous pouvez définir le serveur cible sur la page des propriétés du serveur (Propriétés -> Serveur).

    Lors de la migration des projets Portal Toolkit V5.0.2.2, certaines modifications supplémentaires se produisent :

    Si vous effectuez la migration à partir de versions antérieures de Portal Toolkit, vous devez migrer manuellement les projets de portlet vers les outils de portlet dans Rational Application Developer V6.0, en procédant comme suit :

    1. Exportez le projet existant vers un fichier WAR : Dans la version antérieure de Portal Toolkit, exportez chaque projet vers un fichier WAR avec les fichiers source.
      1. A l'aide du bouton droit de la souris, cliquez sur le projet et sélectionnez Exportation.
      2. Sélectionnez Fichier WAR et Exporter les fichiers source puis cliquez surTerminer.
    2. Importez le fichier WAR de portlet :
      1. Dans les outils de portail de Rational Application Developer V6.0, créez un projet de portlet vide.
        1. Sélectionnez Fichier -> Nouveau -> Projet -> Portail -> Projet de portlet ou Projet de portlet (JSR 168).
        2. Désélectionnez Création d'un portlet.
        3. Cliquez sur Afficher les propriétés avancées.
        4. Si vous importez un portlet WebSphere Portal 4.2, sélectionnez 2.2 en tant que version de servlet.
        5. Sélectionnez WebSphere Portal v5.0 comme serveur cible et cliquez sur Terminer.
      2. Importez le fichier WAR dans ce nouveau projet de type portlet vide.
        1. Sélectionnez Importer.
        2. Sélectionnez Fichier WAR et indiquez le fichier WAR exporté (Exportation d'un projet dans un fichier WAR dans la version précédente).
        3. Sélectionnez le nouveau projet de type portlet vide.
        4. Sélectionnez Remplacer les ressources existantes sans avertissement.
        5. Ne sélectionnez pas Supprimer le projet après remplacement.
    3. Supprimez le fichier TLD :

      Il est recommandé de supprimer le fichier TLD de portlet dans le projet. Sinon, un message d'avertissement est généré lors de la nouvelle compilation du projet. Le fait de conserver ce fichier peut provoquer une erreur lorsque le projet de type portlet est déployé dans WebSphere Portal et que le fichier TLD du portlet est différent du fichier sur le serveur.

    4. Si vous migrez un portlet WebSphere Portal 4.2, vous devez migrer ce projet de type portlet vers WebSphere Portal 5.x.

    Pour obtenir plus d'informations sur la migration des portlets WebSphere Portal V4.2 vers V5.x, reportez-vous à la section Migration des portlets WebSphere Portal V4.2 vers V5.x.

    Pour obtenir plus d'informations sur la migration des ressources Faces dans un projet de portlet, reportez-vous à la section Mise à jour de ressources d'exécution Faces dans un projet de portlet.


    Migration des portlets WebSphere Portal V4.2 vers V5.x

    Rational Application Developer V6.0 ne prend pas en charge le développement de portlets WebSphere Portal V4.2. Vous devez migrer les projets de type portlet WebSphere Portal V4.2 vers V5.x.

    La plupart des portlets créés pour WebSphere Portal V4.2 s'exécutent sans être modifiés dans WebSphere Portal V5.x. Certaines API de portlet 4.2.x sont déconseillées mais sont toujours disponibles dans WebSphere Portal V5.x.

    Note:
    Les projets d'application de portlet migrés ne sont pas compatibles en amont.

    Pour migrer les applications de porlet pour WebSphere Portal V4.2 vers V5.x, procédez comme suit :

    1. Migrez les projets de portlet Portal V4.2 vers les projets de portlet Portal V5.x :
      1. Cliquez à l'aide du bouton droit de la souris sur le projet d'application de portlet à migrer.
      2. Sélectionnez Propriétés -> API de portlet pour ouvrir la page API de portlet.
      3. Dans le menu déroulant au niveau de l'API de portlet, sélectionnez WebSphere Portal Version 5.x.
      4. Cliquez sur OK et les modification suivantes sont automatiquement effectuées :
        • Le fichier TLD (Tag Library Descriptor) de l'API de portlet est supprimé.
        • Le niveau Web est modifié et passe du niveau 2.2 au niveau 2.3.
        • Les entrées de chemin d'accès aux classes propres au portlet sont supprimées alors que le conteneur JRE WebSphere Portal et le conteneur cible d'exécution WebSphere Portal les ajoute dynamiquement.
    2. Si le projet de type de portlet est associé à un projet d'application d'entreprise, il est recommandé de migrer le niveau J2EE du projet EAR vers J2EE 1.3. Les applications de portlet conçues pour WebSphere Portal V5.x doivent être compatibles avec les spécifications J2EE de niveau 1.3.
      Note:
      Avant de migrer le projet d'application d'entreprise vers J2EE 1.3, reportez-vous à la rubrique Chapter 4, Migration des projets J2EE. Pour obtenir plus d'informations sur l'utilisation de l'assistant de migration J2EE, reportez-vous à l'aide en ligne.
      1. Si le projet de type portlet migré est associé uniquement au projet d'application d'entreprise, procédez comme suit :
        1. Fermez tous les éditeurs dans l'espace de travail.
        2. Cliquez à l'aide du bouton droit de la souris sur le projet d'application d'entreprise auquel le projet de type portlet migré est associé.
        3. Sélectionnez Migrer -> Assistant de migration J2EE et cliquez sur Suivant.
        4. Sélectionnez J2EE version 1.3 et WebSphere Portal comme serveur cible.
        5. Cliquez sur Terminer.
      2. Si les autres projets de type portlet sont associés au projet d'application d'entreprise, vous devez retirer le projet de type portlet migré et l'ajouter à un autre projet d'application d'entreprise.
        1. Retirez le module du projet de type portlet migré du projet d'application d'entreprise.
          1. Développez le projet d'application d'entreprise et sélectionnez le descripteur de déploiement.
          2. Sélectionnez Ouvrir avec -> Editeur de descripteur de déploiement.
          3. Sélectionnez l'onglet Module. Sur la page Module de l'éditeur, sélectionnez le fichier WAR du projet de type portlet migré.
          4. Cliquez sur Supprimer.
          5. Sélectionnez Fichier -> Sauvegarder pour sauvegarder les modifications.
        2. Créez un projet d'application d'entreprise et ajoutez à ce dernier le projet de type portlet.
          1. Sélectionnez Fichier -> Nouveau -> Projet.
          2. Sélectionnez la case à cocher Afficher tous les assistants.
          3. Développez J2EE et sélectionnez Projet d'application d'entreprise.
          4. Renseignez la zone Nom du projet, sélectionnez J2EE version 1.3 et WebSphere Portal comme serveur cible puis cliquez sur Suivant.
          5. Sur la page Projets de module EAR, sélectionnez le projet de type portlet et cliquez sur Terminer.

    Le projet de portlet est maintenant migré vers WebSphere Portal V5.x.


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

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

    Dans Rational Application Developer version 6.0.1, les mises à jour des ressources d'exécution Faces sont automatiquement appliquées lorsqu'un projet de portlet est importé ou qu'un espace de travail contenant des ressources antérieures est ouvert. A l'issue de l'importation d'un projet de portlet créés avec Portal Toolkit 5.0.2.2 pour WebSphere Studio Application Developer 5.1.x dans Rational Application Developer 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 de portlet :

    1. Importez un projet de portlet contenant des données Faces de WebSphere Studio Application 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 de portlet 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 de portlet stockant des données Faces, cochez la case Appliquer cette option aux autres projets à mettre à jour pour mettre à jour tous les projets de portlet.
    3. Cliquez sur l'une des options suivantes :
    4. Pour mettre à jour les ressources d'exécution Faces propres au portlet, jsf-portlet.jar et jsf-wp.jar, vous devez suivre les instructions de mise à jour manuelle ci-après :
    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 portlet :

    1. Importez le projet de portlet existant avec le contenu Faces dans un espace de travail Rational Application Developer version 6.0.1.
    2. Créez un projet de portlet nommé JSFP601 avec l'option Portlet Faces sélectionnée dans la deuxième page. 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 JSFP601 et sélectionnez Propriétés dans le menu.
    4. Cliquez sur Fonctions du projet Web et sélectionnez Ajout de Faces Client Framework pour le projet de portlet, puis cliquez sur OK.
    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 :
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.jar
        • odc-jsf.jar
      2. Localisez 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>
        		<variable-resolver>com.ibm.faces.application.WPPortletVariableResolver</variable-resolver>
        		<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
        	</application>
        
        Note:
        Si le projet de portlet utilise l'API JSR 168, indiquez com.ibm.faces.application.PortletVariableResolver à la place de com.ibm.faces.application.WPPortletVariableResolver.
      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 JSFP601 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.
        • Si le projet de portlet utilise l'API de portlet IBM ou un composant de lien personnel, copiez le fichier jsf-wp.jar dans le projet d'origine.
        • Si vous copiez le fichier odc-jsf.jar, copiez également le fichier odc-jsf-portlet.jar.
      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>
        
    6. Supprimez le projet de portlet JSFP601.

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

    Dans Rational Application 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 Application Developer.

    Vous trouverez ci-dessous un récapitulatif des modifications apportées aux environnements de test WebSphere Application Server dans Rational Application 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 Application Developer et Rational Application Developer.

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


    WebSphere Application Server V4.x AEs Version de base WebSphere Application Server V5.x WebSphere Application Server Express 5.x WebSphere Application Server V5.x Portal WebSphere Application Server V6.0
    WebSphere Studio Application Developer V5.1 V4.0.6 V5.0.2 V5.0.2 N/A N/A
    WebSphere Studio Application Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1 V5.0.2 & V5.1 N/A N/A
    WebSphere Studio Application Developer V5.1.2 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1.0.3 V5.0.2 & V5.1.0.3 V5.0.2.3 Base + WebSphere Portal V5.0.2.1 N/A
    Rational Application Developer V6.0 N/A V5.0.x, V5.1.1 V5.0.2 & V5.1.1 V5.0.2.6 Base + WebSphere Portal V5.0.2.2, V5.1.1 Base + WebSphere Portal 5.1 V6.0

    Copyright et remarques