IBM Rational Application 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 Application Developer V5.1.x auf Rational Application Developer V6.0 bereit.
Weitere Informationen
finden Sie zu den folgenden Themen:
Informationen zur
Verwendung von
Rational Application 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 Application 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 Application 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 Application 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 Application 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 Application Developer V6.0
entfernt. Alle EGL-Projekte werden problemlos ohne diese Perspektive auf
Rational Application 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 Application 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 Application 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:
- Wenn Sie zum
Entwickeln von Portletprojekten
Portal
Toolkit V5.0.2.2 mit WebSphere Studio V5.1.2 verwendet haben, wird
Ihr Arbeitsbereich automatisch so migriert, dass er mit
Rational Application Developer kompatibel
ist. Weitere Informationen finden Sie unter Kapitel 5. Migration
auf die Portaltools in
Rational Application Developer V6.0.
- 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 Application 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 Application 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 Application 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 Application 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 Application 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 beim Installieren von
Rational Application Developer eine
frühere Version einer
WebSphere V5.x-Einheitentestumgebung installiert
haben und den integrierten Nachrichtenübertragungsservice verwenden,
führen Sie einen Upgrade für den Service aus, indem Sie die mit
Rational Application Developer
bereitgestellte Version installieren. Weitere Informationen zur
Installation des integrierten Nachrichtenübertragungsservices finden
Sie im Installationshandbuch.
- Wenn
Sie Funktionen verwenden, die Agent Controller benötigen, führen
Sie einen Upgrade für Agent Controller aus, indem Sie die mit
Rational Application 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 Application Developer öffnen, wird er automatisch migriert. Nach der Migration eines Arbeitsbereichs können Sie ihn nicht mehr in WebSphere Studio Application 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 Application 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
- Ausführen der
Aktion "Kompatibilität entfernen" für ein
Unternehmensanwendungsprojekt (wenn das Unternehmensanwendungsprojekt
oder eines seiner Module oder Dienstprogrammprojekte mit
WebSphere Studio Application Developer
V5.1.x abwärts kompatibel sein muss)
Eine
.compatibility-Datei wird automatisch im
Projektverzeichnis erstellt, wenn ein V5.1.x-Projekt im
Rational Application Developer
V6.0-Arbeitsbereich geöffnet wird. Die
.compatibility-Datei wird von
Rational Application 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 Application Developer
V5.1.x finden Sie in Kompatibilität
mit WebSphere Studio V5.1.x inaktivieren.
Eclipse-bezogene Aspekte
Diese Version von Rational Application 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 Application 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 Application 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 Application 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 Application 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 Application 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 Application Developer V6.0 und mit
WebSphere Studio Application 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 Application Developer V6.0
festgelegt wird, geht die J2EE-Projektkompatibilität verloren und
muss erneut eingerichtet
werden.
UML-Diagrammkompatibilität
UML-Diagramme, die in
WebSphere Studio Application Developer
V5.1.x vorhanden waren, sind aufwärts kompatibel und können in
Rational Application Developer V6.0 im
Nur-Lesen-Modus geöffnet werden. In V6.0 werden UML-Diagramme, die in
V5.1.x-J2EE-Projekten erstellt wurden, bei der Migration der
J2EE-Projektstruktur automatisch vom J2EE-Migrationsassistenten
migriert. Nach der Migration können die UML-Diagramme in
Rational Application Developer V6.0
bearbeitet werden.
Anmerkung:
UML-Diagramme
in einem Arbeitsbereich, der auf
Rational Application Developer V6.0
migriert oder darin erstellt wurde, können nicht in
WebSphere Studio Application Developer
V5.1.x geöffnet werden.
Kompatibilität
mit WebSphere Studio V5.1.x inaktivieren
Die Kompatibilität mit WebSphere Studio Application Developer V5.1.x kann vollständig aus einem in Rational Application 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 Application 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 Application Developer
V5.1.x abwärts kompatibel.
Faces-Laufzeitressourcen
in einem Webprojekt aktualisieren
Die JavaServer Faces-Laufzeitressourcen, die ursprünglich mit WebSphere Studio Application Developer V5.1.x bereitgestellt wurden, wurden für Rational Application 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 Application 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 Application Developer
V5.1.x in
Rational Application 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 Application 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 Application 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 Application Developer V5.1.x bereitgestellt wurden, wurden für Rational Application 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 Application 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 Application Developer
V5.1.x in
Rational Application 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 Application 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 Application 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 Application 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 Application 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 Application 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 Application Developer in
Rational Application 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 Application 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 Application 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 Application 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 Application Developer V6.0
installierten JRE. Wenn Sie einen Arbeitsbereich aus
WebSphere Studio Application 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 Application 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 Application
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 Application 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 Application Developer V6.0
aktualisieren
Die JavaServer Faces- und Faces Client-Laufzeitressourcen, die ursprünglich mit Rational Application Developer V6.0 bereitgestellt wurden, wurden für Rational Application 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 Application 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 Application Developer V6.0 in
Rational Application 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 Application 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. Faces-Laufzeitressourcen
für Portletprojekte aus
Rational Application Developer V6.0
aktualisieren
Die JavaServer Faces- und Faces Client-Laufzeitressourcen, die ursprünglich mit Rational Application Developer V6.0 bereitgestellt wurden, wurden für Rational Application Developer V6.0.1 aktualisiert. Wenn Sie die Entwicklung der mit dieser früheren Produktversion erstellten Portletprojekte fortsetzen wollen, wird empfohlen, dass Sie die Ressourcen für die Faces- und Faces Client-Laufzeit auf die jeweils neueste Stufe aktualisieren.
In
Rational Application Developer V6.0.1 werden die
Faces- und Faces Client-Laufzeitressourcen automatisch aktualisiert,
wenn ein Portletprojekt importiert oder ein Arbeitsbereich geöffnet
wird, das bzw. der Faces- oder Faces Client-Laufzeitressourcen
enthält, die nicht auf dem neuesten Stand sind. Nachdem Sie ein
Portletprojekt oder einen Arbeitsbereich aus
Rational Application Developer V6.0 in
Rational Application Developer V6.0.1 importiert bzw.
geöffnet haben, werden Sie aufgefordert, diese Laufzeitressourcen auf
den neusten Stand zu bringen.
Laufzeitressourcen automatisch aktualisieren
Führen Sie folgende Schritte aus, um die Faces- und Faces Client-Laufzeitressourcen für ein Portletprojekt automatisch zu aktualisieren:
- Importieren Sie
ein Portletprojekt (oder einen Arbeitsbereich mit Faces- oder Faces
Client-Inhalt aus
Rational Application 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 Portletprojekt, und wählen Sie
Build -> Projekt aus; der Prozess zum erneuten Erstellen
eines Projekts öffnet das Fenster
Projektmigration.
- Wenn in Ihrem
Arbeitsbereich noch andere Portletprojekte 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
Portletprojekt schließen und erneut starten oder die Workbench neu
starten, bevor Sie Ihr Portletprojekt erneut erstellen. Wenn Sie die
automatische Erstellung inaktiviert haben, klicken Sie mit der rechten
Maustaste auf Ihr Portletprojekt, 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.
- Um die
portletspezifischen Faces-Laufzeitressourcen jsf-portlet.jar und
jsf-wp.jar zu aktualisieren, müssen Sie die unten aufgeführten
manuellen Aktualisierungsschritte ausführen.
Laufzeitressourcen manuell aktualisieren
Führen Sie folgende Schritte aus, um die Faces- und Faces Client-Laufzeitressourcen für ein Portletprojekt manuell zu aktualisieren:
- Erstellen Sie
ein neues Portletprojekt mit dem Namen
JSFP601. 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
JSFP601, und wählen Sie im Menü die Option
Eigenschaften aus.
- Klicken
Sie auf Funktionen des Webprojekts, und wählen Sie
Faces Client Framework für Portletprojekt
hinzufügen aus. Klicken Sie anschließend auf
OK.
- Führen
Sie für jedes vorhandene Faces-Portletprojekt, 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:
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- jsf-portlet.jar
- odc-jsf.jar
- Kopieren
Sie aus dem Verzeichnis
WebContent/WEB-INF/lib
des Projekts JSFP601 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 Ihr
Portletprojekt die
IBM
Portlet-API oder die Personen-Link-Komponente verwendet, kopieren Sie
die Datei jsf-wp.jar in Ihr ursprüngliches Projekt.
- Wenn Sie die
Datei odc-jsf.jar kopieren, kopieren Sie auch die
Datei odc-jsf-portlet.jar.
- Löschen
Sie das Portletprojekt
JSFP601.
Kapitel 4. Migration
der J2EE-Projekte
Der J2EE-Migrationsassistent wurde in Rational Application 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:
Ausführliche Informationen zur Verwendung des J2EE-Migrationsassistenten finden Sie in der Onlinehilfe. Änderungen am Assistenten sind in Änderungen
am J2EE-Migrationsassistenten in
Rational Application 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.
Enterprise
JavaBean-Projekte (EJB 2.0 auf EJB 2.1)
Der J2EE-Migrationsassistent unterstützt die Migration von Enterprise-Bean-Implementierungsdeskriptoren von EJB-Ressourcen der Spezifikationsstufe J2EE 1.3 auf die Spezifikationsstufe J2EE 1.4. Session-Beans ohne Status und nachrichtengesteuerte Beans werden auf J2EE 1.4 migriert.
Migration von Session-Beans
Der J2EE-Migrationsassistent migriert Session-Beans ohne Status, die als Serviceendpunktschnittstellen (SEI, Service Endpoint Interface) im Deskriptor webservices.xml eines EJB-Projekts der
Spezifikationsstufe J2EE 1.3 definiert sind, auf die Spezifikationsstufe
J2EE 1.4, indem die Serviceendpunktschnittstellen auf die Session-Bean
ohne Status gesetzt werden.
Die Spezifikation J2EE
1.4 erfordert, dass eine SEI als eine Session-Bean ohne Status definiert
ist, falls die Session-Bean als ein Web-Service-Endpunkt verwendet wird.
Während der Migration einer EJB-JAR-Datei wird für alle
Session-Beans im EJB-Projekt der Serviceendpunkt auf den Namen gesetzt,
der im Deskriptor webservices.xml des EJB-Projekts verwendet wird.
Es folgt ein Beispiel für die Darstellung der Metadaten eines
EJB-Projekts vor und nach der Migration auf die Spezifikationsstufe J2EE
1.4.
EJB-Projekt in J2EE 1.3: Deskriptor
webservices.xml mit Session-Bean ohne Status,
die vor der Migration als eine Web-Service-Endpunktschnittstelle
verwendet wurde
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN"
"http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd">
<webservices id="WebServices_1084831328093">
<webservice-description id="WebServiceDescription_1084831328093">
<webservice-description-name>EchoEJBService</webservice-description-name>
<wsdl-file>META-INF/wsdl/EchoEJB.wsdl</wsdl-file>
<jaxrpc-mapping-file>META-INF/EchoEJB_mapping.xml</jaxrpc-mapping-file>
<port-component id="PortComponent_1084831328103">
<port-component-name>EchoEJB</port-component-name>
<wsdl-port id="WSDLPort_1084831328103">
<namespaceURI>http://test</namespaceURI>
<localpart>EchoEJB</localpart>
</wsdl-port>
<service-endpoint-interface>test.EchoEJB</service-endpoint-interface>
<service-impl-bean id="ServiceImplBean_1084831328103">
<ejb-link>EchoEJB</ejb-link>
</service-impl-bean>
</port-component>
</webservice-description>
</webservices>
Die Tags <service-endpoint-interface> und
<service-impl-bean> im vorstehenden
Beispiel definieren die Session-Bean ohne Status "EchoEJB" vor der
Migration als einen Serviceendpunkt im Web-Service-Deskriptor auf der
Spezifikationsstufe J2EE 1.3.
EJB-Projekt in J2EE 1.4: EJB-Implementierungsdeskriptor
für die vorstehende Session-Bean ohne Status "EchoEJB" mit
Serviceendpunktschnittstelle, die vom Migrationsprozess erstellt
wurde
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar>
<ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
<display-name>
EchoEJBProject</display-name>
<enterprise-beans>
<session id="EchoEJB">
<ejb-name>EchoEJB</ejb-name>
<home>test.EchoEJBHome</home>
<remote>test.EchoEJB</remote>
<service-endpoint>test.EchoEJB</service-endpoint>
<ejb-class>test.EchoEJBBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
Der Tag <service-endpoint> im vorstehenden
Beispiel definiert "EchoEJB" nach der Migration als einen
Serviceendpunkt der Spezifikationsstufe J2EE 1.4.
Migration von nachrichtengesteuerten Beans
Der J2EE-Migrationsassistent unterstützt die Migration von nachrichtengesteuerten Beans von EJB 2.0 auf nachrichtengesteuerte Beans des Typs EJB 2.1.
Nachrichtengesteuerte
Beans wurden in EJB 2.0 eingeführt, um die Verarbeitung asynchroner
Nachrichten aus einem Java-Nachrichtenservice zu unterstützen. Die
Spezifikationsstufe EJB 2.1 erweitert die Definition von
nachrichtengesteuerten Beans, sodass sie jegliches Nachrichtensystem,
nicht nur JMS, unterstützen
können.
Anmerkung:
Nachrichtengesteuerte
Beans, die von der Spezifikationsstufe EJB 2.0 auf EJB 2.1 migriert
wurden und für WebSphere Application Server Version 6 implementiert
werden, müssen auf einem Java Connector Architecture (JCA)
1.5-Ressourcenadapter implementiert werden anstatt auf einem
Listener-Port (wie in WebSphere Application Server Version 5). Um einen
JCA-Adapter verwenden zu können, müssen Sie mit dem Editor für
Implementierungsdeskriptoren die WebSphere-Bindingeinstellungen für
die nachrichtengesteuerten Beans des Typs EJB 2.1 ändern. Siehe
Nachrichtengesteuerte
Bean des Typs EJB 2.1 für die Verwendung eines JCA-Adapters
konfigurieren.
Bei den aus EJB 2.0
migrierten, nachrichtengesteuerten Beans handelt es sich um Folgende:
- acknowledgeMode
- messageSelector
- destinationType
- subscriptionDurablity
Einige der nachrichtengesteuerten Bean-Elemente aus EJB 2.0 werden durch activation-config-Eigenschaften ersetzt. Die in
der Eigenschaft activation-config zur Beschreibung des
Nachrichtenübertragungsservices verwendeten Eigenschaftsnamen und
-werte sind je nach Art des verwendeten Nachrichtenservices
unterschiedlich. EJB 2.1 definiert jedoch eine Reihe von festen
Eigenschaften für JMS-basierte nachrichtengesteuerte Beans.
Im folgenden Beispiel
werden Elemente einer Musterbean in EJB 2.0 mit der Darstellung der
Elemente in EJB 2.1 verglichen.
Es folgt ein Beispiel für nachrichtengesteuerte
Beanelemente in EJB 2.0:
<message-driven id="Mdb20">
<ejb-name>Mdb</ejb-name>
<ejb-class>ejbs.MdbBean</ejb-class>
<transaction-type>Bean</transaction-type>
<message-selector>mdbMessage</message-selector>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>
</message-driven>
Es folgt ein Beispiel für nachrichtengesteuerte
Beanelemente in EJB 2.1:
<message-driven id="Mdb21">
<ejb-name>Foo/ejb-name>
<ejb-class>ejbs.FooBean</ejb-class>
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Bean/transaction-type>
<message-destination-type>javax.jms.Topic</message-destination-type>
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Topic</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>subscriptionDurability</activation-config-property-name>
<activation-config-property-value>Durable</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>acknowledgeMode</activation-config-property-name>
<activation-config-property-value>AutoAcknowledge</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>messageSelector</activation-config-property-name>
<activation-config-property-value>fooSelector</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
Nachrichtengesteuerte
Bean des Typs EJB 2.1 für die Verwendung eines JCA-Adapters
konfigurieren
Nachrichtengesteuerte Beans, die von Enterprise Java Bean (EJB) 2.0 auf die Spezifikationsstufe EJB 2.1 migriert wurden und für WebSphere Application Server Version 6 implementiert werden, müssen anstatt auf einem Listener-Port auf einem Java Connector Architecture (JCA) 1.5-Ressourcenadapter implementiert werden.
In den folgenden Schritten wird beschrieben, wie der Implementierungsdeskriptor von nachrichtengesteuerten Beans des Typs EJB 2.1 so geändert wird, dass er einen JCA-Adapter verwendet:
- Öffnen Sie das
EJB-Projekt im Projektexplorer.
- Klicken
Sie im Projektexplorer doppelt auf die Datei
Implementierungsdeskriptor des EJB-Projekts. Der
Editor für EJB-Implementierungsdeskriptoren wird geöffnet.
- Klicken
Sie auf die Registerkarte
Bean, um die Seite
Bean zu öffnen.
- Führen
Sie für jede nachrichtengesteuerte Bean des Typs EJB 2.1 Folgendes
aus:
- Wählen
Sie auf der linken Seite der Seite
Bean die nachrichtengesteuerte Bean des Typs EJB 2.1
aus.
- Wählen
Sie unter der Überschrift
WebSphere-Bindings den Knopf
JCA-Adapter aus.
- Geben
Sie die Eigenschaften für die Bindingimplementierung an:
- ActivationSpec-JNDI-Name.
Geben Sie den JNDI-Namen
der J2C-Aktivierungsspezifikation ein, der zur Implementierung dieser
nachrichtengesteuerten Bean verwendet werden soll. Dieser Name muss dem
Namen einer J2C-Aktivierungsspezifikation entsprechen, die Sie für
WebSphere
Application Server definieren.
- ActivationSpec-Berechtigungsaliasname.
Der Name eines
J2C-Authentifizierungsaliasnamens, der für die Authentifizierung von
Verbindungen zum JCA-Ressourcenadapter verwendet wird. Ein
J2C-Authentifizierungsaliasname gibt die Benutzer-ID und das Kennwort
an, die bzw. das zur Authentifizierung der Erstellung einer neuen
Verbindung zum JCA-Ressourcenadapter verwendet wird.
- JNDI-Zielname.
Geben Sie den JNDI-Namen
ein, der von der nachrichtengesteuerten Bean für die Suche nach dem
JMS-Ziel im JNDI-Namensbereich verwendet wird.
- Speichern
Sie die Änderungen, und schließen Sie den Editor für
Implementierungsdeskriptoren.
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 und EJB-Projekten, die J2EE-Web-Services enthalten,
vorhanden. 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, EJB-Projekten 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.
- Für EJB-Projekte
werden alle
<service-ref>-Elemente
innerhalb
<component-scoped-refs>
in
webserviceclient.xml
unter die entsprechende
<enterprise-bean>
in
ejb-jar.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 4. Migration
der J2EE-Projekte.
Migration
von Enterprise JavaBeans-Projekten (EJB 1.1 auf EJB 2.1)
In diesem Abschnitt wird die Migration eines EJB-Projekts von Spezifikationsstufe EJB 1.1 auf EJB 2.1 beschrieben.
Die Migration eines
EJB-Projekts von EJB 1.1 auf EJB 2.1 umfasst die Migration von
CMP-Entity-Beans (CMP, Container-Managed Persistence).
Bei den Entity-Beans wurde
von Spezifikationsstufe J2EE 1.3 auf J2EE 1.4 keine Änderung
vorgenommen. Die Migration von CMP-Entity-Beans von der
Spezifikationsstufe EJB 1.1 auf EJB 2.1 wird auf dieselbe Weise
durchgeführt wie die Migration einer CMP-Entity-Bean von EJB 1.1 auf
EJB 2.0. Zur Migration von CMP-Entity-Beans von Spezifikationsstufe EJB
1.1 auf EJB 2.x sind die folgenden Schritte erforderlich:
- Konvertieren Sie das EJB-Projekt von EJB 1.1 in EJB 2.x.
- Migrieren Sie den EJB-Code von EJB 1.1 auf EJB 2.x.
- Migrieren Sie vorhandene, benutzerdefinierte EJB 1.1-Verweise auf lokale Verweise in EJB 2.x.
Projekte
von EJB 1.1 in EJB 2.x konvertieren
Ein EJB 1.1-Projekt kann mit dem J2EE-Migrationsassistenten in ein EJB 2.x-Projekt konvertiert werden.
- Klicken Sie in der Sicht
"J2EE-Hierarchie" mit der rechten Maustaste auf das 1.1-Projekt, und
wählen Sie dann
Migrieren -> J2EE-Migrationsassistent aus.
Wenn Sie das
ursprüngliche EJB 1.1-Projekt beibehalten wollen, können Sie ein
neues 2.x-Projekt erstellen und anschließend die JAR-Datei des
vorhandenen Projekts in das neue Projekt importieren
(Datei -> Importieren -> EJB-JAR).
Obwohl es sich bei dem
Projekt um ein EJB 2.x-Projekt handelt, bleiben die vorhandenen (oder
importierten) EJB 1.1-CMP-Beans (CMP, Container-Managed Persistence)
weiter EJB 1.1-Beans. Das heißt, die CMP-Beans werden nicht in EJB
2.x konvertiert.
Der
J2EE-Migrationsassistent migriert die Enterprise-Beans in einem EJB
2.x-Projekt aus 1.1 auf 2.x. (Wenn Sie sich dafür entscheiden, Ihre
1.1-CMP-Beans auf 2.x zu migrieren, müssen alle Beans im 2.x-Projekt
migriert werden. Sie können allerdings selektiv auswählen, diesen
migrierten 2.x-Beans lokale Clientsichten hinzuzufügen.)
- Der Assistent behält
die vorhandene EJB 1.1-Vererbung im EJB 2.x-Projekt bei.
- Der Assistent migriert
(proprietäre) EJB 1.1-Beziehungen auf (standardmäßige) EJB
2.x-Beziehungen und bietet weitere Vorteile.
Anmerkung:
Wenn
Sie über zugeordnete Zuordnungen verfügen, werden EJB
2.x-Zuordnungen für die Zuordnungen selbst erstellt, aber die
Aufgabenbereichszuordnungen für diese Zuordnungen werden ungültig.
Wenn Sie die Gültigkeitsprüfung ausführen, werden Sie einen
Fehler feststellen. Um dies zu umgehen, öffnen Sie zuerst den
Zuordnungseditor, und speichern Sie die Zuordnung. Die
Aufgabenbereichszuordnung wird entfernt. Anschließend können Sie
die Gültigkeitsprüfung wieder ausführen und die
Aufgabenbereiche erneut zuordnen.
Code
von EJB 1.1 auf EJB 2.x migrieren
Für Projekte, die von EJB 1.1 in EJB 2.x konvertiert wurden, müssen zur Migration von vorhandenem EJB 1.1-Code auf EJB 2.x bestimmte Schritte ausgeführt werden.
Anmerkung:
EJB
2.x-Beans werden nur in einem EJB 2.x-Projekt unterstützt (obwohl ein
2.x-Projekt auch 1.1-Beans unterstützt).
- Ersetzen Sie bei jeder
1.1-CMP-Bean alle CMP-Felder durch die abstrakten Methoden
getXXX und
setXXX. (Dann muss die Beanklasse abstrakt
sein.)
- Erstellen Sie für jede
CMP eine abstrakte Methode getXXX und
setXXX für den Primärschlüssel.
- Erstellen Sie für jede
CMP 1.1-Finder-Methode eine
EJBQL-Methode (EJBQL, EJB Query Language) für
jede Finder-Methode.
Anmerkung:
Für die EJB Query Language gelten in
Rational Application Developer V6.0 die
folgenden Einschränkungen:
- EJB Query
Language-Abfragen, bei denen EJBs mit Schlüsseln verwendet werden,
die aus Beziehungen zu anderen EJBs bestehen, werden als ungültig
angezeigt und verursachen Fehler bei der Implementierung.
- Die
IBM EJB Query
Language-Unterstützung erweitert die EJB 2.x-Spezifikation auf
verschiedene Arten, beispielsweise durch das Aufheben einiger
Einschränkungen und das Hinzufügen von Unterstützung für
weitere DB2-Funktionen
usw. Wenn die Portierbarkeit zu Datenbanken anderer Hersteller oder das
EJB-Implementierungstool Probleme verursachen, muss sorgfältig darauf
geachtet werden, dass alle Abfragen in EJB Query Language streng nach
den in Kapitel 11 der EJB 2.x-Spezifikation aufgeführten Anweisungen
geschrieben werden.
- Geben Sie für jeden
1.1-CMP-Finder java.util.Collection statt
java.util.Enumeration zurück.
- Ändern Sie für jede
1.1-CMP-Bean alle Vorkommen von
this.field = value in
setField(value) in
ejbCreate() und an den anderen Stellen im
gesamten Code.
- Aktualisieren Sie die
Behandlung von Ausnahmebedingungen (ROLLBACK-Verhalten) bei
Ausnahmebedingungen, die nicht für Anwendungen ausgegeben werden:
- Lösen Sie
javax.ejb.EJBException anstelle von
java.rmi.RemoteException aus, um
Ausnahmebedingungen zu melden, die nicht für Anwendungen ausgegeben
werden.
- In EJB 2.x und 1.1
führen alle Ausnahmebedingungen, die durch das Exemplar nicht für
Anwendungen ausgegeben werden, zu einer ROLLBACK-Operation der
Transaktion, in der das Exemplar ausgeführt wurde, und zum Löschen
des Exemplars.
- Aktualisieren Sie die
Behandlung von Ausnahmebedingungen (ROLLBACK-Verhalten) bei
Ausnahmebedingungen für Anwendungen:
- In EJB 2.x und 1.1
führt eine Ausnahmebedingung für Anwendungen nicht dazu, dass der
Container automatisch eine ROLLBACK-Operation für die Transaktion
ausführt.
- In EJB 1.1 führt der
Container die ROLLBACK-Operation nur dann aus, wenn das Exemplar unter
Verwendung der Methode setRollbackOnly() für sein Objekt
"EJBContext" aufgerufen wurde.
- Aktualisieren Sie
sämtliche CMP-Einstellungen von anwendungsspezifischen
Standardwerten, sodass sie sich in
ejbCreate befinden (verwenden Sie dabei keine
globalen Variablen, da EJB 1.1-Container alle Felder auf generische
Standardwerte setzten, bevor sie
ejbCreate aufrufen; dadurch werden alle
vorherigen anwendungsspezifischen Standardeinstellungen
überschrieben).
Migration
von EJB-Verweisen für EJB 1.1-Beziehungen
Beim Erstellen von EJB 1.1-Beziehungen werden EJB-Verweise in der Sicht "Ferner Client" erstellt. Während der EJB 1.1-Projektmigration mit dem J2EE-Migrationsassistenten werden diese fernen EJB-Verweise für die EJB 1.1-Beziehungen entfernt und durch lokale EJB-Verweise ersetzt. Lokale Verweise für benutzerdefinierte EJB-Verweise müssen manuell erneut erstellt werden.
Anmerkung:
In
EJB 2.x können EJB-Beziehungen nur erstellt werden, wenn für die
Beans die Sicht "Lokaler Client" definiert ist und die lokalen
EJB-Verweise für die EJB 2.x-Beziehungen erstellt
werden.
Für
benutzerdefinierte EJB-Verweise wird
keine Migration mit dem J2EE-Migrationsassistenten
durchgeführt. Führen Sie die folgenden Schritte aus, um die
lokalen Verweise zu erstellen:
- Löschen Sie die
vorhandenen, fernen EJB-Verweise auf der Seite "Verweise" im Editor
für den Implementierungsdeskriptor.
- Fügen Sie einen
lokalen EJB-Verweis auf der Seite "Verweise" im Editor für den
Implementierungsdeskriptor hinzu.
Zusammenfügung
der Methodenelemente während der Projektstrukturmigration
Während der Projektstrukturmigration mit dem J2EE-Migrationsassistenten werden Methodenelemente (hierzu gehören Sicherheitsidentität, Containertransaktion, Methodenberechtigung, Zugriffsart und Isolationsstufen) desselben Typs für alle Beans zusammengefügt, um sie logisch zu gruppieren.
Es folgt ein Beispiel
der Methodenelemente vor und nach der Projektstrukturmigration.
Das folgende Beispiel
zeigt die Methodenberechtigung auf der Quellenseite im Editor für den
Implementierungsdeskriptor vor der Projektstrukturmigration.
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getEJBMetaData</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getHomeHandle</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-namae>remove</method-name>
<method-params>
<method-param>java.lang.Object</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>javax.ejb.Handle</method-param>
</method-params>
</method>
</method-permission>
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Remote</method-intf>
<method-name>isIdentical</method-name>
<method-params>
<method-param>javax.ejb.EJBObject</method-param>
</method-params>
</method>
</method-permission>
Das folgende Beispiel
zeigt die Methodenberechtigung auf der Quellenseite im Editor für den
Implementierungsdeskriptor nach der Projektstrukturmigration.
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getEJBMetaData</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getHomeHandle</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>>java.lang.Object</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>javax.ejb.Handle</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Remote</method-intf>
<method-name>isIdentical</method-name>
<method-params>
<method-param>javax.ejb.EJBObject</method-param>
</method-params>
</method>
</method-permission>
Anmerkung:
Wenn
im J2EE-Migrationsassistenten außer der Projektstrukturmigration auch
die Migration von CMP 1.x-Beans auf CMP 2.x-Beans ausgewählt wurde,
werden Zugriffsart und Isolationsstufen entfernt, alles andere aber wird
während der Migration zusammengefügt. Die Zugriffsarten und
Isolationsstufen werden entfernt, weil sie auf Grund der Änderungen
am Erweiterungsmodell nicht länger gültig sind. Im neuen Modell
sind sowohl Zugriffsarten als auch Isolationsstufen in Zugriffsarten
definiert. Es gibt jetzt Zugriffsarten auf Beanebene und Zugriffsarten
auf Methodenebene. Dabei ist die Verwendung der Zugriffsarten auf
Beanebene gegenüber der Verwendung der Zugriffsarten auf
Methodenebene stets zu bevorzugen.
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 Application Developer V6.0
In Rational Application 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 Application 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 Application 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 5. Migration
auf die Portaltools in
Rational Application Developer V6.0
Projekte aus Portal Toolkit V5.0.2.2 werden automatisch auf Portaltools in Rational Application Developer V6.0 migriert, wenn der Portal Toolkit-Arbeitsbereich migriert wird oder das Projekt aus einem SCM-System für Quellcodeverwaltung (Source Code Management) geladen wird, oder wenn das Projekt mittels der Projektaustauschfunktion importiert wird. Wenn Sie eine Migration aus älteren Versionen von Portal Toolkit ausführen, müssen Sie Ihre Portletprojekte in WAR-Dateien exportieren und diese WAR-Dateien in die Portaltools in Rational Application Developer V6.0 importieren.
Bevor Sie
Portalanwendungen migrieren, müssen Sie die Portaltoolsfunktion von
Rational Application Developer V6.0
installieren. Weitere Informationen finden Sie im
Installationshandbuch.
Anmerkung:
Abwärtskompatibilität
wird für Portletprojekte nicht
unterstützt.
Die automatische Migration wird nur für Projekte unterstützt, die in Portal Toolkit V5.0.2.2 mit WebSphere Studio V5.1.2 erstellt wurden. Weitere
Informationen zur Migration finden Sie in
Kapitel 1. Migration
aus WebSphere Studio V5.1, 5.1.1 oder 5.1.2.
Wenn Ihr Portletprojekt
einem Unternehmensanwendungsprojekt zugeordnet ist, müssen Sie den
entsprechenden Zielserver für das EAR-Projekt setzen. Sie können
den Zielserver auf der Seite
Servereigenschaften
(Eigenschaften -> Server) setzen.
Während der Migration
von Projekten aus Portal Toolkit V5.0.2.2 werden einige zusätzliche
Änderungen vorgenommen:
- Der Zielserver wird auf
WebSphere
Portal V5.0 gesetzt, wenn für das Projekt kein Zielserver angegeben
wird.
- Der
Portleterstellungspfad wird korrigiert.
- Es wird eine
Portletprojektgattung hinzugefügt.
Wenn Sie eine Migration
aus älteren Versionen von Portal Toolkit ausführen, müssen Sie
Ihre Portletprojekte manuell auf Portaltools in
Rational Application Developer V6.0
migrieren. Gehen Sie dazu wie folgt vor:
- Exportieren Sie das
vorhandene Projekt in eine WAR-Datei: Exportieren Sie in der
früheren Version von Portal Toolkit jedes Projekt in eine WAR-Datei
mit Quellendateien.
- Klicken
Sie mit der rechten Maustaste auf das Projekt, und wählen Sie die
Option Exportieren aus.
- Wählen
Sie WAR-Datei und
Quellendateien exportieren aus, und klicken Sie auf
Fertig stellen.
- Importieren
Sie die Portlet-WAR-Datei:
- Erstellen
Sie in den Portaltools für
Rational Application Developer V6.0 ein
neues, leeres Portletprojekt.
- Wählen Sie
Datei -> Neu -> Projekt -> Portal -> Portletprojekt oder Portletprojekt (JSR 168)
aus.
- Nehmen Sie die Auswahl
von Portlet erstellen zurück.
- Klicken Sie auf
Erweiterte anzeigen.
- Wenn Sie ein Portlet
aus WebSphere Portal 4.2 importieren, wählen Sie
2.2 als Servletversion aus.
- Wählen Sie
WebSphere Portal v5.0 als Zielserver aus und klicken
Sie auf Fertig stellen.
- Importieren
Sie die WAR-Datei in dieses neue, leere Portletprojekt.
- Wählen Sie
Importieren aus.
- Wählen Sie
WAR-Datei aus, und geben Sie die WAR-Datei an, die Sie
oben exportiert haben (beim Exportieren des Projekts in eine WAR-Datei
in der früheren Version).
- Wählen Sie das
neue, leere Portletprojekt aus.
- Wählen Sie
Vorhandene Ressourcen ohne Warnung überschreiben
aus.
- Wählen Sie
nicht
Projekte beim Überschreiben löschen
aus.
- Löschen
Sie die TLD-Datei:
Es wird empfohlen, dass
Sie die Portlet-TLD-Datei aus dem Projekt löschen, falls vorhanden.
Andernfalls wird eine Warnung angezeigt, wenn Sie das Projekt erneut
erstellen. Wenn Sie die TLD-Datei nicht löschen, kann dies Probleme
verursachen, wenn Sie das Portletprojekt in
WebSphere
Portal implementieren und sich die TLD-Datei des Portlets von der Datei
auf dem Server unterscheidet.
- Wenn
Sie ein Portlet aus WebSphere Portal 4.2 migrieren, müssen Sie dieses
migrierte Portletprojekt auf
WebSphere
Portal 5.x migrieren.
Informationen zur Migration von WebSphere Portal V4.2-Portlets auf V5.x finden Sie in
Migration
von WebSphere Portal V4.2-Portlets auf V5.x.
Informationen zur
Migration von Faces-Ressourcen in einem Portletprojekt finden Sie in Faces-Laufzeitressourcen
in einem Portletprojekt aktualisieren.
Migration
von WebSphere Portal V4.2-Portlets auf V5.x
Rational Application Developer V6.0 unterstützt nicht die Entwicklung von Portlets unter WebSphere Portal V4.2. Portletprojekte aus WebSphere Portal V4.2 müssen auf V5.x migriert werden.
Die meisten für
WebSphere
Portal V4.2 geschriebenen Portlets können ohne Änderungen in
WebSphere
Portal V5.x ausgeführt werden. Einige der Portlet 4.2.x-APIs sind nun
als veraltet markiert, stehen jedoch weiterhin in
WebSphere
Portal V5.x zur
Verfügung.
Anmerkung:
Migrierte
Portletanwendungsprojekte sind nicht abwärts
kompatibel.
Gehen Sie wie folgt vor, um Portletanwendungen für WebSphere Portal V4.2 auf V5.x zu migrieren:
- Migrieren Sie die
Portal V4.2-Portletprojekte auf Portal V5.x-Portletprojekte:
- Klicken
Sie mit der rechten Maustaste auf das Portletanwendungsprojekt, das Sie
migrieren wollen.
- Wählen
Sie
Eigenschaften -> Portlet-API aus, um die Seite für Portlet-APIs
aufzurufen.
- Wählen
Sie in der Dropdown-Liste für die Portlet-API-Stufe
WebSphere Portal Version 5.x aus.
- Klicken
Sie auf OK. Es werden automatisch die folgenden Änderungen
vorgenommen:
- Die TLD-Datei (TLD,
Tag Library Descriptor) für die Portlet-API wird entfernt, falls
vorhanden.
- Die Webstufe wird von
2.2 in 2.3 geändert.
- Die
portletspezifischen Klassenpfadeinträge werden entfernt, da sie vom
WebSphere
Portal-JRE-Container und vom
WebSphere Portal-Laufzeitzielcontainer dynamisch
hinzugefügt werden.
- Wenn
Ihr Portletprojekt einem Unternehmensanwendungsprojekt zugeordnet ist,
wird empfohlen, dass Sie die J2EE-Stufe des EAR-Projekts auf J2EE 1.3
migrieren. Für
WebSphere Portal V5.x erstellte Portletanwendungen
sollten den Spezifikationen der J2EE-Stufe 1.3
entsprechen.
Anmerkung:
Bevor
Sie Ihr Unternehmensanwendungsprojekt auf J2EE 1.3 migrieren, lesen Sie
die Informationen in
Kapitel 4. Migration
der J2EE-Projekte. Informationen zur Verwendung des
J2EE-Migrationsassistenten finden Sie in der
Onlinehilfe.
- Wenn
das migrierte Portletprojekt nur dem Unternehmensanwendungsprojekt
zugeordnet ist, führen Sie folgende Schritte aus:
- Schließen Sie alle
Editoren in der Workbench.
- Klicken Sie mit der
rechten Maustaste auf das Unternehmensanwendungsprojekt, dem das
migrierte Portletprojekt zugeordnet ist.
- Wählen Sie
Migrieren -> J2EE-Migrationsassistent... aus, und klicken Sie
auf Weiter.
- Wählen Sie
J2EE
Version 1.3 und als Zielserver
WebSphere Portal aus.
- Klicken Sie auf
Fertig stellen.
- Wenn
dem Unternehmensanwendungsprojekt andere Portletprojekte zugeordnet
sind, müssen Sie das migrierte Portletprojekt entfernen und es zu
einem anderen Unternehmensanwendungsprojekt hinzufügen.
- Entfernen Sie das
Modul des migrierten Portletprojekts aus dem
Unternehmensanwendungsprojekt.
- Erweitern Sie das
Unternehmensanwendungsprojekt, und wählen Sie den
Implementierungsdeskriptor aus.
- Wählen Sie
Öffnen
mit -> Editor für Implementierungsdeskriptor
aus.
- Wählen Sie die
Registerkarte Module aus. Wählen Sie auf der Modulseite des
Editors die WAR-Datei des migrierten Portletprojekts aus.
- Klicken Sie auf
Entfernen.
- Wählen Sie
Datei -> Speichern aus, um die Änderungen zu
speichern.
- Erstellen Sie ein
neues Unternehmensanwendungsprojekt, und fügen Sie das Portletprojekt
hinzu.
- Wählen Sie
Datei -> Neu -> Projekt aus.
- Wählen Sie das
Markierungsfeld
Alle Assistenten anzeigen aus.
- Erweitern Sie
J2EE, und wählen Sie
Unternehmensanwendungsprojekt aus.
- Füllen Sie das
Feld für den
Namen des Projekts aus, wählen Sie
J2EE
Version 1.3 und als Zielserver
WebSphere Portal aus, und klicken Sie auf
Weiter.
- Wählen Sie auf
der Seite EAR-Modulprojekte das migrierte Portletprojekt aus,
und klicken Sie auf
Fertig
stellen.
Das Portletprojekt ist nun auf WebSphere Portal V5.x migriert.
Faces-Laufzeitressourcen
in einem Portletprojekt aktualisieren
Die JavaServer Faces-Laufzeitressourcen, die ursprünglich mit WebSphere Studio Application Developer V5.1.2 bereitgestellt wurden, wurden für Rational Application Developer V6.0.1 aktualisiert. Wenn Sie die Entwicklung der mit Portal Toolkit 5.0.2.2 für diese frühere Produktversion erstellten Portletprojekte fortsetzen wollen, wird empfohlen, dass Sie die Ressourcen für die Faces-Laufzeit auf die jeweils neueste Stufe aktualisieren.
In
Rational
Application Developer V6.0.1 werden die Faces-Laufzeitressourcen
automatisch aktualisiert, wenn ein Portletprojekt importiert oder wenn
Arbeitsbereich geöffnet wird, das bzw. der Ressourcen enthält, die
nicht auf dem neuesten Stand sind. Nachdem Sie ein mit Portal Toolkit
5.0.2.2 für
WebSphere Studio Application Developer
V5.1.x erstelltes Portletprojekt in
Rational
Application Developer V6.0.1 importiert 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 Portletprojekt automatisch zu aktualisieren:
- Imporieren Sie ein
Portletprojekt mit Faces-Inhalt aus
WebSphere Studio Application 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 Portletprojekt, und wählen Sie
Build -> Projekt aus; der Prozess zum erneuten Erstellen
eines Projekts öffnet das Fenster
Projektmigration.
- Wenn in Ihrem
Arbeitsbereich noch andere Portletprojekte 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 Portletprojekte 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
Portletprojekt schließen und erneut starten oder die Workbench neu
starten, bevor Sie Ihr Portletprojekt erneut erstellen. Wenn Sie die
automatische Erstellung inaktiviert haben, klicken Sie mit der rechten
Maustaste auf Ihr Portletprojekt, 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.
- Um die
portletspezifischen Faces-Laufzeitressourcen jsf-portlet.jar und
jsf-wp.jar zu aktualisieren, müssen Sie die unten aufgeführten
manuellen Aktualisierungsschritte
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 Portletprojekt manuell zu aktualisieren:
- Importieren Sie Ihr
vorhandenes Portletprojekt mit Faces-Inhalt in einen
Rational
Application Developer V6.0.1-Arbeitsbereich.
- Erstellen
Sie ein neues Portletprojekt mit dem Namen
JSFP601, und wählen Sie dabei auf der zweiten
Seite die Option
Faces-Portlet aus. 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
JSFP601, und wählen Sie im Menü die Option
Eigenschaften aus.
- Klicken
Sie auf Funktionen des Webprojekts, und wählen Sie
Faces Client Framework für Portletprojekt
hinzufügen aus. Klicken Sie anschließend auf
OK.
- 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:
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- jsf-portlet.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>
<variable-resolver>com.ibm.faces.application.WPPortletVariableResolver</variable-resolver>
<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
</application>
Anmerkung:
Wenn
Ihr Portletprojekt die JSR 168-API verwendet, geben Sie
com.ibm.faces.application.PortletVariableResolver
statt com.ibm.faces.application.WPPortletVariableResolver
an.
- Kopieren
Sie aus dem Verzeichnis
WebContent/WEB-INF/lib
des Projekts JSFP601 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 Ihr
Portletprojekt die IBM Portlet-API oder die Personen-Link-Komponente
verwendet, kopieren Sie die Datei jsf-wp.jar in Ihr ursprüngliches
Projekt.
- Wenn Sie die Datei
odc-jsf.jar kopieren, kopieren Sie auch die
Datei odc-jsf-portlet.jar.
- Ö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>
- Löschen
Sie das Portletprojekt JSFP601.
Kapitel 6. Änderungen
in WebSphere-Testumgebungen
Die mit Rational Application Developer V6.0 gelieferten Testumgebungen von WebSphere Application Server enthalten gegenüber den mit früheren Editionen von WebSphere Studio Application Developer bereitgestellten Testumgebungen einige Änderungen.
Es folgt eine
Zusammenfassung der Änderungen an den
WebSphere
Application Server-Testumgebungen
Rational Application 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.
- Zum Testen von Portal-
und Portletanwendungen wurde die
WebSphere
Portal-Testumgebung hinzugefügt.
Die folgende Tabelle zeigt
die Stufen der WebSphere Application Server-Testumgebungen, die im
Produktumfang der verschiedenen Versionen von
WebSphere Studio Application Developer und
Rational Application Developer enthalten
sind.
Tabelle 2. WebSphere Application Server-Testumgebungen in WebSphere Studio Application Developer und Rational Application Developer
|
WebSphere Application Server V4.x AEs |
WebSphere Application Server V5.x Base |
WebSphere Application Server Express 5.x |
WebSphere Application Server V5.x Portal |
WebSphere Application Server V6.0 |
WebSphere Studio Application Developer
V5.1 |
V4.0.6 |
V5.0.2 |
V5.0.2 |
nicht verfügbar |
nicht verfügbar |
WebSphere Studio Application Developer
V5.1.1 |
V4.0.7 + PQ78374 |
V5.0.2 + PQ78374 +PQ78419, V5.1 |
V5.0.2 & V5.1 |
nicht verfügbar |
nicht verfügbar |
WebSphere Studio Application Developer
V5.1.2 |
V4.0.7 + PQ78374 |
V5.0.2 + PQ78374 +PQ78419, V5.1.0.3 |
V5.0.2 & V5.1.0.3 |
V5.0.2.3 Base +
WebSphere
Portal V5.0.2.1 |
nicht verfügbar |
Rational Application Developer V6.0 |
nicht verfügbar |
V5.0.x, V5.1.1 |
V5.0.2 & V5.1.1 |
V5.0.2.6 Base +
WebSphere
Portal V5.0.2.2, V5.1.1 Base +
WebSphere
Portal 5.1 |
V6.0 |
Copyright und Bemerkungen