Une version PDF de ce guide est également disponible dans le répertoire pdf sur le CD-ROM du produit. Le répertoire pdf se trouve sur le CD-ROM VisualAge for Java, Professional Edition et le CD-ROM VisualAge for Java, Enterprise Edition, Additional Features.
Où trouver des informations supplémentaires sur VisualAge for Java ?
Le fichier ne contient aucune information détaillée sur les fonctions et composants particuliers de VisualAge for Java. Pour obtenir ce type d'information, reportez-vous aux notes d'éditions du produit, auxquelles vous pouvez accéder en sélectionnant Démarrage > Programmes > IBM VisualAge for Java pour Windows 4.0 > Notes d'édition. Pour obtenir ces notes d'éditions dans toutes les langues, reportez-vous au site Web à l'adresse suivante : http://www.ibm.com/vadd.
Ce fichier ne comprend également aucune information sur l'utilisation de VisualAge for Java. Pour plus d'informations sur l'utilisation de ce produit, reportez-vous au guide d'initiation et à l'aide en ligne. Une partie de l'aide en ligne est présentée sous forme de documents PDF pouvant être affichés et imprimés via Adobe Acrobat Reader (téléchargeable depuis http://www.adobe.com/). Les documents PDF ne sont pas tous disponibles dans toutes les langues. Ils se trouvent dans le répertoire pdf. Le répertoire pdf se trouve sur le CD-ROM VisualAge for Java, Professional Edition et le CD-ROM VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments). Si vous n'avez pas téléchargé la partie contenant les PDF, ce répertoire n'existe pas.
Pour connaître le contenu de chacun de ces fichiers, reportez-vous à l'index PDF (dans le Guide d'initiation). L'aide en ligne comporte également une section "Ressources Web" qui contient des liens vers les ressources VisualAge disponibles sur Internet.
Le site Web VisualAge Developer Domain (VADD) présente des articles techniques, des didacticiels, des exemples et une foire aux questions. Il permet également d'accéder facilement à l'assistance technique et aux mises à jour disponibles de VisualAge for Java. Sur ce site, vous pouvez télécharger des outils de développement VisualAge for Java, ainsi que des beans réutilisables, des assistants et des toolkits complémentaires qui vous aideront dans le développement d'applets et de servlets. L'adresse URL du site est http://www.ibm.com/vadd. Vous pouvez également utiliser ce site pour soumettre une demande d'ajout de fonctions dans les prochaines versions de VisualAge for Java.
Si vous vous êtes déjà abonné à VisualAge Developers Domain, il n'est pas nécessaire de se réabonner. Pour obtenir des informations et des mises à jour de code, vous pouvez utiliser votre ID et mot de passe en cours. Si vous être un nouvel utilisateur, localisez le numéro d'abonné situé sur la boîte (ou media kit) que vous avez reçue. Si vous avez acheté VisualAge for Java et qu'aucun numéro d'abonné ne vous a été attribué, contactez votre revendeur IBM.
La page d'accueil du produit VisualAge for Java se trouve à l'adresse URL suivante : http://www.ibm.com/software/ad/vajava.
Chapitre A : VisualAge for Java, Professional Edition
1.0 Conditions préalables
2.0 Installation
2.1 Installation de
VisualAge for Java, version 4.0
2.2
Installation ultérieure de composants supplémentaires
2.3
Remarques
sur l'installation sous Windows 2000
2.4 Installation d'IBM Developer Kit, Java Technology Edition, version 1.2.2
3.0 Migration depuis une
version antérieure de VisualAge for Java
3.1
Migratiion
à partir de VisualAge for Java, version 3.5 ou 3.5.3
3.2 Migration
à partir de la version 2.0, 3.0x ou 3.0x Early Adopters de VisualAge for Java
4.0 Problèmes et
restrictions connus
4.1 Problèmes et restrictions connus liés à l'installation
4.2 Problèmes et restrictions connus liés à la désinstallation
Chapitre B : VisualAge for Java, Enterprise Edition
1.0 Conditions préalables
1.1 Informations de configuration générales
1.2
Informations de configuration propres à chaque composant
2.0 Installation
2.1 Installation de
VisualAge for Java, version 4.0
2.2
Installation ultérieure de composants supplémentaires
2.3
Installation de clients coopératifs
VisualAge for Java
2.4 Installation
d'un client disposant d'un référentiel autonome
2.5 Remarques sur l'installation et l'utilisation
s'appliquant à Windows 2000
2.6 Installation du produit IBM Developer Kit, Java Technology
Edition, version 1.2.2
3.0
Migration
depuis une version antérieure de VisualAge of Java
3.1
Migration
d'un référentiel partagé à partir d'une version précédente de VisualAge for Java
4.0 Problèmes et restrictions connus
4.1
Problèmes et restrictions connus liés à
l'installation
4.2 Problèmes et restrictions connus liés à la désinstallation
Chapitre C : Serveur de référentiel coopératif (EMSRV)
1.0 Conditions préalables
1.1 Plateformes prises en charge
1.2 TCP/IP
1.3
Correctifs
Novell requis pour l'exécution d'EMSRV
1.4 Correctifs Solaris
requis pour l'exécution d'EMSRV sous Solaris
1.5 Systèmes de fichiers pris en charge
2.0 Installation
2.1 Installation d'EMSRV pour Windows
2.1.1 Installation d'EMSRV en tant que service dans le registre Windows
2.2 Installation d'EMSRV pour
NetWare
2.3 Installation
d'EMSRV pour OS/2 Warp
2.4 Installation d'EMSRV pour AIX
2.5 Installation d'EMSRV pour HP-UX ou Solaris
2.6 Installation d'EMSRV pour Linux
3.0 Migration
3.1
Migration de la version 6.x ou de la version 7.0 d'EMSRV vers la version 7.1
4.0 Préparation au développement coopératif
4.1 Préparation du serveur coopératif
4.2 Test d'une connexion client
4.3 Ajout d'utilisateurs à la liste des utilisateurs du référentiel
5.0 Problèmes et restrictions connus
5.1 Performances des
connexions réseau à faible largeur de bande et à délai d'attente
important
5.2 Nombre maximal
de connexions TCP/IP
5.3 Détection
des abandons de connexions inattendus
5.4 Cohabitation
des différentes versions d'EMSRV et de ses utilitaires
5.5 Restrictions applicables à PAM
5.6
Mots
de passe comportant des caractères non-ASCII inutilisables
pour l'authentification avec EMSRV
5.7
Caractères corrompus dans les menus et fenêtres lors de
l'exécution de NetWare japonais
5.8 EMADMIN
ne copie pas le répertoire des ressources stockées
Chapitre D : Informations de migration spécifiques aux composants
1.0 CICS Transaction Server * +
2.0 Beans Data Accesss
3.0 Data Access Builder * +
4.0 Environnement de
développement EJB+
5.0 Enterprise Access Builder et e-connectors +
6.0 Enterprise Toolkit pour AS/400 +
7.0 Enterprise Toolkit for OS/390 +
8.0 Enterprise Toolkit for Workstations
* +
9.0 Contrôle des
versions externes
10.0 Environnement de
développement IDL +
11.0 Environnement de développement intégré (IDE)
12.0 Environnement de développement JSP/Servlet
13.0 Assistant de migration *
14.0 Persistence Builder +
15.0 RMI Access Builder * +
16.0 Editeur de composition visuelle
17.0 Servlet Builder et lanceur de servlet * +
18.0 Classes Swing
19.0 XMI Toolkit +
* Ces composants ne sont pas pris en charge dans VisualAge for Java, version 4.0
Version Enterprise Edition uniquement
Chapitre E : Généralités
1.0 Traitement des ressources de projets et de la gestion des ressources
2.0 Migration depuis OS/2 et AIX
3.0
Nouvelles
restrictions liées à la sécurité dans J2SDK version 1.2.2
4.0 Nouvel outil de
contrôle de version externe (en remplacement de l'outil SCM
externe)
5.0 Utilisation des gestionnaires ORB tiers dans VisualAge for Java
6.0 Contenu du
CD-ROM Additional Features
Annexes
Annexe A : Comparaison des fonctions d'accès aux données
Cette édition de VisualAge for Java, version 4.0, requiert les composants matériels et logiciels suivants :
Si vous souhaitez exécuter Websphere Application Server en même temps que DB2 et VisualAge for Java, alors un minimum de 512 Mo est recommandé.
* Remarque : VisualAge for Java ne prend pas en charge la souris à roulette de défilement Logitech. Toute souris Logitech associée à un pilote remappant l'action de défilement vers la souris entraîne une erreur système lors des défilements.
Cette section comporte des informations relatives à l'installation de VisualAge for Java, version 4.0 Important : Si vous effectuez une migration à partir d'une version antérieure de VisualAge for Java, reportez-vous à la section 3.0 avant d'installer la version 4.0. Pour obtenir des informations spécifiques concernant l'installation sous Windows 2000, reportez-vous à la section 2.3.
Pour obtenir des informations relatives aux problèmes et restrictions détectés récemment, reportez-vous également au fichier README (disponible dans le répertoire README du CD-ROM).
A.2.1 Installation de VisualAge for Java, version 4.0
Avant d'installer le produit, vérifiez les points suivants :
Si vous voulez installer VisualAge for Java sous Windows, Millennium Edition, vous serez invité à augmenter l'espace de l'environnement. La procédure décrite ci-dessous doit être exécutée avant l'installation du système d'aide VisualAge for Java qui, à défaut ne fonctionnerait pas correctement. Pour augmenter l'espace de l'environnement, procédez comme suit :
A.2.1.1 Installation de VisualAge for Java, version 4.0 à partir du CD-ROM du produit
Installation en mode silencieux
Pour installer VisualAge for Java, version 4.0 en mode silencieux,
exécutez la commande suivante à partir du répertoire ivj40\setup :
setup /s /v/qn
VisualAge for Java sera installé automatiquement dans le répertoire par défaut c:\Program Files\IBM\VisualAge for Java.
Pour lancer l'installation en mode silencieux dans un autre répertoire (d:\IBMVJava40, par exemple), exécutez la commande suivante à partir du répertoire ivj40\setup :
setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"
où d:\IBMVJava40 correspond au répertoire dans lequel vous voulez effectuer l'installation.
A.2.1.1.1 Installation de Distributed Debugger à
partir du CD-ROM du produit
Si vous avez l'intention de déboguer des classes développées
en dehors de l'environnement IDE VisualAge for Java ou de
déboguer des programmes s'exécutant sur un système
distinct, vous devez installer Distributed Debugger. Distributed
Debugger est pris en charge par les systèmes d'exploitation
suivants : Windows, AIX, OS/2, HP-UX, Solaris, Linux
et Linux/390. Vous trouverez ci-après les instructions d'installation
à suivre pour chaque système d'exploitation. Tous les fichiers de
Distributed Debugger se trouvent
dans le répertoire Debugger du CD-ROM du produit.
Distributed Debugger pour Windows
Distributed Debugger pour OS/2
Suivez les instructions du fichier README_install.txt disponible dans le sous-répertoire Debugger\OS2 sur le CD-ROM du produit.Distributed Debugger pour HP-UX
Composant prérequis :
Java version 1.3 est requis pour l'installation et le débogage de Java.
Distributed Debugger pour Linux
Avec l'ID utilisateur root, entrez la commande suivante pour installer le débogueur : rpm -Uvh DERJPICL-9-1.i386.rpmDistributed Debugger pour Linux/390
Avec l'ID utilisateur root, entrez la commande suivante pour installer le débogueur : rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger pour OS/390
A.2.1.2 Installation à partir de l'image électronique de VisualAge for
Java, version 4.0
Pour réduire le temps de téléchargement, l'image électronique de
VisualAge for Java, Professional Edition pour Windows, version 4.0 se
divise en plusieurs parties.
A.2.1.2.1 IDE
Il existe neuf éléments téléchargeables pour l'environnement
de développement intégré. Ils correspondent
tous à des archives qui s'extraient automatiquement. Vous devez installer les deux premiers ; les autres sont
facultatifs. Reportez-vous à la liste ci-dessous pour des détails relatifs au contenu de chaque archive.
Une fois que vous avez téléchargé les deux premières archives et les fichiers facultatifs souhaités, exécutez chaque archive d'extraction automatique et vérifiez que l'extraction de chacune d'entre elles s'effectue dans le même répertoire temporaire. Une fois que tous les fichiers ont été extraits, accédez au répertoire temporaire et exécutez setup.exe. Suivez les instructions à l'écran et lancez l'IDE.
Si vous avez l'intention de travailler dans une autre langue que l'anglais, vous devez télécharger l'élément adéquat et exécuter l'archive auto-extractible de votre langue avant d'exécuter setup.exe. Il est impossible de modifier ou d'ajouter une langue une fois que VisualAge for Java a été installé.
Si vous utilisez une image électronique de VisualAge for Java, vous ne pouvez pas utiliser la boîte de dialogue Ajout/Suppression de programmes (Démarrer > Paramètres >Panneau de configuration > Ajout/Suppression de programmes) pour installer d'autres composants VisualAge for Java après l'installation initiale. Si vous l'utilisez, vous recevrez un message d'erreur et vous ne pourrez pas installer d'autres composants. Vous devez exécuter setup.exe à partir du chemin utilisé pour extraire les composants téléchargés pour ajouter de nouveaux composants à VisualAge for Java.
La section ci-dessous est une description de chaque élément d'archive.
A.2.1.2.2
Distributed Debugger
Il existe une partie que vous pouvez télécharger
séparément pour chaque système d'exploitation pris en charge par
Distributed Debugger. Si vous avez l'intention de déboguer des
classes développées en dehors de l'environnement IDE VisualAge
for Java ou de déboguer des programmes s'exécutant sur un système
distinct, vous devez télécharger et installer Distributed Debugger.
Vous trouverez ci-après les instructions d'installation à suivre pour
chaque système d'exploitation.
Ces instructions et des informations sur l'accord de licence sont
également disponibles dans le fichier readme.txt file inclus
dans chaque élément.
VisualAge for Java - Distributed Debugger pour Windows contient l'interface utilisateur et le moteur de débogage pour Windows. Cet élément est une archive qui s'extrait automatiquement. Pour l'installer, procédez comme suit :
VisualAge for Java - Distributed Debugger pour HP-UX contient le moteur de débogage pour HP-UX.
Composant prérequis :
Java version 1.3 est requis pour l'installation et le débogage de Java.
Pour l'installer, décompactez le fichier et suivez les instructions ci-dessous :
VisualAge for Java - Distributed Debugger pour Linux contient le moteur de débogage pour Linux. Pour l'installer, décompactez le fichier et suivez les instructions ci-dessous.
Avec l'ID utilisateur root, entrez la commande suivante : rpm -Uvh DERJPICL-9-1.i386.rpmVisualAge for Java - Distributed Debugger pour Linux/390 contient le moteur de débogage pour Linux/390. Pour l'installer, décompactez le fichier et suivez les instructions ci-dessous.
Avec l'ID utilisateur root, entrez la commande suivante : rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger pour OS/390
A.2.1.2.3 IBM Developer Kit 1.2.2
VisualAge for Java - IBM Developer Kit 1.2.2 comporte IBM
Developer Kit, Java Technology Edition, v 1.2.2,
PTF 9, pour la plateforme Windows. Il s'agit d'une archive
auto-extractible. Pour procéder à l'installation,
exécutez ce fichier, qui se lancera automatiquement une fois extrait de l'archive, et suivez les instructions.
A.2.2 Installation ultérieure de composants supplémentaires
Pour installer des composants VisualAge for Java supplémentaires après l'installation, insérez le CD-ROM dans le lecteur, sélectionnez l'option d'installation de VisualAge for Java, et choisissez Modifier dans l'écran de maintenance logicielle. Si l'autoexécution du CD à l'insertion est désactivée sur votre système, vous devrez préalablement lancer setup.exe à partir du répertoire racine du CD-ROM. Si vous disposez d'une version électronique de VisualAge for Java, vous devez également lancer setup.exe manuellement, puis suivre la même procédure.
Tous les composants sont alors affichés dans la fenêtre d'édition des fonctionnalités avec une indication concernant leur état d'installation en cours. Une croix 'X' rouge indique qu'un composant n'est pas installé actuellement. Vous pouvez sélectionner ces composants pour les installer. Ne sélectionnez pas les composants qui ne sont pas marqués d'un 'X' rouge ; ils ont déjà été installés.
Vous ne pouvez pas installer une deuxième instance de VisualAge for Java, version 4.0. Vous ne pouvez changer la langue d'installation sans avoir préalablement désinstallé le produit.
A.2.3 Remarques sur l'installation sous Windows 2000
Cette version de VisualAge for Java offre une prise en charge de tolérance (conformément à la description de Microsoft) pour Windows 2000.
Le répertoire d'installation par défaut est <Program Files>\IBM\VisualAge for Java. Par défaut, pour Windows 2000, l'installation dans <Program Files> ne peut être effectuée que par les utilisateurs ayant des droits Administrateurs et Standard (Power). Les utilisateurs usuels (Restricted) ne peuvent pas écrire de données dans cet emplacement.
En raison de la conception actuelle de VisualAge for Java, si le produit est installé à cet endroit et qu'il doit être utilisé par un utilisateur régulier (avec accès restreint), vous devez modifier les paramètres de sécurité pour le répertoire IBM ou IBM\VisualAge for Java situé sous <Program Files> afin d'autoriser l'accès en écriture pour les utilisateurs réguliers. A défaut de cette modification, l'utilisateur provoquera des échecs lorsqu'il essaiera de démarrer l'environnement IDE.
A.2.4 Installation du produit IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9
Si vous avez installé VisualAge for Java à partir du CD du produit, vous devez exécuter install.exe à partir du répertoire IBM Developer Kit pour installer le produit IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9. Ce répertoire se trouve sur le CD du produit. Si vous disposez d'une version électronique de VisualAge for Java, ce répertoire se trouve dans votre répertoire temporaire (dans lequel vous avez extrait vos éléments). Cependant, il n'est pas nécessaire d'exécuter install.exe, car le programme d'installation est automatiquement lancé une fois que vous l'avez extrait à partir de l'archive IBM Developer Kit téléchargée.
Pour plus d'informations sur IBM Developer Kit, reportez-vous au fichier README disponible dans le répertoire IBM Developer Kit.
Avant de lancer le processus de migration, reportez-vous au chapitre D et au chapitre E pour obtenir des informations de migration générales ou propres à chaque composant.
Vous pouvez migrer automatiquement à partir de la version 3.5 ou 3.5.3. La version 4.0 est installée au dessus de l'une ou l'autre de ces versions. Pour plus d'informations sur la migration depuis VisualAge for Java, version 3.5 ou 3.5.3, reportez-vous à la section 3.1.
Vous pouvez effectuer une migration manuelle depuis 3.0x, Early Adopters. Pour plus d'informations sur la migration depuis VisualAge for Java, 3.0x, Early Adopters, reportez-vous à la section 3.2.
Si vous utilisez actuellement la version 2.0, 3.0 ou 3.0.2 de VisualAge for Java avec prise en charge du JDK 1.1.x, vous ne pouvez pas effectuer de migration automatique de VisualAge for Java, version 4.0. Ces versions de VisualAge for Java sont compatibles avec VisualAge for Java, version 4.0. Reportez-vous à la section 3.2 pour des informations relatives à la migration du contenu de votre référentiel et des fichiers de ressources depuis la version 2.0 ou 3.0x de VisualAge for Java.
Vous ne pouvez pas effectuer de migration de VisualAge for Java, version 3.5, Entry Enterprise Edition ou VisualAge for Java, version 3.5 ou 3.5.3 Enterprise Edition vers VisualAge for Java, version 4.0, Professional Edition. Vous devez alors effectuer une migration vers la version 4.0, Enterprise Edition.
Remarque : Lorsque vous effectuez une migration de VisualAge for Java, version 3.5 ou 3.5.3 vers VisualAge for Java version 4.0, vous pouvez avoir l'impression que la procédure d'installation est bloquée. Cette impression de blocage est due à l'exécution de la fonction "DoCosting" qui compare les versions des fichiers 3.5 ou 3.5.3 à celles des fichiers 4.0 et qui peut prendre jusqu'à 3 minutes.
A.3.1 Migration à partir de la version 3.5 ou 3.5.3
La migration depuis VisualAge for Java, version 3.5 or 3.5.3 est automatique. Le programme d'installation de la version 4.0 met automatiquement à niveau un produit installé de la version 3.5 ou 3.5.3 vers la version 4.0.
Migration automatique
Si l'installation échoue, vous devez faire migrer manuellement vos données utilisateur. Vous devez également les faire migrer manuellement si l'environnement IDE ne démarre pas ou qu'une erreur se produit lors de la migration automatique.
Migration manuelle
A.3.2 Migration à partir de la version 2.0, 3.0x ou 3.0x Early Adopters de VisualAge for Java
Vous pouvez faire migrer manuellement le contenu de votre référentiel et de vos fichiers de ressources depuis la version 2.0, 3.0x ou 3.0x Early Adopters de VisualAge for Java. Pour plus d'informations sur la réparation des dommages éventuels, reportez-vous au fichier d'aide en ligne "Correction des références de classe ou de package".
Vous n'avez pas besoin de désinstaller la version 2.0, 3.0x ou 3.0x Early Adopters ; elles peuvent coexister avec VisualAge for Java, version 4.0.
Suivez la procédure ci-après avant de désinstaller la version 2.0, 3.0x ou 3.0x Early Adopters si vous souhaitez importer le référentiel et les fichiers de ressources de la version 2.0, 3.0x ou 3.0x Early Adopters de Environment for Java 2 Platform, Standard Edition 1.2 dans la version 4.0. Si vous ne désinstallez pas la version 2.0, 3.0x ou 3.0x Early Adopters, il n'est pas nécessaire d'effectuer les étapes 2, 3, 4 et 8 mais vous devez tout de même effectuer les autres étapes.
Pour obtenir des informations relatives aux problèmes et restrictions détectés récemment, reportez-vous également au fichier README (disponible dans le répertoire README du CD-ROM).
A.4.1 Problèmes et restrictions connus liés à l'installation
Vous trouverez ci-après une liste de points à prendre en considération lors de l'installation.
A.4.1.1 Restrictions relatives à l'unité de disque
A.4.1.2 Autorisation utilisateur
A.4.1.3 Remarques concernant TCP/IP
Ces options de configuration s'appliqueront à toutes les cartes TCP/IP, même si elles ont été modifiées uniquement pour la carte choisie. Vous ne pourrez utiliser ni la carte de réseau local ni la carte d'accès distant sans reconfigurer le système.
Les propriétés TCP/IP d'accès réseau à distance doivent être configurées conformément aux instructions de votre fournisseur d'accès Internet. Les propriétés TCP/IP d'accès réseau à distance remplaceront les propriétés TCP/IP de la carte d'accès distant configurées via l'icône Réseau dans le Panneau de configuration Windows 98 ou Windows 2000. Les paramètres seront remplacés uniquement si les propriétés TCP/IP de la carte d'accès distant sont configurées comme indiqué ci-dessus. Vous ne devez pas activer le serveur DNS dans les propriétés TCP/IP de la carte d'accès distant, ni y définir une adresse IP, car ces paramètres auraient une incidence sur la configuration d'accès réseau à distance du fournisseur d'accès Internet.
Dans le cas de Windows NT 4.0, les deux modes de configuration TCP/IP décrits ci-dessus peuvent être utilisés indifféremment. Si vous utilisez un poste autonome, vous pouvez également activer la carte Microsoft Loopback sans faire appel aux deux autres cartes.
A.4.1.4 Extension du shell (Windows NT)
Si vous recevez un message indiquant que le programme d'installation a détecté une extension du shell pour Windows NT, l'installation ne peut pas se poursuivre. Procédez alors comme suit :
A.4.1.5 Reprise en cas d'échec de l'installation
En cas d'échec de votre installation, vous devez supprimer tous les fichiers de la version 4.0 qui ont été installés. Si le répertoire que vous destiniez à l'installation de VisualAge for Java est vide, cela signifie que le processus d'installation s'est annulé et a supprimé tous les fichiers déjà installés. Vous pouvez supprimer le répertoire vide si vous le souhaitez, mais ce n'est pas nécessaire. Toutefois, si ce répertoire contient des fichiers, vous devez redémarrer le processus d'installation. Il s'ouvre alors en mode maintenance et vous devez choisir de supprimer votre installation partielle de la version 4.0 avant d'essayer d'installer le produit de nouveau.
Vous devez également supprimer l'entrée de registre suivante :
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java pour Windows
Procédez comme suit :
Si des fichiers NetQuestion ont été installés avant l'échec de l'installation, vous devez également les supprimer.
IMNINSTSRV=C:\imnnq_nt
L'emplacement du répertoire NetQuestion peut apparaître différemment, en fonction de l'unité d'installation de VisualAge for Java et du système d'exploitation utilisé. Si la variable est définie (vous disposez de l'emplacement sur lequel NetQuestion est installé), passez à l'étape 2.
Si vous recevez un message d'erreur indiquant par exemple que "la variable d'environnement imninstsrv n'est pas définie", alors aucun fichier NetQuestion n'a été installé ou l'installation NetQuestion n'a pas abouti. Si cela se produit, sélectionnez Démarrer > Rechercher > Fichiers ou dossiers et recherchez le fichier vahelp.cfg. Si vous trouvez ce fichier dans un répertoire dont le nom commence par "imnnq" (imnnq_NT ou imnnq_98, par exemple), supprimez-le. Il n'est pas nécessaire d'effectuer les étapes 2 et 3.
Cette opération permet de supprimer les fichiers NetQuestion que VisualAge for Java a installés. Cette opération n'a aucune influence sur les fichiers NetQuestion installés par d'autres produits (DB2, par exemple).
Effectuez une sauvegarde de votre référentiel et de vos fichiers de ressources si cela n'a pas déjà été fait. Pour plus d'informations sur la procédure à suivre, reportez-vous au chapitre A, Section 3.1.
Après avoir effectué ces opérations, réinitialisez le système et réinstallez le produit. Si l'aide ne fonctionne pas une fois que vous avez réinstallé VisualAge for Java, reportez-vous au Guide de résolution des incidents pour obtenir plus d'informations sur la reprise après l'apparition d'incidents liés au système d'aide. Le Guide de résolution des incidents (trshoot.htm) se trouve sur le CD-ROM VisualAge for Java, Professional Edition et sur le CD-ROM VisualAge for Java, Enterprise Edition, Additional Features. A l'issue de l'installation de VisualAge for Java, il est stocké sur X:\IBMVJava, X:\IBMVJava étant le répertoire d'installation de VisualAge for Java.
A.4.1.6 Erreurs liées au programme d'installation Windows
Vous trouverez ci-après la liste des erreurs à prendre en considération lors de l'installation sous Windows.
Erreur 1603 (Windows NT 4.0 uniquement)
Si vous recevez le message 1603 lors de l'installation de VisualAge for Java, cela signifie que le programme d'installation Windows Installer n'est pas parvenu à s'initialiser et que l'installation ne peut pas se poursuivre.
Certains produits (tels que VisualCafe de Symantec) copient automatiquement un fichier appelé sfc.dll lors de leurs installations sous Windows. Ce fichier est uniquement copié sous Windows 2000 où le programme d'installation Windows l'appelle pour des raisons de sécurité.
Si un fichier de ce nom figure dans la section PATH de Windows NT 4.0, le programme d'installation Windows tente de le charger, même si le fichier ne s'applique qu'à Windows 2000. A ce stade, le programme d'installation Windows échoue.
Pour contourner ce problème, procédez comme suit :
Erreur irrémédiable LoadLibrary()
L'erreur irrémédiable LoadLibrary() se produit lorsque certains noyaux d'installation VisualAge for Java (IKernels) n'ont pas été correctement enregistrés par le programme d'installation Windows. Pour contourner ce problème, vous devez supprimer le répertoire InstallShield où résident les fichiers IKernal, puis réinstaller VisualAge for Java en suivant les étapes suivantes :
Erreur 1631 ou erreur interne 2755 (Windows NT 4.0 uniquement)
Si vous installez VisualAge for Java sous Windows NT 4.0, om est possible que vous receviez l'un des messages d'erreur suivants :
Si vous recevez l'un de ces messages d'erreur, il se peut que vos clés de registre soient associées à des valeurs "null". Lors de l'installation de VisualAge for Java, le fichier userenv.dll tente d'analyser plusieurs clés de registre. Si l'une d'entre elles comportent une valeur "null", la procédure d'installation échoue et l'un des messages indiqués ci-dessus s'affiche.
Pour contourner ce problème, vous devez supprimer ou modifier les variables d'environnement "null" (en remplaçant la valeur "null" par une valeur valide) avant d'installer VisualAge for Java. Une fois que VisualAge for Java est installé, vous pouvez rétablir les valeurs d'origine.
Attention : Supprimez ou modifiez les variables null avec prudence. Vous devez étudier l'effet de leur suppression ou de leur modification avant d'effectuer l'opération.
Erreurs internes 2381, 1303, 1310, 1313 (Windows NT uniquement)
Si vous tentez d'installer VisualAge for Java et que l'une des conditions énoncées ci-dessous est vraie :
il est possible que vous receviez l'un des messages d'erreur suivants :
Cet incident se produit lorsque l'utilisateur ne dispose que de droits en lecture sur les dossiers suivants :
\Program Files\IBM\VisualAge for Java
\WinNT\Installer
Pour résoudre cet incident, assurez-vous que vous disposez de tous les droits requis sur les unités et les répertoires. Pour ce faire, procédez comme suit :
Erreur interne 2735 : Démarrage du moteur
Si vous recevez l'erreur 2735, effectuez les opérations ci-dessous :
Erreur 1606/Erreur interne 2707
Si vous recevez le message d'erreur suivant, il se peut que la valeur du fichier de registre Outils d'administration (Commun) soit incorrecte :
Erreur 1606. Impossible d'accéder à l'emplacement réseau
\Profiles\AllUsers\StartMenu\Programs\Administrative Tools\.
Erreur interne 2707. INSTALLDIR.
Vous devez modifier la valeur du fichier de registre Outils d'administration (Commun) pour pouvoir installer VisualAge for Java. Pour ce faire, procédez comme suit :
A.4.2 Problèmes et restrictions connus liés à la désinstallation
Vous trouverez ci-après une liste des points à prendre en considération lors de la désinstallation de VisualAge for Java.
A.4.2.1 Espace disque
L'unité de disque système Windows doit comporter au moins 2 Mo d'espace libre ; la variable d'environnement TEMP ou TMP doit pointer vers un répertoire temporaire valide doté de 5 Mo d'espace libre au minimum.
A.4.2.2 Désinstallation de Distributed Debugger
Si vous avez installé Distributed Debugger lors de l'installation de VisualAge for Java, vous devez désinstaller VisualAge for Java avant de désinstaller Distributed Debugger. Une fois la désinstallation de VisualAge for Java terminée, vous pouvez désinstaller Distributed Debugger en allant dans son répertoire d'installation et en exécutant le programme de désinstallation.
Si vous avez désinstallé VisualAge for Java et que vous ne parvenez pas à désinstaller Distributed Debugger, vous devez supprimer la clé de registre suivante :
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
Ensuite, essayez de nouveau de désinstaller Debugger. NE SUIVEZ PAS cette procédure si vous utilisez Distributed Debugger avec d'autres produits car vous ne pourrez plus utiliser le débogueur après avoir supprimé la clé de registre.
Procédez comme suit :
En outre, attribuez la valeur 1 à la clé de registre suivante :
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount
A.4.2.3 Variables d'environnement (Windows 98)
Lorsque vous désinstallez VisualAge for Java sous Windows 98, certaines entrées d'environnement peuvent demeurer dans le fichier autoexec.bat. Bien que ces entrées ne génèrent habituellement aucun incident, deux problèmes peuvent se poser si vous désinstallez et réinstallez plusieurs fois le produit. Des conflits entre les instructions PATH peuvent empêcher le bon fonctionnement de l'aide en ligne, ou ces instructions risquent d'être trop longues et de faire échouer la réinstallation du produit.
Pour résoudre ces problèmes :
A.4.2.4 Désinstallation de NetQuestion
Lorsque vous désinstallez VisualAge for Java, il est possible que NetQuestion ne soit pas désinstallé. Des problèmes peuvent survenir si NetQuestion n'est pas désinstallé et que vous essayez ultérieurement de réinstaller le produit.
Pour supprimer les fichiers NetQuestion installés par VisualAge for Java, suivez la procédure ci-après. Cette opération n'a aucune influence sur les fichiers NetQuestion installés par d'autres produits (DB2, par exemple).
IMNINSTSRV=C:\imnnq_nt
L'emplacement du répertoire NetQuestion peut apparaître différemment, en fonction de l'unité d'installation de VisualAge for Java et du système d'exploitation utilisé. Si vous recevez un message d'erreur indiquant par exemple que "la variable d'environnement imninstsrv n'est pas définie", tous les fichiers NetQuestion ont été désinstallés.
Vous supprimez ainsi les fichiers NetQuestion que VisualAge for Java a installés.
Si vous réinstallez ultérieurement VisualAge for Java et que le système d'aide ne fonctionne pas, reportez-vous au Guide de résolution des incidents pour obtenir plus d'informations sur la reprise après un dysfonctionnement du système d'aide. Le Guide de résolution des incidents (trshoot.htm) se trouve sur le CD-ROM VisualAge for Java, Professional Edition et sur le CD-ROM VisualAge for Java, Enterprise Edition, Additional Features. A l'issue de l'installation de VisualAge for Java, il est stocké sur X:\IBMVJava, X:\IBMVJava étant le répertoire d'installation de VisualAge for Java.
B.1.1 Informations de configuration générales
Cette édition de VisualAge for Java, version 4.0, requiert les composants matériels et logiciels suivants :
Si vous souhaitez exécuter Websphere Application Server en même temps que DB2 et VisualAge for Java, alors un minimum de 512 Mo est recommandé.
Vous devez utiliser EMSRV, version 7.1, si vous travaillez dans un environnement coopératif. Pour plus d'informations sur la migration de la version 6.x ou 7.0 vers la version 7.1, reportez-vous au chapitre C.
* Remarque : VisualAge for Java ne prend pas en charge la souris à roulette de défilement Logitech. Toute souris Logitech associée à un pilote remappant l'action de défilement vers la souris entraîne une erreur système lors des défilements.
B.1.2 Informations de configuration propres à chaque composant
Des exigences spécifiques s'appliquent à certains composants :
Sous Workstations, le client NFS Maestro pour Windows NT ou Windows 2000. Pour le client NFS sous Windows NT, vous devez effectuer un montage binaire du répertoire HFS dans lequel seront exportés les fichiers classe.
- IMS Connect v1.1 et IMS version 7 (recommandé) ou
- IMS Connect v1.1 et IMS version 5.1 ou 6.1
Cette section comporte des informations relatives à l'installation de VisualAge for Java, version 4.0. Important : Si vous effectuez une migration à partir d'une version précédente de VisualAge for Java, reportez-vous à la section 3.0 ci-dessous avant d'installer VisualAge for Java, version 4.0. Pour obtenir des informations spécifiques concernant l'installation sous Windows 2000, reportez-vous à la section 2.5.
Pour obtenir des informations relatives aux problèmes et restrictions détectés récemment, reportez-vous également au README (figurant dans le répertoire racine du CD).
Important : En raison d'une limitation du support du système de fichiers du CD (CDFS) sous Windows 98, l'installation de certains fichiers de connecteurs e-business à partir du CD peut échouer et générer un ou plusieurs des messages d'erreur ci-après, suivant les connecteurs sélectionnés.
Les fichiers non installés sont conservés dans un fichier zip (econnfix.zip) situé à la racine du CD du produit. Si vous installez VisualAge for Java sous Windows 98 et que vous recevez l'un des messages précédents, vous devez dézipper econnfix.zip dans le répertoire d'installation du produit (par exemple, à l'aide de la commande unzip econnfix.zip -d c:\Program Files\IBM\VisualAge for Java\, c:\Program Files\IBM\VisualAge for Java\ correspondant au répertoire d'installation). Une fois ces fichiers en place, les connecteurs fonctionneront correctement.
B.2.1 Installation de VisualAge for Java, version 4.0, Enterprise Edition
Avant d'installer le produit, vérifiez les points suivants :
Si vous voulez installer VisualAge for Java sous Windows, Millennium Edition, vous serez invité à augmenter l'espace de l'environnement. La procédure décrite ci-dessous doit être exécutée avant l'installation du système d'aide VisualAge for Java qui, à défaut ne fonctionnerait pas correctement. Pour augmenter l'espace de l'environnement, procédez comme suit :
Suivez les instructions ci-dessous, que vous installiez des clients coopératifs VisualAge for Java ou un client possédant un référentiel autonome. Pour plus d'informations sur l'installation d'un client coopératif, reportez-vous à la section 2.3 et pour plus d'informations sur l'installation d'un référentiel local, reportez-vous à la section 2.4.
B.2.1.1 Installation de VisualAge for Java, version 4.0 à partir du CD-ROM du produit
Installation en mode silencieux
Pour installer VisualAge for Java, version 4.0 en mode silencieux, exécutez
la commande suivante à partir du répertoire ivj40\setup :
setup /s /v/qn
VisualAge for Java sera installé automatiquement dans le répertoire par défaut c:\Program Files\IBM\VisualAge for Java.
Pour lancer l'installation en mode silencieux dans un autre répertoire (d:\IBMVJava40, par exemple), exécutez la commande suivante à partir du répertoire ivj40\setup :
setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"
où d:\IBMVJava40 correspond au répertoire dans lequel vous voulez effectuer l'installation.
Remarque : Vous ne pouvez pas établir de connexion à un référentiel partagé lorsque vous installez VisualAge for Java en mode silencieux. Lorsque vous sélectionnez ce mode d'installation, vous ne pouvez vous connecter qu'à un référentiel local. Si vous voulez effectuer une installation silencieuse et que vous travaillez toujours dans un environnement coopératif, vous devez effectuer une installation locale puis vous connecter au référentiel partagé après avoir installé le produit et avoir démarré l'environnement IDE. Reportez-vous au fichier team.pdf dans le répertoire pdf pour effectuer une installation en local qui permet de travailler dans un environnement coopératif. Le répertoire pdf se trouve sur le CD-ROM VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments). Si vous n'avez pas téléchargé la partie contenant les PDF, ce répertoire n'existe pas.
B.2.1.1.1 Installation de Distributed à partir du
CD-ROM du produit
Si vous avez l'intention de déboguer des classes développées en
dehors de l'environnement IDE VisualAge for Java ou de déboguer
des programmes s'exécutant sur un système
distinct, vous devez installer Distributed Debugger. Distributed
Debugger est pris en charge par les systèmes d'exploitation
suivants : Windows, AIX, OS/2, HP-UX, Solaris, Linux
et Linux/390. Vous trouverez ci-après les instructions d'installation
à suivre pour chaque système d'exploitation. Tous les fichiers de
Distributed Debugger se trouvent sur le CD-ROM Additional Features.
Distributed Debugger pour Windows
Distributed Debugger pour OS/2
Suivez les instructions du fichier README_install.txt disponible dans le sous-répertoire Debugger\OS2 sur le CD-ROM Additional Features.Distributed Debugger pour HP-UX
Composant prérequis :
Java version 1.3 est requis pour l'installation et le débogage de Java.
Distributed Debugger pour Linux
Avec l'ID utilisateur root, entrez la commande suivante pour installer le débogueur : rpm -Uvh DERJPICL-9-1.i386.rpmDistributed Debugger pour Linux/390
Avec l'ID utilisateur root, entrez la commande suivante pour installer le débogueur : rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger pour OS/390
B.2.1.1.2 Installation de la version bêta des composants J2EE
Cette version de VisualAge for Java inclut une version bêta de
plusieurs composants de la plateforme Java 2, Enterprise Edition
(J2EE). Sun
Microsystems Inc. n'a pas encore publiée officiellement ces
composants. Cette version de VisualAge for Java comporte la version bêta des
composants J2EE suivants :
Les composants bêta se trouvent dans le sous-répertoire extras\BetaJ2EEConnectors du CD-ROM Additional Features. Pour utiliser ces composants bêta, reportez-vous au fichier README stocké dans le répertoire BetaJ2EEConnectors pour connaître les instructions d'installation.
B.2.1.2. Installation à partir de l'image électronique de VisualAge for Java, version 4.0
Pour réduire le temps de téléchargement, l'image électronique de VisualAge
for Java, Enterprise Edition pour Windows, version 4.0 se divise en plusieurs
parties.
B.2.1.2.1
Environnement de développement intégré (IDE)
Il existe quatorze éléments téléchargeables pour
l'environnement de développement intégré. Ils correspondent tous à
des archives auto-extractibles. Vous devez installer les deux premiers ; les autres sont
facultatifs. Reportez-vous à la liste ci-dessous pour des détails relatifs au contenu de chaque archive.
Une fois que vous avez téléchargé les deux premières archives et les fichiers facultatifs souhaités, exécutez chaque archive d'extraction automatique et vérifiez que l'extraction de chacune d'entre elles s'effectue dans le même répertoire temporaire. Une fois que tous les éléments ont été extraits, accédez au répertoire temporaire et exécutez setup.exe. Suivez les instructions à l'écran et lancez l'IDE.
Si vous avez l'intention de travailler dans une autre langue que l'anglais, vous devez télécharger l'élément adéquat et exécuter l'archive auto-extractible de votre langue avant d'exécuter setup.exe. Il est impossible de modifier ou d'ajouter une langue une fois que VisualAge for Java a été installé.
Si vous utilisez une image électronique de VisualAge for Java, vous ne pouvez pas utiliser la boîte de dialogue Ajout/Suppression de programmes (Démarrer > Paramètres >Panneau de configuration > Ajout/Suppression de programmes) pour installer d'autres composants VisualAge for Java après l'installation initiale. Si vous l'utilisez, vous recevrez un message d'erreur et vous ne pourrez pas installer d'autres composants. Vous devez exécuter setup.exe à partir du chemin utilisé pour extraire les composants téléchargés pour ajouter de nouveaux composants à VisualAge for Java.
La section ci-dessous est une description de chaque élément.
B.2.1.2.2. Distributed Debugger
Il existe un module que vous pouvez télécharger
séparément pour chaque système d'exploitation pris en charge par
Distributed Debugger. Si vous avez l'intention de déboguer des
classes développées en dehors de l'environnement IDE VisualAge
for Java ou de déboguer des programmes s'exécutant sur un système
distinct, vous devez télécharger et installer Distributed Debugger.
Vous trouverez ci-après les instructions d'installation à suivre pour
chaque système d'exploitation. Ces instructions et des informations sur l'accord de licence sont
également disponibles dans le fichier readme-1st.txt file inclus
dans chaque élément.
VisualAge for Java - Distributed Debugger pour Windows contient l'interface utilisateur et le moteur de débogage pour Windows. Cet élément est une archive qui s'extrait automatiquement. Pour l'installer, procédez comme suit :
VisualAge for Java - Distributed Debugger pour OS/2 contient le moteur de débogage pour OS/2. Pour l'installer, suivez les instructions du fichier README_install.txt (inclus dans l'élément Distributed Debugger pour OS/2).
VisualAge for Java - Distributed Debugger pour HP-UX contient le moteur de débogage pour HP-UX.
Composant prérequis :
Java version 1.3 est requis pour l'installation et le débogage de Java.
Pour l'installer, décompactez le fichier et suivez les instructions ci-dessous :
VisualAge for Java - Distributed Debugger pour Linux contient le moteur de débogage pour Linux. Pour l'installer, décompactez le fichier et suivez les instructions ci-dessous.
Avec l'ID utilisateur root, entrez la commande suivante : rpm -Uvh DERJPICL-9-1.i386.rpmVisualAge for Java - Distributed Debugger pour Linux/390 contient le moteur de débogage pour Linux/390. Pour l'installer, décompactez le fichier et suivez les instructions ci-dessous.
Avec l'ID utilisateur root, entrez la commande suivante : rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger pour OS/390
B.2.1.2.3 EMSRV
(serveur coopératif)
VisualAge for Java - EMSRV 7.1 contient le programme du serveur
de référentiels pour l'environnement de développement coopératif. Un élément d'archive unique contient le code du serveur pour Windows, AIX, OS/2, NetWare, HP-UX, Linux et Solaris, dans un fichier ZIP. Pour procédez à l'installation, dézippez ce fichier et suivez les instructions énoncées dans le fichier
instmigr.htm
B.2.1.2.4
IBM Developer Kit 1.2.2
VisualAge for Java - IBM Developer Kit 1.2.2 contient IBM
Developer Kit, Java Technology
Edition, version 1.2.2, PTF 9, pour Windows. Il
s'agit d'une archive auto-extractible. Pour procéder à l'installation,
exécutez ce fichier, qui se lancera automatiquement une fois extrait de l'archive, et suivez les instructions.
B.2.2 Installation ultérieure de composants supplémentaires
Pour installer des composants VisualAge for Java supplémentaires après l'installation initiale du produit, insérez le CD-ROM dans votre lecteur, sélectionnez l'option d'installation de VisualAge for Java, et choisissez Modifier dans l'écran de maintenance logicielle. Si l'autoexécution du CD à l'insertion est désactivée sur votre système, vous devrez préalablement lancer setup.exe à partir du répertoire racine du CD-ROM. Si vous disposez d'une version électronique de VisualAge for Java, vous devez également lancer setup.exe manuellement, puis suivre la même procédure.
Tous les composants sont alors affichés dans la fenêtre d'édition des fonctionnalités avec une indication concernant leur état d'installation en cours. Une croix 'X' rouge indique qu'un composant n'est pas installé actuellement. Vous pouvez sélectionner ces composants pour les installer. Ne sélectionnez pas les composants qui ne sont pas marqués d'un 'X' rouge ; ils ont déjà été installés.
Vous ne pouvez pas installer une deuxième instance de VisualAge for Java, version 4.0. Vous ne pouvez changer la langue d'installation sans avoir préalablement désinstallé le produit.
B.2.3 Installation de clients coopératifs VisualAge for Java
Pour que chaque membre de l'équipe puisse effectuer les opérations suivantes, l'administrateur EMSRV doit avoir configuré et démarré le serveur, testé la connexion client et ajouté les développeurs de l'équipe à la liste des utilisateurs du référentiel. Pour plus d'informations sur la façon d'exécuter ces tâches, reportez-vous au chapitre C de ce guide. Le chapitre C contient également des informations sur la migration d'un référentiel coopératif.
Dans les instructions suivantes, il est supposé que le référentiel partagé qui est installé sur le serveur a pour nom ivj.dat. EMSRV, version 7.1 doit avoir été installé sur votre serveur. Vous pouvez recevoir un message d'erreur si vous tentez de vous connecter à une version précédente d'EMSRV.
B.2.4 Installation d'un client disposant d'un référentiel autonome
Il vous est possible de disposer d'un référentiel de code source VisualAge for Java sur votre poste de travail, que vous pourrez utiliser lorsque vous ne serez pas connecté au référentiel partagé. Dans ce cas, lors de l'installation de VisualAge for Java, version 4.0 sur votre poste de travail, précisez que votre référentiel se trouvera sur votre poste local et non sur le serveur. Le programme d'installation créera alors un référentiel réservé à votre usage personnel.
Si vous voulez utiliser le référentiel partagé sur le serveur coopératif, reportez-vous à l'aide en ligne ou au fichier team.pdf. Le fichier team.pdf se trouve dans le répertoire pdf. Le répertoire pdf se trouve sur le CD VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments). Si vous n'avez pas téléchargé la partie contenant les PDF, ce répertoire n'existe pas.
B.2.5 Remarques sur l'installation et l'utilisation s'appliquant à Windows 2000
This release of VisualAge for Java continues to provide toleration support (as defined by Microsoft) for Windows 2000.
Le répertoire d'installation par défaut est <Program Files>\IBM\VisualAge for Java. Par défaut, sous Windows 2000, l'installation dans <ProgramFiles Files> ne peut être effectuée que par les utilisateurs ayant des droits Administrateurs et Standard (Power). Les utilisateurs usuels (Restricted) ne peuvent pas écrire de données dans cet emplacement.
En raison de la conception actuelle de VisualAge for Java, si le produit est installé à cet endroit et qu'il doit être utilisé par un utilisateur régulier (avec accès restreint), vous devez modifier les paramètres de sécurité pour le répertoire IBM ou IBM\VisualAge for Java situé sous <ProgramFiles> afin d'autoriser l'accès en écriture pour les utilisateurs réguliers. A défaut de cette modification, l'utilisateur provoquera des échecs lorsqu'il essaiera de démarrer l'environnement IDE ou qu'il utilisera des outils VisualAge for Java dans cet environnement.
La liste des serveurs pour AS/400 Enterprise Toolkit est maintenant stocké sous la forme "<ProgramFiles>\IBM\shared files\fvdctcp.txt". De nouveau, par défaut, cet emplacement est protégé et inaccessible en écriture pour les utilisateurs réguliers. Si un utilisateur ne possédant pas les droits suffisants essaie de créer ou de mettre à jour la liste des serveurs à l'aide des boutons Ajouter/Modifier la liste des serveurs de l'un des smartguides AS/400, la création ou la mise à jour de fichier échouera avec une erreur d'E-S dans son code Java qui peut ou non être signalée dans le journal ou sur la console.
L'administrateur système doit déterminer s'il doit octroyer à l'utilisateur régulier des droits d'accès en écriture pour cet emplacement ou maintenir sa protection et charger le fichier manuellement afin d'empêcher les utilisateurs non autorisés d'effectuer des mises à jour du fichier.
B.2.6 Installation du produit IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9
Si vous avez installé VisualAge for Java à partir du CD-ROM du produit, vous devez exécuter le programme install.exe à partir du répertoire IBM Developer Kit pour installer le produit IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9. Ce répertoire se trouve sur le CD-ROM Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, ce répertoire se trouve dans votre répertoire temporaire (dans lequel vous avez extrait vos éléments). Cependant, il n'est pas nécessaire d'exécuter install.exe, car le programme d'installation est automatiquement lancé une fois que vous l'avez extrait de l'archive IBM Developer Kit téléchargée.
Pour plus d'informations sur IBM Developer Kit, reportez-vous au fichier README disponible dans le répertoire IBM Developer Kit.
Avant de lancer le processus de migration, reportez-vous au chapitre D et au chapitre E pour obtenir des informations de migration générales ou propres à chaque composant.
La mise à niveau de VisualAge for Java, version 4.0 met à jour les référentiels lors de l'installation pour que les bibliothèques de classes système du référentiel soient au niveau approprié. Le référentiel doit donc être disponible en lecture et en écriture lors de cette mise à niveau. Aucun code utilisateur ne sera modifié lors de cette opération.
Si vous effectuez une migration à partir d'une version précédente de VisualAge for Java, Enterprise Edition, et que vous travaillez dans un environnement autonome (et non dans un environnement coopératif) et que vous voulez continuer à travailler ainsi, suivez les instructions pour Professional Edition du chapitre A du présent document.
Remarque : Lorsque vous effectuez une migration de VisualAge for Java, version 3.5 ou 3.5.3 vers VisualAge for Java version 4.0, vous pouvez avoir l'impression que la procédure d'installation est bloquée. Cette impression de blocage est due à l'exécution de la fonction "DoCosting" qui compare les versions des fichiers 3.5 ou 3.5.3 à celles des fichiers 4.0 et qui peut prendre jusqu'à 3 minutes.
Si vous procédez à une migration depuis un environnement coopératif ou vers un environnement coopératif, prenez note des remarques ci-dessous avant de commencer.
Les étapes à suivre lors de la migration dépendent de votre situation et de vos réponses aux questions ci-dessus.
Le scénario de migration ci-dessous est l'un des plus compliqué. Dans ce scénario, vous disposez de plusieurs référentiels partagés et de N développeurs utilisant des référentiels locaux version 3.5 ou 3.5.3. Vous désirez utiliser le nouveau référentiel version 4.0 tout en continuant d'utiliser les données de vos anciens référentiels partagés.
Remarque : Ce scénario aborde le traitement des référentiels locaux version 3.5 ou version 3.5.3 (Java 2), et non des référentiels locaux associés à un JDK 1.1.x. Si vous voulez importer des informations d'un référentiel local associé à un JDK 1.1.x vers un référentiel version 4.0, suivez les instructions de la section 3.2 du chapitre A.
A présent, le processus de migration est achevé et les utilisateurs peuvent passer d'un référentiel local à un référentiel partagé s'ils le souhaitent. Remarque : Si vous effectuez une migration à partir d'un environnement coopératif vers un environnement local, vous devez exporter manuellement les projets de l'ancien référentiel partagé vers le référentiel local. De même, si vous disposez d'un référentiel local, vous devez importer tous les projets que vous voulez utiliser à partir de votre ancien référentiel local vers le nouveau référentiel local version 4.0.
B.3.1 Migration d'un référentiel partagé à partir d'une version précédente de VisualAge for Java
Vous devez effectuer une mise à niveau vers la version EMSRV 7.1 avant de pouvoir suivre la procédure ci-après. Pour obtenir des instructions relatives à l'exécution de cette tâche, reportez-vous à la section C.3.1
Vous pouvez mettre à niveau un référentiel partagé version 2.0 ou 3.0x (utilisant JDK 1.1) ou 3.0x, Early Adopters ou 3.5 (utilisant JDK 1.2) de façon à ce qu'il soit compatible avec Java, version 4.0. Au cours des étapes ci-dessous, l'administrateur coopératif effectue une installation complète de VisualAge for Java, version 4.0 à l'aide d'un référentiel local. Il exporte ensuite l'ensemble du contenu du référentiel local dans tous les référentiels partagés.
Pour mettre à niveau un référentiel existant sur le serveur afin qu'il fonctionne avec VisualAge for Java, version 4.0, suivez la procédure ci-après.
Tous les projets sont copiés dans votre référentiel partagé. Les fichiers ressource de votre projet sont aussi exportés. Si le référentiel vers lequel vous effectuez l'exportation s'appelle sample.dat, les ressources du projet seront alors exportées vers un dossier appelé sample.dat.pr.
Pour obtenir des informations sur les problèmes et les restrictions détectés récemment, reportez-vous également au fichier README (disponible dans le répertoire README du CD-ROM).
B.4.1 Problèmes et restrictions connus liés à l'installation
Vous trouverez ci-après une liste des points à prendre en considération lors de l'installation de VisualAge for Java.
B.4.1.1 Restrictions relatives à l'unité de disque
B.4.1.2 Droits d'accès des utilisateurs
B.4.1.3 Remarques concernant TCP/IP
Ces options de configuration s'appliqueront à toutes les cartes TCP/IP, même si elles ont été modifiées uniquement pour la carte choisie. Vous ne pourrez utiliser ni la carte de réseau local ni la carte d'accès distant sans reconfigurer le système.
Les propriétés TCP/IP d'accès réseau à distance doivent être configurées conformément aux instructions de votre fournisseur d'accès Internet. Les propriétés TCP/IP d'accès réseau à distance remplaceront les propriétés TCP/IP de la carte d'accès distant configurées via l'icône Réseau dans le Panneau de configuration Windows 98 ou Windows 2000. Les paramètres seront remplacés uniquement si les propriétés TCP/IP de la carte d'accès distant sont configurées comme indiqué ci-dessus. Vous ne devez pas activer le serveur DNS dans les propriétés TCP/IP de la carte d'accès distant, ni y définir une adresse IP, car ces paramètres auraient une incidence sur la configuration d'accès réseau à distance du fournisseur d'accès Internet.
Dans le cas de Windows NT 4.0, les deux modes de configuration TCP/IP décrits ci-dessus peuvent être utilisés indifféremment. Si vous utilisez un poste autonome, vous pouvez également activer la carte Microsoft Loopback sans faire appel aux deux autres cartes.
B.4.1.4 Extension du shell (Windows NT)
Si vous obtenez un message indiquant que le programme d'installation a détecté une extension du Shell pour Windows NT, l'installation ne peut pas se poursuivre. Procédez alors comme suit :
B.4.1.5 Reprise en cas d'échec de l'installation
En cas d'échec de votre installation, vous devez supprimer tous les fichiers de la version 4.0 qui ont été installés. Si le répertoire que vous destiniez à l'installation de VisualAge for Java est vide, cela signifie que le processus d'installation s'est annulé et a supprimé tous les fichiers déjà installés. Vous pouvez supprimer le répertoire vide si vous le souhaitez, mais ce n'est pas nécessaire. Toutefois, si ce répertoire contient des fichiers, vous devez redémarrer le processus d'installation. Il s'ouvre alors en mode maintenance et vous devez choisir de supprimer votre installation partielle de la version 4.0 avant d'essayer d'installer le produit de nouveau.
Vous devez également supprimer l'entrée de registre suivante :
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java pour Windows
Procédez comme suit :
Si des fichiers NetQuestion ont été installés avant l'échec de l'installation, vous devez également les supprimer.
IMNINSTSRV=C:\imnnq_nt
L'emplacement du répertoire NetQuestion peut apparaître différemment, en fonction de l'unité d'installation de VisualAge for Java et du système d'exploitation utilisé. Si la variable est définie (vous disposez de l'emplacement sur lequel NetQuestion est installé), passez à l'étape 2.
Si vous recevez un message d'erreur indiquant par exemple que "la variable d'environnement imninstsrv n'est pas définie", alors aucun fichier NetQuestion n'a été installé ou l'installation NetQuestion n'a pas abouti. Si cela se produit, sélectionnez Démarrer > Rechercher > Fichiers ou dossiers et recherchez le fichier suivant sur votre système : vahelp.cfg. Si vous trouvez ce fichier dans un répertoire dont le nom commence par "imnnq" (imnnq_NT ou imnnq_98, par exemple), supprimez-le. Il n'est pas nécessaire d'effectuer les étapes 2 et 3.
Vous supprimez ainsi les fichiers NetQuestion que VisualAge for Java a installés. Cette opération n'a aucune influence sur les fichiers NetQuestion installés par d'autres produits (DB2, par exemple).
Effectuez une sauvegarde de votre référentiel et de vos fichiers de ressources si cela n'a pas déjà été fait. Pour plus d'informations sur la procédure à suivre, reportez-vous au chapitre B, section 3.0.
Une fois que vous avez effectué toutes ces tâches, réamorcez le système et réinstallez le produit. Si l'aide ne fonctionne pas une fois que vous avez réinstallé VisualAge for Java, reportez-vous au guide de résolution des incidents pour obtenir plus d'informations sur la reprise après des incidents apparus dans le système d'aide. Le guide de résolution des incidents (trshoot.htm) se trouve sur le CD-ROM VisualAge for Java, Professional Edition et sur le CD-ROM VisualAge for Java, Enterprise Edition, Additional Features. A l'issue de l'installation de VisualAge for Java, il est stocké sur X:\IBMVJava, X:\IBMVJava étant le répertoire d'installation de VisualAge for Java.
B.4.1.6 CICS Transaction Gateway
Si une version de CICS Transaction Gateway est installée sur votre machine lorsque vous installez VisualAge for Java, VisualAge utilisera cette version au lieu d'en installer une autre.
B.4.1.7 Erreurs liées au programme d'installation Windows
Vous trouverez ci-après la liste des erreurs à prendre en considération lors de l'installation sous Windows.
Erreur 1603 (Windows NT 4.0 uniquement)
Si vous recevez le message 1603 lors de l'installation de VisualAge for Java, cela signifie que le programme d'installation Windows Installer n'est pas parvenu à s'initialiser et que l'installation ne peut pas se poursuivre.
Certains produits (tels que VisualCafe de Symantec) copient automatiquement un fichier appelé sfc.dll lors de leurs installations sous Windows. Ce fichier est uniquement utilisé sous Windows 2000 où le programme d'installation l'appelle pour des raisons de sécurité.
Si un fichier de ce nom figure dans la section PATH de Windows NT 4.0, le programme d'installation Windows tente de le charger, même si le fichier ne s'applique qu'à Windows 2000. A ce stade, le programme d'installation Windows échoue.
Pour contourner ce problème, procédez comme suit :
Erreur irrémédiable LoadLibrary()
L'erreur irrémédiable LoadLibrary() se produit lorsque certains noyaux d'installation VisualAge for Java (IKernels) n'ont pas été correctement enregistrés par le programme d'installation Windows. Pour contourner ce problème, vous devez supprimer le répertoire InstallShield où résident les fichiers IKernal, puis réinstaller VisualAge for Java en suivant les étapes suivantes :
Erreur 1631 ou erreur interne 2755 (Windows NT 4.0 uniquement)
Si vous installez VisualAge for Java sous Windows NT 4.0, om est possible que vous receviez l'un des messages d'erreur suivants :
Si vous recevez l'un de ces messages d'erreur, il se peut que vos clés de registre soient associées à des valeurs "null". Lors de l'installation de VisualAge for Java, le fichier userenv.dll tente d'analyser plusieurs clés de registre. Si l'une d'entre elles comportent une valeur "null", la procédure d'installation échoue et l'un des messages indiqués ci-dessus s'affiche.
Pour contourner ce problème, vous devez supprimer ou modifier les variables d'environnement "null" (en remplaçant la valeur "null" par une valeur valide) avant d'installer VisualAge for Java. Une fois que VisualAge for Java est installé, vous pouvez rétablir les valeurs d'origine.
Attention : Supprimez ou modifiez les variables null avec prudence. Vous devez étudier l'effet de leur suppression ou de leur modification avant d'effectuer l'opération.
Erreurs internes 2381, 1303, 1310, 1313 (Windows NT uniquement)
Si vous tentez d'installer VisualAge for Java et que l'une des conditions énoncées ci-dessous est vraie :
il est possible que vous receviez l'un des messages d'erreur suivants :
Cet incident se produit lorsque l'utilisateur ne dispose que de droits en lecture sur les dossiers suivants :
\Program Files\IBM\VisualAge for Java
\WinNT\Installer
Pour résoudre cet incident, assurez-vous que vous disposez de tous les droits requis sur les unités et les répertoires. Pour ce faire, procédez comme suit :
Erreur interne 2735 : Démarrage du moteur
Si vous recevez l'erreur 2735, effectuez les opérations ci-dessous :
Erreur 1606/Erreur interne 2707
Si vous recevez le message d'erreur suivant, il se peut que la valeur du fichier de registre Outils d'administration (Commun) soit incorrecte :
Erreur 1606. Impossible d'accéder à l'emplacement réseau
\Profiles\AllUsers\StartMenu\Programs\Administrative Tools\.
Erreur interne 2707. INSTALLDIR.
Vous devez modifier la valeur du fichier de registre Outils d'administration (Commun) pour pouvoir installer VisualAge for Java. Pour ce faire, procédez comme suit :
B.4.2 Problèmes et restrictions connus liés à la désinstallation
Vous trouverez ci-après une liste de points à prendre en considération lors de la désinstallation :
B.4.2.1 Espace disque
L'unité de disque système Windows doit comporter au moins 2 Mo d'espace libre ; la variable d'environnement TEMP ou TMP doit pointer vers un répertoire temporaire valide doté de 5 Mo d'espace libre au minimum.
B.4.2.2 Désinstallation de Distributed Debugger
Si vous avez installé Distributed Debugger en tant que partie de l'installation de VisualAge for Java, vous devez désinstaller VisualAge for Java AVANT de désinstaller Distributed Debugger. Une fois la désinstallation de VisualAge for Java terminée, vous pouvez désinstaller Distributed Debugger en allant dans son répertoire d'installation et en exécutant le programme de désinstallation.
Si vous avez désinstallé VisualAge for Java et que vous ne parvenez pas à désinstaller Distributed Debugger, vous devez supprimer la clé de registre suivante :
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
Ensuite, essayez de nouveau de désinstaller Debugger. NE SUIVEZ PAS cette procédure si vous utilisez Distributed Debugger avec d'autres produits car vous ne pourrez plus utiliser le débogueur après avoir supprimé la clé de registre.
Procédez comme suit :
En outre, attribuez la valeur 1 à la clé de registre suivante :
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount
B.4.2.3 Variables d'environnement (Windows 98)
Lorsque vous désinstallez VisualAge for Java sous Windows 98, certaines entrées d'environnement peuvent demeurer dans le fichier autoexec.bat. Bien que ces entrées ne soient normalement à l'origine d'aucun problème, si vous désinstallez et réinstallez plusieurs fois le produit, deux problèmes peuvent se poser. Des conflits entre instructions PATH peuvent empêcher l'aide en ligne de fonctionner, ou ces instructions risquent d'être trop longues et de faire échouer la réinstallation du produit.
Pour résoudre ces problèmes :
B.4.2.4 Désinstallation de NetQuestion
Lorsque vous désinstallez VisualAge for Java, il est possible que NetQuestion ne soit pas désinstallé. Des problèmes peuvent survenir si NetQuestion n'est pas désinstallé et que vous essayez ultérieurement de réinstaller le produit.
Pour supprimer les fichiers NetQuestion installés par VisualAge for Java, suivez la procédure ci-après. Cette opération n'a aucune influence sur les fichiers NetQuestion installés par d'autres produits (DB2, par exemple).
IMNINSTSRV=C:\imnnq_nt
L'emplacement du répertoire NetQuestion peut apparaître différemment, en fonction de l'unité d'installation de VisualAge for Java et du système d'exploitation utilisé. Si vous recevez un message d'erreur indiquant par exemple que "la variable d'environnement imninstsrv n'est pas définie", tous les fichiers NetQuestion ont été désinstallés.
Vous supprimez ainsi les fichiers NetQuestion que VisualAge for Java a installés.
Si vous réinstallez ultérieurement VisualAge for Java et que le système d'aide ne fonctionne pas, reportez-vous au guide de résolution des incidents pour obtenir plus d'informations sur la reprise après un dysfonctionnement du système d'aide. Le guide de résolution des incidents (trshoot.htm) se trouve sur le CD-ROM VisualAge for Java, Professional Edition et sur le CD-ROM VisualAge for Java, Enterprise Edition, Additional Features. A l'issue de l'installation de VisualAge for Java, il est stocké sur X:\IBMVJava, X:\IBMVJava étant le répertoire d'installation de VisualAge for Java.
Vous devez utiliser EMSRV, version 7.1, si vous envisagez de travailler dans un environnement coopératif avec VisualAge for Java, Enterprise Edition.
Les fichiers EMSRV se trouvent sur le CD Additional Features.
Reportez-vous également à la section consacrée aux "Problèmes et restrictions connus" à la fin du chapitre C avant d'installer EMSRV.
C.1.1 Plateformes prises en charge
Le serveur EMSRV est prévu pour les systèmes d'exploitation suivants :
* Remarque : HP-UX est uniquement pris en charge sur les postes de travail de la classe 700. Il a été testé sur une machine HP-UX 9000/715/60 et une machine HP-UX 9000/782/200+. EMSRV n'est pas compatible avec les machines de la classe 800 (serveurs), car elles possèdent une architecture à part et nécessitent des fichiers binaires différents.
+ Pour obtenir plus d'informations sur l'obtention de ce correctif, reportez-vous à la section C.1.4.
IBM n'assure plus la prise en charge d'EMSRV sous Netware 4.11 ou Netware 5.0, mais il est possible d'exécuter EMSRV sur cette plateforme si le module CLIBAUX.NLM est chargé avant le module EMSRV.NLM. Le module CLIBAUX.NLM est inclus dans le Support Pack 8a de Novell, mais il est également disponible séparément auprès de Novell dans le fichier CLIBAUX1.EXE que l'on peut trouver à l'adresse URL suivante :
http://support.novell.com/cgi-bin/search/download?/pub/updates/nw/nw42/clibaux1.exe
Abandon de la prise en charge du matériel SMP
** REMARQUE IMPORTANTE : L'exécution d'une édition, quelle qu'elle soit, d'EMSRV pour Windows NT/2000 sur une machine équipée de plusieurs processeurs peut conduire à l'altération des référentiels.
Le support d'EMSRV sur les serveurs Windows NT/2000 fonctionnant sur des machines SMP (c'est-à-dire des machines multiprocesseurs) n'est plus assuré. Cette décision a été prise compte tenu des fréquentes altérations de référentiels qui nous ont été signalées dans ce cas de figure. Pour tous les autres systèmes d'exploitation, le support d'EMSRV sur les machines SMP continue d'être assuré.
IBM N'ASSUMERA PAS LA RESPONSABILITE DES EVENTUELS DOMMAGES RESULTANT DE L'UTILISATION D'EMSRV SUR UN SERVEUR WINDOWS NT/2000 FONCTIONNANT SUR UNE MACHINE SMP. EN AUCUN CAS IBM, SES FOURNISSEURS, SES AGENTS ET SES EMPLOYES NE POURRONT ETRE TENUS POUR RESPONSABLES DE DOMMAGES CONSECUTIFS A L'UTILISATION D'EMSRV SUR UN SERVEUR WINDOWS NT/2000 FONCTIONNANT SUR UNE MACHINE SMP.
Si vous souhaitez utiliser EMSRV sur un serveur fonctionnant sur une machine SMP, vous devez utiliser le paramètre -mp au lancement d'EMSRV. La détection de matériel SMP sera ainsi "court-circuitée". Ce faisant, vous utilisez EMSRV sur une plateforme qui n'est pas supportée officiellement et vous en assumez l'entière responsabilité si vos référentiels viennent à subir des dommages (IBM N'ACCEPTERA AUCUNE RESPONSABILITE).
EMSRV est un processus lié aux entrées-sorties, et non aux processeurs. C'est pourquoi il n'exploite pas les processeurs supplémentaires. Par conséquent, le nombre de processeurs de votre serveur n'aura aucune incidence sur les performances d'EMSRV.
C.1.2 TCP/IP
TCP/IP doit être installé et configuré sur votre serveur.
C.1.3 Correctifs Novell requis pour l'exécution d'EMSRV
Nous vous recommandons de vous procurer et d'appliquer les correctifs de la catégorie NetWare Minimum Patch List. Ils sont disponibles à l'adresse suivante : http://support.novell.com/misc/patlst.htm. Vous devez sélectionner et appliquer les correctifs adaptés à la version de NetWare que vous utilisez.
C.1.4 Correctifs requis pour exécuter EMSRV sousSolaris
L'implémentation de PAM pour Solaris version 2.6 contient un bogue qui empêche EMSRV de fonctionner correctement. Vous devez appliquer le correctif 106257-05 si vous utilisez EMSRV sous Solaris version 2.6. Ce correctif est disponible à l'adresse suivante :
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F106257&zone_32=PAM
Le bogue spécifique auquel ce correctif s'applique est le suivant :
4092227 pam_conv appdata_ptr member is not passed thru to conv() function as documented (le membre pam_conv appdata_ptr n'est pas transmis à la fonction conv() conformément aux instructions)
Le correctif n'est pas requis si vous travaillez avec la version 7.0 de Solaris.
C.1.5 Systèmes de fichiers pris en charge
EMSRV a été testé et certifié avec les systèmes de fichiers suivants :
NetWare
OS/2
Windows NT et Windows 2000
Solaris
HP-UX
AIX
Linux
EMSRV prend en charge uniquement les systèmes de fichiers montés localement.
Cette rubrique contient les instructions d'installation du programme serveur de référentiels EMSRV et d'un référentiel partagé. Pour obtenir plus d'instructions sur le démarrage du serveur, reportez-vous au fichier emsrv71 "Configuration et administration du serveur" (emsrv70.htm pour les langues autres que l'anglais), qui se trouve dans le répertoire TeamServer\docs.
C.2.1 Installation d'EMSRV pour Windows
Configuration d'EMSRV pour Windows
Avant d'installer EMSRV sous Windows, relevez les points
suivants relatifs aux types de fichier :
Installation d'EMSRV sous Windows
Pour installer le programme serveur de référentiels EMSRV et un référentiel partagé
sur un serveur Windows NT ou Windows 2000, suivez la
procédure ci-après :
Le fichier ide.zip se trouve dans le répertoire ivj40\backup du CD VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments).
Ce répertoire est celui dans lequel vous comptez stocker les référentiels de code source partagé. Lors d'un démarrage ultérieur du serveur, vous spécifiez ce sous-répertoire en tant que répertoire de travail EMSRV, à l'aide du paramètre de démarrage EMSRV -W.
EMSRV doit posséder tous les droits d'accès en lecture, en écriture et en recherche pour l'ensemble de l'arborescence de répertoires de ivj.dat.pr. Le répertoire ivj.dat.pr doit toujours être copié dans le même répertoire qu'ivj.dat, sinon vous ne pourrez pas accéder à vos ressources de projet.
Vous pouvez choisir de renommer le fichier référentiel, par exemple en team1.dat. Si vous renommez le référentiel après l'avoir copié sur le serveur, vous devez renommer le répertoire des ressources de projet en conséquence. Par exemple, si vous renommez le référentiel en team1.dat, vous devez renommer le répertoire des ressources de projet team1.dat.pr.
Les membres de l'équipe devront spécifier le nom du fichier référentiel au moment de l'installation du code client VisualAge for Java. Ils devront également préciser le chemin d'accès sur la machine serveur.
Si vous préférez lancer EMSRV comme service et non par l'intermédiaire de la ligne de commande, vous pouvez installer EMSRV dans le registre Windows. Il existe deux avantages à installer EMSRV comme service :
Conseil : Si EMSRV démarre en tant que service, le répertoire de travail EMSRV par défaut est le répertoire system32\ de Windows NT ou Windows 2000. Il est recommandé de modifier cette valeur par défaut à l'aide du paramètre -W lorsque vous installez EMSRV en tant que service dans le Registre Windows NT ou Windows 2000.
Important : Le support d'EMSRV sur les serveurs Windows NT/2000 fonctionnant sur des machines SMP (c'est-à-dire des machines multiprocesseurs) n'est plus assuré. Cette décision a été prise compte tenu des fréquentes altérations de référentiels qui nous ont été signalées dans ce cas de figure. Pour tous les autres systèmes d'exploitation, le support d'EMSRV sur les machines SMP continue d'être assuré.
IBM N'ASSUMERA PAS LA RESPONSABILITE DES EVENTUELS DOMMAGES RESULTANT DE L'UTILISATION D'EMSRV SUR UN SERVEUR WINDOWS NT/2000 FONCTIONNANT SUR UNE MACHINE SMP. EN AUCUN CAS IBM, SES FOURNISSEURS, SES AGENTS ET SES EMPLOYES NE POURRONT ETRE TENUS POUR RESPONSABLES DE DOMMAGES CONSECUTIFS A L'UTILISATION D'EMSRV SUR UN SERVEUR WINDOWS NT/2000 FONCTIONNANT SUR UNE MACHINE SMP.
Pour installer et démarrer EMSRV comme service Windows NT/2000 sur un matériel SMP, vous devez l'installer en spécifiant le paramètre -mp. La détection de matériel SMP sera ainsi "court-circuitée". Ce faisant, vous utilisez EMSRV sur une plateforme qui n'est pas supportée officiellement et vous en assumez l'entière responsabilité si vos référentiels viennent à subir des dommages (IBM N'ACCEPTERA AUCUNE RESPONSABILITE).
Si vous ne l'installez pas à l'aide du paramètre -mp, le service ne démarrera pas et vous recevrez le message d'erreur suivant :
Impossible de démarrer le service EMSRV sur \\host
Erreur 2140 : Erreur interne Windows NT.
Si vous tentez d'installer à nouveau EMSRV comme service (par exemple, pour ajouter le paramètre -mp), le service sera correctement installé, mais vous recevrez le message d'erreur suivant :
Impossible de copier le fichier de messages emsrvmsg.dll dans C:\WINNT\System32\emsrvmsg.dll
--- Erreur SE 1224 : L'opération demandée n'a pas pu être effectuée avec une session ouverte mappée à un utilisateur. Vérifiez que le DLL se trouve dans le même répertoire que le fichier EMSRV.EXE.
Vous pouvez ignorer ce message d'erreur car le DLL a déjà été installé avec le service.
Pour installer EMSRV en tant que service :
Pour plus d'informations sur le démarrage d'EMSRV, reportez-vous au fichier emsrv71.htm "Configuration et administration du serveur" (emsrv70.htm pour les langues autres que l'anglais) qui se trouve dans le répertoire TeamServer\docs.
Les paramètres que vous avez indiqués seront utilisés par défaut lors de chaque démarrage d'EMSRV. Vous pouvez également remplacer ou compléter ces paramètres si vous démarrez EMSRV manuellement à l'aide de l'icône Services du Panneau de configuration de Windows.
C.2.2 Installation d'EMSRV pour NetWareConfiguration d'EMSRV pour Netware
Avant d'installer EMSRV sous Netware, notez bien les limites
suivantes :
Installation d'EMSRV sous Netware
Pour installer le programme serveur de référentiels EMSRV et
un référentiel partagé sous NetWare, suivez la procédure
ci-après.
Le fichier ide.zip se trouve dans le répertoire ivj40\backup du CD VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments).
Lors d'un démarrage ultérieur du serveur, spécifiez ce sous-répertoire en tant que répertoire de travail EMSRV, à l'aide du paramètre de démarrage EMSRV -W. EMSRV doit posséder tous les droits d'accès en lecture, en écriture et en recherche pour l'ensemble de l'arborescence de répertoires de ivj.dat.pr. Le répertoire ivj.dat.pr doit toujours être copié dans le même répertoire qu'ivj.dat, sinon vous ne pourrez pas accéder à vos ressources de projet.
Vous pouvez choisir de renommer le fichier référentiel, par exemple en team1.dat. Si vous renommez le référentiel après l'avoir copié sur le serveur, vous devez renommer le répertoire des ressources de projet en conséquence. Par exemple, si vous renommez le référentiel en team1.dat, vous devez renommer le répertoire des ressources de projet team1.dat.pr.
Les membres de l'équipe devront spécifier le nom et l'emplacement du fichier référentiel au moment de l'installation du code client VisualAge for Java.
C.2.3 Installation d'EMSRV pour OS/2 Warp
Remarque : OS/2 n'est plus pris en charge en tant que plateforme de développement. Reportez-vous au chapitre E pour plus de détails.
Configuration d'EMSRV pour OS/2
Avant d'installer EMSRV sous OS/2, notez bien les limites
suivantes :
Installation d'EMSRV sous OS/2
Pour installer un référentiel partagé et un programme de serveur
de référentiels sur un serveur OS/2, suivez la procédure ci-après.
Placez ces fichiers dans un sous-répertoire figurant déjà dans votre variable d'environnement PATH, ou alors créez un sous-répertoire spécifique et ajoutez-le à la variable PATH. Il est recommandé de choisir un endroit comportant un espace disque conséquent, car c'est également dans ce sous-répertoire que sera créé le fichier journal emsrv.log.
Le fichier ide.zip se trouve dans le répertoire ivj40\backup du CD VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments).
Ce sous-répertoire est celui dans lequel vous comptez stocker les référentiels de code source partagé. Lors d'un démarrage ultérieur du serveur, spécifiez ce sous-répertoire en tant que répertoire de travail EMSRV, à l'aide du paramètre de démarrage EMSRV -W.
EMSRV doit posséder tous les droits d'accès en lecture, en écriture et en recherche pour l'ensemble de l'arborescence de répertoires de ivj.dat.pr. Le répertoire ivj.dat.pr doit toujours être copié dans le même répertoire qu'ivj.dat, sinon vous ne pourrez pas accéder à vos ressources de projet.
Vous pouvez choisir de renommer le fichier référentiel, par exemple en team1.dat. Si vous renommez le référentiel après l'avoir copié sur le serveur, vous devez renommer le répertoire des ressources de projet en conséquence. Par exemple, si vous renommez le référentiel en team1.dat, vous devez renommer le répertoire des ressources de projet team1.dat.pr.
Les membres de l'équipe devront spécifier le nom du fichier référentiel au moment de l'installation du code client VisualAge for Java.
C.2.4 Installation d'EMSRV pour AIX
Configuration d'EMSRV pour AIX
Avant d'installer EMSRV sous AIX, notez bien les points
suivants :
Installation d'EMSRV sous AIX
Dans la procédure ci-après, on appelle "utilisateur
EMSRV" la personne qui démarre le programme EMSRV.
Vous devez copier les fichiers suivants depuis le répertoire TeamServer sur votre machine :
Placez ces fichiers dans un sous-répertoire figurant déjà dans votre variable d'environnement PATH, ou alors créez un sous-répertoire spécifique et ajoutez-le à la variable PATH. Il est recommandé de choisir un endroit comportant un espace disque conséquent, car c'est également dans ce sous-répertoire que sera créé le fichier journal emsrv.log.
Exécutez la procédure suivante pour configurer EMSRV sur un poste AIX :
Le fichier ide.zip se trouve dans le répertoire ivj40\backup du CD Additional Features de VisualAge for Java, Enterprise Edition. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments).
EMSRV doit posséder tous les droits d'accès en lecture, en écriture et en recherche pour l'ensemble de l'arborescence de répertoires de ivj.dat.pr. Le répertoire ivj.dat.pr doit toujours être copié dans le même répertoire qu'ivj.dat, sinon vous ne pourrez pas accéder à vos ressources de projet. Les répertoires doivent avoir les bits (de recherche) rw et x définis pour l'utilisateur EMSRV.
Sur les plateformes UNIX, les droits d'accès root sont requis pour authentifier les utilisateurs. EMSRV n'a PAS besoin d'être démarré par l'utilisateur root pour accomplir l'authentification des utilisateurs. Cela poserait un problème de sécurité car EMSRV aurait alors intégralement accès à l'ensemble des systèmes de fichiers.
Il est préférable d'attribuer la propriété du fichier exécutable EMSRV à l'utilisateur 'root' et de définir le bit SUID du fichier exécutable. Pour ce faire, procédez comme suit :
chown root emsrv
chmod u+s emsrv
Lorsqu'EMSRV essaie d'authentifier un utilisateur, il change provisoirement l'autorité du processus EMSRV en cours d'exécution en l'affectant au propriétaire du fichier exécutable. Une fois l'authentification terminée, l'autorité du processus EMSRV en cours d'exécution est réaffectée à l'utilisateur qui a démarré le programme EMSRV. Cette procédure se produit par processus (par client), de sorte que pendant qu'un client est en cours d'authentification, seul le processus prenant en charge ce client possède provisoirement des droits d'accès root.
Les droits d'accès root sont requis pour l'authentification des utilisateurs, quel que soit le mode d'authentification mis en oeuvre par EMSRV. Les interfaces telles que PAM offrent uniquement une API commune afin de permettre aux applications de prendre en charge plusieurs méthodes d'authentification. La configuration spécifique de chaque méthode doit être correcte.
C.2.5 EMSRV pour HP-UX ou Solaris
C.2.5.1 Configuration d'EMSRV pour HP-UX ou Solaris
Avant d'installer EMSRV sous Solaris ou HP-UX, notez bien les
conditions requises ci-après.
Pour Solaris
Pour HP-UX
C.2.5.2 Installation d'EMSRV pour HP-UX ou Solaris
Dans la procédure ci-après, on appelle "utilisateur
EMSRV" la personne qui démarre le programme EMSRV.
Vous devez copier les fichiers suivants depuis le répertoire TeamServer sur votre machine :
Pour HP-UX :
Pour Solaris :
Placez ces fichiers dans un sous-répertoire figurant déjà dans votre variable d'environnement PATH, ou alors créez un sous-répertoire spécifique et ajoutez-le à la variable PATH. Il est recommandé de choisir un endroit comportant un espace disque conséquent, car c'est également dans ce sous-répertoire que sera créé le fichier journal emsrv.log.
Exécutez la procédure suivante pour configurer EMSRV sur un poste Solaris ou HP-UX :
Le fichier ide.zip se trouve dans le répertoire ivj40\backup du CD VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments).
EMSRV doit posséder tous les droits d'accès en lecture, en écriture et en recherche pour l'ensemble de l'arborescence de répertoires de ivj.dat.pr. ivj.dat.pr doit toujours être copié dans le même répertoire qu'ivj.dat, sinon vous ne pourrez pas accéder à vos ressources de projet. Les répertoires doivent avoir les bits (de recherche) rw et x définis pour l'utilisateur EMSRV.
Sur les plateformes UNIX, les droits d'accès root sont requis pour authentifier les utilisateurs. EMSRV n'a PAS besoin d'être démarré par l'utilisateur root pour accomplir l'authentification des utilisateurs. Cela poserait un problème de sécurité car EMSRV aurait alors intégralement accès à l'ensemble des systèmes de fichiers.
Il est préférable d'attribuer la propriété du fichier exécutable EMSRV à l'utilisateur 'root' et de définir le bit SUID du fichier exécutable. Pour ce faire, procédez comme suit :
chown root emsrv
chmod u+s emsrv
Lorsqu'EMSRV essaie d'authentifier un utilisateur, il change provisoirement l'autorité du processus EMSRV en cours d'exécution en l'affectant au propriétaire du fichier exécutable. Une fois l'authentification terminée, l'autorité du processus EMSRV en cours d'exécution est réaffectée à l'utilisateur qui a démarré le programme EMSRV. Cette procédure se produit par processus (par client), de sorte que pendant qu'un client est en cours d'authentification, seul le processus prenant en charge ce client possède provisoirement des droits d'accès root.
Les droits d'accès root sont requis pour l'authentification des utilisateurs, quel que soit le mode d'authentification mis en oeuvre par EMSRV. Les interfaces telles que PAM offrent uniquement une API commune afin de permettre aux applications de prendre en charge plusieurs méthodes d'authentification. La configuration spécifique de chaque méthode doit être correcte.
C.2.6 Installation d'EMSRV pour Linux
C.2.6.1 Configuration d'EMSRV pour Linux
Avant d'installer EMSRV sous Linux, notez bien les points
suivants :
C.2.6.2 Installation d'EMSRV pour Linux
Dans la procédure ci-après, on appelle "utilisateur
EMSRV" la personne qui démarre le programme EMSRV.
Vous devez copier les fichiers suivants depuis le répertoire TeamServer sur votre machine :
Placez ces fichiers dans un sous-répertoire figurant déjà dans votre variable d'environnement PATH, ou alors créez un sous-répertoire spécifique et ajoutez-le à la variable PATH. Il est recommandé de choisir un endroit comportant un espace disque conséquent, car c'est également dans ce sous-répertoire que sera créé le fichier journal emsrv.log.
Exécutez la procédure suivante pour configurer EMSRV sur un poste Linux :
Le fichier ide.zip se trouve dans le répertoire ivj40\backup du CD Additional Features de VisualAge for Java, Enterprise Edition. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments).
EMSRV doit posséder tous les droits d'accès en lecture, en écriture et en recherche pour l'ensemble de l'arborescence de répertoires de ivj.dat.pr. Le répertoire ivj.dat.pr doit toujours être copié dans le même répertoire qu'ivj.dat, sinon vous ne pourrez pas accéder à vos ressources de projet. Les répertoires doivent avoir les bits (de recherche) rw et x définis pour l'utilisateur EMSRV.
Sur les plateformes UNIX, les droits d'accès root sont requis pour authentifier les utilisateurs. EMSRV n'a PAS besoin d'être démarré par l'utilisateur root pour accomplir l'authentification des utilisateurs. Cela poserait un problème de sécurité car EMSRV aurait alors intégralement accès à l'ensemble des systèmes de fichiers.
Il est préférable d'attribuer la propriété du fichier exécutable EMSRV à l'utilisateur 'root' et de définir le bit SUID du fichier exécutable. Pour ce faire, procédez comme suit :
chown root emsrv
chmod u+s emsrv
Lorsqu'EMSRV essaie d'authentifier un utilisateur, il change provisoirement l'autorité du processus EMSRV en cours d'exécution en l'affectant au propriétaire du fichier exécutable. Une fois l'authentification terminée, l'autorité du processus EMSRV en cours d'exécution est réaffectée à l'utilisateur qui a démarré le programme EMSRV. Cette procédure se produit par processus (par client), de sorte que pendant qu'un client est en cours d'authentification, seul le processus prenant en charge ce client possède provisoirement des droits d'accès root.
Les droits d'accès root sont requis pour l'authentification des utilisateurs, quel que soit le mode d'authentification mis en oeuvre par EMSRV. Les interfaces telles que PAM offrent uniquement une API commune afin de permettre aux applications de prendre en charge plusieurs méthodes d'authentification. La configuration spécifique de chaque méthode doit être correcte.
C.3.1 Migration de la version 6.x ou 7.0 d'EMSRV vers la version 7.1
Si la version 6.x ou la version 7.0 d'EMSRV est actuellement installée et que vous souhaitez installer la version 7.1, vous pouvez soit désinstaller la version 6.x/7.0 et installer la version 7.1, soit conserver votre ancienne version d'EMSRV et installer EMSRV 7.1.
Vous devez installer la version 7.1 pour pouvoir travailler avec VisualAge for Java, version 4.0.
Pour migrer de la version 6.x/7.0 d'EMSRV vers EMSRV, version 7.1, procédez comme suit :
EMSRV 7.1 est compatible avec EMSRV 6.x/7.0. Par exemple, si vous travaillez dans une édition antérieure de VisualAge for Java (qui utilise EMSRV 6.x/7.0), vous pouvez vous connecter depuis votre ancienne version à un référentiel partagé s'exécutant sous EMSRV 7.1.
A ce stade, vous avez déjà installé les fichiers programmes du serveur de référentiel ainsi qu'un référentiel de code source partagé. Pour terminer la mise en place de l'environnement de développement coopératif, vous devez démarrer le serveur, vous y connecter depuis un client VisualAge for Java et ajouter les membres de l'équipe à la liste des utilisateurs du référentiel.
Si vous avez déjà installé le client VisualAge for Java sur un poste de travail, référez-vous à l'aide en ligne pour obtenir plus de détails sur la configuration de l'environnement de développement coopératif. Sinon, consultez le fichier team.pdf dans le répertoire pdf. Le répertoire pdf se trouve sur le CD VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments). Si vous n'avez pas téléchargé la partie contenant les PDF, ce répertoire n'existe pas.
Dans les instructions suivantes, il est supposé que le référentiel partagé qui est installé sur le serveur a pour nom ivj.dat. Lors du démarrage du programme serveur de référentiels, l'administrateur doit désigner le chemin d'accès au fichier ivj.dat comme répertoire de travail d'EMSRV.
C.4.1 Préparation du serveur coopératif
Avant que les développeurs puissent travailler avec le référentiel partagé, l'administrateur doit configurer le serveur VisualAge for Java et démarrer le programme serveur de référentiels EMSRV. Si certains développeurs souhaitent commencer à utiliser VisualAge for Java, version 4.0 avant que le serveur ne soit prêt, ils peuvent configurer leur poste en vue d'une utilisation autonome, puis se connecter ultérieurement au référentiel partagé, une fois le serveur configuré.
C.4.2 Test d'une connexion client
Pour s'assurer que le serveur a été démarré correctement, l'administrateur doit essayer de se connecter au référentiel partagé à partir d'un poste client VisualAge for Java, Enterprise Edition, version 4.0. Si cette tentative aboutit, cela signifie que la connexion TCP/IP du serveur fonctionne correctement, qu'EMSRV a été démarré avec les paramètres appropriés et que l'administrateur sait quelles informations fournir lors de l'installation d'un poste client.
Pour plus d'informations sur la connexion à un référentiel partagé, reportez-vous à la section "Connexion à un référentiel partagé" de l'aide en ligne de VisualAge for Java, ou au fichier team.pdf. Le fichier team.pdf se trouve dans le répertoire pdf. Le répertoire pdf se trouve sur le CD VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments). Si vous n'avez pas téléchargé la partie contenant les PDF, ce répertoire n'existe pas.
C.4.3 Ajout d'utilisateurs à la liste des utilisateurs du référentiel
Lorsqu'un client se connecte pour la première fois au référentiel partagé, l'utilisateur est invité à entrer le nom du propriétaire de l'espace de travail. L'utilisateur ne peut pas démarrer l'environnement IDE sans sélectionner au préalable un nom de propriétaire d'espace de travail valide dans la liste des utilisateurs du référentiel.
Par défaut, la liste des utilisateurs du référentiel de VisualAge for Java version 4.0 contient un utilisateur appelé Administrator. Chaque utilisateur peut initialement choisir ce nom comme propriétaire de l'espace de travail, mais il est fortement recommandé d'indiquer dès le début un nom unique pour se connecter au serveur. En effet, dans l'environnement de développement coopératif de VisualAge for Java, le contrôle des modifications est basé sur les rôles attribués aux utilisateurs, d'où la nécessité pour chaque développeur d'être identifié de manière unique. A cet effet, l'administrateur doit ajouter chaque développeur à la liste des utilisateurs du référentiel. (Il est le seul utilisateur de VisualAge for Java qui puisse ajouter des noms à cette liste.) Si le contrôle d'accès par mot de passe natif est en vigueur, le nom attribué à chaque utilisateur doit correspondre à un nom d'utilisateur du système.
Pour plus d'informations sur l'ajout d'utilisateurs à la liste des utilisateurs du référentiel, reportez-vous à la l'aide en ligne de VisualAge for Java Team, ou au fichier team.pdf situé dans le répertoire pdf. Le répertoire pdf se trouve sur le CD VisualAge for Java, Enterprise Edition, Additional Features. Si vous disposez d'une version électronique de VisualAge for Java, le fichier se trouve dans le répertoire temporaire (où vous avez extrait les éléments). Si vous n'avez pas téléchargé la partie contenant les PDF, ce répertoire n'existe pas.
Lorsque le serveur est configuré correctement et prêt à fonctionner, les utilisateurs doivent procéder à l'installation de leur client VisualAge for Java. Vous trouverez des informations sur l'installation des clients coopératifs VisualAge for Java au chapitre B de ce guide.
C.5.1 Performances des connexions réseau à faible largeur de bande et à délai d'attente important
Le protocole utilisé entre les clients EMSRV et EMSRV génère un nombre important de paquets transmis au serveur. Cela est dû au fait qu'une grande partie du traitement est effectuée sur le client. La majorité des requêtes traitées par EMSRV sont des requêtes d'E/S (par exemple, des requêtes de verrouillage des enregistrements, de lecture et d'écriture).
En raison de cette architecture, les performances obtenues sur le client dépendent principalement des temps d'attente sur le réseau. Les temps d'attente (mesurés par la durée des aller-retour effectués par les paquets de données lors de l'utilisation de la commande ping) inférieurs à 5 ms permettent d'obtenir des performances acceptables. Le temps d'attente LAN est généralement inférieur à 1 ms mais le temps d'attente avec une connexion WAN ou via un modem sur une ligne téléphonique peut atteindre 500 ms. Même avec une ligne d'abonné numérique, le câble, un relais de trames ou des connexions ISDN, le temps d'attente dépend de la distance entre les deux noeuds finaux.
En général, les performances obtenues avec un modem et une ligne téléphonique ne sont pas acceptables car les connexions de ce type ont généralement des temps d'attente égaux ou supérieurs à 200 ms. Les connexions à haut débit n'offrent pas non plus de performances acceptables, sauf si la distance entre le client et le serveur est inférieure ou égale à quelque centaines de kilomètres.
La largeur de bande du protocole EMSRV n'est pas de taille particulièrement importante mais l'utilisation de la largeur de bande dépend du nombre de clients utilisant au même moment une connexion.
C.5.2 Nombre maximal de connexions TCP/IP
Par défaut, le nombre maximal de connexions client vers un serveur EMSRV est 512. Vous pouvez changer cette limite à l'aide du paramètre -M de la commande de démarrage d'EMSRV.
La limite théorique est liée principalement à la quantité de mémoire disponible, mais certaines piles TCP/IP arrivent à court de sockets (prises) avant que la limite de mémoire ne soit atteinte. Généralement, ce nombre est supérieur à cent, mais il varie d'une pile à l'autre.
C.5.3 Détection des abandons de connexions non prévus
EMSRV se sert de la temporisation KEEPALIVE de TCP/IP pour détecter les abandons de connexions non prévus qui résultent du redémarrage de clients ou de leur blocage accidentel. Certaines piles TCP/IP permettent de changer la valeur de la temporisation KEEPALIVE. En règle générale, sa valeur par défaut s'établit à 120 minutes.
Vous pouvez utiliser la commande EMADMIN pour obtenir la liste des connexions établies et identifier toute connexion sur laquelle aucune interaction avec le serveur n'a été enregistrée depuis longtemps. Il est alors possible de fermer une telle connexion à l'aide de la commande EMADMIN STOP et du paramètre -k .
C.5.4 Cohabitation des différentes versions d'EMSRV et de ses utilitaires
VisualAge for Java, version 4.0, est fourni avec la version 7.1 d'EMSRV et la version 7.0 des utilitaires EMADMIN.
Vous devez utiliser EMADMIN 7.0 avec EMSRV 7.1. EMADMIN 7.0 ne fonctionnera pas correctement avec les versions d'EMSRV antérieures à la version 7.0.
C.5.5 Restrictions applicables à PAM
Sur les plateformes Linux et Solaris, l'authentification est implémentées à l'aide de PAM (Password Authentication Modules). Cela devrait théoriquement permettre l'utilisation de n'importe quel module PAM avec EMSRV en changeant le fichier de configuration PAM approprié, mais en pratique, cela n'est pas possible.
La façon dont EMSRV communique avec les clients n'est pas entièrement compatible avec l'architecture PAM. En conséquence, l'authentification EMSRV ne fonctionne que lorsque le module demande initialement la saisie d'un mot de passe en texte clair (fourni initialement par le client).
Suite à un bogue figurant dans les bibliothèques d'exécution Microsoft C, tout mot de passe comportant des caractères non-ASCII entrés en réponse à l'invite suivante :
'Entrez le mot de passe de l'utilisateur qui a démarré EMSRV'
ne sera pas interprété correctement. Une solution palliative est de fournir le mot de passe en ajoutant l'option -p lors de l'exécution de EMADMIN.
C.5.7 Caractères corrompus dans le menus et fenêtres lors de l'exécution de NetWare japonaisEMSRV pour NetWare NLM utilise NLM User Interface Developer Components (NWSNUT) de Novell. Lors de l'exécution de NetWare sur une machine japonaise, les caractères graphiques utilisés dans les fenêtres et menus NWSNUT ne sont pas disponibles et affichent des caractères corrompus. Il ne s'agit pas d'un bogue de EMSRV NLM ou de NetWare mais plutôt d'une limitation de la page de codeShift-JIS.
C.5.8 EMADMIN ne copie pas le répertoire des ressources stockéesLorsque EMADMIN 7.0 est utilisé pour copier un référentiel VisualAge for Java 4.0, il ne copie pas le répertoire de ressources stockées du projet correspondant. Vous devez copier le répertoire de ressources stockées du projet manuellement.
Pour obtenir des informations essentielles relatives à la migration de classes Swing, reportez-vous à la section 18.0.
Cette version de VisualAge for Java ne prend pas en charge CICS Transaction Server. Les classes requises pour le support de CICS TS 1.3 et des versions antérieures ne sont pas fournies avec cette version. Toute application CICS TS que vous essayez de migrer depuis des versions antérieures de VisualAge for Java ne fonctionnera pas dans la version 4.0 et doit être supprimée de l'espace de travail et du référentiel de la version 4.0.
Si vous souhaitez travailler avec CICS TS 1.3 ou avec une version antérieure, vous devez continuer à utiliser une version antérieure (3.02 ou versions précédentes) de VisualAge for Java. Pour l'instant, vous devez également utiliser une version antérieure (3.02 et versions précédentes) de VisualAge for Java si vous voulez utiliser l'interface JCICS ou si avez besoin d'une prise en charge CICS pour IIOP. Nous assurons le support de CICS Transaction Server car il est basé sur JDK 1.1.x.
D.2.1. Migration à partir de la version 2.0 ou 3.0x de VisualAge for Java
Les beans Data Accesss utilisent des composants et des interfaces Swing. Toutes les applications utilisant les beans doivent faire l'objet d'une migration depuis les anciens packages Swing (JDK 1.1.x) vers les nouveaux (J2SDK v.1.2.2). Pour ce faire, sélectionnez les classes et les packages concernés après avoir terminé l'installation de VisualAge for Java version 4.0. Ouvrez le smartguide Correction/Migration, puis sélectionnez la case à cocher Inclure les packages renommés JDK1.2. Les entrées De/Vers appropriées à Swing sont alors ajoutées et vous pouvez faire migrer automatiquement les références Swing vers le Java 2 SDK. Toutes les erreurs pouvant survenir au cours du processus de migration sont enregistrées dans la fenêtre Journal.
Pour plus d'informations sur la procédure correcte de migration des applications, reportez-vous au fichier d'aide en ligne de l'éditeur de composition visuelle "Directives de correction/migration pour les références de classe ou de package", ainsi qu'au fichier des tâches associées "Correction des références de classe ou de package".
D.2.2. Migration à partir de la version 3.5 de VisualAge for Java
Aucune autre étape n'est nécessaire pour effectuer la migration de beans Data Access si vous avez effectué la migration pour VisualAge for Java, version 3.5, étant donné que les beans Data Access de la version 3.5 utilisaient les packages Swing J2SDK v.1.2.2.
Data Access Builder n'est plus inclus dans VisualAge for Java. Si vous voulez continuer à utiliser Data Access Builder, vous devrez continuer à travailler avec une version antérieure de VisualAge for Java.
Il n'existe pas de nouvelle fonction dans VisualAge for Java 4.0 permettant de remplacer directement la fonctionnalité offerte précédemment par Data Access Builder, mais il existe trois composants qui fournissent des fonctions similaires - Beans Data Access, Persistence Builder et Enterprise JavaBeans Development Environment. Chaque fonction permet une approche différente pour créer des classes d'accès aux données.
Vous ne pouvez pas procéder à la migration de votre code vers VisualAge for Java 4.0 et le réutiliser dans l'un de ces outils. Vous devrez recréer vos applications si vous voulez les utiliser dans la version 4.0. Utilisez la fonction qui correspond le mieux à votre objectif de développement de code et à ce que vous attendez de vos applications.
Vous trouverez en annexe à ce guide une comparaison entre Data Access Builder, les beans Data Access et Persistence Builder.
D.4.1 Migration des beans enterprise depuis VisualAge for Java, version 2.0, Enterprise Update
Si vous avez créé des beans enterprise dans VisualAge for Java, Version 2.0, Enterprise Update, et que vous voulez les utiliser dans VisualAge for Java, Version 4.0, vous devez effectuer les opérations suivantes dans votre version actuelle de VisualAge for Java, Version 2.0, Enterprise Update :
Pour terminer la migration du code de votre bean enterprise, dans VisualAge for Java 4.0, suivez la procédure du scénario 1 ou du scénario 2 ci-après, suivant que vous importiez depuis un référentiel (recommandé) ou un fichier JAR.
Scénario 1 - Importation depuis un référentiel
Si vous importez vos beans depuis un référentiel, procédez comme
suit :
Vous pouvez trouver des informations supplémentaires sur l'exécution de cette procédure dans l'aide en ligne de VisualAge for Java pour EJB Development Environment.
Scénario 2 - Importation depuis un fichier JAR
Si vous avez exporté vos beans enterprise vers un fichier JAR,
procédez comme suit :
Vous pouvez trouver des informations supplémentaires sur l'exécution de cette procédure dans l'aide en ligne de VisualAge for Java pour EJB Development Environment.
D.4.2 Migration des beans enterprise depuis VisualAge for Java, Version 3.0 ou 3.02
Si vous disposez d'un bean enterprise pour lequel du code généré à l'aide de VisualAge for Java version 3.0 ou version 3.02 a été déployé et que vous voulez désormais utiliser ce bean enterprise dans VisualAge for Java 4.0, vous devez le migrer vers cette nouvelle version, puis supprimer et régénérer le code déployé.
Cependant, avant de migrer le code du bean enterprise vers la version 4.0, vous devez effectuer les opérations ci-après dans votre version actuelle de VisualAge for Java (Version 3.0 ou Version 3.02).
Pour migrer le code du bean enterprise, puis régénérer le code déployé, suivez la procédure ci-après dans VisualAge for Java 4.0, dans l'ordre indiqué.
D.4.3 Migration des associations EJB depuis VisualAge for Java version 3.0
Lorsque vous ajoutez, éditez ou supprimez une association dans un groupe EJB ayant été créé dans la version 3.0, VisualAge for Java convertit automatiquement toutes les associations du groupe EJB dans le nouveau format d'association. Pour terminer le processus de migration, effectuez les modifications suivantes manuellement :
Ces méthodes n'ont pas été converties automatiquement en raison de la forte probabilité que des modifications manuelles leur aient été apportées. VisualAge for Java ajoute les appels automatiquement lors de la création de beans dans la version 4.0.
Si vous importez un bean entity CMP de la version 3.0 ou d'une version antérieure dans un EJBgroup dont les associations ont déjà été migrées et que vous ajoutez ensuite un nouveau bean qui hérite du bean entity CMP importé, la classe de bean du bean marquera plusieurs méthodes d'un caractère 'X' rouge. Cela s'explique par le fait que la classe de bean du bean importé ne contient pas les méthodes _initLinks, _getLinks et _removeLinks. Vous devez ajouter ces méthodes manuellement à la classe du bean importé.
Lorsque vous êtes prêt à déployer votre code bean enterprise vers un serveur d'applications de production, vous devez vous assurer de déployer également le fichier JAR d'exécution qui contient le code d'exécution requis à la fois par les associations et par les beans access. Ce fichier JAR doit également être déployé vers votre serveur d'applications et doit être inclus dans le chemin d'accès aux classes du serveur d'applications. Des informations supplémentaires concernant le fichier JAR d'exécution sont disponibles dans l'aide en ligne de l'environnement de développement EJB.
D.4.4 Migration des associations EJB depuis VisualAge for Java 3.02
Lorsque vous ouvrez pour la première fois un groupe EJB doté d'associations créées dans la version 3.02 de VisualAge for Java, des icônes d'erreur s'affichent dans ce groupe en regard des classes de liens générées. Lorsque vous ajoutez, éditez ou supprimez une association dans ce type de groupe EJB, VisualAge for Java corrige automatiquement les classes de liens pour toutes les associations du groupe EJB. Si vous n'avez pas l'intention d'effectuer de changement dans une association, vous devrez tout de même la sélectionner dans la sous-fenêtre Propriétés de la page EJB et sélectionner Edition dans le menu en incrustation pour ouvrir l'éditeur d'association. Vous devrez ensuite cliquer sur OK pour terminer la migration.
VisualAge for Java supprime automatiquement certaines méthodes liées aux associations ayant été générées dans VisualAge for Java 3.02. Les méthodes supprimées sont des méthodes qui, en raison des caractéristiques de l'association, n'auraient pas fonctionné correctement dans la version 4.0. Par exemple, si un rôle fait partie de la clé primaire, la méthode set pour ce rôle n'est pas correcte. Cette méthode aurait été générée automatiquement dans la version 3.02 et ne peut pas être générée dans la version 4.0.
D.5.1 Enterprise Access Builder
D.5.1.1 Prise en charge des nouveaux connecteurs
Enterprise Access Builder prend désormais en charge les connecteurs
Common Connector Framework (CCF) et Java 2, Enterprise Edition (J2EE)
Connector Architecture. Enterprise Access Builder contient de
nouveaux outils permettant de migrer des commandes, des
navigateurs, des beans de session et des enregistrements
EAB d'un format CCF à un format J2EE Connector Architecture. En
outre, les smartguides et les éditeurs suivants ont été mis à jour
afin de refléter la nouvelle prise en charge de J2EE
Connector Architecture :
Pour plus d'informations sur la prise en charge des nouveaux connecteurs et outils J2EE (version bêta) et des nouveaux migrateurs EAB, reportez-vous à l'aide en ligne d'Enterprise Access Builder.
D.5.1.2 Régénération et édition des enregistrements et des commandes
Si vous faites migrer vos applications EAB depuis une version antérieure de
VisualAge for Java vers la version 4.0, vous pouvez décider de régénérer vos
enregistrements et vos commandes. Leurs performances s'en trouveront optimisées
dans la version 4.0.
Si vous avez sélectionné précédemment les options "Direct" et "Shorten
names" ("Noms courts"), sans sélectionner "Inner classes" ("Classes internes"),
les noms des enregistrements générés
étaient parfois trop longs.
Les noms générés avaient alors plus de 255 caractères, la limite supérieure
imposée par Windows. L'enregistrement Création du smartguide Type
d'enregistrement a été optimisé pour générer des noms aussi courts que
possibles lorsque les options indiquées plus haut sont sélectionnées.
Toutefois, si vous régénérez des données à l'aide de ces options, vos
applications peuvent s'en trouver affectées dans la mesure où les noms des
enregistrements peuvent être modifiés.
Si votre commande EAB a été créée dans la version 2.0x, vous ne pouvez pas l'éditer dans l'éditeur de commande. Toutefois, vous pouvez l'éditer dans l'éditeur de composition visuelle. La version actuelle de l'exécution offre une compatibilité amont, de sorte que vous pouvez l'utiliser pour exécuter des commandes de la version 2.0x.
D.5.1.3 Déploiement des applications
Version 4.0 est une version de transition d'Enterprise Access Builder (EAB). L'architecture
plus ancienne Common Connector Framework (CCF), sur laquelle est
basée EAB, migre vers l'architecture J2EE Connector. La
documentation EAB aborde cette transition et les différences entre
les deux architectures. Dans cette version, les deux architectures
sont prises en charge. En déploiement, cela signifie qu'il existe
certaines différences. Pour plus de détails, consultez la rubrique relative au
déploiement dans la documentation EAB. Le paragraphe suivant aborde
brièvement le déploiement.
Pour les applications existantes, vous pouvez continuer comme par le passé. Déployez votre application avec les fichiers eab\runtime30\eablib.jar, ccf.jar, recjava.jar et les fichiers JAR requis par votre connecteur lors de l'exécution. Dans le cas des nouvelles applications ayant ajouté certains composants associés à l'architecture J2EE Connector, tels que les enregistrements et commandes utilisant l'architecture J2EE, le déploiement doit s'effectuer avec le fichier eab\runtime35\eablib.jar. Ce fichier est bimodal ; il prend en charge les deux architectures. En outre, vous avez besoin d'autres fichiers JAR associés uniquement à J2EE, qui sont spécifiés dans la rubrique relative au déploiement de la documentation EAB.
D.5.2 E-connector
La section ci-après contient des informations relatives à la migration d'IMS connect, de CICS et d'e-connector.
Important : En raison d'une limitation du support du système de fichiers du CD (CDFS) sous Windows 98, l'installation de certains fichiers de connecteurs e-business à partir du CD peut échouer et générer un ou plusieurs des messages d'erreur ci-après, suivant les connecteurs sélectionnés.
Les fichiers non installés sont conservés dans un fichier zip (econnfix.zip) situé à la racine du CD du produit. Si vous installez VisualAge for Java sous Windows 98 et que vous recevez l'un des messages précédents, vous devez dézipper econnfix.zip dans le répertoire d'installation du produit (par exemple, à l'aide de la commande unzip econnfix.zip -d c:\Program Files\IBM\VisualAge for Java\, c:\Program Files\IBM\VisualAge for Java\ correspondant au répertoire d'installation). Une fois ces fichiers en place, les connecteurs fonctionneront correctement.
D.5.2.1 IMS Connect
La prise en charge d'IMS TCP/IP OTMA Connection (IMS TOC) prendra fin en mars 2001. Nous recommandons aux utilisateurs de migrer d'IMS TOC vers IMS Connect
et d'utiliser ce dernier élément à la place d'IMS TOC.
IMS Connect est un produit IBM installable via SMP disponible séparément (il n'est pas inclus avec VisualAge for Java) que vous pouvez utiliser avec VisualAge for Java IMS Connector pour accéder à IMS. Après avoir effectué une migration d'IMS TOC vers IMS Connect, vous pouvez continuer d'utiliser les programmes IMS Connector for Java. Il n'est pas nécessaire de les changer ou de les mettre à jour.
D.5.2.2 CICS Connector
Le comportement de l'indicateur CICSELUW dans la
spécification ECIInteractionSpec a été modifié afin de se conformer à
l'architecture CCF Connector. Dans les versions précédentes, la
valeur par défaut de cet indicateur était FALSE pour le constructeur.
De plus, qu'un coordinateur réel soit présent ou non, cet indicateur
déterminait toujours si l'unité de travail logique était développée.
Dans cette version, la valeur de l'indicateur CICSELUW est TRUE pour le constructeur ECIInteractionSpec si vous disposez d'un coordinateur CCF réel (JavaCoordinator, par exemple). Sauf si vous avez spécifiquement défini cette propriété dans l'ancien code VisualAge for Java, la valeur par défaut sera TRUE pour la propriété CICSELUW dans l'ancien code, une fois que vous avez effectué une migration vers VisualAge for Java, version 4.0.
Lorsqu'aucun coordinateur réel n'est présent, cet indicateur est ignoré et toutes vos applications (à la fois les anciennes et les nouvelles créées dans VisualAge for Java, version 4.0) se comportent comme si la valeur FALSE était attribuée à l'indicateur CICSELUW. C'est pourquoi, la définition de cet indicateur n'aura aucune influence sauf si vous employez un coordinateur réel dans votre environnement.
D.5.2.3 Migration d'e-connector
Alors que de nombreuses versions précédentes de VisualAge for Java peuvent
coexister avec la version 4.0.x, la coexistence de différents niveaux
d'e-connector n'est pas prise en charge.
Migration à partir de VisualAge for Java, version 3.0x ou version 3.5.x
Si des e-connectors sont installés, vous devez suivre l'un des deux scénarios de migration ci-dessous afin de procéder à la migration depuis une version 3.0x ou 3.5.x de VisualAge for Java vers la version 4.0.
La différence entre les deux scénarios de migration se trouve dans l'étape de migration des connecteurs.
Dans le scénario 1, la migration des connecteurs s'effectuent lors de l'installation initiale. Une fois les étapes de ce scénario accomplies, VisualAge for Java, version 3.0x ou 3.5.x sans connecteurs sera installé et coexistera avec VisualAge for Java, version 4.0 avec connecteurs.
Dans le scénario 2, la migration des connecteurs a lieu après le processus de migration initial. Une fois les étapes de ce scénario accomplies, vous disposez de VisualAge for Java, version 4.0 sans les connecteurs, coexistant avec VisualAge for Java, version 3.0x ou 3.5.x avec connecteurs. Par la suite, vous pouvez désinstaller les connecteurs de la version 3.0x ou 3.5.x et installer les connecteurs de la version 4.0.
Scénario de migration 1
Pour éviter les conflits et les erreurs avec des installations futures de connecteurs, les variables d'environnement ne doivent contenir aucune référence aux connecteurs supprimés. Pour éditer les variables d'environnement :
Windows NT et Windows 2000
Windows 98
Access Builder et Connector pour SAP R/3 fournissent également quelques classes d'utilitaires (par exemple, LogonBean) associées à Swing 1.0.3. Ces classes sont remplacées par des classes associées à Swing 1.1. Lors de la migration depuis une version 3.0x ou 3.5.x vers la version 4.0, vous devez effectuer la migration de vos propres classes associées à Swing 1.0.3 vers le niveau 1.1 pour continuer d'utiliser les classes d'utilitaire fournies par Access Builder et Connector pour SAP R/3. Pour ce faire, vous pouvez utiliser l'outil Correction/Migration de l'environnement IDE.
Scénario de migration 2
Pour installer les connecteurs de VisualAge for Java, version 4.0, vous devez désinstaller la version 3.0x/3.5.x ou désinstaller les connecteurs 3.0x/3.5.x en suivant les étapes décrites dans le scénario de migration 1.
Une fois que vous avez désinstallé les connecteurs de la version 3.0x/3.5.x ou VisualAge for Java, version 3.0x/3.5.x, vous pouvez alors installer les connecteurs de la version 4.0 en suivant les étapes ci-dessous.
Migration à partir de VisualAge for Java, version 3.5 ou 3.5.3
Si vous effectuez une migration depuis VisualAge for Java, version 3.5 ou 3.5.3 vers VisualAge for Java, version 4.0, les connecteurs IBM installés avec VisualAge for Java 3.5 ou 3.5.3 doivent d'abord être désinstallés pour garantir que la version de ces connecteurs qui sera installée avec VisualAge for Java 4.0 est correcte.
Si vous installez VisualAge for Java, version 4.0 avant de supprimer les connecteurs IBM de la version 3.5 ou 3.5.3, une boîte de dialogue vous signale que vous devez d'abord migrer toutes vos applications qui utilisent les connecteurs IBM avant de continuer l'installation de la version 4.0.
Pour migrer vos applications et désinstaller les connecteurs IBM de la version 3.5 ou 3.5.3, procédez comme suit :
Pour éviter les conflits et les erreurs avec des installations futures de connecteurs, les variables d'environnement ne doivent contenir aucune référence aux connecteurs supprimés. Pour éditer les variables d'environnement :
Windows NT et Windows 2000
Windows 98
Désinstallation des connecteurs
Lors de la désinstallation de VisualAge for Java, version 4.0, les connecteurs sont automatiquement désinstallés. Pour éviter les conflits et les erreurs avec des installations futures de connecteurs, les variables d'environnement ne doivent contenir aucune référence aux connecteurs supprimés. Pour éditer les variables d'environnement, suivez la procédure ci-après.Windows NT et Windows 2000
Windows 98
Windows 98 uniquement : Vous pouvez avoir à supprimer manuellement le répertoire des e-connectors (correspondant par défaut à C:\IBM Connectors) une fois que vous avez désinstallé VisualAge for Java.
D.6.1 Migration depuis la version 2.0 de VisualAge for Java
Les classes générées à l'aide d'Enterprise Toolkit pour AS/400 avec VisualAge for Java version 2.0 ne sont pas compatibles avec les classes Java générées à l'aide d'Enterprise Toolkit pour AS/400 avec VisualAge for Java version 4.0. Cette incompatibilité s'explique par le fait que les classes ET/400 Java créées avec la version 2.0 utilisent Abstract Windowing Toolkit (AWT) tandis que les classes ET/400 Java créées avec la version 4.0 utilisent Java 2 SDK Swing.
Toutefois, les classes fournies avec la version 2.0 sont toujours disponibles dans le package com.ibm.ivj.et400.util.awt qui est inclus dans VisualAge for Java version 4.0. Si vous souhaitez utiliser les classes générées dans la version 2.0 dans VisualAge for Java version 4.0, vous devrez modifier dans ces classes toutes les références au package com.ibm.ivj.et400.util en références au package com.ibm.ivj.et400.util.awt. Il vous suffit d'utiliser le smartguide Correction/Migration fourni avec VisualAge for Java. Toutes les erreurs pouvant se produire pendant la migration seront enregistrées dans la fenêtre Journal. Pour plus d'informations sur l'utilisation de ce smartguide, reportez-vous à l'aide en ligne.
D.6.2 Migration depuis la version 3.0 ou 3.02 de VisualAge for Java
Si vous avez généré des classes Java à l'aide du smartguide Conversion de fichiers écran ET/400 avec la version 3.0 ou 3.02 de VisualAge for Java, ces classes ne sont pas compatibles avec les classes Java générées à l'aide du smartguide Conversion de fichiers écran ER/400 de VisualAge for Java version 4.0.
Cette incompatibilité s'explique par le fait que le code généré dans la version 3.0 et 3.02 utilise des classes déconseillées, telles que les classes AS400SVisualTextField et Subfile, tandis que le code généré dans la version 4.0 utilise les beans JFormatted. Toutes les classes déconseillées sont encore disponibles dans le package com.ibm.ivj.et400.util, qui est inclus dans VisualAge for Java, version 4.0. Si vous souhaitez utiliser les classes générées dans la version 3.0 ou 3.02, vous devez utiliser l'outil Correction/Migration pour convertir l'ensemble des classes migrées de façon à ce qu'elles fassent référence aux nouveaux noms de package Java 2 SDK Swing. Pour ce faire, vous devez sélectionner les classes concernées, ouvrir l'outil Correction/Migration et sélectionner la case à cocher Inclure les packages renommés JDK 1.2. Cette action aura pour effet de faire migrer automatiquement les références Swing vers Java 2 SDK. Pour plus d'informations sur cette tâche, reportez-vous à l'aide en ligne. Toutes les erreurs pouvant se produire pendant la migration seront enregistrées dans la fenêtre Journal.
Le smartguide Création d'un sous-fichier n'est pas inclus avec VisualAge for Java version 4.0. Il a été remplacé par les beans DFU et JFormattedTable les plus puissants. Si vous souhaitez continuer d'utiliser le smartguide Création d'un sous-fichier pour générer un code, vous devez continuer d'utiliser une version précédente (3.02 ou antérieure) de VisualAge for Java. Tout code généré par le smartguide Création d'un sous-fichier dans la version 3.0 ou 3.02 peut être migré vers la version 4.0 étant donné que les classes requises pour le code généré sont toujours prises en charge et sont disponibles dans le package com.ibm.ivj.et400.util. Vous devez suivre la procédure décrite au paragraphe précédent pour faire migrer votre code.
La version d'ET/390 que vous devez utiliser pour développer des applications OS/390 varie en fonction du niveau SDK disponible sur les systèmes OS/390 ou les applications middleware et du niveau SDK pris en charge par VisualAge for Java (ET/390 compris).
Deux niveaux SDK sont disponibles sur les systèmes OS/390 et les applications middleware, comme indiqué dans le tableau ci-dessous.
Système ou application middleware | Niveau SDK |
---|---|
OS/390 | SDK 1.1.8, 1.3.0 |
WebSphere Application Server, Version 3.0 | SDK 1.1.8 |
CICS Transaction Server, Version 1.3 | SDK 1.1.8 pour les transactions interprétées et compilées |
DB2 Universal Database, Versions 5 et 6 | SDK 1.1.8 pour les procédures mémorisées compilées uniquement |
Dans VisualAge for Java, chaque version du produit prend en charge des niveaux SDK différents, comme indiqué dans le tableau suivant :
VisualAge for Java | Niveau SDK |
---|---|
Versions 3.5, 3.5.3 et 4.0 | SDK 1.2.2 |
Version 3.02 | SDK 1.1.8 |
Les sections suivantes décrivent les types d'applications OS/390 que vous pouvez développer à l'aide des différentes versions d'ET/390.
VisualAge for Java, versions 3.5, 3.5.3 et 4.0
Dans VisualAge for Java, versions 3.5, 3.5.3 et 4.0, ET/390 est destiné principalement aux types d'applications suivants :
En ce qui concerne les applications interprétées exécutées sous WebSphere Application Server, Version 3.0, vous devez créer vos classes d'application de sorte qu'elles fonctionnent avec les interfaces API Java au niveau SDK 1.1.8. Après avoir créé les classes, vous pouvez les exporter sur une unité montée sur le système de fichiers NFS afin que celles-ci soient accessibles sur le système OS/390. Vous pouvez alors exécuter et déboguer votre application en cliquant sur les options de menu Exécution de main et Débogage de main à partir de l'environnement IDE de VisualAge for Java.
En ce qui concerne les applications interprétées autonomes exécutées sur le système OS/390, vous devez créer vos classes d'application de sorte qu'elles fonctionnent avec les interfaces API Java au niveau SDK 1.3.0. Après avoir créé les classes, vous pouvez les exporter sur une unité montée sur le système de fichiers NFS afin que celles-ci soient accessibles sur le système OS/390. Vous pouvez alors exécuter votre application en cliquant sur l'option de menu Exécution de main à partir de l'environnement IDE de VisualAge for Java.
Pour obtenir des informations détaillées sur le développement, l'exportation, l'exécution et le débogage des applications interprétées, reportez-vous à l'aide en ligne d'ET/390.
VisualAge for Java, Version 3.02
Dans VisualAge for Java, Version 3.0.2, ET/390 est destiné principalement aux types d'applications suivants :
Enterprise Toolkit pour Workstations (ET/WS) et le compilateur haute performance (HPJ) ne sont pas inclus dans cette version de VisualAge for Java. Si vous souhaitez continuer à utiliser Enterprise Toolkit pour Workstations, vous devrez continuer à travailler dans une version précédente (3.02 ou antérieure) de VisualAge for Java.
Aucune nouvelle fonction de VisualAge for Java version 4.0 ne remplace la fonctionnalité fournie précédemment par ET/WS. Une fonctionnalité similaire à ce qui était inclus dans ET/WS est disponible dans le compilateur "Just-in-time" qui fait partie de la machine virtuelle Java (JVM). La JVM est fournie avec IBM Developer Kit, Java Technology Edition, version 1.2.2, PTF 9.
Le compilateur JIT prend le code intermédiaire et le compile en code d'exécution direct, puis exécute les programmes. Le code intermédiaire est préservé et reste transférable. Toutefois, après avoir été compilé par le JIT, le code s'exécute plus rapidement. Pour plus d'informations, accédez au site Web de Sun à l'adresse http://java.sun.com.
Lorsque vous effectuez une migration de VisualAge for Java, version 3.5 vers la version 4.0, vous pouvez continuer à utiliser le contrôle de version externe au niveau des projets que vous utilisiez dans la version 3.5. Si les icônes de contrôle de version externe n'apparaissent pas tout d'abord, sélectionnez Outils > Contrôle de version externe > Régénération du projet et elles devraient apparaître.
Vous pouvez avoir à redémarrer l'API d'accès distant aux outils. Cette action peut être effectuée à partir de la boîte de dialogue Options. Sélectionnez Fenêtres > Option pour ouvrir la boîte de dialogue Options. Sélectionnez l'option d'accès distant à l'API Tools puis cliquez sur le bouton correspondant pour la lancer.
Si vous utilisez le compilateur IDL vers Java fourni par IBM Component Broker Series ou par la fonction CICS IIOP Server Support, vous devez définir manuellement la chaîne d'appel du compilateur IDL vers Java dans les boîtes de dialogue suivantes :
La page Compilateur IDL vers Java de la boîte de dialogue Options (accessible depuis le menu Fenêtres). Modifiez la chaîne dans la zone Commande.
Le boîte de dialogue Modifier les options de compilation IDL vers Java. Dans la page IDL, sélectionnez IDL > Modifier les options de compilation. Modifiez la chaîne dans la zone Commande.
Pour plus d'informations sur la modification de la chaîne et l'ouverture de la page IDL, reportez-vous à la documentation en ligne relative à l'environnement de développement IDL.
Pour plus d'informations sur le support CICS IIOP, reportez-vous à la section 1.0 du chapitre D.
Le niveau JDK a été modifié depuis la version 3.5 (il s'agit maintenant du JDK 1.2.2 PTF 9).
Si vous avez modifié la bibliothèque de classes Java VisualAge for Java, version 3.5 en remplaçant les packages ou les classes s'y trouvant, ces modifications ne seront pas automatiquement répercutées dans la bibliothèque de classes Java de la version 4.0 après migration. Vous devez à nouveau modifier manuellement la bibliothèque de classes Java.
La bibliothèque de classes Java était entièrement en mode lecture seule dans VisualAge for Java avant la version 3.5.
Si vous effectuez une migration à partir d'une version antérieure de VisualAge for Java vers VisualAge for Java, version 4.0, les deux fichiers ci-après seront remplacés par leur nouvelle version et toutes les modifications dont ils auront fait l'objet seront perdues.
Il est recommandé de sauvegarder ces fichiers avant de migrer vers la version 4.0 et d'ajouter vos anciennes modifications aux nouvelles versions de ces fichiers une fois la migration vers VisualAge for Java, version 4.0 terminée. Ne vous contentez pas de remplacer les nouvelles versions de ces fichiers par les anciennes car les nouvelles versions contiennent des informations qui n'existaient pas dans les versions antérieures.
L'Assistant de migration pour ActiveX n'est pas inclus dans cette version de VisualAge for Java. Vous pouvez faire migrer le code que vous avez créé à l'aide de l'assistant de migration dans des versions précédentes (3.02 or antérieure) de VisualAge for Java vers la version 4.0 en exécutant les étapes de migration générales décrites au chapitre B. Aucune nouvelle fonction de VisualAge for Java version 4.0 ne remplace la fonctionnalité fournie précédemment par l'assistant de migration pour ActiveX.
Remarque : Il n'est pas nécessaire d'appliquer Persistence Builder FixPak 3.5.1 ou FixPak 3.5.2 (disponible à partir de VADD) à VisualAge for Java, version 4.0. Ces corrections ont déjà été intégrées dans le code de la version 4.0.
Vous devez utiliser VisualAge for Java pour régénérer le code provenant de versions antérieures de Persistence Builder.
D.14.1 Mise à niveau spécifique à la version 2.0
Les problèmes de migration suivants vous concernent si vous effectuez une mise à niveau depuis VisualAge for Java version 2.0 :
Pour plus d'informations sur l'exécution de ces tâches, reportez-vous à la documentation en ligne relative à Persistence Builder.
D.14.2 Mise à niveau depuis toutes les versions antérieures (y compris la version 2.0)
Lorsque vous chargez les modèles, mappes ou schémas disponibles à partir de l'afficheur de modèle, les liens internes des métadonnées sont modifiés. Il ne vous est alors plus possible de charger sans risque les métadonnées dans un espace de travail d'un niveau de version inférieur à la version 4.0. Le modèle, la mappe ou le schéma s'affiche comme étant "modifié" (dirty). Sauvegardez le modèle, mappe ou schéma.
Remarque : Les informations suivantes s'appliquent uniquement si vous effectuez une migration de version 2.0 ou 3.0x de VisualAge for Java. Elles ne s'appliquent pas si vous effectuez une migration à partir de la version 3.5.
Les classes créées dans les versions précédentes pour les requêtes personnalisées comporteront des erreurs. Dans la structure de requête personnalisée, un objet Throwable est désormais lancé afin de vous permettre d'intercepter les exceptions se produisant lorsque la requête personnalisée est appelée. Par conséquent, toutes les requêtes personnalisées ayant été créées antérieurement seront signalées comme comportant une erreur non résolue (marquée d'un X rouge) dans l'IDE étant donné qu'elles ne prévoient pas la gestion de l'exception lancée. Pour corriger cette situation, lancez l'exception depuis votre requête personnalisée ou interceptez l'exception.
Vous pouvez obtenir plus d'informations sur la gestion des erreurs dans l'aide en ligne de VisualAge for Java.
Modifications du support d'exécution
Le projet qui contient les packages javax indispensables à l'environnement d'exécution Persistence Builder a changé de nom. Cela peut vous conduire à recalculer le chemin d'accès du projet pour les éléments de programme qui font appel à Persistence Builder, en procédant comme suit :
RMI Access Builder n'est pas inclus avec VisualAge for Java, version 4.0. Vous pouvez importer vos anciennes classes générées et vos anciens projets de bibliothèque d'exécution dans l'espace de travail de la version 4.0, mais vous ne pourrez pas exécuter le Gestionnaire d'instances d'objets distants étant donné qu'il n'est pas inclus. Vous devez connaître le nouveau modèle de sécurité Java 2 Platform et savoir quel peut être l'impact de ses restrictions sur vos applications RMI Access Builder.
Ajout de l'exécution de RMI Access Builder à l'espace de travail
Vous devez importer l'exécution RMI Access Builder de la version 3.0x
de VisualAge for Java et l'ajouter à votre espace de travail. Vous ne pouvez
pas exécuter les applications RMI Access Builder dans VisualAge for Java,
version 4.0 sans cela.
Migration de vos applications RMI Access Builder
Si vos applications RMI ne se trouvent pas encore dans le référentiel
version 4.0, exécutez la procédure suivante pour
les importer dans l'espace de travail.
Si vous souhaitez exécuter l'un quelconque de vos objets serveur, vous devrez d'abord créer une ligne de serveur principale. Par exemple, si vous avez un proxy côté serveur : Reverse1S, et ServerObj2S, vous pouvez écrire un serveur principal afin d'instancier les objets serveur :
import...;
public class Servermain {
public static void main(String arg[]) {
try{
Reverse1S myserver = new Reverse1S();
ServerOvj2S obj2 = new ServerObj2S();
}
catch (Exception e) {
e.printStackTrace();
}
System.out.print ln("Server Objects Started.");
}
}
En outre, en raison de restrictions de sécurité plus strictes, vous devrez définir un fichier de stratégie pour les serveurs et les clients. Par exemple, vous pouvez avoir un fichier de stratégie appelé "MyPolicy" :
grant {
//Grant all permissions (accorder toutes les autorisations)
permission java.security.AllPermission;
};
Ou une stratégie permettant à toute personne d'être en mode écoute sur les ports non privilégiés :
grant {
// allows anyone to listen on un-privileged ports (permet à quiconque d'être en mode écoute sur les ports non privilégiés)
permission java.net.SocketPermission "localhost:1024-", "listen";
permission java.net.SocketPermission "localhost:1024-", "resolve";
permission java.net.SocketPermission "pathfinder:1000-4000", "listen";
permission java.net.SocketPermission "pathfinder:1000-4000", "connect";
permission java.net.SocketPermission "pathfinder:1000-4000", "resolve";
};
où pathfinder est le nom de la machine de l'utilisateur.
Lorsque vous lancerez votre client, vous devrez exécuter une commande similaire à ce qui suit pour que le client soit lancé correctement :
java-Djava.security.policy=<myPolicy.file>
Par exemple, si vous exécutez main() dans l'environnement IDE, vous devez spécifier java.security.policy= dans la section Propriétés lors de la sélection de l'élément de menu "exécuter avec".
Vous devez conserver votre code sur la version précédente de VisualAge for Java de façon à pouvoir continuer à le développer ou à le régénérer.
Vous devez utiliser l'outil de migration IDE pour corriger les métadonnées pour les composés visuels. Reportez-vous à la rubrique de l'aide en ligne "Directives de correction/migration pour les références de classe ou de package" pour plus d'informations sur la façon de corriger les références de classe ou de package rompues en conséquence de la migration des classes vers J2SDK version 1.2.2 ou de la modification du nom d'éléments de programmes définis par l'utilisateur.
VisualAge for Java n'assure pas le suivi des dépendances entre les classes en cours de migration. Lorsque des classes sont référencées dans une classe et n'ont pas encore été migrées, il est possible qu'elles aient rencontré des problèmes d'initialisation de classe ou que leur analyse s'effectue incorrectement.
Toutes les erreurs pouvant se produire pendant la migration seront enregistrées dans la fenêtre Journal. Par exemple, supposez que le message suivant s'affiche dans la fenêtre Journal au cours de la migration d'une classe appelée Sample.Samp :
Migration de la classe : Sample.Samp
Echec de la migration de Class:<Pkg>X::Y
Sample.Samp fait référence à X::Y ; VisualAge for Java a rencontré des problèmes lors du chargement de la classe Y. Il est possible que la classe Y n'ait pas encore été migrée ou qu'elle soit manquante. (Dans l'éditeur de composition visuelle, la classe Y est signalée comme étant une classe à problème.) Pour corriger cette situation, faites migrer Y en premier, ou, si la classe Y est manquante, trouvez un remplacement. Dans les cas extrêmes, vous pouvez être amené à ouvrir Samp ou Y dans la version précédente de VisualAge for Java et à réinitialiser les beans ou les propriétés de façon à permettre la poursuite du processus de migration.
Dans certains cas, l'ouverture de la classe dans l'éditeur de composition visuelle peut entraîner l'ouverture de la boîte de dialogue Résolution des références de classe. Cette boîte de dialogue affiche les classes à problème qui existent dans l'éditeur de composition visuelle. La colonne Référence de classe non résolue de la boîte de dialogue indique la classe que VisualAge for Java a utilisée en tant que remplacement provisoire. Cette indication ressemble à ce qui suit :
com.ibm.uvm.abt.edit.DeletedClassView(X)
Le X qui apparaît entre parenthèses est le nom de la classe présentant un problème. Il est probable que X a été migrée correctement après la classe en cours. Pour corriger cette situation, sélectionnez la ligne à corriger, puis cliquez sur le bouton Remplacement. Dans la boîte de dialogue "Sélection d'une classe valide", sélectionnez la classe X en tant que classe de remplacement. Procédez de la même façon pour l'ensemble des classes non résolues, puis sélectionnez OK.
Servlet Builder et le lanceur de servlet ne sont pas inclus avec VisualAge for Java, version 4.0. Un fichier JAR d'exécution Servlet Builder compatible avec la version 4.0 est disponible à l'adresse URL http://www.ibm.com/vadd. Suivez le lien "Téléchargement".
Il n'existe pas de nouvelle fonction dans VisualAge for Java, version 4.0 qui remplace directement la fonctionnalité fournie précédemment par Servlet Launcher. Pour tester vos servlets, vous pouvez les lancer explicitement en entrant l'URL dans un navigateur Web ou en écrivant des pages HTML ou JSP pour les appeler. Pour développer de nouveaux servlets, vous pouvez utiliser le nouveau smartguide Servlet qui crée également une page HTML permettant de lancer votre servlet.
Vous avez deux possibilités pour utiliser le fichier d'exécution :
Scénario 1
Dans ce scénario, éditez le code dans votre édition précédente de VisualAge for Java à l'aide de Servlet Builder avant de l'exporter.
Scénario 2
Dans ce scénario, vous éditez votre code Servlet Builder dans VisualAge for Java en le testant dans WebSphere Unit Test Environment.
Procédez comme suit :
Vous pouvez trouver des informations supplémentaires sur l'exécution de cette procédure dans l'aide en ligne de VisualAge for Java.
La fonction Servlet Builder, qui était disponible dans les versions antérieures de VisualAge for Java, permettait de créer des servlets générant directement une interface utilisateur HTML. Cette fonctionnalité est utile pour le développement rapide d'applications, mais elle présente l'inconvénient de combiner la logique applicative de l'application à son interface utilisateur. Si vous souhaitez modifier l'interface utilisateur, alors l'ensemble du servlet doit être modifié. Pour faciliter la maintenance, il serait préférable d'utiliser la technologie JSP (JavaServer Pages) afin de séparer l'interface utilisateur de la logique applicative.
Une page JSP est un modèle HTML comprenant du contenu généré dynamiquement. Une page JSP peut être modifiée à l'aide d'outils d'édition HTML tels que la fonction PageDesigner dans IBM WebSphere Studio. Dans le modèle de programmation WebSphere d'IBM, les servlets sont toujours utilisés pour l'interaction avec le Web, mais ils délèguent la logique applicative aux beans Java et l'interface utilisateur aux pages JSP. Dans ce modèle de programmation, les servlets et les beans sont développés à l'aide d'outils Java et les pages JSP sont développées à l'aide d'outils HTML.
Cette séparation de la logique applicative et de l'interface utilisateur vous permet d'affecter des responsabilités de développement aux membres de l'équipe possédant les compétences et les outils appropriés, et se traduit par une maintenance plus facile.
Conformément au modèle de programmation WebSphere, la fonction qui était fournie par Servlet Builder a été remplacée par des outils Java dans VisualAge for Java et par des outils HTML dans WebSphere Studio. VisualAge for Java, version 4.0 comprend un nouveau smartguide (assistant) qui vous initie à la création d'applications Web en suivant le modèle WebSphere. Vous pouvez utiliser le smartguide Création d'un servlet pour générer un servlet qui appelle un bean pour la logique applicative et une page JSP pour l'interface utilisateur. Le smartguide génère également un formulaire HTML que vous pouvez utiliser pour tester le servlet. Le servlet peut être testé immédiatement dans l'environnement de test WebSphere de VisualAge for Java, puis être redéfini dans l'environnement IDE. Les fichiers JSP et HTML peuvent également être édités à l'aide de WebSphere Studio ou d'un autre outil HTML.
Le smartguide Création d'un servlet est basé sur l'assistant JavaBean de WebSphere Studio. Il comprend également des fonctionnalités supplémentaires requises par les programmeurs Java. Si vous utilisez déjà WebSphere Studio pour votre développement HTML, vous trouverez que le smartguide simplifie le flux de travail entre cet outil et VisualAge for Java. Les étapes de développement sont les suivantes :
Dans J2SDK version 1.2.2, les classes Swing se trouvent dans un package différent que dans JDK v1.1.x. Si vous avez besoin de mettre à jour les références aux classes Swing, vous pouvez utiliser le smartguide Correction/Migration.
Pour effectuer une migration de vos applications, vous devez sélectionner les classes et les packages concernés, ouvrir le smartguide Correction/Migration (en cliquant avec le bouton droit de la souris sur le package ou la classe, puis en sélectionnant Réorganisation > Correction/Migration) et cochez la case Inclure les packages renommés JDK1.2 pour faire migrer automatiquement les références Swing vers J2SDK v1.2.2. Les entrées De/Vers appropriées à Swing sont alors ajoutées. Toutes les erreurs pouvant se produire pendant la migration seront enregistrées dans la fenêtre Journal.
Reportez-vous aux rubriques suivantes de l'aide en ligne : "Directives de correction/migration pour les références de classe ou de package" et "Correction des références de classe ou de package" pour plus d'informations sur la procédure correcte de migration de vos applications.
Vous pouvez ne pas pouvoir utiliser l'éditeur de composition visuelle pour migrer toutes les propriétés Swing depuis JDK 1.1.7 vers Java 2 à cause de changements effectués entre la version 1.03 et la version 1.1.1 de Swing. Après avoir fait migrer votre code vers VisualAge for Java version 4.0, il se peut que vous ne puissiez pas ouvrir certaines classes d'application Swing dans l'éditeur de composition visuelle. Cela se produira uniquement lorsque vous avez utilisé la feuille de propriétés de l'éditeur de composition visuelle pour définir les propriétés d'un objet Javabean vers un objet Swing.
Pour contourner ce problème, procédez comme suit :
- Ouvrez à nouveau la classe dans la version précédente de VisualAge for Java (dans l'éditeur de composition visuelle).
- Dans la feuille de propriétés de la classe, cliquez sur le bouton Régénération. Une fenêtre s'ouvre répertoriant toutes les propriétés de bean que vous avez modifiées. Reconfigurez toutes les propriétés définies pour des objets Swing afin qu'elles retrouvent leur valeur par défaut.
- Sauvegardez la classe et réimportez-la dans la version 4.0 de l'environnement IDE.
Pour des informations relatives à la migration depuis la version Beta 1.2 de XMI Toolkit, reportez-vous aux notes d'édition XMI Toolkit.
Si vous avez utilisé une version différente de la version 3.5 de XMI Toolkit, (par exemple, un module technique provisoire, une version alphaWorks ou une version bêta précédente), vous devez la désinstaller et supprimer les mises à jour apportées à l'environnement lors de l'installation avant d'utiliser cette version de XMI Toolkit. Les instructions de migration sont fournies uniquement pour la version 1.2.
Les fichiers ZIP et XMI générés à partir des versions bêta 1.2 et pré-bêta 1.2 ne sont pas compatibles avec la version 3.5 ou 3.5.x de XMI Toolkit.
Dans la version 4.0 de VisualAge for Java, vous pouvez désormais versionner et publier vos fichiers de ressources de projet. Pour plus d'informations sur cette nouvelle fonctionnalité, reportez-vous à l'aide en ligne de VisualAge for Java relative à l'environnement IDE et coopératif.
Si vous avez fait migrer des projets depuis la version 2.0 ou 3.0x de
VisualAge for Java vers la version 4.0 de VisualAge for Java, vous devez suivre
la procédure ci-après une fois le processus de migration achevé. Il n'est pas nécessaire d'effectuer
cette procédure dès la migration effectuée mais tant que cette
procédure n'aura pas été suivie, vos ressources de projet ne seront
pas versionnées dans le référentiel.
Remarque : Il n'est pas nécessaire de suivre cette procédure
si vous avez effectué la migration des projets de la version 3.5.
Si vous envisagez de travailler dans un environnement coopératif avec VisualAge for Java, Enterprise Edition, vous devez utiliser EMSRV, version 7.1.
OS/2 et AIX ne sont pas pris en charge en tant que plateformes de développement pour VisualAge for Java version 4.0. Vous pouvez installer VisualAge for Java version 4.0 en tant que client uniquement sous Windows NT, Windows 98 et Windows 2000. Si vous souhaitez utiliser la version 4.0 avec votre référentiel OS/2 et AIX, vous devez vous connecter à ce référentiel à partir de l'environnement IDE version 4.0. Pour plus d'informations sur la façon d'exécuter cette tâche, reportez-vous à l'aide en ligne.
Si vous avez écrit du code spécifique à une plateforme, vous devez le réécrire de façon à ce qu'il soit compatible avec Windows.
Deux scénarios
Remarque : AIX and Windows ne pouvant pas être installés sur une même machine, les étapes du scénario 1 ne s'appliquent qu'à OS/2.
Scénario 1
Si votre référentiel OS/2 ivj.dat se trouve sur la même machine que le client Windows, procédez comme suit :
Scénario 2
Si votre référentiel OS/2 ou AIX ivj.dat se trouve sur une machine différente de celle du client Windows, procédez comme suit :
En raison d'une modification de la stratégie de sécurité s'appliquant aux applets exécutées sur la plateforme Java 2 v1.2.2, les applets ne peuvent plus accéder aux ressources locales.
Plusieurs exemples qui étaient disponibles dans les versions antérieures de VisualAge for Java ne sont pas inclus dans la version 4.0 du fait de cette restriction. De même, certains des exemples inclus ne peuvent être exécutés qu'en tant qu'applications, faute de quoi ils ne fonctionneront pas correctement. Pour obtenir des instructions sur la façon d'exécuter ces exemples correctement, reportez-vous à la documentation en ligne.
Vous pouvez modifier les stratégies de sécurité par défaut en créant votre propre fichier java.policy et en lançant l'afficheur d'appel avec les paramètres suivants : -Djava.security.policy=someURL
où someURL est l'emplacement de votre nouveau fichier de stratégie. Pour obtenir des informations spécifiques sur la sécurité dans Java, reportez-vous à l'adresse URL : http://java.sun.com/security. Pour obtenir des informations spécifiques sur la syntaxe des fichiers de stratégie, reportez-vous à l'adresse URL :http://java.sun.com/products/jdk/1.2/docs/guide/security.
L'outil Contrôle de version externe, intégré à VisualAge for Java, version 3.5, vous permet de vous connecter à des fournisseurs SCM (source code management, gestion du code source) externes, tels que ClearCase, PVCS Version Manager, TeamConnection, and SourceSafe à partir de VisualAge for Java. Grâce à cet outil, vous pouvez ajouter des classes à votre fournisseur SCM, vérifier les fichiers de classes et de ressources en entrée et en sortie du système SCM, et importer la dernière version archivée d'une classe depuis le système SCM.
Cet outil remplace l'ancien outil SCM externe et offre des fonctionnalités accrues.
Vous pouvez utiliser des gestionnaires ORB (Object Request Brokers) tiers dans VisualAge for Java s'ils sont compatibles avec le J2SDK version 1.2.2. Vous devez importer les classes ORB dans l'environnement IDE avant de pouvoir les utiliser.
Lorsque vous importez des classes Java dans l'environnement IDE, vous pouvez ajouter des classes d'extension ORB aux Bibliothèques de classes Java. Vous pouvez également remplacer certaines classes d'extension ORB disponibles dans les bibliothèques de classes Java existantes à condition qu'elles ne fassent pas partie des classes principales du J2SDK version 1.2.2.
Vous trouverez un article comportant plus de détails sur l'utilisation de gestionnaires ORB tiers dans la version 3.5.x à l'adresse URL suivante :
http://www.ibm.com/software/vadd/Data/Document2175
Cet article comporte des informations relatives au développement de l'architecture CORBA (Common Object Request Broker Architecture) et aux applications ORB dans VisualAge for Java.
Certaines classes de bibliothèque de classes Java peuvent être remplacées lorsqu'un ORB tiers est importé dans VisualAge for Java. Le correctif 2 de la version 3.5 corrige un bogue qui vous permettait de manière erronée d'importer certaines classes immuables (contenues dans des packages modifiables) dans VisualAge for Java. Après avoir appliqué le correctif 2 à VisualAge for Java, version 3.5, vous pouvez recevoir de nouveaux avertissements dans la fenêtre de journalisation lors de l'importation d'un ORB tiers. Ces avertissements se produisent parce que vous ne pouvez pas importer de classes immuables dans VisualAge for Java une fois que le correctif 2 est appliqué. Ces avertissements peuvent être ignorés.
Le CD VisualAge for Java Additional Features contient les composants suivants :
Le Guide d'installation et de migration et le fichier README du produit se trouvent sur le CD Additional Features et sur le CD principal du produit.
Remarque : Le CD Additional Features n'est inclus qu'avec VisualAge for Java, Enterprise Edition. Les composants suivants sont toutefois inclus dans le CD de VisualAge for Java, Professional Edition :
Le Guide d'installation et de migration et le fichier README du produit se trouvent sur le CD de VisualAge for Java, Professional Edition.
IBM J2EE Connectors and Tools for J2EE(TM) - Beta
Cette version de VisualAge for Java inclut une version bêta de plusieurs composants de la plateforme Java 2, Enterprise Edition (J2EE) que Sun Microsystems Inc. n'a pas encore publiée officiellement. Il s'agit des composants suivants :
Les composants bêta se trouvent dans le sous-répertoire extras\BetaJ2EEConnectors. Pour utiliser ces composants bêta, reportez-vous au fichier README, dans le répertoire BetaJ2EEConnectors, afin d'en connaître les instructions d'installation.
Remarque : Les composants livrés avec VisualAge for Java version 4.0 ne sont pris en charge que par Windows NT et Windows 2000. Les fichiers de l'environnement d'exécution J2EE ne sont pas tous pris en charge. Pour plus d'informations sur les composants J2EE, reportez-vous à l'aide en ligne et aux notes d'édition d'Enterprise Access Beans.
Team Server (EMSRV)
Le répertoire TeamServer du CD Additional Features contient le programme serveur du référentiel EMSRV et le fichier d'administration et de configuration du serveur (emsrv71.htm ou emsrv70.htm pour les langues autres que l'anglais). Pour les instructions d'installation d'EMSRV, reportez-vous au chapitre C et pour plus d'informations sur le démarrage du serveur, au fichier d'administration et de configuration du serveur (situé dans le répertoire TeamServer\docs).
Distributable Run-Times
Lorsque vous exportez et déployez une applet ou une application créée à l'aide de VisualAge for Java, vous devez également déployer la bibliothèque d'exécution des fonctionnalités à l'aide desquelles vous avez créé le code (s'il en existe), et de spécifier le fichier JAR ou ZIP d'exécution déployé dans le chemin d'accès aux classes.
En général, les fichiers JAR sont compressés et sont utilisés lors de l'exécution d'applets externes à un serveur. Les fichiers Zip sont décompressés et doivent être placés dans le chemin d'accès aux classes de la machine de déploiement pour l'exécution des applications en local.
Les bibliothèques d'exécution de VisualAge for Java se trouvent dans les répertoires extras/runtime30 and extras/runtime35. Suivant la fonctionnalité de VisualAge for Java installée, l'intégralité des bibliothèques d'exécution ou seulement certaines d'entre elles sont également fournies dans le répertoire eab/runtime35 ou runtime30 de l'image d'installation. Remarque : Les bibliothèques de l'environnement d'exécution J2EE ne sont pas incluses sur le CD Additional Features. Les fichiers de l'environnement d'exécution des connecteurs J2EE se trouvent dans eab\runtime 35 et IBM Connectors\classes une fois l'installation des composants beta terminée.
Pour plus d'informations sur l'installation et l'utilisation des bibliothèques d'exécution, consultez l'aide en ligne.
IBM Developer Kit 1.2.2 (pour Windows)
IBM Developer Kit, Java Technology Edition, v 1.2.2, PTF 9, situé dans le répertoire IBM Developer Kit, est un environnement de développement Java permettant de développer des applets et des applications Java autonomes conformes à la spécification 100 % Java.
Il inclut des outils permettant de développer des applets et des applications Java, tels que les outils suivants :
Pour installer IBM Developer Kit, exécutez install.exe depuis le répertoire IBM Developer Kit. Pour obtenir des informations plus détaillées sur IBM Developer Kit, reportez-vous au fichier README se trouvant dans le répertoire IBM Developer Kit.
Merant DataDirect SequeLink Java Edition version 5.1 pour Oracle et Microsoft SQLServer
VisualAge for Java version 4.0 prend en charge le pilote de Merant's DataDirect SequeLink Java Edition version 5.1 pour l'accès à la base de données Microsoft SQL Server et Oracle.
Remarque : Le serveur Merant DataDirect SequeLink Java Edition version 5.1 livré avec VisualAge for Java version 4.0 n'est pris en charge que par Windows NT et Windows 2000.
SequeLink est un composant intermédiaire d'accès aux données qui permet aux dernières normes JDBC une connectivité à diverses bases de données telles qu'Oracle, au serveur Microsoft SQL et aux données système. Le composant client de SequeLink ne dépend pas de la base de données ; aucune modification n'est donc nécessaire si de nouvelles bases de données sont ajoutées à l'infrastructure. Un client SequeLink est inclus dans WebSphere Test Environment.
Remarque : Le client SequeLink étant personnalisé, vous ne pouvez communiquer avec le serveur Merant DataDirect SequeLink Java Edition Version 5.1 que lorsque vous utilisez le client avec WebSphere Test Environment ou Websphere Application Server. Merant DataDirect Sequelink Java Edition version 5.1 n'étant pas un serveur sous licence, vous ne pouvez l'utiliser qu'avec le client Sequelink personnalisé. Si vous disposez d'un serveur Merant DataDirect SequeLink Java Edition version 5.1 sous licence, le client Sequelink personnalisé peut également être utilisé.
Le serveur SequeLink correspondant est disponible comme installation non codée (aucune clé d'enregistrement ne vous sera demandée lors de l'installation). Le serveur peut être installé depuis le sous-répertoire Merant\SequeLinkServer du CD Additional Features.
Le processus d'installation et de configuration du pilote dépend du composant avec lequel vous l'utiliserez. Pour des informations d'installation et de configuration plus spécifiques (et des informations sur la configuration du client SequeLink inclus avec WebSphere Test Environment), reportez-vous aux notes d'édition ci-après.
Distributed Debugger
Si vous avez l'intention de déboguer des classes développées en dehors de l'environnement IDE VisualAge for Java ou de déboguer des programmes s'exécutant sur un système distinct, vous devez installer Distributed Debugger.
Distributed Debugger est pris en charge par les systèmes d'exploitation suivants : Windows, AIX, OS/2, HP-UX, Solaris, Linux et Linux/390. Tous les fichiers Debugger se trouvent dans le répertoire Debugger du CD-ROM Additional Features. Reportez-vous à la rubrique 2.1.1.1, , du chapitre B, pour les instructions d'installation.
avant-premières techniques
Le CD Additional Features contient deux avant-premières techniques : IBM Stored Procedure Integration Tool for Enterprise JavaBeans et XMI Bridge.
IBM Stored Procedure Integration Tool for Enterprise JavaBeans
IBM Stored Procedure Integration Tool for Enterprise JavaBeans (outil d'intégration SP pour EJB) permet d'améliorer vos EJB de session sans état en ajoutant des méthodes qui font appel à des procédures mémorisées dans des bases de données. A l'aide du smartguide de création de méthode d'appel des procédures mémorisées, vous pouvez définir vos méthodes, puis les générer dans votre bean de session sans état.
A l'aide de l'outil d'intégration pour EJB, vous pouvez optimiser la logique applicative de vos procédures mémorisées dans un environnement EJB. Vous pouvez minimiser votre effort de développement EJB et éviter une logique applicative redondante sur votre serveur EJB et votre système DBMS (database management system). En outre, les procédures mémorisées permettant de réduire le trafic réseau entre le serveur EJB et le système DBMS, vous pouvez améliorer les performances de vos applications de production.
L'outil d'intégration SP pour EJB se trouve dans le sous-répertoire extras\spt. Pour plus d'informations sur l'installation et l'utilisation de l'avant-première technique, consultez le fichier EJB_SPTool.PDF, dans le répertoire spt. A l'issue de l'installation de l'outil d'intégration SP pour EJB, le fichier EJB_SPTool.PDF se trouve dans le répertoire x:\ibmvjava\ide\tools\com-ibm-ivj-sptools, x:\ibmvjava étant le répertoire d'installation du produit.
XMI Bridge
XMI Bridge est une avant-première technique pour Persistence Builder et Enterprise Java Beans qui permet d'importer un fichier modèle Rational Rose ou un document XMI dans un modèle Persistence Builder ou un groupe d'EJB.
XMI Bridge se trouve dans le répertoire extras\xmib. XMI Toolkit doit être installé sur l'espace de travail pour que vous puissiez utiliser XMI Bridge. Pour plus d'informations sur l'installation et l'utilisation de l'avant-première technique, consultez le fichier README, dans le répertoire xmib.
Documentation imprimable
Une partie de l'aide en ligne est présentée sous forme de documents PDF pouvant être affichés et imprimés via Adobe Acrobat Reader (téléchargeable depuis http://www.adobe.com/). Les documents PDF ne sont pas tous disponibles dans toutes les langues. Ils se trouvent dans le répertoire PDF.
Pour connaître le contenu de chacun de ces fichiers, reportez-vous à l'index PDF (dans le Guide d'initiation).
Système d'aide - Guide d'identification des incidents
Pour plus d'informations sur la résolution des erreurs relatives à l'aide, reportez-vous au guide d'identification des incidents du système d'aide. Ce guide se trouve dans le répertoire Troubleshoot du CD Additional Features et est disponible dans toutes les langues.
Référentiel et ressources
Le répertoire ivj40 contient deux fichiers zip : ide.zip et wte_resources.zip. Le fichier ide.zip contient une copie du référentiel (ivj.dat), le répertoire des ressources du projet (ivj.dat.pr) et le fichier de l'espace de travail (ide.icx). Les fichiers wte_resources.zip contiennent une copie de sauvegarde des ressources de projet de la fonctionnalité WTE.
Vous trouverez ci-après une comparaison entre Data Access Builder, les beans Data Access et Persistence Builder. Une brève description de l'environnement de développement EJB est incluse, mais ce composant ne figure pas dans l'étude comparative.
La fonction Data Access beans permet d'accéder rapidement aux données relationnelles de façon visuelle. Cette fonction est conçue pour être utilisée avec des applications dans lesquelles un modèle d'objet réutilisable n'est pas requis. Vous pouvez utiliser des beans d'accès aux données pour créer des applications visuelles qui ont besoin d'une vue directe sur les tables de la base de données cible. Vous pouvez aussi intégrer des beans d'accès aux données dans votre code manuellement.
L'environnement de développement EJB permet de
développer des beans conformes à la norme de programmation EJB (Enterprise JavaBeans) de Sun Microsystems. L'environnement de développement EJB fournit tous les supports d'exécution nécessaires pour
IBM WebSphere Application Server. Un contrôle de cohérence incrémentiel vérifie que les beans
enterprise sont conformes aux spécifications de programmation EJB et indique les modifications à apporter pour
corriger les incohérences si nécessaire. Reportez-vous à l'aide en ligne pour plus d'informations sur l'environnement de développement
EJB.
Persistence Builder
fournit un support de persistance échelonnable pour les modèles
d'objet et correspond à la première étape vers l'environnement EJB
pour de nombreux clients. Les applications créées à l'aide de Persistence Builder peuvent se référer au modèle d'objet optimal réutilisable et le mapper rapidement vers n'importe quelle base de données relationnelles prise en charge. Persistence Builder prend en charge le mappage "vers le haut" (schéma vers objet) et le mappage "vers le bas" (objet vers schéma). Cette fonction mappe les objets ainsi que les relations entre les
objets vers des données stockées dans des bases de données relationnelles.
La suite du présent document décrit les différences entre les fonctions d'accès aux données, c'est-à-dire les beans Data Access, Data Access Builder et Persistence Builder.
Les détails de la mise en oeuvre de chaque fonction ne sont pas inclus. La documentation en ligne couvre la fonctionnalité supplémentaire que Persistence Builder et les beans Data Access offrent, telle que les relations, les éléments de palette visuelle, les capacités transactionnelles et le smartguide d'assistance SQL.
La liste des fonctions de base répertoriées ci-dessous correspond à une vue d'ensemble des principales possibilités de Data Access Builder. Chaque fonction de base a été mise en oeuvre de différentes façons pour chaque composant.
Partie 1 : Fonctions de mappage relationnel lié à un objet
Schéma de base de données - Mappage d'objets
Génération de code
Partie 2 : Fonctions d'exécution
Chapitre 3 : Fonctions des beans Data Access
Les mises en oeuvre des fonctions sont expliquées dans les pages ci-dessous. Les fonctions Data Access Builder et Persistence Builder sont toutes comparées les unes après les autres, alors que les fonctions comparables des beans Data Access (pour le mappage) sont énumérées à la fin de la section.
Schéma de base de données - Mappage d'objets
1.0 Schéma de base de données pour le mappage d'objets à l'aide des tables et des vues
Dans Data Access Builder
Remarque : Toutes les étapes de Data Access Builder doivent être effectuées dans une version antérieure de VisualAge for Java (3.02 ou précédentes) qui inclut Data Access Builder.
Dans le smartguide de mappage de schéma, sélectionnez la connexion DB2 ou ODBC, puis sélectionnez le bouton d'option de sélection des tables ou des vues de base de données. Cliquez sur Suivant. La page suivante s'ouvre et présente une liste de tables :
Sélectionnez les tables avec lesquelles vous voulez travailler et cliquez sur Fin. Les mappages d'un objet vers un objet entre ces tables et l'objet résultant seront créés. La fenêtre de Data Access Builder montre la colonne permettant d'attribuer les mappages qui ont lieu automatiquement.
Dans Persistence Builder
Dans l'afficheur de schémas, sélectionnez Schémas > Importation de schéma à partir de la base de données. Entrez les informations de connexion. La boîte de dialogue Sélection de tables s'ouvre.
Sélectionnez les tables et les vues souhaitées et cliquez sur OK. L'afficheur de schémas contient à présent le nouveau schéma et répertorie ses tables, ses colonnes et ses clés.
Sélectionnez Schémas > Génération de modèle à partir de schéma. Le modèle généré est un simple modèle de gestion un-un.
2.0 Schéma de base de données pour le mappage d'objets à l'aide de requêtes personnalisées
Dans Data Access Builder
Dans le smartguide de schéma de mappes, sélectionnez la connexion DB2 ou ODBC, puis le bouton d'option de saisie d'instruction SQL . Cliquez sur Suivant. Sélectionnez les tables avec lesquelles vous voulez travailler et cliquez sur Suivant. La page suivante s'ouvre :Entrez votre requête et cliquez sur Fin. L'exemple ci-dessus montre une requête de fusion de deux tables. Les requêtes associées à des valeurs de paramètres sont également prises en charge.
L'objet résultant contient les attributs provenant des deux tables comme indiqué ci-dessous.
Dans Persistence Builder
Vous pouvez utiliser Persistence Builder pour effectuer le mappage de requête de fusion en mappant le schéma manuellement.3.0 Schéma de base de données pour le mappage d'objets à l'aide des procédures de stockage
Dans Data Access Builder
Dans le smartguide de schéma de mappage, sélectionnez la connexion DB2 ou ODBC, puis sélectionnez le bouton d'option relatif à l'ensemble de résultats de procédure mémorisée. La page de procédure mémorisée s'ouvre et affiche la liste des procédures mémorisées. Entrez un nom pour le mappage, sélectionnez la procédure mémorisée et cliquez surFin.
L'objet résultant contient des attributs mappés aux colonnes de résultat de la procédure mémorisée. Les requêtes ou les procédures mémorisées des opérations CRUD ne sont pas prédéfinies pour ce type de mappage.
Dans Persistence Builder
Persistence Builder n'est associé à aucun outil prenant en charge le mappage des procédures mémorisées. Vous pouvez générer un "schéma de raccord" qui crée des classes de service squelettes, pour lesquelles vous devez fournir le code pris en charge. La méthode all-instances peut correspondre à :
/**
* Return a query spec for the query called
allInstances
* @return java.util.Vector
*/
public java.util.Vector allInstancesQuery() {
Vector aSpecArray = new Vector();
DatabaseCompoundType aCompoundType;
DatabaseQuerySpec spec = new
DatabaseCallableQuerySpec("{call getAllEmp ()}");
aCompoundType = new DatabaseCompoundType();
aCompoundType.addField((DatabaseTypeField)(new
com.ibm.ivj.db.base.DatabaseDecimalField("COMM")).setAttributes(9,2,3,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("EMPNO")).setAttributes(4,0,4,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseDecimalField("SAL")).setAttributes(9,2,3,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("DEPTNO")).setAttributes(2,0,4,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseStringField("ENAME")).setAttributes(10,0,12,false));
((DatabaseSelectQuerySpec)spec).setOutputShape(aCompoundType);
aSpecArray.addElement(spec);
return aSpecArray;
}
Génération de code
4.0 Opérations CRUD sur les objets
Data Access Builder
Les opérations CRUD de base (création, extraction, mise à jour et suppression) sont automatiquement générées à l'aide de mappage table/objet. Si vous utilisez des requêtes personnalisées ou des procédures mémorisées, ces requêtes manquent et vous devez manuellement les définir à l'aide de l'outil Data Access Builder. Par exemple, il peut s'agir d'une requête de jointure qui définit un objet Customer.
Entrez les instructions SQL suivantes :
INSERT
INTO TPF.CUSTOMER (
CUSNO,
FIRSTNAME,
MIDINIT,
LASTNAME,
HOMEPHONE,
HOMEADDR,
WORKPHONE,
BILLADDR,
BRANCHNO,
OPEN DATE)
VALUES (?, ?, ?, ?, ?, ?, ?,?, ? ,?)
Une fois que Data Access Builder a validé la requête, vous devez mapper les paramètres individuellement à l'aide de la page Paramètre.
Vous devez également définir la requête addCustomer2 pour l'insertion de la deuxième table de jointure CUSTDATA. La synchronisation des deux requêtes pour cette fonction atomique est traitée par l'utilisateur.
Persistence Builder
Persistence Builder génère toutes les opérations CRUD une fois qu'une mappe a été créée entre les schéma et modèle définis. En cas de jointures multi-tables, chaque requête de table est générée, et le moteur de service gère ces opérations en tant qu'unité atomique.
Les procédures mémorisées ne sont pas encore prises en charge dans les outils, mais les "schémas de raccord" peuvent être générés et étendus. Vous trouverez ci-après un exemple de requête de procédure mémorisée.
/**
*Return a query spec for the query called insert
* @return java.util.Vector
* @param args java.util.Vector
* @param anInjector com.ibm.vap.Persistence.BOInjector
public java.util.Vector insertQuery(java.util.Vector args,com.ibm.vap.Persistence.BOInjector anInjector) {
Vector aSpecArray = new Vector();
DatabaseCompoundType aCompoundType;
DatabaseQuerySpec spec = new DatabaseCallableQuerySpec("{call
insertEmp (?,?,?,?)}");
Vector stringArgs;
a CompoundType = new DatabaseCompoundType();
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("EMPNO")).setAttributes(4,0,4,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseDecimalField("SAL")).setAttributes(9,2,3,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("DEPTNO")).setAttributes(2,0,4,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseStringField("ENAME")).setAttributes(10,0,12,false));
StringArgs = new Vector();
stringArgs.addElement("EMPNO");
stringArgs.addElement("SAL");
stringArgs.addElement("DEPTNO");
stringArgs.addElement("ENAME");
spec.setInputShape(aCompoundType);
spec.setInputValues(args);
spec.setInputNamesWithDuplicates(stringArgs);
aSpecArray.addElement(spec);
return aSpecArray;
5.0 Prise en charge de requête personnalisée
Dans Data Access Builder
Les requêtes personnalisées dans Data Access Builder sont définies de la même façon que les requêtes CRUD. L'utilisateur ajoute la requête nommée et utilise la page des paramètres si nécessaire. La requête qui en résulte apparaît sous la forme d'une méthode de la classe BusinessObjectMgr.
Data Access Builder fournit également d'autres méthodes permettant de définir les requêtes personnalisées, telles que la substitution de prédicat SQL.
TheEmpMgr.select('WHERE WORKDEPT = 'E11');
Dans Persistence Builder
Il existe deux options permettant d'ajouter les requêtes personnalisées dans Persistence Builder. Les collections Lite peuvent être définies au niveau classe à l'aide de l'éditeur de classes. La page suivante permet d'effectuer des recherches et d'établir des filtres dans la classe indiquée.
Les requêtes de collection Lite sont généralement utilisées dans les listes de recherche ou les boîtes de dialogue pour "explorer en aval" les objets de gestion appropriés. Les méthodes résultantes renvoient des vecteurs d'"objets de données" qui peuvent être utilisés pour l'extraction de l'objet de gestion persistant correspondant.
Vous trouverez ci-après un exemple de code utilisant la collection lite ci-dessus.
VapCourseHomeImpl aHome = VapCourseHomeImpl.singleton();
VapDepartmentKey aKey = new VapDepartmentKey("Sales");
VapLiteCollection liteCollection = aHome.getByDepartmentLiteCollection(aKey);
Enumeration enum = liteCollection.elements();
VapCourseDataObject aDO;
VapCourse aCourse;
while (enum.hasMoreElements()) {
aDO =
(VapCourseDataObject)enum.nextElement();
aCourse =
aHome.find(aDO.getNumber());
//Fetching fully
hydrated EJBObject
}
Persistence Builder fournit également une structure de requêtes personnalisées qui peut être utilisée pour définir plusieurs opérations sur une classe de gestion. Ces requêtes renverront des objets de gestion complètement fonctionnels.
Vous trouverez ci-après un exemple de classe d'étudiant associée à la requête personnalisée "retrieveStudentsOver21". La classe Home pour les étudiants possède la méthode suivante :
public Vector retrieveStudentsOver21() throws
java.rmi.RemoteException,
com.ibm.vap.common.VapReadFailureException {
return customQuery("studentsOver21Query");
}
La requête QueryPool pour étudiants contient les méthodes correspondantes pour le service personnalisé :
/* Return a query spec for the query called studentsOver21
@return
java.util.Vector */
public java.util.Vector studentsOver21Query() {
Vector aSpecArray = new Vector();
aSpecArray.addElement(new DatabaseSelectQuerySpec(studentsOver21SqlString()));
return aSpecArray;
}
/* Return the SQL string for the query called studentsOver21Query
@return
java.lang.String */
public java.lang.String studentsOver21SqlString() {
return "SELECT T1.SNAME, T1.SNO, T1.SADVFNO, T1.SBDATE, T1.SADDR, T1.SPHNO,
T1.SMAJ, T1.SIQ FROM SPARKY.STUDENT T1 WHERE
T1.SBDATE <= (CURRENT DATE - 00210000.)";
}
Cette méthode est exécutée à partir de la base et possède le même comportement de mise en cache d'objets que la méthode All-instances. Pour plus d'informations sur cette méthode, reportez-vous à l'aide en ligne de Persistence Builder.
1.0 Capacité de magasin de données/transactionnelle
Dans Data Access Builder
Vous pouvez configurer les magasins de données de Data Access Builder à plusieurs niveaux d'application.
Les magasins de données Data Access Builder possèdent un modèle transactionnel à plat, c'est-à-dire que si plusieurs transactions sont nécessaires pour appliquer une fonction de gestion, un magasin de données représentant chaque transaction devra être activé.
Voici un scénario simple comportant un modèle Employee et un modèle Department :
EmployeeDatastore anEmpDS = new EmployeeDatastore().connect();
DepartmentDatastore aDeptDS = new DepartmentDatastore().connect();
Employee anEmp = new Employee();
Department aDept = new Department();
// Perform actions on anEmp and aDept
if (User Applied Employee Changes)
anEmpDS.commit()
else
anEmpDS.rollback();
aDeptDS.commit();
Persistence Builder
Dans VisualAge for Java, version 4.0, Persistence Builder peut utiliser le pool de connexion WebSphere à l'aide du nom JNDI pour effectuer des recherches dans la source de données. Cette option est disponible lors de la génération des classes de service.
Plusieurs magasins de données dans Persistence Builder ne sont requis que si des bases de données différentes sont utilisées pour accéder aux données des modèles. Plusieurs transactions imbriquées sont prises en charge pour chaque magasin de données. Les transactions ne sont pas sous-entendues comme elles le sont dans Data Access Builder. Les transactions utilisateur sont contrôlées par des objets de transactions qui peuvent consulter les objets de gestion des applications.
Vous trouverez ci-après un extrait de code montrant la même capacité transactionnelle que dans l'exemple Data Access Builder.
DB2Datastore aDS = DB2Datastore.singleton().activate();
Transaction empTransaction = Transaction.begin();
Employee anEmp = EmployeeHomeImpl.create("EmpNum1");
Transaction deptTransaction = Transaction.begin();
Department aDept = DepartmentHomeImpl.create("DeptNum1");// Do some actions on anEmp and aDept, always resuming the appropriate transaction before making changes to the corresponding BO.
if (User Applied Employee Changes)
empTransaction.commit();
else
empTransaction.rollback();
deptTransaction.commit();
Remarque : Dans Persistence Builder, aucune instruction SQL n'est exécutée tant qu'une transaction n'est pas validée. L'état transactionnel des objets est géré en interne jusqu'à ce qu'une annulation ou une validation ait lieu.
2.0 Prise en charge d'API
Les méthodes générées pour les objets métier résultants, et les objets de gestion associés, sont légèrement différentes selon les trois structures. Le tableau ci-dessous montre les classes et les méthodes utilisées pour chaque fonction.
|
Data Access Builder |
Persistence Builder |
Beans Data Access |
Création |
aBusinessObject.add(); |
aBusinessObjectHome.create(); |
aSelectBean.newRow(); |
Extraction |
aBusinessObject.retrieve(); |
aBusinessObjectHome.find (aKey); |
aSelectBean.setParameter ("ColumnName", value); aSelectBean.execute(); |
Extraction globale | aBusinessObjectMgr.select(); | aBusinessObjectHome.allInstances(); | aSelectBean.execute(); |
Mise à jour | aBusinessObject.update(); | (*) | Non prise en charge |
Suppression | aBusinessObject.delete(); | aBusinessObject.remove(); | Non prise en charge |
Suppression de l'élément en cours | aBusinessObject.deleteCurrent(); | Non prise en charge (**) | aSelectBean.deleteRow(); |
Mise à jour de l'élément en cours | aBusinessObject.updateCurrent(); | Non prise en charge (**) | aSelectBean.updateRow(); |
Validation | aBusinessObjectDS.commit(); | currentTransaction.commit(); | aSelectBean.commit(); |
Annulation | aBusinessObjectDS.rollback(); | currentTransaction.rollback(); | aSelectBean.rollback(); |
Activation | aBusinessObjectDS.connect(); | aDataStore.activate(); | aSelectBean.connect(); |
Réinitialisation | ABusinessObjectDS.disconnect(); | aDataStore.reset(); | aSelectBean.disconnect(); |
Exemple de code : Rechercher un employé et modifier son numéro de téléphone |
|||
Employee anEmp = |
EmployeeHome aHome = EmployeeHome.singleton(); Employee anEmp = anEmp.setPhoneno("555-9988"); |
Retrieve all employees: aSelectBean.execute();
positionToEmployee
aSelectBean. aSelectBean.updateRow();
aSelectBean.commit();
Retrieve result set with
aSelectBean.setParameter
aSelectBean.commit(); |
(*)Les opérations de mises à jour sont la conséquence de la modification des valeurs d'un objet métier ; si la transaction active est validée, les modifications seront synchronisées avec le magasin de données à l'aide de l'émission des instructions de mise à jour appropriées.
(**)La section relative à la prise en charge des curseurs développe d'autres solutions.
Prise en charge LOB
Data Access Builder |
Persistence Builder |
Beans Data Access |
Data Access Builder inclut une classe appelée DAIOStream, qui permet d'extraire des LOB de la base de données sans placer en mémoire l'objet entier. |
Persistence Builder ne prend pas encore en charge les LOB de flots de données. Les objets LOB sont placés en mémoire. |
DAB prend en charge les types de données de LOB JDBC 2.0. Si vous utilisez un pilote JDBC 2.0 pour extraire un LOB, vous pouvez extraire le LOB entier en mémoire ou juste l'emplacement du LOB. |
Formulaires rapides 3.0 (Fonctions RAD)
Data Access Builder |
Persistence Builder |
Beans Data Access |
La fonction de formulaire rapide de Data Access Builder procure des vues exemple rapides, à l'aide d'éléments AWT connus représentant le modèle fourni. |
Un ensemble d'éléments visuels de VCE ont pour but d'assister les utilisateurs dans la programmation visuelle. Ces éléments représentent des classes transactionnelles qui permettent à l'utilisateur de séparer visuellement les unités de travail. |
La version 4.0 contient un assistant d'application de base de données qui génère une application utilisant des composants Swing pour représenter les colonnes d'une table obtenue par un bean Select. Vous pouvez également utiliser les possibilités de formulaire rapide standard du VCE pour créer rapidement une UI en fonction des propriétés d'un bean Select. |
4.0 Prise en charge des date/heure/horodatage
Les outils Data Access Builder permettent à l'utilisateur d'indiquer les types de données date.heure "en cours", ce qui permet de générer l'instruction SQL appropriée. Persistence Builder et les beans Data Access ne prennent pas cette fonction en charge dans leurs outils mais vous pouvez ajouter l'instruction SQL manuellement.
5.0 Prise en charge du curseur
Data Access Builder prend en charge les fonctions de curseur pour les ensembles de résultats, tels que updateCurrent() ou deleteCurrent().
Persistence Builder ne prend pas encore en charge ces opérations. Vous pouvez à la place utiliser la fonction Data Access Beans.
Les beans Data Access prennent en charge les fonctions de curseur, l'élément visuel DBNavigator gérant la position du curseur. Voici une description de toutes les fonctions de curseur :
JDBC version 1.0 ne prend pas en charge le défilement arrière dans un ensemble de résultats JDBC. Le bean Select gère une mémoire cache de l'ensemble de résultats qui permet de naviguer dans l'ensemble de résultats ainsi que d'accéder directement à une ligne particulière. Ses propriétés permettent de contrôler la taille de la mémoire cache. Vous pouvez extraire l'ensemble de résultats entier dans la mémoire cache (qui est l'élément par défaut) ou n'extraire qu'un paquet à la fois. La taille et le nombre des paquets sont définis par l'utilisateur.
Une fois qu'un ensemble de résultats a été obtenu, le bean Select fournit des méthodes de mise à jour, de suppression ou d'insertion de lignes dans l'ensemble de résultats. L'utilisateur ne doit écrire aucune nouvelle instruction SQL afin d'exécuter ces fonctions.
6.0 Exécution asynchrone
Data Access Builder prend en charge une opération asynchrone en fournissant des interfaces exécutables pour les classes générées.
Persistence Builder fournit également des interfaces exécutables pour chaque opération CRUD et une interface pour les requêtes personnalisées. L'objet de service de chaque classe de gestion est associé à la méthode runAsynch(), qui détermine le type d'exécution de cette classe.
Les beans Data Access prennent en charge l'exécution asynchrone par le biais de l'outil DBNavigator qui engendre des instances exécutables "DBAction".
Questions de concurrence (verrouillage/niveaux d'isolement)
Data Access Builder ne dispose pas d'API permettant de définir le niveau d'isolement de la base de données pour la classe de magasin de données générée setTransactionisolement(int).
Persistence Builder gère ses propres transactions et prend en charge les niveaux d'isolement suivants en interne :
La transaction est associée au niveau d'isolement Lecture reproductible ou Lecture non reproductible. La mise en oeuvre du service pour la classe de gestion est associée à la valeur "avec verrouillage" ou "sans verrouillage". Pour plus de détails sur les différences entre les niveaux, reportez-vous à l'aide en ligne de Persistence Builder.
Les beans Data Access comportent une API permettant de définir le niveau d'isolement de la base de données. Vous pouvez indiquer le niveau d'isolement souhaité lorsque vous fournissez les informations de connexion à l'aide de l'éditeur de propriétés personnalisées via la méthode DatabaseConnection.setTransactionIsolation().
Le mappage des beans DAB s'effectue entre des tables et des beans Select. Ce mappage entre une table et un bean Select n'est pas 1:1, c'est pourquoi le bean Select ne représente pas la table. Toutefois, les beans Select peuvent être très utiles si vous voulez travailler avec la ligne en cours et avec un ensemble de résultats. Vous pouvez créer un ou deux beans Select permettant d'effectuer des opération de programmation de base de données basiques dans une table. Par conséquent, si vous utilisez DAX pour les opérations de base de données telles que les requêtes, l'écriture, la lecture et la suppression simples et rapides, DAB peut remplacer DAX.
Vous pouvez interagir avec les bases de données en définissant la propriété query (composée d'informations de connexion et de requêtes SQL) d'un bean Select. Les informations de connexion contenues dans la propriété query peuvent être utilisées par plus d'un bean select. Vous pouvez intégrer des beans select dans votre code visuellement à l'aide de l'éditeur de composition visuelle (VCE) ou manuellement.
Vous trouverez ci-après une présentation générale de la procédure à suivre pour créer un bean Select afin de travailler avec la ligne en cours d'une table client. Reportez-vous à l'aide en ligne pour plus de détails sur la réalisation de ces étapes.
Ce bean Select permet d'effectuer des opérations de base de données basiques (lecture, écriture, mise à jour et suppression) sur une ligne de la table client (lorsque le numéro du client est indiqué).
Création d'un bean Select secondaire
Un autre bean Select peut être créé pour travailler avec un ensemble de résultats (c'est-à-dire après une requête de base de données) en suivant la même procédure sans indiquer de condition. Ce deuxième bean Select permet de bénéficier de la fonctionnalité de l'ensemble de résultats DAB. La classe d'accès à la base de données pour ce bean Select a la forme suivante :
Beans Select et requêtes personnalisées
DAB prend en charge la création de beans Select utilisant des requêtes personnalisées. Conformément aux indications ci-après, le smartguide d'assistance SQL peut vous aider à créer une requête de jointure, à indiquer des conditions relatives à une requête, à sélectionner et à trier des colonnes, et à mapper des champs.
Beans Data Access et procédures stockées
Le bean Procedure Call permet de travailler avec des procédures mémorisées. La création d'un bean Procedure Call ressemble beaucoup à la création d'un bean Select. Le smartguide relatif aux procédures mémorisées répertorie les procédures mémorisées disponibles comme indiqué ci-dessous.
Pour plus d'informations sur l'utilisation du bean Procedure Call, reportez-vous à l'aide en ligne des beans Data Access.
Copyright et remarques
© Copyright IBM Corp.1997, 2001. Tous droits réservés.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Le présent document peut contenir des informations ou des références concernant certains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plus de détails, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial IBM. Toute référence à un produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit d'IBM. Il est de la responsabilité de l'utilisateur d'évaluer et de vérifier lui-même les installations et applications réalisées avec des produits, logiciels ou services non expressément référencés par IBM.
Le paragraphe suivant ne s'applique pas au Royaume-Uni ni à tout pays où de telles dispositions ne sont pas conformes à la législation locale :
LE PRESENT DOCUMENT EST LIVRE "EN L'ETAT". IBM DECLINE TOUTE RESPONSABILITE, EXPRESSE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE QUALITE MARCHANDE OU D'ADAPTATION A VOS BESOINS. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable. Le présent document peut contenir des inexactitudes ou des coquilles. Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut apporter des améliorations et/ou des modifications au(x) produit(s) et/ou programme(s) décrit(s) dans cette publication à tout moment et à sa seule discrétion.
Les références à des sites Web non IBM sont fournies à titre d'information uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils contiennent.
Les éléments figurant sur ces sites Web ne font pas partie des éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule responsabilité. IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans aucune obligation de sa part, tout ou partie des informations qui lui seront fournies. Le logiciel sous licence décrit dans ce document et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux termes du Contrat sur les produits et services IBM, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.
IBM, AIX, AS/400, DB2, OS/390, OS/400, RS/6000, S/390, VisualAge et WebSphere sont des marques d'IBM Corporation dans certains pays.
Lotus, Lotus Notes et Domino sont des marques de Lotus Development Corporation dans certains pays. Java et toutes les marques et logos incluant Java sont des marques de Sun Microsystems, Inc. dans certains pays. Microsoft, Windows et Windows NT sont des marques de Microsoft Corporation dans certains pays. Intel et Pentium sont des marques d'Intel Corporation dans certains pays. D'autres sociétés sont propriétaires des autres marques, noms de produits ou logos qui pourraient apparaître dans ce document.