IBM Rational Web Developer für Windows und Linux, Version 6.0 Migrationshandbuch


Inhaltsverzeichnis

Kapitel 1. Migration aus WebSphere Studio V5.1, 5.1.1 oder 5.1.2
Kompatibilität mit WebSphere Studio V5.1.x
Kompatibilität mit WebSphere Studio V5.1.x inaktivieren
Faces-Laufzeitressourcen in einem Webprojekt aktualisieren
Ressourcen der Faces Client-Laufzeit in einem Webprojekt aktualisieren
Struts-Webprojekte migrieren
Änderungen am Debugger in V6.0
Migration von WDO auf SDO
Reservierte EGL-Wörter in V6.0
Kapitel 2. Faces-Laufzeitressourcen für Webprojekte aus Rational Web Developer V6.0 aktualisieren
Kapitel 3. Migration der J2EE-Projekte
Migration sicherer Web-Services
Migration der J2EE-Spezifikationsstufe 1.3 auf 1.4
Webprojekte (Servletstufe 2.3 auf Servletstufe 2.4)
Connectorprojekte (JCA 1.0 auf JCA 1.5)
Web-Services (J2EE 1.3 auf J2EE 1.4)
Migration von J2EE-Spezifikationsstufe 1.2 auf 1.4
Webprojekte (Servletstufe 2.2 auf Servletstufe 2.4)
Änderungen am J2EE-Migrationsassistenten in Rational Web Developer V6.0
Kapitel 4. Änderungen in WebSphere-Testumgebungen

Kapitel 1. Migration aus WebSphere Studio V5.1, 5.1.1 oder 5.1.2

Diese Dokumentation stellt Anweisungen zur Migration aus WebSphere Studio Site Developer V5.1.x auf Rational Web Developer V6.0 bereit.

Weitere Informationen finden Sie zu den folgenden Themen:

Informationen zur Verwendung von Rational Web Developer finden Sie in der Onlinehilfe.

Aktuelle Dokumentation finden Sie unter folgender Adresse: www.ibm.com/developerworks/rational.

Informationen zur Migration von früheren Versionen von WebSphere Studio auf v5.x oder zur Migration von VisualAge für Java auf WebSphere Studio finden Sie unter www.ibm.com/software/awdtools/studioappdev/support/, wenn Sie nach dem Stichwort "migration guide" (Migrationshandbuch) suchen.

Gehen Sie wie folgt vor, um aus WebSphere Studio V5.1.x eine Migration auszuführen:

  1. 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.
  2. Sichern Sie Ihren WebSphere Studio V5.1.x-Arbeitsbereich.
  3. Installieren Sie Rational Web Developer. Ziehen Sie dabei die Informationen im Installationshandbuch (Datei install.html) hinzu. Diese Datei steht im Root der ersten Produkt-CD zur Verfügung.
  4. Empfehlung: Wenn Sie Rational Web Developer zum ersten Mal starten, werden Sie standardmäßig aufgefordert, zu bestätigen, dass Sie einen Arbeitsbereich mit dem Namen rationalsdp6.0\workspace verwenden wollen. Das heißt, das Dialogfenster des Startprogramms für den Arbeitsbereich zeigt auf ein Verzeichnis, das nicht mit Ihrem WebSphere Studio-Arbeitsbereich identisch ist. Wenn Sie die neue Umgebung durchsuchen wollen, bevor Sie Ihren alten Arbeitsbereich migrieren, übernehmen Sie die Standardeinstellung, oder geben Sie beim Start von Rational Web Developer einen anderen neuen Verzeichnisnamen an. Sie erhalten dadurch beispielsweise die Möglichkeit, ein oder zwei Testprojekte zu erstellen, Informationen zu den neuen Funktionen zu lesen (Hilfe -> Willkommen), einige der neuen Lernprogramme auszuführen (Hilfe -> Lernprogrammsammlung) oder einige der neuen Beispiele auszuprobieren (Hilfe -> Beispielsammlung).
  5. 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:
    1. Migration eines Arbeitsbereichs: Wenn Sie bereit sind, Ihren V5.1.x-Arbeitsbereich endgültig zu migrieren, starten Sie Rational Web Developer mit Hilfe Ihres alten Arbeitsbereichs. Ein Statusanzeiger bestätigt, dass Ihre Projekte automatisch migriert werden.

      Hinweis: Während der Migration des Arbeitsbereichs wird das Dialogfenster Probleme mit folgender Nachricht angezeigt: Das Workbenchlayout konnte nicht wiederhergestellt werden. Ursache: Bei der Wiederherstellung der Arbeitsumgebung sind Probleme aufgetreten. Die Fehlernachrichten haben keine Auswirkungen auf die erfolgreiche Migration des Arbeitsbereichs. Notieren Sie sich den Namen der Perspektive, die nicht wiederhergestellt werden konnte, indem Sie im Fehlerdialog auf den Knopf für Details klicken. Klicken Sie anschließend auf OK, um den Dialog zu schließen.

      Zum Wiederherstellen der Perspektive gehen Sie wie folgt vor:

      1. Schließen Sie die Perspektive, indem Sie Fenster -> Perspektive schließen auswählen.
      2. Öffnen Sie die Perspektive erneut, indem Sie Fenster -> Perspektive öffnen auswählen.
      Anmerkung:
      Für EGL-Projekte (EGL, Enterprise Generation Language), die in WebSphere Studio V5.1.2 die EGL-Webperspektive verwendeten: Diese Perspektive wurde in Rational Web Developer V6.0 entfernt. Alle EGL-Projekte werden problemlos ohne diese Perspektive auf Rational Web Developer V6.0 migriert. Wenn Sie früher die EGL-Webperspektive verwendeten, führen Sie die folgenden Schritte aus:
      1. Schließen Sie die EGL-Webperspektive.
      2. Aktivieren Sie die EGL-Funktionalität in den Benutzervorgaben (Fenster -> Benutzervorgaben). Weitere Informationen zur Aktivierung der EGL-Funktionalität finden Sie in der Onlinehilfe.
      3. Wählen Sie Fenster -> Perspektive öffnen aus, und wählen Sie die Webperspektive aus.
    2. Migration von Projekten, die aus einem SCM-System für Quellcodemanagement (Source Code Management) geladen werden: Projekte aus WebSphere Studio 5.1.x, die in einem SCM-System vorhanden sind, werden automatisch auf V6.0 migriert, wenn Sie in Rational Web Developer geladen werden.
    3. Migration von Projekten, die mittels Projektaustausch importiert werden: Projekte, die aus WebSphere Studio V5.1.2 oder V5.1.1 exportiert und mittels der Projektaustauschfunktion in Rational Web Developer V6.0 importiert werden, werden automatisch auf V6.0 migriert. Die Projektaustauschfunktion war in WebSphere Studio V5.1.2 verfügbar und lag für V5.1.1 als optionales Plug-in vor.

    Hinweise:

    Wichtig:

  6. Der DB2-Net-JDBC-Treiber wird in Rational Web Developer V6.0 nicht unterstützt. Wenn Sie mit dem DB2-Net-JDBC-Treiber JDBC-Verbindungen erstellt haben, können Sie die Verbindungen in Rational Web Developer V6.0 nicht wiederherstellen. Sie müssen die Verbindungen so ändern, dass sie einen der unterstützten JDBC-Treiber verwenden. Weitere Informationen zu den in V6.0 unterstützten JDBC-Treibern finden Sie in der Onlinehilfe.
  7. Wenn Sie Inhalte von Web- oder XML-Dateien aus WebSphere Studio Site Developer V5.1.x migriert haben, die den Shift_JIS-Zeichensatz verwendeten und vom Hersteller ausgewählte Zeichen enthielten, müssen Sie stattdessen den Windows-31J-Zeichensatz angeben.
  8. Wenn Sie in WebSphere Studio Site Developer V5.1.x Plug-ins anderer Hersteller installiert haben, müssen Sie sich die entsprechenden Plug-ins für V6.0 besorgen und diese erneut installieren.
  9. Wenn Sie Funktionen verwenden, die Agent Controller benötigen, führen Sie einen Upgrade für Agent Controller aus, indem Sie die mit Rational Web Developer bereitgestellte Version installieren. Weitere Informationen finden Sie im Installationshandbuch.
  10. Informationen zur Migration von VisualAge Generator finden Sie im Migrationshandbuch VisualAge Generator to Enterprise Generation Language (EGL) Migration Guide; dieses Handbuch befindet sich im PDF-Format in der Onlinehilfe im Abschnitt "Installieren und Migrieren" unter dem Hilfethema "Auf das Handbuch für die Migration von VisualAge Generator zu EGL zugreifen". Die aktuellste Kopie des Handbuchs finden Sie unter http://www.ibm.com/developerworks/rational/library/egldoc.html.

Kompatibilität mit WebSphere Studio V5.1.x

Wenn Sie einen Arbeitsbereich von WebSphere Studio V5.1.x zum ersten Mal in Rational Web Developer öffnen, wird er automatisch migriert. Nach der Migration eines Arbeitsbereichs können Sie ihn nicht mehr in WebSphere Studio Site Developer öffnen. Die im Arbeitsbereich von Version 6.0 vorhandenen Projekte können jedoch weiter mit WebSphere Studio V5.1.x gemeinsam verwendet werden, entweder durch Verwendung eines SCM-Systems (SCM, Source Code Management) zur Quellcodeverwaltung (beispielsweise Rational ClearCase), durch Importieren und Exportieren eines Projekts mittels Projektaustausch, oder durch Importieren von Archiven und Exportieren von Projekten. Wichtig: Für Portletanwendungen aus Portal Toolkit V5.0.2.2, die auf Portal Tools in Rational Web Developer V6.0 migriert werden, wird keine Abwärtskompatibilität unterstützt.

Anmerkung:
Folgendes gilt nicht für Portletanwendungsprojekte.

Vorhandene Projekte von Version 5.1.x, die aus einem SCM-System oder einem anderen Entwickler mittels Projektaustausch in V6.0 importiert werden, können mit V5.1.x gemeinsam verwendet werden, sofern Sie keine der folgenden Aktionen ausführen:

Eine .compatibility-Datei wird automatisch im Projektverzeichnis erstellt, wenn ein V5.1.x-Projekt im Rational Web Developer V6.0-Arbeitsbereich geöffnet wird. Die .compatibility-Datei wird von Rational Web Developer beim Migrieren von Projektressourcen zum Überwachen der Zeitmarken der Ressourcen verwendet. Sie sollten sie weder editieren noch löschen.

Weitere Informationen zum Entfernen der Abwärtskompatibilität mit WebSphere Studio Site Developer V5.1.x finden Sie in Kompatibilität mit WebSphere Studio V5.1.x inaktivieren.

Eclipse-bezogene Aspekte

Diese Version von Rational Web Developer basiert auf Eclipse V3.0. Wenn Sie Ihre eigenen Plug-ins entwickeln, sollten Sie die Informationen zu den Änderungen an der Plattform lesen, bevor Sie die Migration ausführen.

Weitere Informationen finden Sie in der Readme-Datei im Unterverzeichnis eclipse\readme der Installationsposition von Rational Web Developer V6.0. Die folgenden Abschnitte der Readme-Datei sind für die Migration relevant:

J2EE-Projektkompatibilität

Die Kompatibilität mit Rational Web Developer V6.0 von Projekten, die in WebSphere Studio V5.1.x erstellt wurden, wird über Metadaten aktiviert, die beim Migrieren Ihres V5.1.x-Arbeitsbereichs automatisch zu .project-Dateien hinzugefügt werden. Gleichermaßen werden beim Erstellen eines neuen J2EE 1.2- oder 1.3-Moduls oder einer -Anwendung in Rational Web Developer V6.0 automatisch erstellte Metadaten für die Abwärtskompatibilität mit V5.1.x zur .project-Datei hinzugefügt.

Anmerkung:
Wenn ein in V6.0 erstelltes, neues J2EE 1.2- und J2EE 1.3-Modul oder eine neue -Anwendung in WebSphere Studio Site Developer V5.1.x verwendet wird, wo V6.0-Erstellungsprogramme nicht zur Verfügung stehen, werden auf Grund dieser Metadaten für Kompatibilität Nachrichten hinsichtlich "fehlender Erstellungsprogramme" angezeigt oder protokolliert. Diese Nachrichten sind normal, Sie können sie ignorieren.

So lange diese Metadaten für Kompatibilität vorhanden sind, werden beim Laden von Rational Web Developer V6.0-Projekten in WebSphere Studio V5.1.x Nachrichten hinsichtlich "fehlender Erstellungsprogramme" angezeigt. Es folgt ein Beispiel für eine solche Nachricht:

!ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
!MESSAGE Das Erstellungsprogramm com.ibm.wtp.j2ee.LibCopyBuilder für Projekt Test60EARWeb wird übersprungen. 
Entweder wurde das Erstellungsprogramm nicht
installiert oder es gehört zu einer
Projektgattung, die nicht vorhanden oder
inaktiviert ist.

Diese Nachrichten sind normal, Sie können sie ignorieren. Wenn Sie sicher sind, dass Sie mit einem bestimmten Projekt nicht mehr in WebSphere Studio V5.1.x arbeiten werden, können Sie die Ausgabe dieser Nachrichten verhindern, indem Sie die Abwärtskompatibilität für dieses Projekt inaktivieren.

Wichtig: In V6.0 erstellte, neue Projekte der Spezifikation J2EE 1.2 oder 1.3 sind mit WebSphere Studio V5.1.x kompatibel, Sie müssen jedoch nach dem Laden des Projekts in WebSphere Studio einige manuelle Schritte ausführen, bevor Sie mit dem Projekt arbeiten können. Diese Schritte sind erforderlich, da Laufzeitziele für neue, in V6.0 erstellte Projekte der Spezifikation J2EE 1.2 oder 1.3 nicht direkt mit Zielservern in V5.1.x abwärts kompatibel sind. Nach dem Laden eines neuen V6.0-Projekts in V5.1.x müssen die folgenden manuellen Schritte ausgeführt werden:

  1. Öffnen Sie die .classpath-Datei für jedes J2EE-Projekt, das über eine .classpath-Datei verfügt.
  2. Löschen Sie die folgenden Klassenpfadeinträge aus der .classpath-Datei, und speichern und schließen Sie die Datei.
  3. 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.
  4. Klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie Eigenschaften -> J2EE aus.
  5. 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.
  6. Der von Ihnen ausgewählte Zielserver wird mit Rational Web Developer V6.0 und mit WebSphere Studio Site Developer V5.1.x kompatibel sein. Nach dem Festschreiben der Änderungen im SCM-System sind die J2EE-Projekte funktionell auf V5.1.x und V6.0 unter Verwendung eines SCM-Systems abgestimmt.
    Anmerkung:
    Wenn der Zielserver erneut in Rational Web Developer V6.0 festgelegt wird, geht die J2EE-Projektkompatibilität verloren und muss erneut eingerichtet werden.

Kompatibilität mit WebSphere Studio V5.1.x inaktivieren

Die Kompatibilität mit WebSphere Studio Site Developer V5.1.x kann vollständig aus einem in Rational Web Developer V6.0 erstellten Unternehmensanwendungsprojekt oder einem aus einer früheren Version von WebSphere Studio migrierten Unternehmensanwendungsprojekt entfernt werden. Sie sollten die Kompatibilität mit WebSphere Studio V5.1.x nur dann entfernen, wenn Sie sicher sind, dass das Unternehmensanwendungsprojekt entweder nicht länger funktionell auf V5.1.x abgestimmt oder nicht länger mit V5.1.x kompatibel sein soll.

Gehen sie wie folgt vor, um die Kompatibilität mit WebSphere Studio Site Developer V5.1.x zu entfernen:

  1. Klicken Sie mit der rechten Maustaste auf ein Unternehmensanwendungsprojekt, und wählen Sie aus dem Popup-Menü die Option Kompatibilität entfernen aus.
  2. 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.
  3. Klicken Sie auf Ja, um mit der Operation zum Entfernen der Kompatibilität fortzufahren.

Nach dem Ausführen der Operation zum Entfernen der Kompatibilität sind das Unternehmensanwendungsprojekt und alle unter dem Unternehmensanwendungsprojekt verschachtelten Module und Dienstprogrammprojekte nicht mehr mit WebSphere Studio Site Developer V5.1.x abwärts kompatibel.

Faces-Laufzeitressourcen in einem Webprojekt aktualisieren

Die JavaServer Faces-Laufzeitressourcen, die ursprünglich mit WebSphere Studio Site Developer V5.1.x bereitgestellt wurden, wurden für Rational Web Developer V6.0.1 aktualisiert. Wenn Sie die Entwicklung der mit dieser früheren Produktversion erstellten Projekte fortsetzen wollen, wird empfohlen, dass Sie die Ressourcen für die Faces-Laufzeit auf die jeweils neueste Stufe aktualisieren.

In Rational Web Developer V6.0.1 werden die Faces-Laufzeitressourcen automatisch aktualisiert, wenn ein Webprojekt importiert oder ein Arbeitsbereich geöffnet wird, das bzw. der Ressourcen enthält, die nicht auf dem neuesten Stand sind. Nachdem Sie ein Webprojekt oder einen Arbeitsbereich aus WebSphere Studio Site Developer V5.1.x in Rational Web Developer V6.0.1 importiert bzw. geöffnet haben, werden Sie aufgefordert, die Faces-Laufzeitressourcen auf den neuesten Stand zu bringen.

Laufzeitressourcen automatisch aktualisieren

Führen Sie folgende Schritte aus, um die Faces-Laufzeitressourcen für ein Webprojekt automatisch zu aktualisieren:

  1. Importieren Sie ein Webprojekt (oder einen Arbeitsbereich) mit Faces-Inhalt aus WebSphere Studio Site Developer V5.1.x. Das Fenster Projektmigration wird geöffnet.
    Anmerkung:
    Wenn das Fenster Projektmigration nicht geöffnet wird, ist möglicherweise Ihre Einstellung für automatische Erstellung inaktiviert. Klicken Sie im Projektexplorer mit der rechten Maustaste auf Ihr Webprojekt, und wählen Sie Build -> Projekt aus; der Prozess zum erneuten Erstellen eines Projekts öffnet das Fenster Projektmigration.
  2. 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.
  3. Klicken Sie auf eine der folgenden Optionen:
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:

  1. Importieren Sie Ihr vorhandenes Webprojekt mit Faces-Inhalt in einen Rational Web Developer V6.0.1-Arbeitsbereich.
  2. 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.
  3. Klicken Sie im Projektexplorer mit der rechten Maustaste auf das Projekt JSF601, und wählen Sie im Menü die Option Eigenschaften aus.
  4. 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.
  5. Wenn Sie mit EGL arbeiten, erstellen Sie eine JSF-Seitendatei wie folgt:
    1. Klicken Sie mit der rechten Maustaste auf den Ordner 'WebContent' Ihres neuen EGL-Webprojekts.
    2. Wählen Sie Neu -> Andere -> Faces-JSP-Datei aus.
    Die Dateien eglintdebug.jar und eglintdebugsupport.jar werden zu Ihrem Projekt hinzugefügt.
  6. Führen Sie für jedes vorhandene Faces-Projekt, das Sie aktualisieren wollen, die folgenden Schritte aus:
    1. 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
    2. 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>
    3. 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.
    4. Ö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>
    5. Wenn in Ihrem ursprünglichen Projekt WebSphere-Datenobjekte (WDOs) für Datenzugriff verwendet wurden, führen Sie die folgenden zusätzlichen Schritte aus:
      1. Klicken Sie in Ihrem ursprünglichen Projekt auf Datei -> Neu -> Faces-JSP-Datei, um eine neue temporäre Faces-JSP-Datei zu erstellen.
      2. Ziehen Sie eine relationale Satzliste aus dem Drawer für Daten der Palette auf die Seite.
      3. 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.
      4. Löschen Sie die temporäre JSP-Datei.
    6. 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.
  7. Löschen Sie das Webprojekt JSF601.

Ressourcen der Faces Client-Laufzeit in einem Webprojekt aktualisieren

Die JavaServer Faces Client-Laufzeitressourcen, die ursprünglich mit WebSphere Studio Site Developer V5.1.x bereitgestellt wurden, wurden für Rational Web Developer V6.0.1 aktualisiert. Wenn Sie die Entwicklung der mit dieser früheren Produktversion erstellten Projekte fortsetzen wollen, wird empfohlen, dass Sie die Ressourcen für die Faces Client-Laufzeit auf die jeweils neueste Stufe aktualisieren.

In Rational Web Developer V6.0.1 werden die Faces Client-Laufzeitressourcen automatisch aktualisiert, wenn ein Webprojekt importiert oder ein Arbeitsbereich geöffnet wird, das bzw. der Ressourcen enthält, die nicht auf dem neuesten Stand sind. Nachdem Sie ein Webprojekt oder einen Arbeitsbereich aus WebSphere Studio Site Developer V5.1.x in Rational Web Developer V6.0.1 importiert bzw. geöffnet haben, werden Sie aufgefordert, die Faces Client-Laufzeitressourcen auf den neuesten Stand zu bringen.

Laufzeitressourcen automatisch aktualisieren

Führen Sie folgende Schritte aus, um die Faces Client-Laufzeitressourcen für ein Webprojekt automatisch zu aktualisieren:

  1. Importieren Sie ein Webprojekt (oder einen Arbeitsbereich) mit Faces Client-Inhalt aus WebSphere Studio Site Developer V5.1.x. Das Fenster Projektmigration wird geöffnet.
    Anmerkung:
    Wenn das Fenster Projektmigration nicht geöffnet wird, ist möglicherweise Ihre Einstellung für automatische Erstellung inaktiviert. Klicken Sie im Projektexplorer mit der rechten Maustaste auf Ihr Webprojekt, und wählen Sie Build -> Projekt aus; der Prozess zum erneuten Erstellen eines Projekts öffnet das Fenster Projektmigration.
  2. 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.
  3. Klicken Sie auf eine der folgenden Optionen:
  4. 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.
  5. Ö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.
  6. Führen Sie für jedes Datenobjekt in Der Clientdatensicht Folgendes aus:
    1. Klicken Sie mit der rechten Maustaste, und wählen Sie Konfigurieren aus.
    2. 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:

  1. Führen Sie die in Faces-Laufzeitressourcen in einem Webprojekt aktualisieren unter Laufzeitressourcen manuell aktualisieren aufgeführten Schritte aus.
  2. 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:

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:

  1. Generieren Sie die neuen Diff-Handler und -Prozessoren für jedes Clientdatenobjekt in Ihrem Webprojekt.
    1. Wählen Sie das Clientdatenobjekt aus, klicken Sie mit der rechten Maustaste, und wählen Sie Konfigurieren aus.
    2. Klicken Sie auf der Registerkarte Erweitert auf die Option Alle erneut generieren.
  2. 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";
  3. 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.

Änderungen an Faces Client-Komponenten in V6.0

Struts-Webprojekte migrieren

Sie müssen am Implementierungsdeskriptor von Struts-Webprojekten, die in WebSphere Studio V5.1.x erstellt wurden, eine kleine Änderung vornehmen, um das EAR-Projekt unter WebSphere Application Server V6.0 ausführen zu können. Sie können auch vorhandene Webprojekte von Struts 1.0.2 oder Struts 1.1 Beta (2 oder 3) manuell in Struts 1.1 umwandeln.

Den Implementierungsdeskriptor vorhandener Struts-Webprojekte modifizieren

Wenn ein Struts-Projekt in WebSphere Studio v5.x erstellt wird, wird der Konfigurationsparameter (<parametername>config</parametername>) im Implementierungsdeskriptor des Webprojekts auf WEB-INF/struts-config.xml gesetzt. WebSphere Application Server V6.0 erfordert, dass in diesem Parameter ein führender Schrägstrich "/" vorhanden ist. Wenn Sie ein in WebSphere Studio V5.1.x erstelltes Struts-Webprojekt unter WebSphere Application Server V6.0 ausführen, kann beim Starten des EAR-Projekts die Ausnahmebedingung java.net.MalformedURLException ausgegeben werden.

Anmerkung:
Rational Web Developer V6.0 fügt bei der Erstellung eines neuen Struts-Projekts den Schrägstrich "/" hinzu, bei der Migration von WebSphere Studio V5.1x muss er jedoch manuell hinzugefügt werden.

Führen Sie die folgenden Schritte aus, um in V6.0 den Implementierungsdeskriptor eines in WebSphere Studio v5.1.x erstellten Struts-Webprojekts zu korrigieren:

  1. Öffnen Sie das Struts-Webprojekt im Projektexplorer.
  2. Klicken Sie im Projektexplorer doppelt auf die Datei Webimplementierungsdeskriptor des Webprojekts. Der Editor für Webimplementierungsdeskriptoren wird geöffnet.
  3. Klicken Sie auf die Registerkarte Quelle, um die Quellenseite zu öffnen.
  4. Ä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>.

  5. 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:

  1. Laden Sie Ihre Struts 1.1 Beta-Projekte in einen Rational Web Developer V6.0-Arbeitsbereich.
  2. 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.
  3. Für jedes Projekt von Struts 1.1 Beta 2, das Sie in Struts 1.1 umwandeln wollen, müssen Sie Folgendes ausführen:
    1. Löschen Sie die folgenden JAR-Dateien aus dem Verzeichnis Web Content/WEB-INF/lib Ihres Projekts:
      • commons-*.jar.
      • struts.jar.
    2. 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.
    3. Löschen Sie die folgenden TLD-Dateien (TLD, Tag Library Descriptor) aus dem Verzeichnis Web Content/WEB-INF Ihres Projekts: struts-*.tld.
    4. 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:

  1. Laden Sie Ihre Struts 1.0.2-Projekte in einen Rational Web Developer V6.0-Arbeitsbereich.
  2. 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.
  3. Für jedes Projekt von Struts 1.0.2, das Sie in Struts 1.1 umwandeln wollen, müssen Sie Folgendes ausführen:
    1. Löschen Sie die Datei struts.jar aus dem Verzeichnis Content/WEB-INF/lib Ihres Projekts.
    2. 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.
    3. Löschen Sie die folgenden TLD-Dateien (TLD, Tag Library Descriptor) aus dem Verzeichnis Web Content/WEB-INF Ihres Projekts: struts-*.tld.
    4. Kopieren Sie die folgenden TLD-Dateien aus dem Verzeichnis Struts11/WebContent/WEB-INF in das Verzeichnis Web Content/WEB-INF Ihres Projekts: struts-*.tld.

Änderungen am Debugger in V6.0

Die Debug-Tools in Rational Web Developer V6.0 enthalten eine Reihe von Änderungen, die Sie beachten müssen, um diese Tools im Anschluss an die Migration für Ihre Projekte verwenden zu können. Sie müssen gegebenenfalls einige Einstellungen ändern oder wiederherstellen.

Arbeitsbereiche wiederherstellen und Konfigurationen starten

Wenn ein V5.1.x-Arbeitsbereich aus WebSphere Studio Site Developer in Rational Web Developer V6.0 geöffnet wird, werden die folgenden, dem Arbeitsbereich zugeordneten Startkonfigurationen für den Debugger nicht automatisch migriert:

Debugsichten

Die Sichten für Speicher und Speicherzuordnung sind nicht länger verfügbar. Sie wurden durch die Sichten für Speicher und Speicherbereitstellung ersetzt.

Der XSLT-Debugger

Der XSLT-Debugger wurde für V6.0 modifiziert, und viele seiner Sichten und Aktionen wurden in wesentlichen Punkten geändert. Weitere Informationen finden Sie in der Dokumentation des XSLT-Debuggers im Informationszentrum.

Eine der wesentlichsten Änderungen im XSLT-Debugger ist seine Abhängigkeit von der mit Rational Web Developer V6.0 installierten JRE. Wenn Sie einen Arbeitsbereich aus WebSphere Studio Site Developer V5.1.x migrieren, müssen Sie die installierte JRE so ändern, dass sie auf die richtige Position zeigt, bevor Sie eine XSLT-Debugsitzung für den Arbeitsbereich starten können. Sie können dazu eine der folgenden Aktionen ausführen:

Migration von WDO auf SDO

Wenn Sie in einem zielgruppenspezifischen Webprojekt für WebSphere Application Server V5.1 Code generiert haben, der relationale WDO-Datensätze (WDO, WebSphere Data Objects) oder relationale Datensatzlisten verwendet, müssen Sie nun, wenn diese Anwendungen zielgruppenspezifisch für WebSphere Application Server V6.0 verwendet werden sollen, relationale SDO-Datensätze (SDO, Service Data Objects) und relationale Datensatzlisten verwenden. Die Migration von WDO auf SDO wird automatisch ausgeführt, wenn Sie den Zielserver Ihrer Anwendung von WebSphere Application Server V5.1 in WebSphere Application Server V6.0 ändern.

Der Zielserver kann auf zwei Weisen geändert werden:

Hilfethemen zum Ändern des Zielservers und zur Verwendung des J2EE-Migrationsassistenten finden Sie in der Onlinehilfe von Rational Web Developer.

Kompatibilitätsaspekte

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:

  1. 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;
  2. Ä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:

Ä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:

Änderungen an Webprojekten nach dem Ändern der J2EE-Stufe Ihrer Anwendung von 1.3 in 1.4

Zusätzlich zu den Änderungen, die durch Ändern des Zielservers in WebSphere Application Server V6.0 zum Migrieren von WDO in SDO auftreten, werden durch das Ändern der J2EE-Spezifikationsstufe Ihrer Anwendung von 1.3 in 1.4 alle Tagbibliotheksverweise in Ihren JSPs so geändert, dass statt WDO, JSTL 1.0-Tagbibliotheken nun SDO, JSTL 1.1/JSP 2.0-Tagbibliotheken verwendet werden. Die folgende Tabelle zeigt die Änderungen an den JSP-Tagbibliotheksverweisen bei einer Migration von J2EE 1.3 auf J2EE 1.4.

Tabelle 1. JSP-Tagbibliotheksverweise in J2EE 1.3 und J2EE 1.4.
J2EE 1.3-Tagbibliothek (WDO) J2EE 1.4-Tagbibliothek (SDO)
http://www.ibm.com/websphere/wdo/core http://www.ibm.com/websphere/sdo/core
http://java.sun.com/jstl/core http://java.sun.com/jsp/jstl/core
http://java.sun.com/jstl/fmt http://java.sun.com/jsp/jstl/fmt
http://java.sun.com/jstl/xml http://java.sun.com/jsp/jstl/xml
http://java.sun.com/jstl/sql http://java.sun.com/jsp/jstl/sql

Reservierte EGL-Wörter in V6.0

In Rational Web Developer wurden neue Wörter für EGL (Enterprise Generation Language) reserviert.

Die folgenden, neuen Wörter sind für EGL reserviert:

EGL-Programme aus WebSphere Studio V5.1.x, die in einen V6.0-Arbeitsbereich importiert und erstellt werden und die diese Wörter als Variablen- oder Komponentennamen verwenden, werden mit der folgenden Nachricht gekennzeichnet:IWN.SYN.2002.e 39/2 Syntaxfehler in der Eingabe "variableName". Sie können das Problem korrigieren, indem Sie die Variable umbenennen.

Kapitel 2. Faces-Laufzeitressourcen für Webprojekte aus Rational Web Developer V6.0 aktualisieren

Die JavaServer Faces- und Faces Client-Laufzeitressourcen, die ursprünglich mit Rational Web Developer V6.0 bereitgestellt wurden, wurden für Rational Web Developer V6.0.1 aktualisiert. Wenn Sie die Entwicklung der mit dieser früheren Produktversion erstellten Projekte fortsetzen wollen, wird empfohlen, dass Sie die Ressourcen für die Faces- und Faces Client-Laufzeit auf die jeweils neueste Stufe aktualisieren.

In Rational Web Developer V6.0.1 werden die Faces- und Faces Client-Laufzeitressourcen automatisch aktualisiert, wenn ein Webprojekt importiert oder ein Arbeitsbereich geöffnet wird, das bzw. der Faces- oder Faces Client-Ressourcen enthält, die nicht auf dem neuesten Stand sind. Nachdem Sie ein Webprojekt oder einen Arbeitsbereich aus Rational Web Developer V6.0 in Rational Web Developer V6.0.1 importiert bzw. geöffnet haben, werden Sie aufgefordert, diese Laufzeitressourcen auf den neuesten Stand zu bringen.

Laufzeitressourcen automatisch aktualisieren

Führen Sie folgende Schritte aus, um die Faces- und Faces Client-Laufzeitressourcen für ein Webprojekt automatisch zu aktualisieren:

  1. Importieren Sie ein Webprojekt (oder einen Arbeitsbereich) mit Faces- oder Faces Client-Inhalt aus Rational Web Developer V6.0. Das Fenster Projektmigration wird geöffnet.
    Anmerkung:
    Wenn das Fenster Projektmigration nicht geöffnet wird, ist möglicherweise Ihre Einstellung für automatische Erstellung inaktiviert. Klicken Sie im Projektexplorer mit der rechten Maustaste auf Ihr Webprojekt, und wählen Sie Build -> Projekt aus; der Prozess zum erneuten Erstellen eines Projekts öffnet das Fenster Projektmigration.
  2. 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.
  3. Klicken Sie auf eine der folgenden Optionen:

Laufzeitressourcen manuell aktualisieren

Führen Sie folgende Schritte aus, um die Faces- und Faces Client-Laufzeitressourcen für ein Webprojekt manuell zu aktualisieren:

  1. 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.
  2. Klicken Sie im Projektexplorer mit der rechten Maustaste auf das Projekt JSF601, und wählen Sie im Menü die Option Eigenschaften aus.
  3. 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.
  4. Wenn Sie mit EGL arbeiten, erstellen Sie eine JSF-Seitendatei wie folgt:
    1. Klicken Sie mit der rechten Maustaste auf den Ordner 'WebContent' Ihres neuen EGL-Webprojekts.
    2. Wählen Sie Neu -> Andere -> Faces-JSP-Datei aus.
    Die Dateien eglintdebug.jar und eglintdebugsupport.jar werden zu Ihrem Projekt hinzugefügt.
  5. Führen Sie für jedes vorhandene Faces-Projekt, das Sie aktualisieren wollen, die folgenden Schritte aus:
    1. 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
    2. 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.
    3. 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.
  6. Löschen Sie das Webprojekt JSF601.

Kapitel 3. Migration der J2EE-Projekte

Der J2EE-Migrationsassistent wurde in Rational Web Developer V6.0 6.0 aktualisiert, um Projekte der Spezifikationsstufe J2EE auf J2EE 1.4 zu migrieren. Der J2EE-Migrationsassistent unterstützt die Migration von Spezifikationsstufe J2EE 1.2 und 1.3 auf J2EE 1.4 für alle J2EE-Modularten.

Weitere Informationen zur Migration von Artefakten der Spezifikationsstufen J2EE 1.3 und 1.2 auf Spezifikationsstufe J2EE 1.4 finden Sie in Migration der J2EE-Spezifikationsstufe 1.3 auf 1.4 und Migration von J2EE-Spezifikationsstufe 1.2 auf 1.4.

Anmerkung:
Bevor Sie den J2EE-Migrationsassistenten verwenden, sollten Sie unbedingt die folgenden Schritte ausführen:

Gehen Sie wie folgt vor, um auf den J2EE-Migrationsassistenten zuzugreifen:

  1. Klicken Sie in der Sicht J2EE-Hierarchie der Perspektive "J2EE" mit der rechten Maustaste auf das Unternehmensanwendungsprojekt, das Sie migrieren wollen.
  2. Wählen Sie im Kontextmenü die Option Migrieren -> J2EE-Migrationsassistent aus.
  3. 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 Web Developer V6.0 beschrieben.

Weitere Informationen zu den Änderungen, die an Artefakten der Spezifikationsstufen J2EE 1.3 und 1.2 bei der Migration auf J2EE 1.4 ausgeführt werden, finden Sie in Migration der J2EE-Spezifikationsstufe 1.3 auf 1.4 und Migration von J2EE-Spezifikationsstufe 1.2 auf 1.4.

Migration sicherer Web-Services

Beim Migrieren von Web-Services von J2EE 1.3 auf J2EE 1.4. mit dem J2EE-Migrationsassistent werden sichere Web-Services nicht migriert. Für die Migration von sicheren Web-Services sind manuelle Schritte erforderlich.

Nach der J2EE-Migration müssen die sicheren Binding- und Erweiterungsdateien wie folgt manuell auf J2EE 1.4 migriert werden:

  1. Klicken Sie doppelt auf die Datei webservices.xml, um den Editor für Web-Services aufzurufen.
  2. Wählen Sie die Registerkarte Binding-Konfigurationen aus, um die Binding-Datei zu bearbeiten.
  3. 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.
  4. Wählen Sie die Registerkarte Erweiterung aus, um die Erweiterungsdatei zu bearbeiten.
  5. Fügen Sie alle erforderlichen Erweiterungskonfigurationen unter den neuen Abschnitten Anforderung von Verbraucherservicekonfigurationsdetails und Servicekonfigurationsdetails für das Generieren von Antworten hinzu.
  6. Speichern Sie, und schließen Sie den Editor.

Migration der J2EE-Spezifikationsstufe 1.3 auf 1.4

J2EE-Projekte können von der Spezifikationsstufe J2EE 1.3 auf J2EE 1.4 migriert werden. In diesem Abschnitt werden für jeden J2EE-Projekttyp die durch den J2EE-Migrationsassistenten von Spezifikationsstufe J2EE 1.3 auf J2EE 1.4 migrierten Artefakte beschrieben.

Webprojekte (Servletstufe 2.3 auf Servletstufe 2.4)

Artefakte eines Webimplementierungsdeskriptors werden durch den J2EE-Migrationsassistenten migriert, wenn ein J2EE 1.3-Webprojekt auf J2EE 1.4 migriert wird.

Die folgenden Webanwendungsartefakte werden migriert:

Authentifizierungseinschränkungen

J2EE 1.4 enthält ein Objekt Description mit zwei Attributen: language und value. Dieses Objekt Description war in J2EE 1.3 nicht vorhanden; die Beschreibung war ein Attribut der Authentifizierungseinschränkung. Wenn die Artefakte eines Webimplementierungsdeskriptors auf J2EE 1.4 migriert werden, wird daher der Wert (value) für das Objekt Description aus dem Beschreibungsattribut der Authentifizierungseinschränkung übernommen.

Sicherheitseinschränkungen

In J2EE 1.3 war die Beschreibung ein Attribut der Sicherheitseinschränkung. J2EE 1.4 enthält ein neues Objekt Description mit den Attributen language und value. Der Wert (value) des Objekts Description wird daher aus dem Beschreibungsattribut der Sicherheitseinschränkung übernommen.

Webanwendung

Das Beschreibungszeichenfolgeattribut des Objekts ContextParam der Spezifikationsstufe 1.3 wurde in J2EE 1.4 in ein Objekt Description in ParamValue verschoben.

Das Objekt TagLib der Spezifikationsstufe J2EE 1.3 wurde in J2EE 1.4 in das Objekt JSPConfig verschoben. Die JSPConfig-Objekte gehörten in 1.3 zum Webstammobjekt.

Connectorprojekte (JCA 1.0 auf JCA 1.5)

Der J2EE Migrationsassistent migriert die Artefakte eines JCA 1.0-Deskriptors (JCA, J2EE Connector Architecture) auf JCA 1.5. Die migrierten Artefakte gehören zu den Elementen des Objekts ResourceAdaptor, da auf Spezifikationsstufe J2EE 1.4 für Connectorprojekte zwei neue Objekte, OutboundResourceAdaptor und ConnectionDefinition, zum Objekt ResourceAdaptor hinzugefügt wurden.

Die Zuordnung der migrierten Elemente wird nachstehend beschrieben.

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:

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:

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.

Migration von J2EE-Spezifikationsstufe 1.2 auf 1.4

J2EE-Module können von Spezifikationsstufe J2EE 1.2 auf J2EE 1.4 migriert werden. In diesem Abschnitt werden die Artefakte für J2EE-Projekte beschrieben, die durch den J2EE-Migrationsassistenten von Spezifikationsstufe J2EE 1.2 auf J2EE 1.4 migriert werden.

Ausführliche Informationen zur Verwendung des J2EE-Migrationsassistenten finden Sie in Kapitel 3. Migration der J2EE-Projekte.

Webprojekte (Servletstufe 2.2 auf Servletstufe 2.4)

Artefakte eines Webimplementierungsdeskriptors werden durch den J2EE-Migrationsassistenten migriert, wenn ein J2EE 1.2-Webprojekt auf die Spezifikationsstufe J2EE 1.4 migriert wird.

Die folgenden Webanwendungsartefakte werden migriert:

Authentifizierungseinschränkungen

J2EE 1.4 enthält ein Objekt Description mit zwei Attributen: language und value. Dieses Objekt Description war in J2EE 1.2 nicht vorhanden; die Beschreibung war ein Attribut der Authentifizierungseinschränkung. Wenn die Artefakte eines Webimplementierungsdeskriptors auf J2EE 1.4 migriert werden, wird daher der Wert (value) für das Objekt Description aus dem Beschreibungsattribut der Authentifizierungseinschränkung übernommen.

Sicherheitseinschränkungen

In J2EE 1.2 war die Beschreibung ein Attribut der Sicherheitseinschränkung. J2EE 1.4 enthält ein neues Objekt Description mit den Attributen language und value. Der Wert (value) des Objekts Description wird daher aus dem Beschreibungsattribut der Sicherheitseinschränkung übernommen.

Webanwendung

Das Beschreibungszeichenfolgeattribut des Objekts ContextParam der Spezifikationsstufe 1.2 wurde in J2EE 1.4 in ein Objekt Description in ParamValue verschoben.

Das Objekt TagLib der Spezifikationsstufe J2EE 1.2 wurde in J2EE 1.4 in das Objekt JSPConfig verschoben. Die JSPConfig-Objekte gehörten in 1.2 zum Webstammobjekt.

Änderungen am J2EE-Migrationsassistenten in Rational Web Developer V6.0

In Rational Web Developer V6.0 6.0 wurden Änderungen am J2EE-Migrationsassistenten vorgenommen, die für die Migration aller Stufen der Spezifikation J2EE gelten.

Optionale Migration der Projektstruktur

In WebSphere Studio V5.1.x bis V5.1.2 erfolgte die Migration der Projektstruktur gleichzeitig mit der Migration der J2EE-Spezifikationsstufe. Die Migration der Projektstruktur war bei der Migration der J2EE-Spezifikationsstufe nicht optional.

Beim J2EE-Migrationsassistenten in Rational Web Developer V6.0 ist Projektstruktur migrieren eine separate, optionale Auswahl für J2EE-Spezifikationsstufe für Projekte migrieren. Die Migration der J2EE-Spezifikationsstufe und die Migration der Projektstruktur können unabhängig voneinander durchgeführt werden.

Zielserver erforderlich

In Rational Web Developer V6.0 muss für neue und vorhandene J2EE-Projekte, die auf eine höhere J2EE-Spezifikationsstufe migriert werden, ein Zielserver für das Projekt angegeben werden. Serverzielunterstützung (Server Targeting) ist in V6.0 der Standardmechanismus für das Festlegen des Klassenpfads für J2EE-Projekte. Informationen zum Festlegen eines Zielservers und zur Verwendung des J2EE-Migrationsassistenten finden Sie in der Onlinehilfe.

Kapitel 4. Änderungen in WebSphere-Testumgebungen

Die mit Rational Web Developer V6.0 gelieferten Testumgebungen von WebSphere Application Server enthalten gegenüber den mit früheren Editionen von WebSphere Studio Site Developer bereitgestellten Testumgebungen einige Änderungen.

Es folgt eine Zusammenfassung der Änderungen an den WebSphere Application Server-Testumgebungen Rational Web Developer V6.0:

Die folgende Tabelle zeigt die Stufen der WebSphere Application Server-Testumgebungen, die im Produktumfang der verschiedenen Versionen von WebSphere Studio Site Developer und Rational Web Developer enthalten sind.

Tabelle 2. WebSphere Application Server-Testumgebungen in WebSphere Studio Site Developer und Rational Web Developer
WebSphere Application Server V4.x AEs WebSphere Application Server V5.x Base WebSphere Application Server Express V5.x WebSphere Application Server V6.0
WebSphere Studio Site Developer V5.1 V4.0.6 V5.0.2 V5.0.2 nicht verfügbar
WebSphere Studio Site Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1 V5.0.2 & V5.1 nicht verfügbar
WebSphere Studio Site Developer V5.1.2 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1.0.3 V5.0.2 & V5.1.0.3 nicht verfügbar
Rational Web Developer V6.0 nicht verfügbar V5.0.x, V5.1.1 V5.0.2 & V5.1.1 V6.0

Copyright und Bemerkungen