IBM Rational Application Developer pour Windows et Linux, version 6.0 - Guide de migration
Chapter 1. Migration à partir de WebSphere Studio V5.1, 5.1.1 ou 5.1.2
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
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
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 :
- 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.
- Sauvegardez l'espace de travail WebSphere Studio
V5.1.x.
- Installez Rational Application Developer. Reportez-vous au
guide d'installation (fichier install.html) qui est
disponible à la racine du premier CD du produit.
- 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).
- 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
:
- 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 :
- Fermez la perspective en sélectionnant Fenêtre ->
Fermer la perspective
- 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.
- Fermez la perspective Web EGL.
- 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.
- Sélectionnez Fenêtre -> Ouvrir la
perspective et choisissez la perspective Web.
- 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.
- 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 :
- Si vous utilisiez Portal Toolkit V5.0.2.2 avec
WebSphere Studio V5.1.2 pour développer les projets de
type portlet, votre espace de travail sera automatiquement migré afin
d'être compatible avec Rational Application Developer. Pour
obtenir plus d'informations, reportez-vous à la section Chapter 5, Migration vers les outils de portail dans Rational Application Developer V6.0.
- Pour chaque projet V5.1.x migré vers la version
6.0, le programme de migration ajoute automatiquement un fichier
.compatibility au dossier de projet dans la version 6.0.
Ce fichier est utilisé pour la compatibilité en amont avec WebSphere
Studio V5.1.x. Ne modifiez ou ne supprimez pas ce
fichier. Pour obtenir plus d'informations, reportez-vous à la
section relative à la compatibilité avec
WebSphere Studio V5.1.x.
Important :
- S'il existe des configurations de lancement de débogage
associées à l'espace de travail migré, vous devez prendre en
compte que certaines configurations de lancement ne seront pas migrées
automatiquement. Pour obtenir plus d'informations sur le mode de
restauration des configurations de lancement vers un espace de travail
migré, reportez-vous à la section Modifications apportés au débogueur dans la version 6.0.
- Si vous utilisiez le débogueur XSLT ou le débogueur EGL sur les
projets dans l'espace de travail migré, vous devez changer
l'environnement d'exécution Java (JRE) installé avec Rational
Application Developer V6.0. Pour savoir comment effectuer ce
changement, reportez-vous à la section Modifications apportés au débogueur dans la version 6.0.
- Si vous avez des programmes développés à l'aide d'EGL
(Enterprise Generation Language) migrés vers la version 6.0,
n'oubliez pas qu'il y a de nouveaux mots réservés pour EGL
dans la version 6.0. Si vous utilisez ces mots comme noms de
variables ou de parties, vous devez les changer. Reportez-vous à la
section Mots réservés dans V6.0
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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 :
- Modification des métadonneés de compatibilité ajoutées au
fichier .project et au fichier .compatibility créés par
l'outil de migration.
- Suppression du fichier
.compatibility de ces projets.
- Suppression de la compatibilité pour un projet d'application
d'entreprise (si l'application d'entreprise ou un de ses
modules ou projets d'utilitaire doit être compatible avec WebSphere
Studio Application Developer V5.1.x).
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é avec les versions précédentes
- Mise à niveau de l'espace de travail à partir d'une
version précédente
- Interopérabilité avec les versions précédentes
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 :
- Ouvrez le fichier .classpath de chaque projet J2EE qui a
un fichier .classpath.
- Supprimez les entrées de chemin d'accès aux classes suivantes
du fichier
.classpath puis fermez et sauvegardez le fichier.
-
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/
org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v5.1 JRE"/>
-
<classpathentry kind="con"
path="com.ibm.wtp.server.java.core.container/
com.ibm.etools.websphere.runtime.core.runtimeTarget.v51/was.base.v51"/>
- 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".
- Cliquez avec le bouton droit de la souris sur le projet et sélectionnez
Propriétés -> J2EE.
- 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.
- 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.
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 :
- 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é.
- 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.
- 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.
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 :
- 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.
- 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.
- Cliquez sur l'une des options suivantes :
- Oui pour exécuter la mise à jour automatiquement.
- Plus tard pour différer la mise à jour. Pour
mettre automatiquement à jour les ressources d'exécution après
avoir sélectionné Plus tard, vous devez fermer et rouvrir le
projet Web et redémarrer le plan de travail avant de regénérer le
projet Web. Si vous avez désactivé les générations
automatiques, cliquez sur le projet Web à l'aide du bouton droit de la
souris et sélectionnez Générer un projet.
- Jamais pour conserver les ressources d'exécution à
un niveau antérieur. Si vous sélectionnez Jamais et
que vous conservez volontairement les ressources d'exécution à un
niveau antérieur, le système ne vous invite plus à les mettre à
jour. Vous devrez migrer manuellement les ressources de projet si vous
en avez besoin ultérieurement.
- 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 :
- Importez le projet Web stockant les données Faces dans un environnement
Rational Application Developer version 6.0.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.
- 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.
- 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.
- Si vous utilisez EGL, créez un fichier JSP de la manière
suivante :
- Cliquez à l'aide du bouton droit de la souris sur le dossier
WebContent du nouveau projet Web EGL.
- Sélectionnez Nouveau -> Autre ->
Fichier JSP Faces.
Les fichiers eglintdebug.jar et
eglintdebugsupport.jar sont ajoutés au projet.
- Pour chaque projet Faces à mettre à jour, procédez comme suit
:
- 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
- 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>
- 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.
- 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>
- 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.
- Dans le projet d'origine, cliquez sur Fichier ->
Nouveau -> Fichier JSP Faces pour créer un
fichier JSP Faces temporaire.
- Déplacez un composant de liste d'enregistrements relationnels à
partir du tiroir de données sur la palette de la page.
- 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.
- Supprimez le fichier JSP temporaire.
- 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.
- Supprimez le projet JSF601.
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 :
- 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.
- 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.
- Cliquez sur l'une des options suivantes :
- Oui pour exécuter la mise à jour automatiquement.
- Plus tard pour différer la mise à jour. Pour
mettre automatiquement à jour les ressources d'exécution après
avoir sélectionné Plus tard, vous devez fermer et rouvrir le
projet Web et redémarrer le plan de travail avant de regénérer le
projet Web. Si vous avez désactivé les générations
automatiques, cliquez sur le projet Web à l'aide du bouton droit de la
souris et sélectionnez Générer un projet.
- Jamais pour conserver les ressources d'exécution à
un niveau antérieur. Si vous sélectionnez Jamais et
que vous conservez volontairement les ressources d'exécution à un
niveau antérieur, le système ne vous invite plus à les mettre à
jour. Vous devrez migrer manuellement les ressources de projet si vous
en avez besoin ultérieurement.
- 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.
- 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.
- Pour chaque objet de données dans la vue Client Data :
- A l'aide du bouton droit de la souris, cliquez sur
Configure.
- 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 :
- 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.
- 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 :
- Les classes du médiateur de données client déjà
générées ne seront plus compilées. Chaque page JSP doit
être regénérée séparément.
- Ouvrez le fichier OdysseyBrowserFramework.properties disponible
dans le dossier source Java(TM). Sauvegardez le contenu pour une
utilisation ultérieure.
- Dans le fichier OdysseyBrowserFramework.properties, pour chaque
page JSP du projet Web contenant des données Faces Client, recherchez les
entrées <client-données-nom>.ecore et
<client-données-nom>.emap pour les propriétés EMAP_FILES
et ECORE_FILES.
- Conservez uniquement les entrées correspondantes pour les données
client de la page JSP et supprimez toutes les autres entrées.
Par exemple, si des données client portent le nom ACCOUNT dans la page
en cours et que le fichier des propriétés dispose d'une entrée
du type :
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
Vous devez supprimer
com\\ibm\\dynwdo4jsmediators/orders.emap de
l'entrée. L'entrée doit maintenant avoir l'aspect
suivant :
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
- Sauvegardez le fichier properties.
- Cliquez sur un objet de données client dans une page JSP à
l'aide du bouton droit de la souris et sélectionnez
Configurer.
- Dans l'onglet Avancé, cliquez sur
Régénérer tout. Cette action permet de
regénérer tous les artefacts nécessaires aux données client de la
page JSP en cours.
- Répétez les étapes 2-6 pour chaque page JSP contenant des
données client dans le projet Web.
- Après la regénération des classes de médiateur des données
client, certaines classes du médiateur ne seront pas compilées.
Il s'agit des médiateurs des éléments de schéma qui ne sont
plus utilisés dans les objets SDO (Service Data Objects) de la version
6.x et qui appliquent la convention de dénomination
*_DataGraphSchema_wdo4js_*.java et
*_RootDataObject_wdo4js_*.java. Supprimez ces classes de
médiateur du projet pour éviter ces erreurs de compilation.
- Après la fin de la mise à jour, restaurez le contenu d'origine
du fichier OdysseyBrowserFramework.properties.
- Les composants Faces Client de la vue Arborescence associés à WDO ne
parviennent pas à s'exécuter sur le serveur après le changement
du serveur cible du projet en système WebSphere Application Server
V6.0. Pour éviter cette situation, il suffit de modifier la
vue source de la page JSP afin de modifier toutes les balises className et
d'utiliser la classe SDO DataObject à la place de la classe DataObject
WDO. Par exemple, pour un objet WDO nommé account :
- Pour l'objet racine, modifiez la balise
classNameclassName="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)"
en
className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
- Pour tous les noeuds enfant, modifiez la balise className
className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)"
en
className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)",
où ACCOUNT correspond au noeud de données.
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 :
- Générez les nouveaux gestionnaires Diff et les processeurs sur
chaque objet de données client dans votre projet Web.
- Cliquez à l'aide du bouton droit de la souris sur l'objet de
données client et sélectionnez Configurer.
- Dans l'onglet Avancé, cliquez sur
Régénérer tout.
- 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";
- 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.
- Voici les modifications apportées à l'interface DiffHandler
:
- La méthode du gestionnaire émet maintenant Exception outre
DiffException.
- L'infrastructure utilise la nouvelle méthode de localisation pour
trouver des objets.
- La nouvelle méthode getId permet le débogage et permet également
à l'infrastructure d'imprimer la valeur d'un objet.
Les méthodes getId et de localisation sont utilisées en interne par
les éléments DiffHandler générés. Pour les
éléments DiffHandler personnalisés, vous pouvez implémenter des
méthodes vides pour la compatibilité avec l'interface. Ces
méthodes ne sont pas appelées par l'infrastructure.
L'interface DiffHandler est maintenant la suivante :
public interface DiffHandler
{
public void handle(DiffInfo Diff) throws DiffException, Exception;
public Object find (DiffInfo Diff) throws DiffException, Exception;
public String getId (DiffInfo Diff, boolean Original);
}
- Voici les modifications apportées à la classe DiffInfo :
- La méthode ArrayList getAncestors() a été remplacée par la
méthode DiffInfo getParent(), qui permet d'accéder plus facilement
aux informations de chaque objet de l'arborescence des ancêtres de
manière récursive.
- Les méthodes getCurrent() et getOriginal() renvoient maintenant un
objet DataObject à la place d'un objet EObject. Il n'est
pas obligatoire de changer le code pour utiliser l'objet
DataObject. Toutefois, l'utilisation de l'interface
DataObject est plus simple et plus intuitive que celle de l'objet
EObject. Vous pouvez facilement transtyper un objet DataObject en un
objet EObject pour le code existant.
- Une nouvelle chaîne de méthodes getPropertyName() a été
ajoutée pour l'identification du nom de propriété auquel
s'applique cet objet. Cet ajout est important si, par exemple, une
classe donnée a deux propriétés du même type.
Précédemment, dans la classe DiffInfo, le code n'aurait pas pu
effectuer la différence entre les deux propriétés.
La classe DiffInfo est maintenant la suivante :
public class DiffInfo
{
public char getCrud()
public DataObject getCurrent()
public String getEClassName()
public DataObject getOriginal()
public String getPropertyName()
public DiffInfo getParent()
}
- Note:
- La classe DiffInfo n'est plus prise en charge pour l'utilisation
publique et les gestionnaires et les processeurs Diff sont maintenant
automatiquement générés. La conservation des anciens
gestionnaires n'est qu'une solution temporaire et il est fortement
recommandé d'utiliser des gestionnaires automatisés.
Modifications apportées aux composants Faces Client dans la version
6.0 :
- Prise en charge de WebSphere Application Server version 6.0.
- Prise en charge des objets SDO (Service Data Objects) dans WebSphere
Application Server version 6.0.
- Les données EGL sont maintenant prises en charge comme données
client.
- Les gestionnaires et processeurs Diff sont automatiquement
générés.
- Il existe de nouveaux événements pour les composants suivants
:
- TabbedPanel : onInitialPageShow
- Tree : onNodeExpand, onNodeCollapse, onExpand, onCollapse
- DataGrid : onPage, onSort, onFilter
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 :
- Ouvrez le projet Web Struts dans l'explorateur de projets.
- 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.
- Cliquez sur l'onglet Source pour ouvrir la page
Source.
- 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>.
- 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 :
- Chargez les projets Struts 1.1 bêta dans l'espace de
travail Rational Application Developer version 6.0.
- 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é.
- Effectuez les opérations ci-dessous pour chaque projet Struts
1.1 bêta que vous souhaitez convertir pour Struts 1.1 :
- Supprimez les fichiers .JAR suivants du répertoire Web
Content/WEB-INF/lib du projet :
- commons-*.jar.
- struts.jar.
- 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.
- Supprimez les fichiers TLD (Tag Library Descriptor) suivants stockés
dans le répertoire Web Content/WEB-INF du projet :
struts-*.tld.
- 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 :
- Chargez les projets Struts 1.0.2 dans un environnement
Rational Application Developer version 6.0.
- 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é.
- Effectuez les opérations ci-dessous pour chaque projet Struts
1.0.2 à convertir vers Struts 1.1
- Supprimez les fichiers
.JAR struts stockés dans le répertoire Web Content/WEB-INF/lib du
projet.
- 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.
- Supprimez les fichiers TLD (Tag Library Descriptor) suivants du
répertoire Web Content/WEB-INF du projet :
struts-*.tld.
- Copiez les fichiers suivants du répertoire Struts11/WebContent/WEB-INF
dans le répertoire du projet Web Content/WEB-INF :
struts-*.tld.
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 :
- Débogage sur le serveur : Les configurations de
lancement précédemment créées via l'action Déboguer sur le
serveur ne seront pas migrées vers la version 6.0. Pour
lancer une application pour le débogage sur le serveur dans V6.0,
sélectionnez à nouveau l'application et sélectionnez
Déboguer sur le serveur. Cette action permet de créer
une configuration de lancement pour l'application.
- Connexion à un serveur : Les configurations de
lancement de débogage de WebSphere Application Server précédemment
créées pour une connexion serveur ne seront pas migrées vers la
version 6.0. La configuration de lancement de débogage de
WebSphere Application Server n'existe plus. Pour effectuer une
connexion au serveur pour le débogage dans la version 6.0, utilisez
l'option Déboguer sur le serveur et créez une connexion
au serveur WebSphere V5 pour 5.x ou une connexion au serveur WebSphere
V6.0 pour 6.0.
- Débogueur SQLJ : La configuration de lancement de
débogage SQLJ n'existe plus et les configurations de lancement SQLJ
précédemment créées ne seront pas migrées vers la version
6.0. Pour lancer des programmes SQLJ pour le débogage dans la
version 6.0, utilisez la configuration de lancement d'application
Java.
- Programme de débogage de procédure mémorisée
:Les configurations de lancement de débogage de procédure
mémorisée précédemment créées seront migrées vers
Rational Application Developer V6.0 et seront disponibles dans la
boîte de dialogue des configurations de lancement de
débogage. Après la migration, si vous utilisez
l'option Déboguer du menu contextuel Vue des
définitions de données, une nouvelle configuration de lancement
sera créée.
- Note:
- Si vous effectuez la migration d'un espace de travail contenant une
procédure mémorisée et que vous créez ensuite la procédure
mémorisée pour débogage, les configurations de lancement migrées
associées à la procédure mémorisée ne fonctionnent pas.
- Débogueur EGL : Après la migration d'un espace
de travail, les étapes suivantes seront effectuées pour les
configurations de lancement du débogueur EGL :
- Modifiez l'environnement d'exécution Java afin qu'il
désigne l'emplacement correct. Après la migration d'un
espace de travail, son environnement JRE installé désigne
l'environnement JRE de la version précédente de WebSphere Studio
Application Developer. Pour modifier cela, désignez
l'emplacement du nouvel environnement JRE, procédez comme suit :
- Sélectionnez Fenêtre ->
Préférences dans le menu du plan de travail.
- Dans la boîte de dialogue Préférences, développez
le noeud Java puis sélectionnez JRE installés.
- Sur le côté droit, définissez l'environnement JRE
installé de telle sorte qu'il désigne celui qui a été
installé avec la version en cours de ce produit. L'emplacement
de l'environnement JRE est le sous-répertoire \eclipse\jre du
répertoire d'installation de Rational Application Developer
V6.0.
- Dans la configuration de lancement, sélectionnez l'onglet
Source avant le lancement (si vous n'effectuez pas cette
action, une erreur "Source introuvable" est générée). Si vous
avez ajouté des emplacements source à la configuration de lancement dans
l'espace de travail V5.1.x, vous devez ajouter manuellement
ces emplacements à la configuration de migration migrée.
- Débogueur de langage compilé : Après la
migration d'un espace de travail, les étapes suivantes doivent être
suivies pour les configurations de lancement de débogage du langage
compilé existantes :
- Si vous avez défini les variables d'environnement dans
l'onglet Environnement système de la configuration de
lancement Application compilée, vous devez ajouter manuellement
ces emplacements à la configuration de lancement migrée.
- Si vous avez ajouté des emplacements source aux configurations de
lancement Application compilée ou Association à un
processus en cours d'exécution, vous devez les ajouter
manuellement à la configuration de lancement migrée.
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 :
- Modifiez l'environnement JRE pour l'intégralité de
l'espace de travail en désignant l'emplacement du nouvel
emplacement JRE en suivant la procédure suivante :
- Sélectionnez Fenêtre ->
Préférences dans le menu du plan de travail.
- Dans la fenêtre Préférences, développez le noeud
Java puis sélectionnez JRE installés.
- Sur le côté droit, définissez l'environnement JRE de telle
sorte qu'il désigne celui qui a été installé avec la version
en cours de ce produit. L'emplacement de l'environnement JRE
est le sous-répertoire \eclipse\jre du répertoire d'installation de
Rational Application Developer V6.0.
- Si vous envisagez de lancer la session de débogage via la boîte de
dialogue des configurations de lancement de débogage, vous
pouvez changer l'environnement JRE pour la configuration de lancement en
désignant le nouvel emplacement JRE. Pour cela, ouvrez la
configuration de lancement dans la boîte de dialogue des configurations de
lancement de débogage. Sélectionnez l'onglet
JRE et spécifiez le nouvel emplacement JRE dans la zone
Autre JRE.
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 :
- Vous pouvez modifier le serveur cible à l'aide de la boîte de
dialogue des propriétés du projet. Cliquez à l'aide du
bouton droit dans la vue Explorateur de projets et sélectionnez
Propriétés -> Serveur ->
Environnement d'exécution cible.
- Lors de la migration J2EE à l'aide de l'assistant de
migration J2EE, vous pouvez cibler à nouveau l'application afin
qu'elle utilise un autre serveur.
- Note:
- Vous pouvez effectuer la migration uniquement vers un niveau de
spécification J2EE supérieur.
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é
- Tout code écrit dans les API (Application Programming Interface)
publiques pour les beans d'accès WDO est pris en charge dans la
version 6.0 (bien que les classes d'implémentation ont
été modifiées pour cibler l'environnement d'exécution
SDO).
- Le nouveau code généré pour WebSphere Application Server
V6.0 n'utilise pas les beans d'accès WDO mais génère
à la place du code pour les API SDO pures.
- Tout code généré sur un projet avec la version 6.0 ne
s'exécute pas sur un serveur V5.1 même s'il a été
migré en ciblant à nouveau le serveur.
- Le code rédigé pour la version 5.1 peut être migré en
amont et en aval en ciblant un serveur V5.1.
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 :
- 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;
- 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 fichiers JAR (Java archive) wdo_web.jar et
wdo_jdbc_access.jar sont supprimés du projet.
- Les fichiers JAR suivants sont supprimés du chemin d'accès aux
classes du projet :
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- Les fichiers sdo_web.jar et sdo_access_beans.jar sont
ajoutés au projet (les fichiers JAR de l'environnement
d'exécution SDO sont automatiquement ajoutés à un chemin
d'accès aux classes d'un projet V6.0).
- Les fichiers JAR JSTL (JavaServer Pages Standard Tag Library) 1.0
sont supprimés du projet. Les fichiers JAR JSTL 1.1/JSP
2.0 sont automatiquement ajoutés au chemin d'accès aux
classes du projet V6.0.
- Les instructions d'importation suivantes sont modifiées dans les
fichiers source Java :
- com.ibm.websphere.wdo.access.connections.ConnectionManager
est modifié en
com.ibm.websphere.sdo.access.connections.ConnectionManager.
- com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper
est modifié en
com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper.
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 :
- Les fichiers JAR sdo_web.jar et sdo_access_beans.jar sont
supprimés du projet.
- Les fichiers JAR wdo_web.jar et wdo_jdbc_access.jar sont
ajoutés au projet.
- Les fichiers JAR suivants sont ajoutés au chemin d'accès aux
classes du projet :
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- Les fichiers JAR JSTL 1.0 sont ajoutés au projet. Les
fichiers JAR JSTL 1.1/JSP 2.0 sont supprimés du chemin
d'accès aux classes du projet.
- Les instructions d'importation suivantes sont modifiées dans les
fichiers source Java :
- com.ibm.websphere.sdo.access.connections.ConnectionManager
devient
com.ibm.websphere.wdo.access.connections.ConnectionManager.
- com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper
devient
com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper.
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
|
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.
- as
- isa
- like
- matches
- money
- openUI
- ref
- self
- string
- this
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.
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 :
- 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.
- 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.
- Cliquez sur l'une des options suivantes :
- Oui pour exécuter la mise à jour automatiquement.
- Plus tard pour différer la mise à jour. Pour
mettre automatiquement à jour les ressources d'exécution après
avoir sélectionné Plus tard, vous devez fermer et rouvrir le
projet Web et redémarrer le plan de travail avant de regénérer le
projet Web. Si vous avez désactivé les générations
automatiques, cliquez sur le projet Web à l'aide du bouton droit de la
souris et sélectionnez Générer un projet.
- Jamais pour conserver les ressources d'exécution à
un niveau antérieur. Si vous sélectionnez Jamais et
que vous conservez volontairement les ressources d'exécution à un
niveau antérieur, le système ne vous invite plus à les mettre à
jour. Vous devrez migrer manuellement les ressources de projet si vous
en avez besoin ultérieurement.
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 :
- 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.
- 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.
- 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.
- Si vous utilisez EGL, créez un fichier JSP de la manière
suivante :
- Cliquez à l'aide du bouton droit de la souris sur WebContent du
nouveau projet Web EGL.
- Sélectionnez Nouveau -> Autre ->
Fichier JSP Faces.
Les fichiers eglintdebug.jar et
eglintdebugsupport.jar sont ajoutés au projet.
- Pour chaque projet Faces à mettre à niveau, procédez comme suit
:
- 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
- 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.
- 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.
- Supprimez le projet JSF601.
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 :
- 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.
- 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.
- Cliquez sur l'une des options suivantes :
- Oui pour exécuter la mise à jour automatiquement.
- Plus tard pour différer la mise à jour. Pour
mettre automatiquement à jour les ressources d'exécution après
avoir sélectionné Plus tard, vous devez fermer et rouvrir le
projet de portlet et redémarrer le plan de travail avant de regénérer
le projet de portlet. Si vous avez désactivé les
générations automatiques, cliquez sur le projet de portlet à
l'aide du bouton droit de la souris et sélectionnez Générer
un projet.
- Jamais pour conserver les ressources d'exécution à
un niveau antérieur. Si vous sélectionnez Jamais et
que vous conservez volontairement les ressources d'exécution à un
niveau antérieur, le système ne vous invite plus à les mettre à
jour. Vous devrez migrer manuellement les ressources de projet si vous
en avez besoin ultérieurement.
- 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 :
- 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.
- 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.
- Cliquez sur Fonctions du projet Web et sélectionnez
Ajout de Faces Client Framework pour le projet de portlet, puis
cliquez sur OK.
- Pour chaque projet de portlet Faces à mettre à niveau, procédez
comme suit :
- 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
- 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.
- Supprimez le projet de portlet JSFP601.
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.
- Sauvegardez l'intégralité de votre espace de travail.
- Si vous utilisez un référentiel partagé, réservez ou
verrouillez tous les projets correspondants.
Il est possible d'accéder à l'assistant de migration J2EE
de la manière suivante :
- 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.
- Dans le menu contextuel, sélectionnez Migrer ->
Assistant de migration J2EE.
- 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 :
- Une migration manuelle des fichiers d'extension et de liaison
sécurisés est requise pour la migration des services Web sécurisés
(J2EE 1.3 vers 1.4). Pour plus de détails,
reportez-vous à la section Migration des services Web sécurisés.
- Pour la migration de projets Enterprise JavaBeans (EJB 1.1 vers EJB
2.1), des étapes manuelles sont requises. Pour plus de
détails, reportez-vous à la section Migration de projets EJB (EJB 1.1 vers EJB 2.1).
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.
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 :
- Cliquez deux fois sur le fichier webservices.xml pour ouvrir
l'éditeur de services Web.
- Sélectionnez l'onglet Configurations de liaison pour
modifier le fichier de liaison.
- 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.
- Sélectionnez l'onglet Extension pour modifier le
fichier d'extension.
- 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.
- Sauvegardez et quittez l'éditeur.
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.
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 :
- acknowledgeMode
- messageSelector
- destinationType
- subscriptionDurablity
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>
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 :
- Ouvrez le projet EJB dans l'explorateur de projets.
- 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.
- Cliquez sur l'onglet Bean pour ouvrir la page
Bean.
- Effectuez les opérations ci-dessous pour chaque bean géré par
message EJB 2.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.
- Dans la section Liaisons WebSphere, cliquez sur le bouton
Adaptateur JCA.
- Indiquez les propriétés de déploiement des liaisons :
- 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.
- 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.
- 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.
- Sauvegardez les modifications et fermez l'éditeur de descripteur
de déploiement.
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.
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.
- Les éléments suivants sont déplacés de l'objet
ResourceAdaptor vers l'objet OutboundResourceAdaptor :
- reauthenticationSupport
- transactionSupport
- Les éléments suivants ont été déplacés de l'objet
ResourceAdaptor vers l'objet ConnectionDefinition :
- managedConnectionFactoryClass
- connectionFactoryInterface
- connectionFactoryImplClass
- connectionInterface
- connectionImplClass
- L'objet outboundResourceAdaptor contient une liste de définitions
ConnectionDefinition. Par conséquent, ConnectionDefinition est
ajouté à la liste ConnectionDefinition se trouvant dans
OutboundResourceAdaptor.
- L'objet OutboundResourceAdaptor se trouve dans l'objet
ResourceAdaptor.
- L'objet AuthenticationMechanism a subi des modifications dans JCA
1.5 où l'élément customAuthMechType est remplacé par
authenticationMechanism et l'élément authenticationType est
remplacé par authenticationMechanism
- L'attribut de description de l'objet ResourceAdaptor est
remplacé par un objet de description où l'élément value est
affecté à la chaîne d'attributs de description dans l'objet
Description pour les objets suivants :
- SecurityPermission
- AuthenticationMechanism
- ConfigurationProperties
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 :
- servlets avec JAXR-RPC,
- des servlets avec SOAP direct et
- des beans session sans état.
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 :
- Descripteur de services Web
- Descripteur client de services Web
- Descripteur de mappage JAX-RPC
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.
- Descripteur de services Web (webservices.xml)
Le descripteur de déploiement webservices.xml se trouve dans des
projets Web et dans des projets EJB qui contiennent des services Web
J2EE. Les éléments <wsdl-port> et
<soap-header> contiennent tous deux des noms qualifiés et
leur contenu sera migré vers le format J2EE 1.4.
Par exemple, si <wsdl-port> est représenté de la
manière suivante avant la migration,
<wsdl-port>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBook</localpart>
</wsdl-port>
après la migration <wsdl-port> aura l'aspect
suivant :
<wsdl-port xmlns:pfx="http://addressbook.webservice">pfx:AddressBook</wsdl-port>
Le préfixe "pfx" est utilisé comme préfixe d'espace de nom
pour tous les noms qualifiés migrés.
- Descripteur client de services Web
(webservicesclient.xml)
Le descripteur de déploiement webservicesclient.xml se trouve
dans les projets Web J2EE 1.3, dans les projets EJB et les projets
client d'application qui contiennent des clients de service Web
J2EE. Lors de la migration de J2EE 1.3 vers 1.4, le
contenu de webservicesclient.xml est migré et déplacé vers le
descripteur de déploiement pour le projet. Le processus qui se
produit est le suivant :
- Pour les projets Web, tous les éléments
<service-ref> du fichier webserivcesclient.xml sont
déplacés sous l'élément <web-app> dans
web.xml.
- Pour les projets client d'application, tous les éléments
<service-ref> du fichier webservicesclient.xml sont
déplacés sous l'élément <application-client>
dans application-client.xml.
- Pour les projets EJB, tous les éléments
<service-ref> au sein d'un
élément<component-scoped-refs> du fichier
webserviceclient.xml sont déplacés sous l'élément
<enterprise-bean> correspondant dans
ejb-jar.xml.
- Le fichier webservicesclient.xml est supprimé.
Les éléments <service-qname> et
<soap-header> contiennent tous deux des noms qualifiés et
leur contenu sera migré vers le format J2EE 1.4. Par exemple,
si <service-qname> est représenté de la manière
suivante avant la migration,
<service-qname>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBookService</localpart>
</service-qname>
après la migration <service-qname> aura l'aspect
suivant :
<service-qname xmlns:pfx="http://addressbook.webservice">pfx:AddressBookService</service-qname>
Le préfixe "pfx" est utilisé comme préfixe d'espace de nom
pour tous les noms qualifiés migrés.
- Descripteur de mappage JAX-RPC
Les descripteurs de déploiement webservices.xml et
webservicesclient.xml peuvent tous deux faire référence à un
ou plusieurs descripteurs de déploiement de mappage JAX-RPC.
Dans le fichier webservices.xml, ces références se trouvent
dans l'élément <jaxrpc-mapping-file> sous chaque
élément <webservice-description>. Dans le
fichier webservicesclient.xml, ces références se trouvent dans
l'élément <jaxrpc-mapping-file> sous chaque
élément <service-ref>.
Lors de la migration de J2EE 1.3 vers 1.4, tous les
descripteurs de déploiement référencés dans webservices.xml
et webservicesclient.xml sont migrés. La migration inclut la
migration de tous les noms qualifiés vers le format J2EE 1.4 (pour
obtenir des exemples de noms qualifiés après la migration, reportez-vous
aux section relatives aux fichiers webservices.xml et
webservicesclient.xml).
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.
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.
- Conversion du projet EJB d'EJB 1.1
en EJB 2.x.
- Migration du code EJB à partir d'EJB
1.1 vers EJB 2.x.
- Migration des références d'EJB
1.1 définies par l'utilisateur vers les références
locales dans 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.
- Dans la vue Hiérarchie J2EE, cliquez avec le bouton droit de la souris
sur le projet 1.1 puis sélectionnez Migrer ->
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).
- L'assistant conserve l'héritage EJB 1.1 existant dans
le projet EJB 2.x.
- L'assistant migre les relations EJB 1.1 (propriétaire) vers
les relations EJB 2.x (standard) et effectue d'autres
opérations.
- 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.
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).
- 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.)
- Pour un bean CMP, créez une méthode getXXX et
setXXX abstraite pour la clé primaire.
- 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.
- Pour une méthode de localisation (finder) CMP 1.1, renvoyez
java.util.Collection au lieu de
java.util.Enumeration.
- 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.
- Mettez à jour le traitement des exceptions (comportement de la fonction
d'annulation) pour les exceptions ne concernant pas des applications
:
- Lancez javax.ejb.EJBException au lieu de
java.rmi.RemoteException pour signaler des exceptions
ne concernant pas des applications.
- Dans EJB 2.x et 1.1, toutes les exceptions ne concernant pas
des applications qui ont été lancées par l'instance se
traduisent par l'annulation de la transaction dans laquelle
l'instance est exécutée, et par l'élimination de
l'instance.
- Mettez à jour le traitement des exceptions (comportement de la fonction
d'annulation) pour les exceptions ne concernant pas des applications
:
- Dans EJB 2.x et 1.1, une exception d'application
n'oblige pas le conteneur à annuler automatiquement une
transaction.
- Dans EJB 1.1, le conteneur procède à l'annulation
uniquement si l'instance est appelée via la méthode
setRollbackOnly() sur son objet EJBContext.
- 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).
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.
- Supprimez les références éloignées d'EJB existantes dans
la page Références de l'éditeur de descripteur de
déploiement.
- Ajoutez une référence locale d'EJB dans la page
Références de l'éditeur de descripteur de déploiement.
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.
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.
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.
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 :
- Par défaut, le serveur cible est WebSphere Portal V5.0, si aucun
serveur cible n'est défini pour le projet.
- Le chemin de compilation du portlet est corrigé
- Une nature de projet de portlet est ajoutée.
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 :
- 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.
- A l'aide du bouton droit de la souris, cliquez sur le projet et
sélectionnez Exportation.
- Sélectionnez Fichier WAR et Exporter les fichiers
source puis cliquez surTerminer.
- Importez le fichier WAR de portlet :
- Dans les outils de portail de Rational Application Developer V6.0,
créez un projet de portlet vide.
- Sélectionnez Fichier -> Nouveau ->
Projet -> Portail -> Projet de portlet
ou Projet de portlet (JSR 168).
- Désélectionnez Création d'un portlet.
- Cliquez sur Afficher les propriétés avancées.
- Si vous importez un portlet WebSphere Portal 4.2, sélectionnez
2.2 en tant que version de servlet.
- Sélectionnez WebSphere Portal v5.0 comme serveur
cible et cliquez sur Terminer.
- Importez le fichier WAR dans ce nouveau projet de type portlet
vide.
- Sélectionnez Importer.
- Sélectionnez Fichier WAR et indiquez le fichier WAR
exporté (Exportation d'un projet dans un fichier WAR dans la version
précédente).
- Sélectionnez le nouveau projet de type portlet vide.
- Sélectionnez Remplacer les ressources existantes sans
avertissement.
- Ne sélectionnez pas Supprimer le projet après
remplacement.
- 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.
- 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.
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 :
- Migrez les projets de portlet Portal V4.2 vers les projets de
portlet Portal V5.x :
- Cliquez à l'aide du bouton droit de la souris sur le projet
d'application de portlet à migrer.
- Sélectionnez Propriétés -> API de
portlet pour ouvrir la page API de portlet.
- Dans le menu déroulant au niveau de l'API de portlet,
sélectionnez WebSphere Portal Version 5.x.
- 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.
- 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.
- Si le projet de type portlet migré est associé uniquement au projet
d'application d'entreprise, procédez comme suit :
- Fermez tous les éditeurs dans l'espace de travail.
- 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é.
- Sélectionnez Migrer -> Assistant de migration
J2EE et cliquez sur Suivant.
- Sélectionnez J2EE version 1.3 et WebSphere
Portal comme serveur cible.
- Cliquez sur Terminer.
- 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.
- Retirez le module du projet de type portlet migré du projet
d'application d'entreprise.
- Développez le projet d'application d'entreprise et
sélectionnez le descripteur de déploiement.
- Sélectionnez Ouvrir avec -> Editeur de
descripteur de déploiement.
- Sélectionnez l'onglet Module. Sur la page Module
de l'éditeur, sélectionnez le fichier WAR du projet de type portlet
migré.
- Cliquez sur Supprimer.
- Sélectionnez Fichier -> Sauvegarder pour
sauvegarder les modifications.
- Créez un projet d'application d'entreprise et ajoutez à ce
dernier le projet de type portlet.
- Sélectionnez Fichier -> Nouveau ->
Projet.
- Sélectionnez la case à cocher Afficher tous les
assistants.
- Développez J2EE et sélectionnez Projet
d'application d'entreprise.
- Renseignez la zone Nom du projet, sélectionnez J2EE
version 1.3 et WebSphere Portal comme serveur cible
puis cliquez sur Suivant.
- 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.
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 :
- 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.
- 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.
- Cliquez sur l'une des options suivantes :
- Oui pour exécuter la mise à jour automatiquement.
- Plus tard pour différer la mise à jour. Pour
mettre automatiquement à jour les ressources d'exécution après
avoir sélectionné Plus tard, vous devez fermer et rouvrir le
projet portlet et redémarrer le plan de travail avant de regénérer le
projet de portlet. Si vous avez désactivé les générations
automatiques, cliquez sur le projet de portlet à l'aide du bouton
droit de la souris et sélectionnez Générer un
projet.
- Jamais pour conserver les ressources d'exécution à
un niveau antérieur. Si vous sélectionnez Jamais et
que vous conservez volontairement les ressources d'exécution à un
niveau antérieur, le système ne vous invite plus à les mettre à
jour. Vous devrez migrer manuellement les ressources de projet si vous
en avez besoin ultérieurement.
- 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 :
- Importez le projet de portlet existant avec le contenu Faces dans un
espace de travail Rational Application Developer version
6.0.1.
- 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.
- 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.
- Cliquez sur Fonctions du projet Web et sélectionnez
Ajout de Faces Client Framework pour le projet de portlet, puis
cliquez sur OK.
- Pour chaque projet Faces à mettre à niveau, procédez comme suit
:
- 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
- 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.
- 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.
- 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>
- Supprimez le projet de portlet JSFP601.
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 :
- Les serveurs WebSphere Application Server V4.x ne sont plus des
environnements de test pris en charge. Toutefois, les applications de
niveau de spécification J2EE 1.2 peuvent toujours être
exportées et déployées manuellement pour le test sur des serveurs
V4.x distants.
- Le serveur WebSphere Application Server V6.0 a été ajouté
en tant qu'environnement de test installable. Il prend en charge
l'exécution des applications de niveau de spécification J2EE
1.4.
- L'environnement de test WebSphere Portal a été ajouté pour
le test des portails et des applications de portlet.
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