IBM Rational Web Developer für Windows und Linux, Version 6.0 Migrationshandbuch
Kapitel 1. Migration
aus WebSphere Studio V5.1, 5.1.1 oder 5.1.2
Diese Dokumentation stellt Anweisungen zur Migration aus WebSphere Studio Site Developer V5.1.x auf Rational Web Developer V6.0 bereit.
Weitere Informationen
finden Sie zu den folgenden Themen:
Informationen zur
Verwendung von
Rational Web Developer finden Sie in der
Onlinehilfe.
Aktuelle Dokumentation
finden Sie unter folgender Adresse:
www.ibm.com/developerworks/rational.
Informationen zur
Migration von früheren Versionen von
WebSphere
Studio auf v5.x oder zur Migration von
VisualAge
für Java auf
WebSphere
Studio finden Sie unter
www.ibm.com/software/awdtools/studioappdev/support/,
wenn Sie nach dem Stichwort
"migration guide" (Migrationshandbuch)
suchen.
Gehen Sie wie folgt vor, um aus WebSphere Studio V5.1.x eine Migration
auszuführen:
- Bevor Sie mit der
Installation beginnen, lesen Sie die Informationen zur
Kompatibilität mit Eclipse V2.x und WebSphere Studio V5.1.x.
Beachten Sie, dass für Portletanwendungen, die mit
WebSphere
Studio V5.1.2 von Portal Toolkit V5.0.2.2 migriert wurden, keine
Unterstützung für Abwärtskompatibilität vorhanden ist.
- Sichern
Sie Ihren WebSphere Studio V5.1.x-Arbeitsbereich.
- Installieren
Sie
Rational Web Developer. Ziehen Sie dabei
die Informationen im Installationshandbuch (Datei install.html) hinzu.
Diese Datei steht im Root der ersten Produkt-CD zur
Verfügung.
- Empfehlung: Wenn Sie
Rational Web Developer zum ersten Mal
starten, werden Sie standardmäßig aufgefordert, zu bestätigen,
dass Sie einen Arbeitsbereich mit dem Namen rationalsdp6.0\workspace
verwenden wollen. Das heißt, das Dialogfenster des Startprogramms
für den Arbeitsbereich zeigt auf ein Verzeichnis, das nicht mit Ihrem
WebSphere Studio-Arbeitsbereich identisch ist. Wenn
Sie die neue Umgebung durchsuchen wollen, bevor Sie Ihren alten
Arbeitsbereich migrieren, übernehmen Sie die Standardeinstellung,
oder geben Sie beim Start von
Rational Web Developer einen anderen neuen
Verzeichnisnamen an. Sie erhalten dadurch beispielsweise die
Möglichkeit, ein oder zwei Testprojekte zu erstellen, Informationen
zu den neuen Funktionen zu lesen
(Hilfe -> Willkommen), einige der neuen Lernprogramme
auszuführen
(Hilfe -> Lernprogrammsammlung) oder einige der neuen
Beispiele auszuprobieren
(Hilfe -> Beispielsammlung).
- Migrieren
Sie Ihre Projekte auf V6.0. Projekte, die in
WebSphere Studio V5.1.x erstellt wurden, können
wie folgt automatisch auf V6.0 migriert werden:
- Migration eines Arbeitsbereichs: Wenn Sie bereit sind,
Ihren V5.1.x-Arbeitsbereich endgültig zu migrieren, starten Sie
Rational Web Developer mit Hilfe Ihres
alten Arbeitsbereichs. Ein Statusanzeiger bestätigt, dass Ihre
Projekte automatisch migriert werden.
Hinweis: Während der Migration des Arbeitsbereichs
wird das Dialogfenster
Probleme mit folgender Nachricht angezeigt:
Das Workbenchlayout konnte nicht wiederhergestellt
werden. Ursache: Bei der Wiederherstellung der Arbeitsumgebung sind
Probleme aufgetreten. Die Fehlernachrichten haben keine
Auswirkungen auf die erfolgreiche Migration des Arbeitsbereichs.
Notieren Sie sich den Namen der Perspektive, die nicht wiederhergestellt
werden konnte, indem Sie im Fehlerdialog auf den Knopf für Details
klicken. Klicken Sie anschließend auf
OK, um den Dialog zu schließen.
Zum Wiederherstellen
der Perspektive gehen Sie wie folgt vor:
- Schließen Sie die
Perspektive, indem Sie
Fenster -> Perspektive schließen auswählen.
- Öffnen Sie die
Perspektive erneut, indem Sie
Fenster -> Perspektive öffnen
auswählen.
Anmerkung:
Für EGL-Projekte (EGL, Enterprise Generation
Language), die in WebSphere Studio V5.1.2 die EGL-Webperspektive
verwendeten: Diese Perspektive wurde in
Rational Web Developer V6.0 entfernt. Alle
EGL-Projekte werden problemlos ohne diese Perspektive auf
Rational Web Developer V6.0 migriert. Wenn
Sie früher die EGL-Webperspektive verwendeten, führen Sie die
folgenden Schritte aus:
- Schließen Sie die
EGL-Webperspektive.
- Aktivieren Sie die
EGL-Funktionalität in den Benutzervorgaben
(Fenster -> Benutzervorgaben). Weitere Informationen zur
Aktivierung der EGL-Funktionalität finden Sie in der
Onlinehilfe.
- Wählen Sie
Fenster -> Perspektive öffnen aus, und wählen Sie die
Webperspektive aus.
- Migration von Projekten, die aus einem SCM-System für
Quellcodemanagement (Source Code Management) geladen werden:
Projekte aus WebSphere Studio 5.1.x, die in einem SCM-System
vorhanden sind, werden automatisch auf V6.0 migriert, wenn Sie in
Rational Web Developer geladen
werden.
- Migration von Projekten, die mittels Projektaustausch
importiert werden: Projekte, die aus
WebSphere Studio V5.1.2 oder V5.1.1 exportiert und
mittels der Projektaustauschfunktion in
Rational Web Developer V6.0 importiert
werden, werden automatisch auf V6.0 migriert. Die
Projektaustauschfunktion war in
WebSphere Studio V5.1.2 verfügbar und lag für
V5.1.1 als optionales Plug-in vor.
Hinweise:
- Für jedes auf
V6.0 migrierte V5.1.x-Projekt fügt das Migrationsprogramm in V6.0
automatisch eine .compatibility-Datei zum Projektordner hinzu. Diese
Datei wird für die Abwärtskompatibilität mit Benutzern von
WebSphere Studio V5.1.x benötigt. Sie sollten
diese Datei weder löschen noch editieren. Weitere Informationen
finden Sie im Abschnitt zu
-Kompatibilität mit WebSphere Studio V5.1.x.
Wichtig:
- Wenn dem
Arbeitsbereich, den Sie migrieren, Startkonfigurationen für den
Debugger zugeordnet sind, müssen Sie beachten, dass einige
Startkonfigurationen nicht automatisch migriert werden. Informationen
zum Wiederherstellen von Startkonfigurationen in einem migrierten
Arbeitsbereich finden Sie in Änderungen
am Debugger in V6.0.
- Wenn Sie den
XSLT-Debugger oder den EGL-Debugger für Projekte in ihrem migrierten
Arbeitsbereich verwendet haben, müssen Sie die mit
Rational Web Developer V6.0 installierte
Java-Laufzeitumgebung (JRE) ändern.
Informationen zum Ausführen dieser Änderungen finden Sie in Änderungen
am Debugger in V6.0.
- Wenn Sie Programme
haben, die mit EGL (Enterprise Generation Language) entwickelt und auf
V6.0 migriert wurden, sollten Sie beachten, dass in Version 6.0 neue
Wörter für EGL reserviert wurden. Wenn Sie diese Wörter als
Variablen- oder Komponentennamen verwenden, müssen Sie sie ändern.
Weitere Informationen finden Sie in Reservierte
EGL-Wörter in V6.0.
- Der
DB2-Net-JDBC-Treiber wird in
Rational Web Developer V6.0 nicht
unterstützt. Wenn Sie mit dem
DB2-Net-JDBC-Treiber JDBC-Verbindungen erstellt
haben, können Sie die Verbindungen in
Rational Web Developer V6.0 nicht
wiederherstellen. Sie müssen die Verbindungen so ändern, dass sie
einen der unterstützten JDBC-Treiber verwenden. Weitere Informationen
zu den in V6.0 unterstützten JDBC-Treibern finden Sie in der
Onlinehilfe.
- Wenn
Sie Inhalte von Web- oder XML-Dateien aus
WebSphere Studio Site Developer V5.1.x
migriert haben, die den Shift_JIS-Zeichensatz verwendeten und vom
Hersteller ausgewählte Zeichen enthielten, müssen Sie stattdessen
den Windows-31J-Zeichensatz angeben.
- Wenn
Sie in
WebSphere Studio Site Developer V5.1.x
Plug-ins anderer Hersteller installiert haben, müssen Sie sich die
entsprechenden Plug-ins für V6.0 besorgen und diese erneut
installieren.
- Wenn
Sie Funktionen verwenden, die Agent Controller benötigen, führen
Sie einen Upgrade für Agent Controller aus, indem Sie die mit
Rational Web Developer bereitgestellte
Version installieren. Weitere Informationen finden Sie im
Installationshandbuch.
- Informationen
zur Migration von VisualAge Generator finden Sie im Migrationshandbuch
VisualAge Generator to Enterprise Generation Language (EGL) Migration Guide;
dieses Handbuch befindet sich im PDF-Format in der Onlinehilfe im
Abschnitt "Installieren und Migrieren" unter dem Hilfethema "Auf das
Handbuch für die Migration von
VisualAge Generator zu EGL zugreifen". Die aktuellste
Kopie des Handbuchs finden Sie unter
http://www.ibm.com/developerworks/rational/library/egldoc.html.
Kompatibilität
mit WebSphere Studio V5.1.x
Wenn Sie einen Arbeitsbereich von WebSphere Studio V5.1.x zum ersten Mal in Rational Web Developer öffnen, wird er automatisch migriert. Nach der Migration eines Arbeitsbereichs können Sie ihn nicht mehr in WebSphere Studio Site Developer öffnen. Die im Arbeitsbereich von Version 6.0 vorhandenen Projekte können jedoch weiter mit WebSphere Studio V5.1.x gemeinsam verwendet werden, entweder durch Verwendung eines SCM-Systems (SCM, Source Code Management) zur Quellcodeverwaltung (beispielsweise Rational ClearCase), durch Importieren und Exportieren eines Projekts mittels Projektaustausch, oder durch Importieren von Archiven und Exportieren von Projekten. Wichtig: Für Portletanwendungen aus Portal Toolkit V5.0.2.2, die auf Portal Tools in Rational Web Developer V6.0 migriert werden, wird keine Abwärtskompatibilität unterstützt.
Anmerkung:
Folgendes
gilt nicht für Portletanwendungsprojekte.
Vorhandene Projekte von
Version 5.1.x, die aus einem SCM-System oder einem anderen Entwickler
mittels Projektaustausch in V6.0 importiert werden, können mit V5.1.x
gemeinsam verwendet werden, sofern Sie
keine der folgenden Aktionen ausführen:
- Ändern der
Kompatibilitätsmetadaten, die zur
.project-Datei und zur vom Migrationstool
erstellten .compatiblity-Datei hinzugefügt wurden
- Löschen der
.compatibility-Datei aus den
Projekten
Eine
.compatibility-Datei wird automatisch im
Projektverzeichnis erstellt, wenn ein V5.1.x-Projekt im
Rational Web Developer V6.0-Arbeitsbereich
geöffnet wird. Die .compatibility-Datei wird von
Rational Web Developer beim Migrieren von
Projektressourcen zum Überwachen der Zeitmarken der Ressourcen
verwendet. Sie sollten sie weder editieren noch löschen.
Weitere Informationen
zum Entfernen der Abwärtskompatibilität mit
WebSphere Studio Site Developer V5.1.x
finden Sie in Kompatibilität
mit WebSphere Studio V5.1.x inaktivieren.
Eclipse-bezogene Aspekte
Diese Version von Rational Web Developer basiert auf Eclipse
V3.0. Wenn Sie Ihre eigenen Plug-ins entwickeln, sollten Sie die
Informationen zu den Änderungen an der Plattform lesen, bevor Sie die
Migration ausführen.
Weitere Informationen
finden Sie in der Readme-Datei im Unterverzeichnis
eclipse\readme
der Installationsposition von
Rational Web Developer V6.0. Die folgenden
Abschnitte der Readme-Datei sind für die Migration relevant:
- Kompatibilität mit
früheren Releases
- Durchführung des
Upgrades des Arbeitsbereichs von einem früheren Release
- Interoperabilität
mit früheren Releases
J2EE-Projektkompatibilität
Die Kompatibilität
mit
Rational Web Developer V6.0 von Projekten,
die in WebSphere Studio V5.1.x erstellt wurden, wird über
Metadaten aktiviert, die beim Migrieren Ihres V5.1.x-Arbeitsbereichs
automatisch zu .project-Dateien hinzugefügt werden.
Gleichermaßen werden beim Erstellen eines neuen J2EE 1.2- oder
1.3-Moduls oder einer -Anwendung in
Rational Web Developer V6.0 automatisch
erstellte Metadaten für die Abwärtskompatibilität mit V5.1.x
zur .project-Datei hinzugefügt.
Anmerkung:
Wenn
ein in V6.0 erstelltes, neues J2EE 1.2- und J2EE 1.3-Modul oder eine
neue -Anwendung in
WebSphere Studio Site Developer V5.1.x
verwendet wird, wo V6.0-Erstellungsprogramme nicht zur Verfügung
stehen, werden auf Grund dieser Metadaten für Kompatibilität
Nachrichten hinsichtlich "fehlender Erstellungsprogramme" angezeigt oder
protokolliert. Diese Nachrichten sind normal, Sie können sie
ignorieren.
So lange diese Metadaten
für Kompatibilität vorhanden sind, werden beim Laden von
Rational Web Developer V6.0-Projekten in
WebSphere
Studio V5.1.x Nachrichten hinsichtlich "fehlender Erstellungsprogramme"
angezeigt. Es folgt ein Beispiel für eine solche
Nachricht:
!ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
!MESSAGE Das Erstellungsprogramm com.ibm.wtp.j2ee.LibCopyBuilder für Projekt Test60EARWeb wird übersprungen.
Entweder wurde das Erstellungsprogramm nicht
installiert oder es gehört zu einer
Projektgattung, die nicht vorhanden oder
inaktiviert ist.
Diese Nachrichten sind
normal, Sie können sie ignorieren. Wenn Sie sicher sind, dass Sie mit
einem bestimmten Projekt nicht mehr in
WebSphere
Studio V5.1.x arbeiten werden, können Sie die Ausgabe dieser
Nachrichten verhindern, indem Sie die
Abwärtskompatibilität für dieses Projekt inaktivieren.
Wichtig: In V6.0 erstellte, neue Projekte der
Spezifikation J2EE 1.2 oder 1.3 sind mit
WebSphere
Studio V5.1.x kompatibel, Sie müssen jedoch nach dem Laden des
Projekts in WebSphere Studio einige manuelle Schritte
ausführen, bevor Sie mit dem Projekt arbeiten können. Diese
Schritte sind erforderlich, da Laufzeitziele für neue, in V6.0
erstellte Projekte der Spezifikation J2EE 1.2 oder 1.3 nicht direkt mit
Zielservern in V5.1.x abwärts kompatibel sind. Nach dem Laden eines
neuen V6.0-Projekts in V5.1.x müssen die folgenden manuellen Schritte
ausgeführt werden:
- Öffnen Sie die
.classpath-Datei für jedes J2EE-Projekt, das
über eine .classpath-Datei verfügt.
- Löschen Sie die
folgenden Klassenpfadeinträge aus der
.classpath-Datei, und speichern und schließen
Sie die Datei.
-
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/
org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v5.1 JRE"/>
-
<classpathentry kind="con"
path="com.ibm.wtp.server.java.core.container/
com.ibm.etools.websphere.runtime.core.runtimeTarget.v51/was.base.v51"/>
- Stellen Sie sicher,
das auf der Seite der J2EE-Benutzervorgaben die
Serverzielunterstützung aktiviert ist. Wählen Sie
Fenster -> Benutzervorgaben -> J2EE aus, und stellen Sie sicher, dass unter
"Serverzielunterstützung"
Serverzielunterstützung aktivieren ausgewählt
ist.
- Klicken Sie mit der
rechten Maustaste auf das Projekt, und wählen Sie
Eigenschaften -> J2EE aus.
- Wählen Sie den
entsprechenden Zielserver für das Laufzeitziel des Projekts aus
(beispielsweise WebSphere Application Server V5.1 mit
Laufzeitumgebung JDK 1.4) und klicken Sie auf
OK.
- Der von Ihnen
ausgewählte Zielserver wird mit
Rational Web Developer V6.0 und mit
WebSphere Studio Site Developer V5.1.x
kompatibel sein. Nach dem Festschreiben der Änderungen im SCM-System
sind die J2EE-Projekte funktionell auf V5.1.x und V6.0 unter Verwendung
eines SCM-Systems
abgestimmt.
Anmerkung:
Wenn
der Zielserver erneut in
Rational Web Developer V6.0 festgelegt
wird, geht die J2EE-Projektkompatibilität verloren und muss erneut
eingerichtet werden.
Kompatibilität
mit WebSphere Studio V5.1.x inaktivieren
Die Kompatibilität mit WebSphere Studio Site Developer V5.1.x kann vollständig aus einem in Rational Web Developer V6.0 erstellten Unternehmensanwendungsprojekt oder einem aus einer früheren Version von WebSphere Studio migrierten Unternehmensanwendungsprojekt entfernt werden. Sie sollten die Kompatibilität mit WebSphere Studio V5.1.x nur dann entfernen, wenn Sie sicher sind, dass das Unternehmensanwendungsprojekt entweder nicht länger funktionell auf V5.1.x abgestimmt oder nicht länger mit V5.1.x kompatibel sein soll.
Gehen sie wie folgt vor,
um die Kompatibilität mit
WebSphere Studio Site Developer V5.1.x zu
entfernen:
- Klicken Sie mit der
rechten Maustaste auf ein Unternehmensanwendungsprojekt, und wählen
Sie aus dem Popup-Menü die Option
Kompatibilität entfernen aus.
- Sie
werden in einem Dialogfenster aufgefordert, das Entfernen der
Abwärtskompatibilität des Unternehmensprojekts sowie aller im
Projekt verschachtelten Module und Dienstprogrammprojekte zu
bestätigen.
- Klicken
Sie auf Ja, um mit der Operation zum Entfernen der
Kompatibilität fortzufahren.
Nach dem Ausführen der Operation zum Entfernen der Kompatibilität sind das Unternehmensanwendungsprojekt und alle unter dem Unternehmensanwendungsprojekt verschachtelten Module und Dienstprogrammprojekte nicht mehr mit WebSphere Studio Site Developer V5.1.x
abwärts kompatibel.
Faces-Laufzeitressourcen
in einem Webprojekt aktualisieren
Die JavaServer Faces-Laufzeitressourcen, die ursprünglich mit WebSphere Studio Site Developer V5.1.x bereitgestellt wurden, wurden für Rational Web Developer V6.0.1 aktualisiert. Wenn Sie die Entwicklung der mit dieser früheren Produktversion erstellten Projekte fortsetzen wollen, wird empfohlen, dass Sie die Ressourcen für die Faces-Laufzeit auf die jeweils neueste Stufe aktualisieren.
In
Rational Web Developer V6.0.1 werden die
Faces-Laufzeitressourcen automatisch aktualisiert, wenn ein Webprojekt
importiert oder ein Arbeitsbereich geöffnet wird, das bzw. der
Ressourcen enthält, die nicht auf dem neuesten Stand sind. Nachdem
Sie ein Webprojekt oder einen Arbeitsbereich aus
WebSphere Studio Site Developer V5.1.x in
Rational Web Developer V6.0.1 importiert
bzw. geöffnet haben, werden Sie aufgefordert, die
Faces-Laufzeitressourcen auf den neuesten Stand zu bringen.
Laufzeitressourcen automatisch aktualisieren
Führen Sie folgende Schritte aus, um die Faces-Laufzeitressourcen für ein Webprojekt automatisch zu aktualisieren:
- Importieren Sie ein
Webprojekt (oder einen Arbeitsbereich) mit Faces-Inhalt aus
WebSphere Studio Site Developer V5.1.x. Das
Fenster Projektmigration wird
geöffnet.
Anmerkung:
Wenn
das Fenster Projektmigration nicht geöffnet wird, ist
möglicherweise Ihre Einstellung für automatische Erstellung
inaktiviert. Klicken Sie im Projektexplorer mit der rechten Maustaste
auf Ihr Webprojekt, und wählen Sie
Build -> Projekt aus; der Prozess zum erneuten Erstellen
eines Projekts öffnet das Fenster
Projektmigration.
- Wenn in Ihrem
Arbeitsbereich noch andere Webprojekte mit Faces-Inhalt vorhanden sind,
können Sie Diese Auswahl auf alle anderen Projekte anwenden, für
die ein Upgrade ausgeführt werden muss auswählen, damit alle
diese Projekte aktualisiert werden.
- Klicken Sie auf eine der
folgenden Optionen:
- Klicken Sie auf
Ja, um die Aktualisierung automatisch
auszuführen.
- Klicken Sie auf
Später, um die Aktualisierung auf einen späteren
Zeitpunkt zu verschieben. Wenn Sie die Laufzeitressourcen automatisch
aktualisieren wollen, nachdem Sie
Später ausgewählt haben, müssen Sie das
Webprojekt schließen und erneut starten oder die Workbench neu
starten, bevor Sie Ihr Webprojekt erneut erstellen. Wenn Sie die
automatische Erstellung inaktiviert haben, klicken Sie mit der rechten
Maustaste auf Ihr Webprojekt, und wählen Sie
Projekt erstellen aus.
- Klicken Sie auf
Nie, um Ihre Laufzeitressourcen auf dem Stand der
früheren Version beizubehalten. Wenn Sie
Nie
auswählen und absichtlich die Laufzeitressourcen der früheren
Version beibehalten, werden Sie nicht mehr zur Aktualisierung der
Ressourcen aufgefordert. Sollte dann zukünftig eine Aktualisierung
der Laufzeitressourcen erforderlich werden, müssen Sie dies manuell
ausführen.
Anmerkung:
Wenn
Sie Faces-JSPs erstellt haben, die Faces Client-Komponenten enthalten,
müssen Sie die Laufzeitressourcen der Faces Client-Komponenten
separat auf den jeweils neuesten Stand aktualisieren. Weitere
Informationen finden Sie in
Ressourcen
der Faces Client-Laufzeit in einem Webprojekt aktualisieren.
Laufzeitressourcen manuell aktualisieren
Führen Sie folgende Schritte aus, um die Faces-Laufzeitressourcen für ein Webprojekt manuell zu aktualisieren:
- Importieren Sie Ihr
vorhandenes Webprojekt mit Faces-Inhalt in einen
Rational Web Developer
V6.0.1-Arbeitsbereich.
- Erstellen
Sie ein neues Webprojekt (bzw. ein neues EGL-Webprojekt, wenn Sie mit
EGL arbeiten) mit dem Namen
JSF601. Sie werden dieses Projekt lediglich als
Quelle für die neuesten Laufzeitressourcen verwenden, und Sie
können es nach Abschluss der Aktualisierung löschen.
- Klicken
Sie im Projektexplorer mit der rechten Maustaste auf das Projekt
JSF601, und wählen Sie im Menü die Option
Eigenschaften aus.
- Klicken
Sie auf Funktionen des Webprojekts, und wählen Sie
Faces-Basiskomponenten hinzufügen und
Faces
Client Framework hinzufügen aus. Klicken Sie anschließend auf
OK.
- Wenn Sie mit EGL arbeiten, erstellen Sie eine
JSF-Seitendatei wie folgt:
- Klicken
Sie mit der rechten Maustaste auf den Ordner 'WebContent' Ihres neuen
EGL-Webprojekts.
- Wählen
Sie
Neu -> Andere -> Faces-JSP-Datei aus.
Die Dateien
eglintdebug.jar und
eglintdebugsupport.jar werden zu Ihrem Projekt
hinzugefügt.
- Führen
Sie für jedes vorhandene Faces-Projekt, das Sie aktualisieren wollen,
die folgenden Schritte aus:
- Erweitern
Sie im Projektexplorer ein vorhandenes Projekt, um die im Ordner
WebContent/WEB-INF/lib/
vorhandenen Dateien anzuzeigen. Suchen und löschen Sie die folgenden
JAR-Dateien in diesem Verzeichnis:
- eglintdebug.jar
(nur EGL)
- eglintdebugsupport.jar
(nur EGL)
- fda.jar
(nur EGL)
- fdaj.jar
(nur EGL)
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- odc-jsf.jar
- Suchen
und öffnen Sie die Datei
WebContent/WEB-INF/faces-config.xml.
Fügen Sie zu dieser Konfigurationsdatei die folgenden Elemente hinzu,
wenn sie noch nicht vorhanden
sind:
<lifecycle>
<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
</lifecycle>
<application>
<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
</application>
- Kopieren
Sie aus dem Verzeichnis
WebContent/WEB-INF/lib
des Projekts JSF601 für jede der gelöschten JAR-Dateien
jeweils die JAR-Datei desselben Namens, und fügen Sie sie in Ihr
ursprüngliches Projekt an derselben Position ein. Für einige
Konfigurationen müssen nicht alle JAR-Dateien im Projekt vorhanden
sein; kopieren Sie keine der JAR-Dateien, die nicht im ursprünglichen
Projekt vorhanden war.
- Öffnen
Sie den Implementierungsdeskriptor
web.xml im
ursprünglichen Projekt, und fügen Sie zur Konfiguration Folgendes
hinzu:
<context-param>
<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
<param-value>true</param-value>
</context-param>
- Wenn
in Ihrem ursprünglichen Projekt
WebSphere-Datenobjekte (WDOs) für Datenzugriff
verwendet wurden, führen Sie die folgenden zusätzlichen Schritte
aus:
- Klicken Sie in Ihrem
ursprünglichen Projekt auf
Datei -> Neu -> Faces-JSP-Datei, um eine neue temporäre
Faces-JSP-Datei zu erstellen.
- Ziehen Sie eine
relationale Satzliste aus dem Drawer für Daten der Palette auf die
Seite.
- Wählen Sie eine
beliebige Verbindung und Datenquelle aus, und klicken Sie auf
Fertig stellen. Die ausgewählten Daten spielen
keine Rolle. Dieser Prozess generiert die erforderliche Konfiguration,
um WDOs in diesem Projekt weiterhin verwenden zu können.
- Löschen Sie die
temporäre JSP-Datei.
- Wenn Sie mit EGL arbeiten, klicken Sie mit der
rechten Maustaste auf den Namen jedes EGL-Webprojekts und klicken Sie
auf Generieren. Wenn Sie die Projekte nicht automatisch
erstellen, klicken Sie anschließend auf
Projekt -> Build für alle.
- Löschen
Sie das Webprojekt JSF601.
Ressourcen
der Faces Client-Laufzeit in einem Webprojekt aktualisieren
Die JavaServer Faces Client-Laufzeitressourcen, die ursprünglich mit WebSphere Studio Site Developer V5.1.x bereitgestellt wurden, wurden für Rational Web Developer V6.0.1 aktualisiert. Wenn Sie die Entwicklung der mit dieser früheren Produktversion erstellten Projekte fortsetzen wollen, wird empfohlen, dass Sie die Ressourcen für die Faces Client-Laufzeit auf die jeweils neueste Stufe aktualisieren.
In
Rational Web Developer V6.0.1 werden die
Faces Client-Laufzeitressourcen automatisch aktualisiert, wenn ein
Webprojekt importiert oder ein Arbeitsbereich geöffnet wird, das bzw.
der Ressourcen enthält, die nicht auf dem neuesten Stand sind.
Nachdem Sie ein Webprojekt oder einen Arbeitsbereich aus
WebSphere Studio Site Developer V5.1.x in
Rational Web Developer V6.0.1 importiert
bzw. geöffnet haben, werden Sie aufgefordert, die Faces
Client-Laufzeitressourcen auf den neuesten Stand zu bringen.
Laufzeitressourcen automatisch aktualisieren
Führen Sie folgende Schritte aus, um die Faces Client-Laufzeitressourcen für ein Webprojekt automatisch zu aktualisieren:
- Importieren Sie ein
Webprojekt (oder einen Arbeitsbereich) mit Faces Client-Inhalt aus
WebSphere Studio Site Developer V5.1.x. Das
Fenster Projektmigration wird geöffnet.
Anmerkung:
Wenn
das Fenster Projektmigration nicht geöffnet wird, ist
möglicherweise Ihre Einstellung für automatische Erstellung
inaktiviert. Klicken Sie im Projektexplorer mit der rechten Maustaste
auf Ihr Webprojekt, und wählen Sie
Build -> Projekt aus; der Prozess zum erneuten Erstellen
eines Projekts öffnet das Fenster
Projektmigration.
- Wenn in Ihrem
Arbeitsbereich noch andere Webprojekte mit Faces Client-Inhalt vorhanden
sind, können Sie
Diese Auswahl auf alle anderen Projekte anwenden, für
die ein Upgrade ausgeführt werden muss auswählen, damit alle
diese Projekte aktualisiert werden.
- Klicken Sie auf eine
der folgenden Optionen:
- Klicken Sie auf
Ja, um die Aktualisierung automatisch
auszuführen.
- Klicken Sie auf
Später, um die Aktualisierung auf einen späteren
Zeitpunkt zu verschieben. Wenn Sie die Laufzeitressourcen automatisch
aktualisieren wollen, nachdem Sie
Später ausgewählt haben, müssen Sie das
Webprojekt schließen und erneut starten oder die Workbench neu
starten, bevor Sie Ihr Webprojekt erneut erstellen. Wenn Sie die
automatische Erstellung inaktiviert haben, klicken Sie mit der rechten
Maustaste auf Ihr Webprojekt, und wählen Sie
Projekt erstellen aus.
- Klicken Sie auf
Nie, um Ihre Laufzeitressourcen auf dem Stand der
früheren Version beizubehalten. Wenn Sie
Nie auswählen und absichtlich die
Laufzeitressourcen der früheren Version beibehalten, werden Sie nicht
mehr zur Aktualisierung der Ressourcen aufgefordert. Sollte dann
zukünftig eine Aktualisierung der Laufzeitressourcen erforderlich
werden, müssen Sie dies manuell ausführen.
- Löschen Sie in
Ihrem Webprojekt im Ordner
Java-Ressourcen -> JavaSource alle Clientdatenmediatorklassenpakete,
die der Namenskonvention
com.ibm.dynwdo4jsmediators.<clientdatenname> entsprechen.
Löschen Sie NICHT das Paket mit dem Namen
com.ibm.dynwdo4jsmediators. Dieses Paket enthält Metadaten (ecore-
und emap-Dateien) für die Clientdaten in Ihrem Projekt, die zur
erneuten Generierung der Mediatoren verwendet werden.
- Öffnen Sie in Ihrem
Webprojekt im Ordner
Java-Ressourcen -> JavaSource die Datei
OdysseyBrowserFramework.properties, und löschen Sie die Einträge
für EMAP_FILES und
ECORE_FILES.
- Führen Sie für
jedes Datenobjekt in Der Clientdatensicht Folgendes aus:
- Klicken Sie mit der
rechten Maustaste, und wählen Sie
Konfigurieren aus.
- Klicken Sie auf der
Registerkarte Erweitert auf
Von serverseitigen Daten neu generieren, um alle
Mediatoren für das Datenobjekt erneut zu generieren.
Laufzeitressourcen manuell aktualisieren
Führen Sie folgende Schritte aus, um die Faces Client-Laufzeitressourcen für ein Webprojekt manuell zu aktualisieren:
- Führen Sie die in
Faces-Laufzeitressourcen
in einem Webprojekt aktualisieren unter
Laufzeitressourcen manuell aktualisieren
aufgeführten Schritte aus.
- Führen Sie die
Schritte 4-6 des oben aufgeführten Abschnitts
Laufzeitressourcen automatisch aktualisieren aus.
Es können Probleme auftreten, wenn Sie den Zielserver
eines Projekts, das Faces Client-Komponenten enthält, von
WebSphere
Application Server V5.1 in V6.0 ändern.
Wenn Sie den Zielserver
eines Projekts, das Faces Client-Komponenten enthält, von
WebSphere
Application Server V5.1 in V6.0 ändern, können die folgenden
beiden Probleme auftreten:
- Bereits erstellte
Mediatorklassen von Clientdaten können nicht mehr kompiliert werden.
Sie müssen nacheinander für jeweils eine JSP erneut generiert
werden.
- Öffnen Sie die
Datei OdysseyBrowserFramework.properties, die sich im Stammverzeichnis
des Java-Quellenordners befindet. Speichern Sie den
Inhalt für zukünftige Verwendung.
- Suchen Sie in der
Datei OdysseyBrowserFramework.properties für jede JSP in Ihrem
Webprojekt, die Faces Client-Daten enthält, die Einträge
<clientdatenname>.ecore und <clientdatenname>.emap für
die Eigenschaften EMAP_FILES und ECORE_FILES.
- Behalten Sie nur die
übereinstimmenden Einträge für die Clientdaten auf Ihrer JSP,
und löschen Sie alle anderen Einträge.
Beispiel: Ihre aktuelle
Seite enthält Clientdaten namens ACCOUNT, und Ihre Eigenschaftsdatei
'.properties' enthält den folgenden
Eintrag:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
In diesem Fall müssen Sie com\\ibm\\dynwdo4jsmediators/orders.emap aus dem
Eintrag löschen. Der Eintrag würde nun wie folgt
aussehen:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
- Sichern Sie die
Eigenschaftsdatei.
- Wählen Sie ein
Clientdatenobjekt in einer JSP aus, klicken Sie mit der rechten
Maustaste, und wählen Sie
Konfigurieren aus.
- Klicken Sie auf der
Registerkarte Erweitert auf die Option
Alle erneut generieren. Dadurch werden alle Artefakte
erneut generiert, die für sämtliche Clientdaten auf der aktuellen
JSP benötigt werden.
- Wiederholen Sie die
Schritte 2-6 für jede JSP in Ihrem Webprojekt, die Clientdaten
enthält.
- Nachdem Sie die
Mediatorklassen der Clientdaten erneut generiert haben, werden immer
noch einige Mediatorklassen vorhanden sein, die nicht kompiliert werden
können. Hierbei handelt es sich um Mediatoren für Schemaelemente,
die in V6.x nicht mehr in SDOs (Service Data Objects) verwendet werden
und die der Namenskonvention *_DataGraphSchema_wdo4js_*.java und
*_RootDataObject_wdo4js_*.java entsprechen. Löschen Sie diese
Mediatorklassen aus Ihrem Webprojekt, um diese Kompilierungsfehler zu
vermeiden.
- Stellen Sie nach
erfolgreichem Abschluss der Aktualisierung den ursprünglichen Inhalt
der Datei OdysseyBrowserFramework.properties wieder her.
- Faces
Client-Komponenten der Baumstrukturansicht, die an WDOs gebunden sind,
können auf dem Server nicht mehr ausgeführt werden, nachdem der
Zielserver des Projekts in
WebSphere
Application Server V6.0 geändert wurde. Dieses Problem kann umgangen
werden, indem in der Quellenansicht Ihrer JSP alle className-Tags so
geändert werden, dass sie statt der WDO-DataObject-Klasse die
SDO-DataObject-Klasse verwenden. Beispiel für ein WDO mit dem Namen
account:
- Ändern Sie für
das Stammobjekt den Tag 'className' von
className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)"
in className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
- Ändern Sie für
alle untergeordneten Knoten den Tag 'className' von
className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)"
in className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)",
wobei ACCOUNT der Name des Datenknotens ist.
Upgrade auf automatisierte Diff-Handler und
-Prozessoren
Diff-Prozessoren und
-Handler werden automatisch generiert. Wenn Sie Diff-Handler und
-Prozessoren für Ihre Faces Client-Komponenten in
WebSphere
Studio V5.1.x geschrieben haben, wird empfohlen, den entsprechenden Code
zu verwerfen und die automatisch generierten Handler und Prozessoren zu
verwenden:
- Generieren Sie die
neuen Diff-Handler und -Prozessoren für jedes Clientdatenobjekt in
Ihrem Webprojekt.
- Wählen Sie das
Clientdatenobjekt aus, klicken Sie mit der rechten Maustaste, und
wählen Sie Konfigurieren aus.
- Klicken Sie auf der
Registerkarte Erweitert auf die Option
Alle erneut generieren.
- Entfernen Sie den
Code, den Sie zum Aufrufen Ihrer Diff-Prozessoren und -Handler
geschrieben haben, da die generierten Prozessoren und Handler
automatisch aufgerufen werden. Dieser Code wurde beispielsweise
häufig für das Befehlsereignis für die Komponente
'Befehlsschaltfläche' verwendet, z. B. wie folgt:
String Diff = getClientData1().getDiffStr();
if (DiffProcessor.Synch(getRoot(), Diff) == true)
return "";
return "failure";
- Entfernen Sie aus
Ihrem Projekt die Dateien, die den alten angepassten Handlern und
Prozessoren entsprechen, die Sie erstellt haben.
Angepasste, für V5.1.x geschriebene Diff-Handler und
-Prozessoren beibehalten
Wenn Sie entgegen
jeder Empfehlung Ihre angepassten Diff-Handler und -Prozessoren aus
V5.1.x beibehalten wollen, müssen Sie diese ändern, damit sie in
V6.0 funktionieren, da die Schnittstelle 'DiffHandler' und die Klasse
'DiffInfo' geändert wurden.
- Die Schnittstelle
'DiffHandler' wurde wie folgt geändert:
- Die Methode 'handle'
löst jetzt neben 'DiffException' auch 'Exception' aus.
- Die neue Methode
'find' wird vom Framework für die Suche nach Objekten verwendet.
- Die neue Methode
'getId' wird für das Debug verwendet und ermöglicht es dem
Framework, den Wert eines Objekts zu drucken.
Die Methoden 'find' und
'getId' werden intern von den generierten Diff-Handlern verwendet. Sie
können leere Methoden für Ihre angepassten Diff-Handler
implementieren, damit diese mit der Schnittstelle funktionieren. Diese
Methoden werden vom Framework nicht aufgerufen.
Die neue Schnittstelle
'DiffHandler' sieht wie folgt
aus:
public interface DiffHandler
{
public void handle(DiffInfo Diff) throws DiffException, Exception;
public Object find (DiffInfo Diff) throws DiffException, Exception;
public String getId (DiffInfo Diff, boolean Original);
}
- Die Klasse 'DiffInfo'
wurde wie folgt geändert:
- Die Methode
'ArrayList getAncestors()' wurde ersetzt durch die Methode 'DiffInfo
getParent()', die eine einfachere Möglichkeit bietet, auf die
Informationen für die einzelnen Objekte in der Baumstruktur der
Vorgänger rekursiv zuzugreifen.
- Die Methoden
'getCurrent()' und 'getOriginal()' geben jetzt anstelle eines
EObject-Objekts ein DataObject-Objekt zurück. Es ist nicht
obligatorisch, den Code zu ändern und das Objekt 'DataObject' zu
verwenden. Allerdings ist die Schnittstelle 'DataObject' viel einfacher
und intuitiver zu verwenden als 'EObject'. Für vorhandenen Code
können Sie problemlos ein DataObject-Objekt in ein EObject-Objekt
umsetzen.
- Die Methode 'String
getPropertyName()' wurde neu hinzugefügt, um den Eigenschaftsnamen,
für den dieses Objekt gilt, zu ermitteln. Dies ist beispielsweise
dann von Bedeutung, wenn eine bestimmte Klasse über zwei
Eigenschaften desselben Typs verfügt. In der vorherigen Klasse
'DiffInfo' wäre der Code nicht in der Lage gewesen, zwischen den
beiden Eigenschaften zu unterscheiden.
Die neue Klasse
'DiffInfo' sieht wie folgt
aus:
public class DiffInfo
{
public char getCrud()
public DataObject getCurrent()
public String getEClassName()
public DataObject getOriginal()
public String getPropertyName()
public DiffInfo getParent()
}
Anmerkung:
Die
Klasse 'DiffInfo' wird nicht länger für öffentliche Verwendung
unterstützt, da Diff-Prozessoren und -Handler nun automatisch
generiert werden. Die Beibehaltung der alten Handler ist nur eine
vorläufige Lösung, und es wird dringend empfohlen, automatisierte
Handler zu verwenden.
Änderungen an Faces Client-Komponenten in V6.0
- Unterstützung
für WebSphere Application Server V6.0.
- Unterstützung
für Servicedatenobjekte (SDOs) unter
WebSphere
Application Server V6.0.
- EGL-Daten werden
jetzt als Clientdaten unterstützt.
- Diff-Prozessoren und
-Handler werden automatisch generiert.
- Für die folgenden
Komponenten sind neue Ereignisse vorhanden:
- TabbedPanel:
onInitialPageShow
- Tree: onNodeExpand,
onNodeCollapse, onExpand, onCollapse
- DataGrid: onPage,
onSort, onFilter
Struts-Webprojekte
migrieren
Sie müssen am Implementierungsdeskriptor von Struts-Webprojekten, die in WebSphere Studio V5.1.x erstellt wurden, eine kleine Änderung vornehmen, um das EAR-Projekt unter WebSphere Application Server V6.0 ausführen zu können. Sie können auch vorhandene Webprojekte von Struts 1.0.2 oder Struts 1.1 Beta (2 oder 3) manuell in Struts 1.1 umwandeln.
Den Implementierungsdeskriptor vorhandener
Struts-Webprojekte modifizieren
Wenn ein Struts-Projekt in
WebSphere
Studio v5.x erstellt wird, wird der Konfigurationsparameter
(<parametername>config</parametername>) im
Implementierungsdeskriptor des Webprojekts auf WEB-INF/struts-config.xml
gesetzt. WebSphere Application Server V6.0 erfordert, dass in
diesem Parameter ein führender Schrägstrich "/" vorhanden ist.
Wenn Sie ein in WebSphere Studio V5.1.x erstelltes Struts-Webprojekt
unter WebSphere
Application Server V6.0 ausführen, kann beim Starten des EAR-Projekts
die Ausnahmebedingung java.net.MalformedURLException ausgegeben werden.
Anmerkung:
Rational Web Developer V6.0 fügt bei der
Erstellung eines neuen Struts-Projekts den Schrägstrich "/" hinzu,
bei der Migration von WebSphere Studio V5.1x muss er jedoch manuell
hinzugefügt werden.
Führen Sie die folgenden
Schritte aus, um in V6.0 den Implementierungsdeskriptor eines in
WebSphere
Studio v5.1.x erstellten Struts-Webprojekts zu korrigieren:
- Öffnen Sie das
Struts-Webprojekt im Projektexplorer.
- Klicken Sie im
Projektexplorer doppelt auf die Datei
Webimplementierungsdeskriptor des Webprojekts. Der
Editor für Webimplementierungsdeskriptoren wird geöffnet.
- Klicken Sie auf die
Registerkarte Quelle, um die Quellenseite zu öffnen.
- Ändern Sie die Zeile
<parameterwert>WEB-INF/struts-config.xml</parameterwert>
(diese Zeile befindet sich innerhalb der
<servlet></servlet>-Tags)
in
<parameterwert>/WEB-INF/struts-config.xml</parameterwert>.
- Speichern Sie den
Webimplementierungsdeskriptor.
Die Ausnahmebedingung java.net.MalformedURLException sollte beim erneuten Start des EAR-Projekts nicht ausgegeben werden.
Struts-Webprojekte von 1.1 Beta in Struts 1.1
umwandeln
In
WebSphere
Studio V5.1.x wurde die Struts-Laufzeitbibliothek von Struts 1.1 Beta (2
oder 3) in V5.0.x auf Struts 1.1 (final) erhöht. Wenn Sie vorhandene
Webprojekte aus Struts 1.1 Beta (2 oder 3) haben und diese in Struts 1.1
(final) umwandeln wollen, können Sie dies manuell ausführen.
(Hinweis:
Es ist nicht erforderlich, Projekte von Struts 1.1 Beta (2 oder 3) in
Struts 1.1. umzuwandeln.)
Führen Sie die folgenden
Schritte aus, um Webprojekte von Struts 1.1 Beta (2 oder 3) in Struts
1.1 umzuwandeln:
- Laden Sie Ihre Struts 1.1
Beta-Projekte in einen
Rational Web Developer V6.0-Arbeitsbereich.
- Erstellen Sie ein neues
Webprojekt von Struts 1.1, beispielsweise mit dem Namen
Struts11.
Sie erstellen dieses temporäre Projekt, um bequemen Zugriff auf die
Struts 1.1-Laufzeitdateien bereitzustellen, die Sie bei der Umwandlung
Ihrer richtigen Projekte benötigen. Sie können dieses Projekt
löschen, sobald Sie fertig sind.
- Für jedes Projekt von
Struts 1.1 Beta 2, das Sie in Struts 1.1 umwandeln wollen, müssen Sie
Folgendes ausführen:
- Löschen Sie die
folgenden JAR-Dateien aus dem Verzeichnis Web Content/WEB-INF/lib Ihres
Projekts:
- commons-*.jar.
- struts.jar.
- Kopieren Sie die folgenden
JAR-Dateien aus dem Verzeichnis Struts11/WebContent/WEB-INF/lib in das
Verzeichnis Web Content/WEB-INF/lib Ihres Projekts:
- commons-*.jar.
- struts.jar.
- Löschen Sie die
folgenden TLD-Dateien (TLD, Tag Library Descriptor) aus dem Verzeichnis
Web Content/WEB-INF Ihres Projekts: struts-*.tld.
- Kopieren Sie die folgenden
TLD-Dateien aus dem Verzeichnis Struts11/WebContent/WEB-INF in das
Verzeichnis Web Content/WEB-INF Ihres Projekts:
struts-*.tld.
Struts-Webprojekte von 1.0.2 in Struts 1.1
umwandeln
In
WebSphere
Studio V5.1.x (und V5.0.x) hatten Sie die Möglichkeit, beim
Hinzufügen von Struts-Unterstützung zu einem Webprojekt Struts
1.0.2 auszuwählen. Wenn Sie vorhandene Webprojekte aus Struts 1.0.2
haben und sie in Struts 1.1 umwandeln wollen, können sie dies manuell
ausführen. (Hinweis: Es ist nicht erforderlich, Projekte von
Struts 1.1 Beta (2 oder 3) in Struts 1.1. umzuwandeln.)
Führen Sie die folgenden
Schritte aus, um Webprojekte von Struts 1.0.2 in Struts 1.1 umzuwandeln:
- Laden Sie Ihre Struts
1.0.2-Projekte in einen
Rational Web Developer V6.0-Arbeitsbereich.
- Erstellen Sie ein neues
Webprojekt von Struts 1.1, beispielsweise mit dem Namen
Struts11.
Sie erstellen dieses temporäre Projekt, um bequemen Zugriff auf die
Struts 1.1-Laufzeitdateien bereitzustellen, die Sie bei der Umwandlung
Ihrer richtigen Projekte benötigen. Sie können dieses Projekt
löschen, sobald Sie fertig sind.
- Für jedes Projekt von
Struts 1.0.2, das Sie in Struts 1.1 umwandeln wollen, müssen Sie
Folgendes ausführen:
- Löschen Sie die Datei
struts.jar aus dem Verzeichnis Content/WEB-INF/lib Ihres Projekts.
- Kopieren Sie die folgenden
JAR-Dateien aus dem Verzeichnis Struts11/WebContent/WEB-INF/lib in das
Verzeichnis Web Content/WEB-INF/lib Ihres Projekts:
- commons-*.jar.
- struts.jar.
- jarkarta-oro.jar.
- Löschen Sie die
folgenden TLD-Dateien (TLD, Tag Library Descriptor) aus dem Verzeichnis
Web Content/WEB-INF Ihres Projekts: struts-*.tld.
- Kopieren Sie die folgenden
TLD-Dateien aus dem Verzeichnis Struts11/WebContent/WEB-INF in das
Verzeichnis Web Content/WEB-INF Ihres Projekts:
struts-*.tld.
Änderungen
am Debugger in V6.0
Die Debug-Tools in Rational Web Developer V6.0 enthalten eine Reihe von Änderungen, die Sie beachten müssen, um diese Tools im Anschluss an die Migration für Ihre Projekte verwenden zu können. Sie müssen gegebenenfalls einige Einstellungen ändern oder wiederherstellen.
Arbeitsbereiche wiederherstellen und Konfigurationen starten
Wenn ein
V5.1.x-Arbeitsbereich aus
WebSphere Studio Site Developer in
Rational Web Developer V6.0 geöffnet
wird, werden die folgenden, dem Arbeitsbereich zugeordneten
Startkonfigurationen für den Debugger nicht automatisch migriert:
- Debug auf Server: Startkonfigurationen, die zuvor
über die Aktion für Debug auf dem Server erstellt wurden, werden
nicht auf V6.0 migriert. Um eine Anwendung für Debug auf dem Server
in V6.0 zu starten, wählen Sie die Anwendung erneut aus, und
wählen Sie Debug auf Server aus. Hiermit wird eine neue
Startkonfiguration für die Anwendung erstellt.
- Serververbindung: Startkonfigurationen für ein
Debug von WebSphere Application Server, die zuvor für eine
Serververbindung erstellt wurden, werden nicht auf V6.0 migriert. Die
Startkonfiguration für ein Debug von
WebSphere Application Server ist nicht mehr
vorhanden. Um in V6.0 eine Serververbindung für ein Debug
auszuführen, verwenden Sie die Aktion
Debug auf Server, und erstellen Sie eine
WebSphere V5-Serververbindung für 5.x oder eine
WebSphere v6.0-Serververbindung für 6.0.
- SQLJ-Debugger: Die Startkonfiguration für
SQLJ-Debug ist nicht länger vorhanden, und zuvor erstellte
Startkonfigurationen für SQLJ werden nicht auf V6.0 migriert. Um in
V6.0 SQLJ-Programme für ein Debug zu starten, verwenden Sie die
Startkonfiguration für
Java-Anwendungen.
- Debugger für gespeicherte Prozeduren:Startkonfigurationen für Debug von gespeicherten Prozeduren, die
zuvor erstellt wurden, werden auf
Rational Web Developer V6.0 migriert und
stehen im Dialogfenster
Debug für Startkonfigurationen zur Verfügung.
Wenn Sie nach der Migration die Aktion
Debug im Popup-Menü der Sicht
Datendefinition verwenden, wird eine neue
Startkonfiguration für Sie
erstellt.
Anmerkung:
Wenn
Sie einen Arbeitsbereich migrieren, der eine gespeicherte Prozedur
enthält, und anschließend die gespeicherte Prozedur für ein
Debug erneut erstellen, werden die der gespeicherten Prozedur
zugeordneten, migrierten Startkonfigurationen nicht
funktionieren.
- EGL-Debugger: Nach der Migration eines Arbeitsbereichs
müssen für vorhandene Startkonfigurationen für den EGL-Debugger
die folgenden Schritte ausgeführt werden:
- Ändern Sie die
installierte Java-Laufzeitumgebung (JRE) so, dass sie auf die
korrekte Position zeigt. Nach der Migration eines Arbeitsbereichs zeigt
dessen JRE noch auf die JRE aus der früheren Version von
WebSphere Studio Site Developer. Um diese
Änderung auszuführen, zeigen Sie wie folgt auf die neue
JRE-Position:
- Wählen Sie
Fenster -> Benutzervorgaben im Workbenchmenü aus.
- Es wird ein Dialog
für Benutzervorgaben angezeigt. Erweitern Sie darin den
Java-Knoten, und wählen Sie anschließend
Installierte JREs aus.
- Legen Sie auf der
rechten Seite die installierte JRE so fest, dass sie auf die mit der
aktuellen Version dieses Produkts installierte JRE zeigt. Die Position
der JRE ist das Unterverzeichnis
\eclipse\jre
des Installationsverzeichnisses von
Rational Web Developer V6.0.
- Wählen Sie in
der Startkonfiguration die Registerkarte
Quelle aus, bevor Sie den Start ausführen
(andernfalls wird ein Fehler angezeigt, dass keine Quelle gefunden
wurde). Wenn Sie im Arbeitsbereich von V5.1.x Quellenpositionen zur
Startkonfiguration hinzugefügt hatten, müssen Sie diese Positionen
manuell zur migrierten Startkonfiguration hinzufügen.
- Debugger für Compilersprache: Nach der Migration
eines Arbeitsbereichs müssen für vorhandene Startkonfigurationen
für den Debugger für Compilersprache die folgenden Schritte
ausgeführt werden:
- Wenn Sie auf der
Registerkarte für
Systemumgebung der Startkonfiguration für
Kompilierte Anwendung Umgebungsvariablen gesetzt
hatten, müssen Sie diese manuell zur migrierten Startkonfiguration
hinzufügen.
- Wenn Sie zu den
Startkonfigurationen für
Kompilierte Anwendung oder
An aktiven Prozess anhängen Quellenpositionen
hinzugefügt hatten, müssen Sie diese Positionen manuell zur
migrierten Startkonfiguration
hinzufügen.
Debugsichten
Die Sichten für
Speicher und Speicherzuordnung sind nicht länger verfügbar. Sie
wurden durch die Sichten für Speicher und Speicherbereitstellung
ersetzt.
Der XSLT-Debugger
Der XSLT-Debugger
wurde für V6.0 modifiziert, und viele seiner Sichten und Aktionen
wurden in wesentlichen Punkten geändert. Weitere Informationen finden
Sie in der Dokumentation des XSLT-Debuggers im Informationszentrum.
Eine der
wesentlichsten Änderungen im XSLT-Debugger ist seine Abhängigkeit
von der mit
Rational Web Developer V6.0 installierten
JRE. Wenn Sie einen Arbeitsbereich aus
WebSphere Studio Site Developer V5.1.x
migrieren, müssen Sie die installierte JRE so ändern, dass sie auf
die richtige Position zeigt, bevor Sie eine XSLT-Debugsitzung für den
Arbeitsbereich starten können. Sie können dazu eine der folgenden
Aktionen ausführen:
- Ändern Sie die
JRE für den gesamten Arbeitsbereich, indem Sie auf die neue
JRE-Position zeigen. Führen Sie dazu folgende Schritte aus:
- Wählen Sie
Fenster -> Benutzervorgaben im Workbenchmenü aus.
- Erweitern Sie im
Dialog für Benutzervorgaben den
Java-Knoten, und wählen Sie
anschließend
Installierte JREs aus.
- Legen Sie auf der
rechten Seite die installierte JRE so fest, dass sie auf die mit der
aktuellen Version dieses Produkts installierte JRE zeigt. Die Position
der JRE ist das Unterverzeichnis
\eclipse\jre
des Installationsverzeichnisses von
Rational Web Developer V6.0.
- Wenn Sie die
Debugsitzung über das Dialogfenster
Debug für Startkonfigurationen starten wollen,
können Sie die JRE für die Startkonfiguration ändern, indem Sie
auf die neue JRE-Position zeigen. Öffnen Sie dazu die
Startkonfiguration im Dialogfenster
Debug für Startkonfigurationen. Wählen Sie die
Registerkarte
JRE aus, und geben Sie die neue JRE-Position im Feld
Andere JRE verwenden an.
Migration
von WDO auf SDO
Wenn Sie in einem zielgruppenspezifischen Webprojekt für WebSphere Application Server V5.1 Code generiert haben, der relationale WDO-Datensätze (WDO, WebSphere Data Objects) oder relationale Datensatzlisten verwendet, müssen Sie nun, wenn diese Anwendungen zielgruppenspezifisch für WebSphere Application Server V6.0 verwendet werden sollen, relationale SDO-Datensätze (SDO, Service Data Objects) und relationale Datensatzlisten verwenden. Die Migration von WDO auf SDO wird automatisch ausgeführt, wenn Sie den Zielserver Ihrer Anwendung von WebSphere Application Server V5.1 in WebSphere Application Server V6.0 ändern.
Der Zielserver kann auf zwei
Weisen geändert werden:
Hilfethemen zum Ändern des Zielservers und zur Verwendung des J2EE-Migrationsassistenten finden Sie in der Onlinehilfe von Rational Web Developer.
Kompatibilitätsaspekte
- Der gesamte Code, der
für die WDO-Access-Beans in die öffentlichen
Anwendungsprogrammierschnittstellen (APIs) geschrieben wurde, wird in
V6.0 unterstützt (obwohl die Implementierungsklassen durch
zielgerichtete Klassen für die SDO-Laufzeit ersetzt worden
sind).
- Der neue, für
WebSphere
Application Server V6.0 generierte Code wird die WDO-Access-Beans nicht
verwenden, sondern stattdessen Code für die reinen SDO-APIs
generieren.
- Code, der für ein auf
V6.0 zielgerichtetes Projekt generiert wird, kann nicht auf einem
V5.1-Server ausgeführt werden, auch wenn durch Ändern des
Zielservers eine Abwärtsmigration vorgenommen wird.
- Für V5.1 geschriebener
Code kann aufwärts und durch Ändern des Zielservers in einen
V5.1-Server abwärts migriert werden.
Mögliche Fehler wegen Typenkollision nach der Migration von WDO auf SDO
Wenn ein Projekt, das WDO
verwendet, auf ein SDO-basiertes Projekt migriert wird und Sie SDO-Daten
zu einer bereits vorhandenen JSP-Seite mit bestehenden WDO-Daten
hinzufügen, treten möglicherweise Fehler wegen einer
Typenkollision auf, wenn bereits vorhandene WDO-Access-Beans und
Standalone-SDO-APIs gemischt werden. So wird möglicherweise für
die Java-Quellendatei der JSP-Seite ein
Kompilierungsfehler ähnlich dem folgenden
angezeigt:
Der Import
com.ibm.websphere.sdo.mediator.exception.MediatorException kollidiert mit einem anderen importierten Typ.
Diese Typenkollisionsfehler
können wie folgt korrigiert werden:
- Entfernen Sie die
kollidierende Importanweisung 'import' aus der
Java-Quellendatei. Gemäß dem vorstehenden
Beispiel würden Sie die folgende Importanweisung aus der Quellendatei
entfernen:
import com.ibm.websphere.wdo.mediator.exception.MediatorException;
- Ändern Sie die
Java-Quellendatei, die auf den betreffenden Typ
verweist, damit sie den vollständig qualifizierten Klassennamen
verwendet. Gemäß vorstehendem Beispiel müsste der Typ
MediatorException
in
com.ibm.websphere.wdo.mediator.exception.MediatorException
geändert werden. Ein Quellcode beispielsweise, der als
catch ( MediatorException e1 ) {
geschrieben ist, müsste in folgenden Code geändert werden:
catch ( com.ibm.websphere.wdo.mediator.exception.MediatorException e1 ) {
Änderungen an Webprojekten nach dem Ändern des Zielservers von V5.1 in V6.0 (WDO in SDO)
Wenn der Zielserver von V5.1
in V6.0 geändert wird, werden automatisch die folgenden Änderungen
vorgenommen:
- Die
Java-Archivdateien (JAR-Dateien)
wdo_web.jar und
wdo_jdbc_access.jar
werden aus dem Projekt entfernt.
- Die folgenden JAR-Dateien
werden aus dem Klassenpfad des Projekts entfernt:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- Die Dateien
sdo_web.jar und
sdo_access_beans.jar
werden dem Projekt hinzugefügt (JAR-Dateien der SDO-Laufzeit werden
den Klassenpfaden aller V6.0-Projekte automatisch hinzugefügt).
- JAR-Dateien von
JavaServer Pages Standard Tag Library (JSTL) 1.0 werden aus dem Projekt
entfernt. (JAR-Dateien von JSTL 1.1/JSP 2.0 werden automatisch zu
Klassenpfaden von V6.0-Projekten hinzugefügt.)
- In
Java-Quellendateien werden die folgenden
Importanweisungen geändert:
- com.ibm.websphere.wdo.access.connections.ConnectionManager
wird in
com.ibm.websphere.sdo.access.connections.ConnectionManager
geändert.
- com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper
wird in
com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper
geändert.
Änderungen an Webprojekten nach dem Ändern des Zielservers von V6.0 in V5.1 (SDO in WDO)
Wenn der Zielserver von V6.0
in V5.1 geändert wird, werden automatisch die folgenden Änderungen
vorgenommen:
- Die JAR-Dateien
sdo_web.jar und
sdo_access_beans.jar
werden aus dem Projekt entfernt.
- Die JAR-Dateien
wdo_web.jar und
wdo_jdbc_access.jar
werden zum Projekt hinzugefügt.
- Die folgenden JAR-Dateien
werden zum Klassenpfad des Projekts hinzugefügt:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- JAR-Dateien von JSTL 1.0
werden zum Projekt hinzugefügt. (JAR-Dateien von JSTL 1.1/JSP 2.0
werden aus dem Klassenpfad des Projekts entfernt.)
- In
Java-Quellendateien werden die folgenden
Importanweisungen geändert:
- com.ibm.websphere.sdo.access.connections.ConnectionManager
wird zu
com.ibm.websphere.wdo.access.connections.ConnectionManager.
- com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper
wird zu
com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper.
Änderungen an Webprojekten nach dem Ändern der J2EE-Stufe Ihrer Anwendung von 1.3 in 1.4
Zusätzlich zu den
Änderungen, die durch Ändern des Zielservers in
WebSphere
Application Server V6.0 zum Migrieren von WDO in SDO auftreten, werden
durch das Ändern der J2EE-Spezifikationsstufe Ihrer Anwendung von 1.3
in 1.4 alle Tagbibliotheksverweise in Ihren JSPs so geändert, dass
statt WDO, JSTL 1.0-Tagbibliotheken nun SDO, JSTL 1.1/JSP
2.0-Tagbibliotheken verwendet werden. Die folgende Tabelle zeigt die
Änderungen an den JSP-Tagbibliotheksverweisen bei einer Migration von
J2EE 1.3 auf J2EE 1.4.
Tabelle 1. JSP-Tagbibliotheksverweise in J2EE 1.3 und J2EE 1.4.
J2EE 1.3-Tagbibliothek (WDO) |
J2EE 1.4-Tagbibliothek (SDO) |
http://www.ibm.com/websphere/wdo/core |
http://www.ibm.com/websphere/sdo/core |
http://java.sun.com/jstl/core |
http://java.sun.com/jsp/jstl/core |
http://java.sun.com/jstl/fmt |
http://java.sun.com/jsp/jstl/fmt |
http://java.sun.com/jstl/xml |
http://java.sun.com/jsp/jstl/xml |
http://java.sun.com/jstl/sql |
http://java.sun.com/jsp/jstl/sql |
Reservierte
EGL-Wörter in V6.0
In Rational Web Developer wurden neue Wörter für EGL (Enterprise Generation Language) reserviert.
Die folgenden, neuen Wörter sind für EGL reserviert:
- as
- isa
- like
- matches
- money
- openUI
- ref
- self
- string
- this
EGL-Programme aus
WebSphere Studio V5.1.x, die in einen
V6.0-Arbeitsbereich importiert und erstellt werden und die diese
Wörter als Variablen- oder Komponentennamen verwenden, werden mit der
folgenden Nachricht
gekennzeichnet:IWN.SYN.2002.e 39/2 Syntaxfehler in der Eingabe
"variableName". Sie können das Problem korrigieren, indem Sie
die Variable umbenennen.
Kapitel 2. Faces-Laufzeitressourcen
für Webprojekte aus
Rational Web Developer V6.0
aktualisieren
Die JavaServer Faces- und Faces Client-Laufzeitressourcen, die ursprünglich mit Rational Web Developer V6.0 bereitgestellt wurden, wurden für Rational Web Developer V6.0.1 aktualisiert. Wenn Sie die Entwicklung der mit dieser früheren Produktversion erstellten Projekte fortsetzen wollen, wird empfohlen, dass Sie die Ressourcen für die Faces- und Faces Client-Laufzeit auf die jeweils neueste Stufe aktualisieren.
In
Rational Web Developer V6.0.1 werden die
Faces- und Faces Client-Laufzeitressourcen automatisch aktualisiert,
wenn ein Webprojekt importiert oder ein Arbeitsbereich geöffnet wird,
das bzw. der Faces- oder Faces Client-Ressourcen enthält, die nicht
auf dem neuesten Stand sind. Nachdem Sie ein Webprojekt oder einen
Arbeitsbereich aus
Rational Web Developer V6.0 in
Rational Web Developer V6.0.1 importiert
bzw. geöffnet haben, werden Sie aufgefordert, diese
Laufzeitressourcen auf den neuesten Stand zu bringen.
Laufzeitressourcen automatisch aktualisieren
Führen Sie folgende Schritte aus, um die Faces- und Faces Client-Laufzeitressourcen für ein Webprojekt automatisch zu aktualisieren:
- Importieren Sie ein
Webprojekt (oder einen Arbeitsbereich) mit Faces- oder Faces
Client-Inhalt aus
Rational Web Developer V6.0. Das Fenster
Projektmigration wird geöffnet.
Anmerkung:
Wenn
das Fenster Projektmigration nicht geöffnet wird, ist
möglicherweise Ihre Einstellung für automatische Erstellung
inaktiviert. Klicken Sie im Projektexplorer mit der rechten Maustaste
auf Ihr Webprojekt, und wählen Sie
Build -> Projekt aus; der Prozess zum erneuten Erstellen
eines Projekts öffnet das Fenster
Projektmigration.
- Wenn in Ihrem
Arbeitsbereich noch andere Webprojekte mit Faces- oder Faces
Client-Inhalt vorhanden sind, können Sie
Diese Auswahl auf alle anderen Projekte anwenden, für
die ein Upgrade ausgeführt werden muss auswählen, damit alle
diese Projekte aktualisiert werden.
- Klicken Sie auf eine
der folgenden Optionen:
- Klicken Sie auf
Ja, um die Aktualisierung automatisch
auszuführen.
- Klicken Sie auf
Später, um die Aktualisierung auf einen späteren
Zeitpunkt zu verschieben. Wenn Sie die Laufzeitressourcen automatisch
aktualisieren wollen, nachdem Sie
Später ausgewählt haben, müssen Sie das
Webprojekt schließen und erneut starten oder die Workbench neu
starten, bevor Sie Ihr Webprojekt erneut erstellen. Wenn Sie die
automatische Erstellung inaktiviert haben, klicken Sie mit der rechten
Maustaste auf Ihr Webprojekt, und wählen Sie
Projekt erstellen aus.
- Klicken Sie auf
Nie, um Ihre Laufzeitressourcen auf dem Stand der
früheren Version beizubehalten. Wenn Sie
Nie auswählen und absichtlich die
Laufzeitressourcen der früheren Version beibehalten, werden Sie nicht
mehr zur Aktualisierung der Ressourcen aufgefordert. Sollte dann
zukünftig eine Aktualisierung der Laufzeitressourcen erforderlich
werden, müssen Sie dies manuell ausführen.
Laufzeitressourcen manuell aktualisieren
Führen Sie folgende Schritte aus, um die Faces- und Faces Client-Laufzeitressourcen für ein Webprojekt manuell zu aktualisieren:
- Erstellen Sie ein
neues Webprojekt (bzw. ein neues EGL-Webprojekt, wenn Sie mit EGL
arbeiten) mit dem Namen
JSF601. Sie werden dieses Projekt lediglich als
Quelle für die neuesten Laufzeitressourcen verwenden, und Sie
können es nach Abschluss der Aktualisierung löschen.
- Klicken
Sie im Projektexplorer mit der rechten Maustaste auf das Projekt
JSF601, und wählen Sie im Menü die Option
Eigenschaften aus.
- Klicken
Sie auf Funktionen des Webprojekts, und wählen Sie
Faces-Basiskomponenten hinzufügen und
Faces Client Framework hinzufügen aus. Klicken Sie
anschließend auf
OK.
- Wenn Sie mit EGL arbeiten, erstellen Sie eine
JSF-Seitendatei wie folgt:
- Klicken
Sie mit der rechten Maustaste auf den Ordner 'WebContent' Ihres neuen
EGL-Webprojekts.
- Wählen
Sie
Neu -> Andere -> Faces-JSP-Datei aus.
Die Dateien
eglintdebug.jar und
eglintdebugsupport.jar werden zu Ihrem Projekt
hinzugefügt.
- Führen
Sie für jedes vorhandene Faces-Projekt, das Sie aktualisieren wollen,
die folgenden Schritte aus:
- Erweitern
Sie im Projektexplorer ein vorhandenes Projekt, um die im Ordner
WebContent/WEB-INF/lib/
vorhandenen Dateien anzuzeigen. Suchen und löschen Sie die folgenden
JAR-Dateien in diesem Verzeichnis:
- eglintdebug.jar
(nur EGL)
- eglintdebugsupport.jar
(nur EGL)
- fda6.jar
(nur EGL)
- fdaj6.jar
(nur EGL)
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- odc-jsf.jar
- Kopieren
Sie aus dem Verzeichnis
WebContent/WEB-INF/lib
des Projekts JSF601 für jede der gelöschten JAR-Dateien
jeweils die JAR-Datei desselben Namens, und fügen Sie sie in Ihr
ursprüngliches Projekt an derselben Position ein. Für einige
Konfigurationen müssen nicht alle JAR-Dateien im Projekt vorhanden
sein; kopieren Sie keine der JAR-Dateien, die nicht im ursprünglichen
Projekt vorhanden war.
- Wenn Sie mit EGL arbeiten, klicken Sie mit der
rechten Maustaste auf den Namen jedes EGL-Webprojekts und klicken Sie
auf Generieren. Wenn Sie die Projekte nicht automatisch
erstellen, klicken Sie anschließend auf
Projekt -> Build für alle.
- Löschen
Sie das Webprojekt JSF601.
Kapitel 3. Migration
der J2EE-Projekte
Der J2EE-Migrationsassistent wurde in Rational Web Developer V6.0 6.0 aktualisiert, um Projekte der Spezifikationsstufe J2EE auf J2EE 1.4 zu migrieren. Der J2EE-Migrationsassistent unterstützt die Migration von Spezifikationsstufe J2EE 1.2 und 1.3 auf J2EE 1.4 für alle J2EE-Modularten.
Weitere Informationen zur
Migration von Artefakten der Spezifikationsstufen J2EE 1.3 und 1.2 auf
Spezifikationsstufe J2EE 1.4 finden Sie in Migration
der J2EE-Spezifikationsstufe 1.3 auf 1.4 und Migration
von J2EE-Spezifikationsstufe 1.2 auf 1.4.
Anmerkung:
Bevor
Sie den J2EE-Migrationsassistenten verwenden, sollten Sie unbedingt die
folgenden Schritte ausführen:
- Sichern Sie Ihren
gesamten Arbeitsbereich.
- Wenn Sie mit einem
gemeinsam genutzten Repository arbeiten, sperren oder entnehmen Sie alle
entsprechenden Projekte.
Gehen Sie wie folgt vor,
um auf den J2EE-Migrationsassistenten zuzugreifen:
- Klicken Sie in der
Sicht J2EE-Hierarchie der Perspektive "J2EE" mit der rechten
Maustaste auf das Unternehmensanwendungsprojekt, das Sie migrieren
wollen.
- Wählen
Sie im Kontextmenü die Option
Migrieren -> J2EE-Migrationsassistent aus.
- Befolgen
Sie die Anweisungen auf der Begrüßungsseite des
J2EE-Migrationsassistenten, bevor Sie mit dem Migrationsprozess
fortfahren.
Hinweis:
- Für die Migration von
sicheren Web-Services (J2EE 1.3 auf 1.4) ist eine manuelle Migration der
sicheren Binding- und Erweiterungsdateien erforderlich. Weitere
Informationen finden Sie in Migration
sicherer Web-Services.
Ausführliche Informationen zur Verwendung des J2EE-Migrationsassistenten finden Sie in der Onlinehilfe. Änderungen am Assistenten sind in Änderungen
am J2EE-Migrationsassistenten in
Rational Web Developer V6.0
beschrieben.
Weitere Informationen zu
den Änderungen, die an Artefakten der Spezifikationsstufen J2EE 1.3
und 1.2 bei der Migration auf J2EE 1.4 ausgeführt werden, finden Sie
in Migration
der J2EE-Spezifikationsstufe 1.3 auf 1.4 und Migration
von J2EE-Spezifikationsstufe 1.2 auf 1.4.
Migration
sicherer Web-Services
Beim Migrieren von Web-Services von J2EE 1.3 auf J2EE 1.4. mit dem J2EE-Migrationsassistent werden sichere Web-Services nicht migriert. Für die Migration von sicheren Web-Services sind manuelle Schritte erforderlich.
Nach der J2EE-Migration
müssen die sicheren Binding- und Erweiterungsdateien wie folgt
manuell auf J2EE 1.4 migriert werden:
- Klicken Sie doppelt
auf die Datei
webservices.xml,
um den Editor für Web-Services aufzurufen.
- Wählen
Sie die Registerkarte
Binding-Konfigurationen aus, um die Binding-Datei zu
bearbeiten.
- Fügen
Sie alle erforderlichen Binding-Konfigurationen unter den neuen
Abschnitten Anforderung von
Verbraucher-Binding-Konfigurationsdetails und
Binding-Konfigurationsdetails für das Generieren von
Antworten hinzu.
- Wählen
Sie die Registerkarte
Erweiterung aus, um die Erweiterungsdatei zu
bearbeiten.
- Fügen
Sie alle erforderlichen Erweiterungskonfigurationen unter den neuen
Abschnitten Anforderung von
Verbraucherservicekonfigurationsdetails und
Servicekonfigurationsdetails für das Generieren von
Antworten hinzu.
- Speichern
Sie, und schließen Sie den Editor.
Migration
der J2EE-Spezifikationsstufe 1.3 auf 1.4
J2EE-Projekte können von der Spezifikationsstufe J2EE 1.3 auf J2EE 1.4 migriert werden. In diesem Abschnitt werden für jeden J2EE-Projekttyp die durch den J2EE-Migrationsassistenten von Spezifikationsstufe J2EE 1.3 auf J2EE 1.4 migrierten Artefakte beschrieben.
Webprojekte
(Servletstufe 2.3 auf Servletstufe 2.4)
Artefakte eines Webimplementierungsdeskriptors werden durch den J2EE-Migrationsassistenten migriert, wenn ein J2EE 1.3-Webprojekt auf J2EE 1.4 migriert wird.
Die folgenden Webanwendungsartefakte werden migriert:
Authentifizierungseinschränkungen
J2EE 1.4 enthält ein
Objekt
Description
mit zwei Attributen: language und
value. Dieses Objekt
Description
war in J2EE 1.3 nicht vorhanden; die Beschreibung war ein Attribut der
Authentifizierungseinschränkung. Wenn die Artefakte eines
Webimplementierungsdeskriptors auf J2EE 1.4 migriert werden, wird daher
der Wert (value) für das Objekt
Description
aus dem Beschreibungsattribut der Authentifizierungseinschränkung
übernommen.
Sicherheitseinschränkungen
In J2EE 1.3 war die
Beschreibung ein Attribut der Sicherheitseinschränkung. J2EE 1.4
enthält ein neues Objekt
Description
mit den Attributen language und
value. Der Wert
(value) des Objekts
Description
wird daher aus dem Beschreibungsattribut der Sicherheitseinschränkung
übernommen.
Webanwendung
Das
Beschreibungszeichenfolgeattribut des Objekts
ContextParam
der Spezifikationsstufe 1.3 wurde in J2EE 1.4 in ein Objekt
Description in
ParamValue
verschoben.
Das Objekt
TagLib der
Spezifikationsstufe J2EE 1.3 wurde in J2EE 1.4 in das Objekt
JSPConfig
verschoben. Die
JSPConfig-Objekte
gehörten in 1.3 zum Webstammobjekt.
Connectorprojekte (JCA 1.0 auf JCA 1.5)
Der J2EE Migrationsassistent migriert die Artefakte eines JCA 1.0-Deskriptors (JCA, J2EE Connector Architecture) auf JCA 1.5. Die migrierten Artefakte gehören zu den Elementen des Objekts ResourceAdaptor, da auf Spezifikationsstufe J2EE 1.4 für Connectorprojekte zwei neue Objekte, OutboundResourceAdaptor und ConnectionDefinition, zum Objekt ResourceAdaptor hinzugefügt wurden.
Die Zuordnung der migrierten Elemente wird nachstehend beschrieben.
- Die folgenden Elemente
werden vom Objekt
ResourceAdaptor
in das Objekt
OutboundResourceAdaptor
versetzt:
- reauthenticationSupport
- transactionSupport
- Die folgenden Elemente
werden vom Objekt
ResourceAdaptor
in das Objekt
ConnectionDefinition
versetzt:
- managedConnectionFactoryClass
- connectionFactoryInterface
- connectionFactoryImplClass
- connectionInterface
- connectionImplClass
- Das Objekt
outboundResourceAdaptor
enthält eine Liste mit
ConnectionDefinition-Definitionen.
Daher wird
ConnectionDefinition
zu der in
OutboundResourceAdaptor
enthaltenen
ConnectionDefinition-Liste
hinzugefügt.
- Das Objekt
OutboundResourceAdaptor
ist im Objekt
ResourceAdaptor
enthalten.
- Das Objekt
AuthenticationMechanism
wurde in JCA 1.5 einigen Änderungen unterzogen, wobei das Element
customAuthMechType
durch
authenticationMechanism
und das Element
authenticationType
durch
authenticationMechanism
ersetzt wurde.
- Das
Beschreibungsattribut im Objekt
ResourceAdaptor
wird durch ein Beschreibungsobjekt ersetzt, wobei im Beschreibungsobjekt
die Beschreibungsattributzeichenfolge für die folgenden Objekte auf
das Element value gesetzt ist:
- SecurityPermission
- AuthenticationMechanism
- ConfigurationProperties
Web-Services
(J2EE 1.3 auf J2EE 1.4)
Der Spezifikation J2EE 1.4 wurde durch die neue JAX-RPC 1.0-API Unterstützung für Web-Services hinzugefügt.
Die JAX-RPC-API unterstützt Serviceendpunkte durch:
- Servlets mit
JAXR-RPC
- Servlets mit direktem
SOAP
- Session-Beans ohne
Status
Die Spezifikation J2EE 1.4 unterstützt die Web-Services für die J2EE-Spezifikation (JSR 109). JSR 109 definiert die Implementierungsanforderungen für Web-Services und verwendet das Programmiermodell JAX-RPC.
Mit dem
J2EE-Migrationsassistenten werden die folgenden Web-Service-Artefakte
migriert:
- Web-Services-Deskriptor
- Web-Services-Client-Deskriptor
- JAX-RPC-Zuordnungsdeskriptor
Migration von Implementierungsdeskriptoren für Web-Services
Implementierungsdeskriptoren für Web-Services, die in J2EE 1.3-Projekten enthalten sind und auf die Spezifikationsstufe J2EE 1.4 migriert wurden, werden von JSR-109 V1.0 (für J2EE 1.3) auf J2EE 1.4 migriert.
Gemäß der
Definition von JSR-109 V1.0 umfassen Implementierungsdeskriptoren für
Web-Services die Dateien
webservices.xml,
webservicesclient.xml
und alle Implementierungsdeskriptoren für JAX-RPC-Zuordnung, auf die
in den Dateien
webservices.xml
und
webservicesclient.xml
verwiesen wird. Wie bei anderen J2EE-Implementierungsdeskriptoren
verändert die Migration die Struktur der in den Deskriptoren
enthaltenen Informationen, sodass diese diese mit der Spezifikation J2EE
1.4 konform sind. Eine strukturelle Änderung, die für
Implementierungsdeskriptoren für Web-Services kennzeichnend ist, ist
die geänderte Darstellung der qualifizierten Namen. In JSR-109 V1.0
werden qualifizierte Namen mithilfe einer aus zwei Elementen bestehenden
Sequenz dargestellt,
<namespaceURI>
und
<localpart>,
die die namespace-URI bzw. den lokalen Teil des Namens enthalten.
Qualifizierte Namen basieren in J2EE 1.4 auf dem XMLSchema QName-Typ,
der XML-Namespaces verwendet.
Weitere Informationen
zur Migration der einzelnen Implementierungsdeskriptoren für
Web-Services finden Sie in den nachfolgenden Abschnitten.
- Web-Services-Deskriptor
(webservices.xml)
Der
Implementierungsdeskriptor
webservices.xml
ist in Webprojekten vorhanden, die J2EE-Web-Services enthalten. Sowohl
das Element
<wsdl-port>
als auch das Element
<soap-header>
enthalten qualifizierte Namen und ihr Inhalt wird auf das J2EE
1.4-Format migriert.
Wenn z. B.
<wsdl-port>
vor der Migration wie folgt dargestellt
wird,
<wsdl-port>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBook</localpart>
</wsdl-port>
wird
<wsdl-port>
nach der Migration wie folgt
dargestellt:
<wsdl-port xmlns:pfx="http://addressbook.webservice">pfx:AddressBook</wsdl-port>
Das Präfix "pfx" wird
als Namespace-Präfix für alle migrierten qualifizierten Namen
verwendet.
- Web-Services-Client-Deskriptor
(webservicesclient.xml)
Der
Implementierungsdeskriptor
webservicesclient.xml
ist in J2EE 1.3-Webprojekten und Anwendungsclientprojekten vorhanden,
die J2EE-Web-Service-Clients enthalten. Während der Migration von
J2EE 1.3 auf 1.4 werden die Inhalte von
webservicesclient.xml
migriert und in den Implementierungsdeskriptor für das Projekt
versetzt. Dabei tritt der folgende Prozess auf:
- Für Webprojekte
werden alle
<service-ref>-Elemente
in
webservicesclient.xml unter das
<web-app>-Element
in web.xml versetzt.
- Für
Anwendungsclientprojekte werden alle
<service-ref>-Elemente
in
webservicesclient.xml
unter das
<application-client>-Element
in
application-client.xml
versetzt.
- Webservicesclient.xml
wird gelöscht.
Sowohl das Element
<service-qname>
als auch das Element
<soap-header>
enthalten qualifizierte Namen, und ihr Inhalt wird auf das J2EE
1.4-Format migriert. Wenn z. B.
<service-qname>
vor der Migration wie folgt dargestellt
wird,
<service-qname>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBookService</localpart>
</service-qname>
wird
<service-qname>
nach der Migration wie folgt
dargestellt:
<service-qname xmlns:pfx="http://addressbook.webservice">pfx:AddressBookService</service-qname>
Das Präfix "pfx"
wird als Namespace-Präfix für alle migrierten qualifizierten Namen
verwendet.
- JAX-RPC-Zuordnungsdeskriptor
Die
Implementierungsdeskriptoren
webservices.xml
und
webservicesclient.xml
können beide auf einen oder mehrere Implementierungsdeskriptoren
für JAX-RPC-Zuordnung verweisen.
In der Datei
webservices.xml
sind diese Verweise im Element
<jaxrpc-mapping-file>
unter dem jeweiligen Element
<webservice-description>
enthalten. In der Datei
webservicesclient.xml
sind diese Verweise im Element
<jaxrpc-mapping-file>
unter dem jeweiligen Element
<service-ref>
enthalten.
Während der
Migration von J2EE 1.3 auf 1.4 werden alle Implementierungsdeskriptoren
für die JAX-RPC-Zuordnung, auf die in
webservices.xml
und
webservicesclient.xml
verwiesen wird, migriert. Die Migration umfasst das Migrieren aller
qualifizierten Namen auf das J2EE 1.4-Format (siehe die vorstehenden
Abschnitte über
webservices.xml und
webservicesclient.xml
für Beispiele für qualifizierte Namen nach der
Migration).
Migration
von J2EE-Spezifikationsstufe 1.2 auf 1.4
J2EE-Module können von Spezifikationsstufe J2EE 1.2 auf J2EE 1.4 migriert werden. In diesem Abschnitt werden die Artefakte für J2EE-Projekte beschrieben, die durch den J2EE-Migrationsassistenten von Spezifikationsstufe J2EE 1.2 auf J2EE 1.4 migriert werden.
Ausführliche
Informationen zur Verwendung des J2EE-Migrationsassistenten finden Sie
in Kapitel 3. Migration
der J2EE-Projekte.
Webprojekte
(Servletstufe 2.2 auf Servletstufe 2.4)
Artefakte eines Webimplementierungsdeskriptors werden durch den J2EE-Migrationsassistenten migriert, wenn ein J2EE 1.2-Webprojekt auf die Spezifikationsstufe J2EE 1.4 migriert wird.
Die folgenden Webanwendungsartefakte werden migriert:
Authentifizierungseinschränkungen
J2EE 1.4 enthält
ein Objekt
Description
mit zwei Attributen: language und
value. Dieses Objekt
Description
war in J2EE 1.2 nicht vorhanden; die Beschreibung war ein Attribut der
Authentifizierungseinschränkung. Wenn die Artefakte eines
Webimplementierungsdeskriptors auf J2EE 1.4 migriert werden, wird daher
der Wert (value) für das Objekt
Description
aus dem Beschreibungsattribut der Authentifizierungseinschränkung
übernommen.
Sicherheitseinschränkungen
In J2EE 1.2 war die
Beschreibung ein Attribut der Sicherheitseinschränkung. J2EE 1.4
enthält ein neues Objekt
Description
mit den Attributen language und
value. Der Wert
(value) des Objekts
Description
wird daher aus dem Beschreibungsattribut der Sicherheitseinschränkung
übernommen.
Webanwendung
Das
Beschreibungszeichenfolgeattribut des Objekts
ContextParam
der Spezifikationsstufe 1.2 wurde in J2EE 1.4 in ein Objekt
Description
in
ParamValue
verschoben.
Das Objekt
TagLib der
Spezifikationsstufe J2EE 1.2 wurde in J2EE 1.4 in das Objekt
JSPConfig
verschoben. Die
JSPConfig-Objekte
gehörten in 1.2 zum Webstammobjekt.
Änderungen
am J2EE-Migrationsassistenten in
Rational Web Developer V6.0
In Rational Web Developer V6.0 6.0 wurden Änderungen am J2EE-Migrationsassistenten vorgenommen, die für die Migration aller Stufen der Spezifikation J2EE gelten.
Optionale Migration der Projektstruktur
In
WebSphere
Studio V5.1.x bis V5.1.2 erfolgte die Migration der Projektstruktur
gleichzeitig mit der Migration der J2EE-Spezifikationsstufe. Die
Migration der Projektstruktur war bei der Migration der
J2EE-Spezifikationsstufe nicht optional.
Beim
J2EE-Migrationsassistenten in
Rational Web Developer V6.0 ist
Projektstruktur migrieren eine separate, optionale
Auswahl für J2EE-Spezifikationsstufe für Projekte migrieren.
Die Migration der J2EE-Spezifikationsstufe und die Migration der
Projektstruktur können unabhängig voneinander durchgeführt
werden.
Zielserver erforderlich
In
Rational Web Developer V6.0 muss für
neue und vorhandene J2EE-Projekte, die auf eine höhere
J2EE-Spezifikationsstufe migriert werden, ein Zielserver für das
Projekt angegeben werden. Serverzielunterstützung (Server Targeting)
ist in V6.0 der Standardmechanismus für das Festlegen des
Klassenpfads für J2EE-Projekte. Informationen zum Festlegen eines
Zielservers und zur Verwendung des J2EE-Migrationsassistenten finden Sie
in der Onlinehilfe.
Kapitel 4. Änderungen
in WebSphere-Testumgebungen
Die mit Rational Web Developer V6.0 gelieferten Testumgebungen von WebSphere Application Server enthalten gegenüber den mit früheren Editionen von WebSphere Studio Site Developer bereitgestellten Testumgebungen einige Änderungen.
Es folgt eine
Zusammenfassung der Änderungen an den
WebSphere
Application Server-Testumgebungen
Rational Web Developer V6.0:
- Die Testumgebungen bieten
für WebSphere Application Server V4.x-Server keine
Unterstützung mehr. Anwendungen der Spezifikationsstufe J2EE 1.2
können jedoch nach wie vor exportiert und zu Testzwecken manuell auf
fernen WAS V4.x-Servern implementiert werden.
- WebSphere Application Server V6.0-Server wurde als
installierbare Testumgebung hinzugefügt. Er unterstützt aktive
Anwendungen der Spezifikationsstufe J2EE 1.4.
Die folgende Tabelle zeigt
die Stufen der WebSphere Application Server-Testumgebungen, die im
Produktumfang der verschiedenen Versionen von
WebSphere Studio Site Developer und
Rational Web Developer enthalten sind.
Tabelle 2. WebSphere Application Server-Testumgebungen in WebSphere Studio Site Developer und Rational Web Developer
|
WebSphere Application Server V4.x AEs |
WebSphere Application Server V5.x Base |
WebSphere Application Server Express V5.x |
WebSphere Application Server V6.0 |
WebSphere Studio Site Developer
V5.1 |
V4.0.6 |
V5.0.2 |
V5.0.2 |
nicht verfügbar |
WebSphere Studio Site Developer
V5.1.1 |
V4.0.7 + PQ78374 |
V5.0.2 + PQ78374 +PQ78419, V5.1 |
V5.0.2 & V5.1 |
nicht verfügbar |
WebSphere Studio Site Developer
V5.1.2 |
V4.0.7 + PQ78374 |
V5.0.2 + PQ78374 +PQ78419, V5.1.0.3 |
V5.0.2 & V5.1.0.3 |
nicht verfügbar |
Rational Web Developer V6.0 |
nicht verfügbar |
V5.0.x, V5.1.1 |
V5.0.2 & V5.1.1 |
V6.0 |
Copyright und Bemerkungen