IBM Rational Application 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 Application Developer V6.0 aktualisieren
Kapitel 3. Faces-Laufzeitressourcen für Portletprojekte aus Rational Application Developer V6.0 aktualisieren
Kapitel 4. Migration der J2EE-Projekte
Migration sicherer Web-Services
Migration der J2EE-Spezifikationsstufe 1.3 auf 1.4
Enterprise JavaBean-Projekte (EJB 2.0 auf EJB 2.1)
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
Migration von Enterprise JavaBeans-Projekten (EJB 1.1 auf EJB 2.1)
Webprojekte (Servletstufe 2.2 auf Servletstufe 2.4)
Änderungen am J2EE-Migrationsassistenten in Rational Application Developer V6.0
Kapitel 5. Migration auf die Portaltools in Rational Application Developer V6.0
Migration von WebSphere Portal V4.2-Portlets auf V5.x
Faces-Laufzeitressourcen in einem Portletprojekt aktualisieren
Kapitel 6. Ä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 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:

  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 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.
  4. 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).
  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 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:

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

    Wichtig:

  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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:

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:

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:

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

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

  1. 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.
  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 Application 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 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:

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

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

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:

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

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

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

  1. 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.
  2. 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.
  3. Klicken Sie auf eine der folgenden Optionen:
  4. 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:

  1. 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.
  2. Klicken Sie im Projektexplorer mit der rechten Maustaste auf das Projekt JSFP601, und wählen Sie im Menü die Option Eigenschaften aus.
  3. 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.
  4. Führen Sie für jedes vorhandene Faces-Portletprojekt, 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:
      • jsf-api.jar
      • jsf-ibm.jar
      • jsf-impl.jar
      • jsf-portlet.jar
      • odc-jsf.jar
    2. 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.
  5. 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:

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

  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.

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:

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:

  1. Öffnen Sie das EJB-Projekt im Projektexplorer.
  2. Klicken Sie im Projektexplorer doppelt auf die Datei Implementierungsdeskriptor des EJB-Projekts. Der Editor für EJB-Implementierungsdeskriptoren wird geöffnet.
  3. Klicken Sie auf die Registerkarte Bean, um die Seite Bean zu öffnen.
  4. Führen Sie für jede nachrichtengesteuerte Bean des Typs EJB 2.1 Folgendes aus:
    1. Wählen Sie auf der linken Seite der Seite Bean die nachrichtengesteuerte Bean des Typs EJB 2.1 aus.
    2. Wählen Sie unter der Überschrift WebSphere-Bindings den Knopf JCA-Adapter aus.
    3. Geben Sie die Eigenschaften für die Bindingimplementierung an:
      1. 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.

      2. 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.

      3. 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.

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

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

  1. Konvertieren Sie das EJB-Projekt von EJB 1.1 in EJB 2.x.
  2. Migrieren Sie den EJB-Code von EJB 1.1 auf EJB 2.x.
  3. 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.

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.)

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).

  1. Ersetzen Sie bei jeder 1.1-CMP-Bean alle CMP-Felder durch die abstrakten Methoden getXXX und setXXX. (Dann muss die Beanklasse abstrakt sein.)
  2. Erstellen Sie für jede CMP eine abstrakte Methode getXXX und setXXX für den Primärschlüssel.
  3. 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.
  4. Geben Sie für jeden 1.1-CMP-Finder java.util.Collection statt java.util.Enumeration zurück.
  5. Ä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.
  6. Aktualisieren Sie die Behandlung von Ausnahmebedingungen (ROLLBACK-Verhalten) bei Ausnahmebedingungen, die nicht für Anwendungen ausgegeben werden:
  7. Aktualisieren Sie die Behandlung von Ausnahmebedingungen (ROLLBACK-Verhalten) bei Ausnahmebedingungen für Anwendungen:
  8. 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:

  1. Löschen Sie die vorhandenen, fernen EJB-Verweise auf der Seite "Verweise" im Editor für den Implementierungsdeskriptor.
  2. 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:

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:

  1. 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.
    1. Klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie die Option Exportieren aus.
    2. Wählen Sie WAR-Datei und Quellendateien exportieren aus, und klicken Sie auf Fertig stellen.
  2. Importieren Sie die Portlet-WAR-Datei:
    1. Erstellen Sie in den Portaltools für Rational Application Developer V6.0 ein neues, leeres Portletprojekt.
      1. Wählen Sie Datei -> Neu -> Projekt -> Portal -> Portletprojekt oder Portletprojekt (JSR 168) aus.
      2. Nehmen Sie die Auswahl von Portlet erstellen zurück.
      3. Klicken Sie auf Erweiterte anzeigen.
      4. Wenn Sie ein Portlet aus WebSphere Portal 4.2 importieren, wählen Sie 2.2 als Servletversion aus.
      5. Wählen Sie WebSphere Portal v5.0 als Zielserver aus und klicken Sie auf Fertig stellen.
    2. Importieren Sie die WAR-Datei in dieses neue, leere Portletprojekt.
      1. Wählen Sie Importieren aus.
      2. 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).
      3. Wählen Sie das neue, leere Portletprojekt aus.
      4. Wählen Sie Vorhandene Ressourcen ohne Warnung überschreiben aus.
      5. Wählen Sie nicht Projekte beim Überschreiben löschen aus.
  3. 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.

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

  1. Migrieren Sie die Portal V4.2-Portletprojekte auf Portal V5.x-Portletprojekte:
    1. Klicken Sie mit der rechten Maustaste auf das Portletanwendungsprojekt, das Sie migrieren wollen.
    2. Wählen Sie Eigenschaften -> Portlet-API aus, um die Seite für Portlet-APIs aufzurufen.
    3. Wählen Sie in der Dropdown-Liste für die Portlet-API-Stufe WebSphere Portal Version 5.x aus.
    4. 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.
  2. 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.
    1. Wenn das migrierte Portletprojekt nur dem Unternehmensanwendungsprojekt zugeordnet ist, führen Sie folgende Schritte aus:
      1. Schließen Sie alle Editoren in der Workbench.
      2. Klicken Sie mit der rechten Maustaste auf das Unternehmensanwendungsprojekt, dem das migrierte Portletprojekt zugeordnet ist.
      3. Wählen Sie Migrieren -> J2EE-Migrationsassistent... aus, und klicken Sie auf Weiter.
      4. Wählen Sie J2EE Version 1.3 und als Zielserver WebSphere Portal aus.
      5. Klicken Sie auf Fertig stellen.
    2. Wenn dem Unternehmensanwendungsprojekt andere Portletprojekte zugeordnet sind, müssen Sie das migrierte Portletprojekt entfernen und es zu einem anderen Unternehmensanwendungsprojekt hinzufügen.
      1. Entfernen Sie das Modul des migrierten Portletprojekts aus dem Unternehmensanwendungsprojekt.
        1. Erweitern Sie das Unternehmensanwendungsprojekt, und wählen Sie den Implementierungsdeskriptor aus.
        2. Wählen Sie Öffnen mit -> Editor für Implementierungsdeskriptor aus.
        3. Wählen Sie die Registerkarte Module aus. Wählen Sie auf der Modulseite des Editors die WAR-Datei des migrierten Portletprojekts aus.
        4. Klicken Sie auf Entfernen.
        5. Wählen Sie Datei -> Speichern aus, um die Änderungen zu speichern.
      2. Erstellen Sie ein neues Unternehmensanwendungsprojekt, und fügen Sie das Portletprojekt hinzu.
        1. Wählen Sie Datei -> Neu -> Projekt aus.
        2. Wählen Sie das Markierungsfeld Alle Assistenten anzeigen aus.
        3. Erweitern Sie J2EE, und wählen Sie Unternehmensanwendungsprojekt aus.
        4. 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.
        5. 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:

  1. 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.
  2. 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.
  3. Klicken Sie auf eine der folgenden Optionen:
  4. 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:

  1. Importieren Sie Ihr vorhandenes Portletprojekt mit Faces-Inhalt in einen Rational Application Developer V6.0.1-Arbeitsbereich.
  2. 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.
  3. Klicken Sie im Projektexplorer mit der rechten Maustaste auf das Projekt JSFP601, und wählen Sie im Menü die Option Eigenschaften aus.
  4. 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.
  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:
      • jsf-api.jar
      • jsf-ibm.jar
      • jsf-impl.jar
      • jsf-portlet.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>
      		<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.
    3. 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.
    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>
  6. 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 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