Migration von WebSphere Studio "Classic" auf IBM WebSphere
Studio Site Developer
Kapitel 1. WebSphere Application Server - Express Migration - Übersicht
Kapitel 2. Ihren Produktionsserver migrieren
Kapitel 3. Von IBM WebSphere Studio Site Developer Version 5.1 migrieren
Kapitel 4. Von IBM WebSphere Studio Site Developer Version 5 oder 5.0.1 migrieren
Kapitel 5. Von IBM WebSphere Studio Site Developer Version 4.0.x migrieren
Kapitel 6. Migration von WebSphere Studio "Classic" auf IBM WebSphere Studio Site Developer
Kapitel 7. Migration von VisualAge für Java auf IBM WebSphere Studio Site Developer
Kapitel 8. Migration von VisualAge für Java Visual Composition Editor auf Visual Editor für Java
Kapitel 9. Erstellungskonfiguration (Bibliothek, JARs, abhängige Projekt-JARs, Ant-Erstellungen)
Kapitel 10. Migrationsbeispiele
Kapitel 11. Weiterführende Informationen
In dieser Version von IBM(R) WebSphere(R)Application Server - Express Version 5.1 können Sie den Code aus folgenden Programmen migrieren:
WebSphere Application Server - Express 5.1 setzt sich aus WebSphere Application Server 5.1 und WebSphere Studio Site Developer 5.1.1 zusammen. Im ersten nachfolgenden Kapitel wird die Migration der Serverfunktion von WebSphere Application Server - Express behandelt. Die übriegn Kapitel dieses Migrationshandbuchs befassen sich mit der Migration von Code aus verschiedenen Versionen von WebSphere Studio Site Developer.
Wichtiger Hinweis hinsichtlich der Migration des Servers:
Eine Migration Ihrer Serverkonfiguration ist nur dann von Bedeutung, wenn Sie den Server unter Verwendung der Administrationskonsole verwalten, so wie in der Regel in einer Produktionsumgebung üblich. Bei dieser Betriebsart werden die Serverkonfiguration und die implementierten Anwendungen im Konfigurationsverzeichnis des Servers gespeichert. Der Migrationsprozess migriert diese Konfiguration und die Anwendungsdateien für Sie. Wenn Sie jedoch WebSphere Studio Site Developer zum Konfigurieren und Implementieren von Anwendungen auf Ihrem fernen Server verwenden, müssen Sie die Serverkonfigurationsdateien nicht migrieren. Die Konfigurations- und Anwendungsdateien werden in diesem Fall im Studio Site Developer-Arbeitsbereich verwaltet. Der Arbeitsbereich wird von Studio Site Developer migriert. Sie können anschließend ein neues Exemplar eines WebSphere Application Server - Express 5.1-Servers definieren und Ihre Anwendungen von Studio Site Developer aus implementieren.
Das vorliegende Handbuch enthält die folgenden Kapitel:
Migration von WebSphere Studio "Classic" auf IBM WebSphere
Studio Site Developer
Informationen zur Verwendung von WebSphere Application Server - Express finden Sie im Handbuch Erste Schritte und in der Onlinehilfefunktion. Lesen Sie das Installationshandbuch bevor Sie WebSphere Application Server - Express installieren. Nachdem Sie WebSphere Application Server - Express erfolgreich installiert haben, lesen Sie das Handbuch Erste Schritte, und arbeiten Sie die Lernprogramme unter Erste Schritte durch. Die Lernprogramme stellen Ihnen die Workbench, die Java(TM)-Entwicklung und die Web-Services vor. Nachdem Sie die Lernprogramme abgeschlossen haben, können Sie Ihre Anwendungsressourcen unter Anleitung des vorliegenden Handbuchs auf WebSphere Application Server - Express migrieren.
Die HTML- und Acrobat PDF-Versionen dieses Handbuchs finden Sie im Verzeichnis /readme. Der Inhalt beider Versionen ist identisch. Sie können migrate.html in einem beliebigen Web-Browser öffnen. Um migrate.pdf aufzurufen, müssen Sie die Acrobat Reader-Software installiert haben. Sie können diese unter der Adresse www.adobe.com/products/acrobat/readstep2.html herunterladen.
Im vorliegenden Handbuch Migration werden durchgängig Windows(R)-Konventionen verwendet. Die Angabe "WS_Installdir\" unter Windows ist beispielsweise äquivalent zur Angabe "WS_Installdir/" unter Linux.
Künftige Aktualisierungen dieses Handbuchs finden Sie unter der Adresse www.ibm.com/websphere/developer/zones/studio/transition.html.
Die Migration ermöglicht die Weiterverwendung vorhandenen Materials. Migrationstasks und -tools helfen Ihnen bei der Ausführung von Upgrades für das Produkt und die erforderlichen Voraussetzungen, der Wiederverwendung vorhandener Anwendungskomponenten, sofern möglich, und der Übertragung von Verwaltungskonfigurationen aus Ihrer früheren Version in eine aktuelle Version.
Die Migration von WebSphere Application Server-Produkten bewirkt, dass die vorhandene Umgebung und vorhandene Anwendungen weiter verwendet werden können und stellt deren Kompatibilität mit der aktuellen Produktversion sicher.
Funktionen zur Produktmigration werden von den Migrationstools in IBM WebSphere Application Server - Express, Version 5.1 bereitgestellt. Die Migrationstools unterstützen die Migration von folgenden Versionen:
Der Produktinstallationsassistent stellt fest, ob bereits ältere Versionen von IBM WebSphere Application Server - Express vorhanden sind und gibt Ihnen die Möglichkeit, während der Installation von Version 5.1 die Migrationstools auszuführen. Zum Migrieren von IBM WebSphere Application Server Version 3.5 müssen Sie diese Tools direkt ausführen.
Redbook zur Migration
Die Veröffentlichung Migrating to WebSphere V5: An End-to-End Migration Guide ist auf der Website für Redbooks unter http://www.ibm.com/redbooks verfügbar. Um das Redbook auf der Website zu finden, suchen Sie nach der Dokumentnummer SG24-6910-00. Das Redbook enthält umfassendere Informationen als dieser Artikel, z. B. ausführlichere Informationen zur Planung der Anwendungsmigration und den Tools und Beispielen von WebSphere Studio Application Developer.
Migration von Version 3.5: Wechsel auf das J2EE-Modell
Benutzer von V3.5.x, die einen Upgrade auf V5 ausführen, wechseln damit auf eine Plattform, die auf den J2EE-Spezifikationen basiert. Die J2EE-Technologie zieht eine deutliche Trennung zwischen der Erstellung von Anwendungen und der Verwaltung und Implementierung von Anwendungen. Die Migration von V3.5 umfasst Änderungen in Anwendungsstrukturen, Entwicklung und Implementierung.
Die Migrationstools helfen beim Übergang von Version 3.5.x auf Version 5 durch Migration der Systemkonfiguration und der Erstellung von J2EE-Artefakten, einschließlich der J2EE-Sicherheitsberechtigungsklassenzuordnung. Die Migrationstools erstellen auf Basis der Konfigurationen von Version 3.5.x erste J2EE-Unternehmensanwendungen. Auf Grund der erheblichen Änderungen in den Anwendungsstrukturen sollten Sie unter Verwendung der Entwicklungs- und Implementierungstools die migrierten Anwendungen sorgfältig testen und optimieren, um genau festzustellen, wie die Anwendungen in der neuen Umgebung funktionieren.
Das J2EE-Modell ermöglicht es, Anwendungen unabhängig von ihrer endgültigen Implementierungsumgebung zu entwickeln. Diese Tasktrennung vereinfacht den Hochstufungsprozess einer Anwendung vom Beginn der Entwicklung über die gesamte Produktion bzw. das Versetzen einer Anwendung von einem Server auf einen anderen. Dadurch sollen jeweils nur die Implementierungsparameter der Anwendung und nicht der Anwendungscode geändert werden müssen.
Bevor Sie beginnen, stellen Sie fest, ob auf der Maschine, auf der Sie Ihr Produkt der Version 5.1 installieren wollen, bereits eine Version von WebSphere Application Server installiert ist. Ist dies der Fall, müssen Sie planen, ob Sie die Konfiguration und die Anwendungen der früheren Version in die neue Version kopieren wollen, d. h. ob Sie eine Migration vornehmen wollen. Bei der Migration wird die frühere Version nicht deinstalliert. Dieses frühere Release bleibt weiterhin funktionsfähig. Wenn Sie es gleichzeitig mit der Installation von Version 5.1 ausführen, besteht zwischen den beiden Versionen eine Koexistenz. Damit Sie beide Versionen zur selben Zeit ausführen können, müssen Sie die Ports so konfigurieren, dass es nicht zu Konflikten kommt. Beachten Sie, dass die Migrationsoperation die Portdefinitionen nur "wie vorhanden" migriert, sodass Sie für beide Versionen die selben Definitionen vorliegen haben. WebSphere Application Server enthält Migrationstools, die die gesamte Migrationsfunktionalität bereitstellen. Der Installationsassistent kann die Migrationstools aufrufen, aber Sie können die Tools auch zu einem späteren Zeitpunkt manuell aufrufen.
Im Überblick ist die Migration von IBM WebSphere Application Server - Express V5.0.x auf V5.1 eine Routineoperation. Sie können das Installationsprogramm zur Migration verwenden, sodass Sie anschließend nur wenige oder gar keine Optimierungsoperationen ausführen müssen. Sie können die Migrationstools aber auch manuell einsetzen, um die Konfigurationsdaten von V5.0.0, V5.0.1 oder V5.0.2 zu speichern, V5.0.0, V5.0.1 oder V5.0.2 zu deinstallieren, V5.1 zu installieren und können die Migrationstools erneut verwenden, um die Konfigurationsdaten wiederherzustellen.
Im Überblick umfasst die Migration von IBM WebSphere Application Server V3.5 auf IBM WebSphere Application Server - Express V5.1 wesentliche Änderungen hinsichtlich der Anwendungsstrukturen, der Entwicklung und der Implementierung. Die Migrationstools unterstützen Sie bei diesem Übergang durch Migration von Systemkonfigurationen und Erstellung von J2EE-Artefakten, einschließlich der Zuordnung von früheren Sicherheitseinstellungen zu J2EE-Sicherheitsberechtigungsklassen. Diese Sicherheitszuordnungen ermöglichen Ihnen während dieses Übergangs den Zugriff auf migrierte Ressourcen. Die Migrationstools erstellen auf Basis der Konfigurationen von V3.5.x erste J2EE-Unternehmensanwendungen. Auf Grund der erheblichen Änderungen in den Anwendungsstrukturen sollten Sie unter Verwendung der Entwicklungs- und Implementierungstools die migrierten Anwendungen jedoch sorgfältig testen und optimieren.
Bei der Migration werden die folgenden Dateien im Sicherungsverzeichnis gespeichert.
In diesem Abschnitt werden die Migrationstools vorgestellt, die mit WebSphere Application Server zur Verfügung gestellt werden. Alle Migrationstools befinden sich im Verzeichnis /migration auf der Produkt-CD-ROM. Es ist wichtig, dass Sie jeweils die Migrationstools für die Version von Application Server verwenden, die Sie installieren. Die Tools unterliegen Änderungen im Lauf der Zeit. Die Tools, die auf der Produkt-CD-ROM enthalten sind, bieten die erforderliche Funktionalität für die Migration von einem früheren Release von Application Server auf die Version der Produkt-CD-ROM. Die auf der CD-ROM mitgelieferten Tools entsprechen dem Produkt auf der CD-ROM. Wenn Sie Migrationstools eines früheren Releases von Application Server verwenden, treten bei der Migration höchstwahrscheinlich Probleme auf.
Das Script WASPreUpgrade.sh (oder WASPreUpgrade.bat) ist ein Migrationstool, mit dem die Konfiguration und Anwendungen früherer Versionen oder Releases auf Version 5.1 Application Server - Express migriert werden können.
Die Befehlsdatei befindet sich nach der Installation im Unterverzeichnis AppServer/bin des Installationsstammverzeichnisses. Sie steht auch direkt auf der CD zur Verfügung, im Unterverzeichnis migration.
Syntax
WASPreUpgrade sicherungsverzeichnis aktuellesWASVerzeichnis
[adminKnotenname]
[-nameServiceHost hostname [-nameServicePort portnummer ]]
[-traceString trace_spezifikation [-traceFile dateiname ]]
Parameter
Die ersten beiden Argumente sind erforderlich und positionsgebunden.
Es werden folgende Argumente unterstützt:
Protokollierung
Das Tool WASPreUpgrade zeigt während der Ausführung den Status auf dem Bildschirm an. Es speichert außerdem umfangreiche Protokolldaten im sicherungsverzeichnis. Sie können die Datei WASPreUpgrade.log mit einem Texteditor anzeigen.
Das Script WASPostUpgrade.sh (oder WASPostUpgrade.bat) ist ein Migrationstool, mit dem die Konfiguration und Anwendungen früherer Versionen oder Releases auf Version 5.1 Application Server - Express migriert werden können.
Die Befehlsdatei befindet sich im Unterverzeichnis AppServer/bin des Installationsstammverzeichnisses.
Das Tool WASPostUpgrade installiert alle migrierten Anwendungen im Verzeichnis AppServer/installedApps für die Installation der Version 5.1. Das Tool enthält Anwendungen aus dem Sicherungsverzeichnis, das vom Tool WASPreUpgrade erstellt wird. Das Tool WASPreUpgrade kopiert die Anwendungen aus dem Verzeichnis installedApps und anderen Verzeichnissen der früheren Version oder des früheren Releases.
Syntax
WASPostUpgrade sicherungsverzeichnis
[-serverName servername]
[-webModuleAdditionalClasspath klassenpfad]
[-documentRootLimit nummer]
[-substitute "schlüssel1=wert1[;schlüssel2=wert2;[...]]"]
[-portBlock portstartnummer]
[-backupConfig true | false]
[-replacePorts true | false]
[[-traceString trace_spezifikation [-traceFile dateiname]]
Parameter
Das erste Argument ist erforderlich. Es werden folgende Argumente unterstützt:
In der XML-Dateneingabedatei wird jeder der zu ersetzenden Schlüssel als $key$ angezeigt. Dieses Argument ersetzt in der XML-Eingabedatei alle Vorkommen von $NODE_NAME$ durch admin_knoten und $APP_SERVER$ durch standardserver.
Wenn die Ersatzzeichenfolge Semikolons enthält, verwenden Sie dafür $semiColon$, um sie vom Begrenzer ";" zu unterscheiden. Auf UNIX-Plattformen fügen Sie zu jedem Dollarzeichen ($) in der Ersatzzeichenfolge ein Escapezeichen hinzu (beispielsweise \$semiColon\$).
Dieser Parameter kann auf gespeicherte Konfigurationen von Advanced Edition, Version 3.5.x angewendet werden.
Protokollierung
Das Tool WASPostUpgrade zeigt während der Ausführung den Status auf dem Bildschirm an. Es speichert außerdem umfangreiche Protokolldaten im protokollverzeichnis. Sie können die Datei WASPostUpgrade.log mit einem Texteditor anzeigen.
In diesem Abschnitt werden die Änderungen während der Migration beschrieben, die immer eine einzelne Maschine, beispielsweise eine Entwicklungsumgebung oder eine Standalone-Maschine betrifft.
Analysieren Sie die Datei WASPostUpgrade.log, wenn Sie genauere Informationen zur Migration von Enterprise-Beans erhalten wollen. Das J2EE-Programmiermodell gibt eine Architektur zur Erstellung und Implementierung von Anwendungen an. Da Anwendungen in Version 3.5.x nicht dieselbe Architektur haben, erstellt das Tool WASPostUpgrade Anwendungen erneut. Es erstellt alle migrierten Webressourcen und Enterprise-Beans in J2EE-Anwendungen. Es ordnet alle Unternehmensanwendungen aus der Installation der Version 3.5.x zu J2EE-Anwendungen desselben Namens zu, die auf demselben Server implementiert werden.
Das Tool WASPostUpgrade ordnet Webressourcen, die nicht in einer Unternehmensanwendung enthalten sind, einer J2EE-Standardanwendung zu, die den Namen des Servers enthält. Das Tool ordnet Webanwendungen zu J2EE-WAR-Dateien zu. Das Tool fasst Ressourcen in einer J2EE-EAR-Datei zusammen und implementiert diese in der Konfiguration der Version 5.
Sie können die Datei datasources.xml einer Version 3.5.x verwenden, um die Konfigurationseinstellungen für Datenquellen zu ergänzen. Version 3.5.x speichert die Datei im Verzeichnis properties. Die Migrationstools migrieren eine vorhandene Datei datasources.xml, indem die in der Datei enthaltenen Eigenschaften in die Konfiguration der Datenquelle und des JDBC-Treibers eingefügt werden.
Die Einträge der Unternehmensanwendungen von Version 3.5.x sind optional, sie werden oft zum Gruppieren von Objekten für Sicherheitsdefinitionen verwendet. Die Enterprise-Bean- und Webanwendungsabschnitte der Unternehmensanwendung zeigen auf ihre jeweiligen Einträge in anderen Abschnitten der xml-Datei. Jede Unternehmensanwendung wird verarbeitet, um eine J2EE-Anwendung mit demselben Namen zu erstellen. Die Enterprise-Bean- und Webanwendungseinträge werden als Zeiger auf die Definitionen der Enterprise-Beans und Webanwendungen verwendet. Die Einzeldaten dieser Einträge werden anschließend verwendet, um eine J2EE-Anwendung zu erstellen.
Für Enterprise-Bean-Dateien wird die Definition der JAR-Datei dazu verwendet, die erneut zu implementierenden JAR-Dateien zu finden und zur J2EE-Anwendung hinzuzufügen. Die Dokumentstammverzeichniseinträge der Webanwendung werden verwendet, um die in der Webanwendung verwendeten Ressourcen zu finden (HTML, JSP-Seiten usw.). Diese Dateien werden in die WAR-Datei innerhalb der J2EE-Anwendung kopiert. Die Klassenpfadeinträge der Webanwendung werden verwendet, um Servlets und JAR-Dateien zu finden, die in die WAR-Datei innerhalb der J2EE-Anwendung kopiert werden.
Unternehmensanwendungen werden während der Migration von Version 3.5.x erstellt. Sie werden als J2EE 1.2-kompatible Unternehmensanwendungen erstellt und enthalten Module der Stufe Servlet 2.2 und JSP 1.1. Dies bietet die direkteste Kompatibilität und ermöglicht die Interoperabilität mit früheren Versionen von WebSphere Application Server.
Das Sicherheitsberechtigungsmodell in Version 3.5.x basiert auf dem Konzept von Unternehmensanwendungen und Methodengruppen. Das übergreifende Produkt der Unternehmensanwendung und der Methodengruppen ist eine WebSphere Application Server-Berechtigung. Die J2EE-Spezifikation umfasst ein auf Berechtigungsklassen basierendes Berechtigungsmodell.
Wenn Sie vom Berechtigungsmodell von WebSphere Application Server Version 3.5.x in das auf Berechtigungsklassen basierende Berechtigungsmodell in Version 5 konvertieren wollen, erstellen die Migrationstools eine Eins-zu-Eins-Zuordnung zwischen einer WebSphere Application Server-Berechtigung und einer neuen Berechtigung unter dieser Anwendung. Daher erstellen die Migrationstools für jede Unternehmensanwendung und jede Methodengruppe in Version 3.5.x eine Berechtigungsklasse in Version 5, die im Implementierungsdeskriptor der J2EE-Anwendung enthalten ist. Die berechtigten Subjekte für jede Berechtigungsklasse sind in einer Berechtigungstabelle in der Bindung der J2EE-Anwendung enthalten.
Die J2EE-Spezifikation umfasst ein auf Berechtigungsklassen basierendes Berechtigungsmodell. WebSphere Application Server interpretiert die Berechtigungsklasse so, dass sie eine Reihe von Berechtigungen für den Zugriff auf eine Ressource darstellt. Wenn eine Enterprise-Bean-Methode aufgerufen wird, wird die Berechtigung für den Zugriff auf die Methode für eine bestimmte Bean von eine Methodenberechtigung angegeben. Diese Methodenberechtigung ist mindestens einer Berechtigungsklasse in der Bean-JAR-Datei zugeordnet.
Beim Zugriff auf Webressourcen wird die Berechtigung für den Zugriff auf eine Web-URI und den Aufruf einer HTTP-Methode für diese URI mittels Webressoucensammlungen und Sicherheitsbedingungen in der J2EE-Spezifikation angegeben. Der Implementierungsdeskriptor der WAR-Datei der Webanwendung enthält die Sicherheitsbedingungen und Webressourcensammlungen.
Version 5 führt Objekte der Stufe JSP 1.0 und 1.1 als JSP 1.2-Objekte aus; dies ist die einzige unterstützte Stufe.
Version 5 bietet keine Unterstützung für Servlet Redirector aus früheren Versionen. Die Migrationstools ignorieren diese Objekte.
Wenn die Version 3.5.x-Konfiguration das Servlet SimpleFileServlet definiert, wird das Servlet nicht migriert. Die Migrationstools setzen das Attribut FileServingEnabled in der Webmoduldatei ibm-web-ext.xmi auf true.
Wenn die Version 3.5-Konfiguration das Servlet InvokerServlet definiert, wird das Servlet nicht migriert. Die Migrationstools setzen das Attribut ServeServletsByClassnameEnabled in der Webmoduldatei ibm-web-ext.xml auf true.
Wenn die Version 3.5.x-Konfiguration das Servlet DefaultErrorReporter definiert, wird das Servlet in die Webmoduldatei web.xml migriert. Die Migration verwendet das neue Paket zum Festlegen des Klassennamens.
Der Standardtransporttype der Servlet-Steuerkomponente in Version 3.5.x ist Open Servlet Engine (OSE). Da Version 5 für OSE-Transport keine Unterstützung mehr bietet, ordnen die Migrationstools diese Transporte zu HTTP-Transporten zu und verwenden dabei dieselben Portzuordnungen. Sie müssen für jeden Port manuell Aliasnamenseinträge für VirtualHost hinzufügen.
Sie können administrative Konfigurationen mit dem Installationsassistenten oder manuell migrieren, wie in dieser Task beschrieben. Wenn Sie sich für die manuelle Migration entscheiden, wählen Sie nicht das Markierungsfeld für Migration Fenster des Installationsassistenten aus.
Wenn Sie eine frühere Version von WebSphere Application Server verwenden, ist es möglich, dass der Systemadministrator verschiedene Anwendungs- und Servereinstellungen für Ihre Umgebung optimiert hat. Es ist wichtig, dass Sie sich eine Strategie zurechtlegen, um diese Einstellungen mit möglichst hoher Effizienz und möglichst geringen Verlusten zu migrieren.
Sie können eine schrittweise manuelle Migration ausführen, indem Sie die Migrationstools mehrmals hintereinander aufrufen und jedes Mal eine andere Konfigurationsdatei angeben. Es können aus verschiedenen Gründen mehrere Konfigurationsdateien vorhanden sein. Unabhängig von diesen Gründen können Sie beim Migrieren von jeweils nur einer Konfigurationsdatei pro Schritt die Anwendungen schrittweise testen, bevor Sie mit der nächsten Konfigurationsdatei fortfahren.
Bevor Sie die Migrationstools verwenden, lesen Sie das Dokument mit den Release-Informationen zu V5.x, um sich einen Überblick über die für frühere Versionen erforderlichen Programmkorrekturen zu verschaffen. Wenn Sie Programmkorrekturen auf eine frühere Version anwenden, werden davon möglicherweise auch Dateien betroffen, die für die Migration von Bedeutung sind. Wenden Sie alle erforderlichen Programmkorrekturen an, um möglichst die effektivste Migration von Konfigurationen und Anwendungen zu erzielen.
Manuelle Migration bietet einen übersichtlicheren, schrittweisen Migrationsverlauf als die vom Installationsassistent ausgeführte vollständige Migration. IBM stellt eine Reihe von Migrationstools zur Verfügung, mit denen administrative Konfigurationen für das Produkt WebSphere Application Server - Express von einer beliebigen Version von V3.5.x oder V5.0.x ausgeführt werden können. Der gesamte Migrationsprozess umfasst das Speichern der aktuellen Konfiguration und der erforderlichen Dateien mit dem Migrationstool WASPreUpgrade, das Deinstallieren des früheren Releases, das Installieren des Produkts der Version 5 ohne Auswahl der Option für automatische Migration sowie das Wiederherstellen der Konfiguration aus dem früheren Release mit dem Migrationstool WASPostUpgrade.
Wählen Sie eines dieser Migrationsszenarios aus, um Informationen zur Migration von Konfigurationsdaten auf einen WebSphere Application Server-Basisknoten abzurufen:
Sie können die Migrationstools zum Migrieren von Konfigurationsdaten von Version 3.5 von WebSphere Application Server auf Version 5.1 von WebSphere Application Server - Express verwenden.
Sie würden in der Regel die Migrationstools WASPreUpgrade und WASPostUpgrade aus V5.1 von WebSphere Application Server zur Migration von V3.5 auf V5.1 auf derselben Maschine verwenden. Wenn Ihr Szenario die Migration einer V3.5-Konfiguration auf einer Maschine auf WebSphere Application Server - Express V5.1 auf einer anderen Maschine beinhaltet, verwenden Sie die alternative Prozedur, die in Migration von V3.5.x auf eine ferne V5.1-Maschine beschrieben ist.
In diesem Abschnitt wird beschrieben, wie Sie die V5.1-Migrationstools für folgende Migration verwenden:
Das Tool WASPreUpgrade speichert die vorhandene V3.5-Konfiguration in einem migrationsspezifischen Sicherungsverzeichnis migration-specific-backup. Das Tool WASPostUpgrade verwendet dieses Verzeichnis, um die alten Konfigurationseinstellungen zur neuen V5.1-Umgebung hinzuzufügen.
Schritte für diese Task
Auf dieser CD befindet sich ein Verzeichnis migration/bin. Dieses Verzeichnis enthält eine Sonderumgebung, die Sie zur Ausführung des Tools WASPreUpgrade verwenden können, ohne V5.1 zu installieren.
Speichern Sie die Konfiguration im Verzeichnis migration-specific-backup:
WASPreUpgrade /usr/tmp/migration-specific-backup /usr/websphere/appserver IhrKnotenname
Stellen Sie sicher, dass der Administrationsserver der vorhandenen Umgebung aktiv ist. Das Tool WASPreUpgrade gibt den Status auf den Bildschirm und in Protokolldateien im Verzeichnis migration-specific-backup aus. ASCII-Protokolldateinamen beginnen mit dem Text WASPreUpgrade und enthalten eine Datumszeitmarke.
Das Tool WASPreUpgrade speichert alle Dateien aus den folgenden Verzeichnissen der vorhandenen V3.5.x-Konfiguration im Sicherungsverzeichnis:
Das Tool WASPreUpgrade speichert die ausgewählten Dateien aus dem Verzeichnis /bin der V3.5.x. Es exportiert auch die vorhandene Application Server-Konfiguration aus dem Repository von V3.5.x. Das Tool WASPreUpgrade ruft XMLConfig auf, um das vorhandene V3.5-Repository in die Datei websphere_backup.xml im Verzeichnis migration-specific-backup zu exportieren.
Wenn während der Ausführung des Tools WASPreUpgrade Fehler auftreten, müssen Sie gegebenenfalls Programmkorrekturen auf die V3.5-Installation anwenden, um den Exportschritt erfolgreich abschließen zu können. Die neuesten, gegebenenfalls erforderlichen Programmkorrekturen finden Sie auf der Seite der IBM Unterstützungsfunktion. Wenn Sie diese Informationen über das InfoCenter ansehen, klicken Sie auf Support, um eine Verbindung zur Seite der IBM Unterstützungsfunktion herzustellen.
Wählen Sie die Migrationsoption nicht aus, falls sie angezeigt wird.
Überprüfen Sie nach jeder Verwendung von WASPostUpgrade die V5-Porteinstellungen in den folgenden beiden Dateien:
Wenn der Port BOOTSTRAP_ADDRESS der früheren Version 900 lautete, ordnet die Migration ihm dem Wert 7809 zu. Wenn der Port BOOTSTRAP_ADDRESS der früheren Version nicht 900 lautete, ordnet die Migration ihm in einer Migration der Advanced Edition den Wert server1 zu bzw. in einer Migration der Advanced Single Server Edition den tatsächlichen Servernamen.
Die Verarbeitung von WASPostUpgrade fügt die HTTP-Transportports der früheren Version zur Datei server.xml der Version 5 hinzu. Dies bedeutet, dass server1 doppelte HTTP-Transport-Portzuordnungen enthält, aus der Koexistenzanzeige und dem Standardserver der früheren Version.
Das Tool WASPostUpgrade migriert die V3.5.x-Konfigurationsdaten, die vom Tool WASPreUpgrade erstellt wurden, auf die Installation von V5.1. Da das V5.1-Produkt das J2EE-Programmiermodell beachtet und V3.5.x dies nicht tut, sind erhebliche Änderungen erforderlich, um die V3.5.x-Konfiguration auf eine V5.1-Installation anwenden zu können.
Das Tool WASPostUpgrade migriert keine Beispiele oder die Administrationskonsolenanwendung, da in V5.1 bereits Beispiele und eine Administrationskonsolenanwendung vorhanden sind.
Das Tool WASPostUpgrade zeichnet zu jeder Enterprise-Bean, die es implementiert, ausführliche Informationen in der Datei WASPostUpgrade.log auf.
Das Konfigurieren von WebSphere Application Server nach der Migration ist eine Möglichkeit, die Ergebnisse der Migrationstools zu überprüfen. Sie können auch während der Migration die Konfigurationszuordnung verwenden, um die Ergebnisse der Migration zu prüfen. Der Abschnitt enthält eine ausführliche Beschreibung, wie die Migrationstools Objekte migrieren und was Sie überprüfen sollten.
Sie können mit den Migrationstools eine manuelle Migration zwischen zwei Maschinen ausführen.
Sie würden in der Regel die Migrationstools WASPreUpgrade und WASPostUpgrade aus V5.1 von WebSphere Application Server - Express zur Migration von V3.5 auf V5.1 auf derselben Maschine verwenden.
Es gibt jedoch Situationen, in denen Sie die V3.5-Konfiguration auf einer Maschine auf V5.1 auf eine andere Maschine migrieren müssen. Eines dieser Szenarios ist das Installieren neuer Maschinen für Ihre neueste V5.1-Umgebung, wobei Sie die vorhandenen V3.5-Konfigurationen auf andere Maschinen migrieren müssen.
In diesem Abschnitt wird beschrieben, wie Sie die V5.1-Migrationstools für folgende Migration verwenden:
Das Tool WASPreUpgrade speichert die vorhandene V3.5-Konfiguration in einem migrationsspezifischen Sicherungsverzeichnis migration-specific-backup. Das Tool WASPostUpgrade verwendet dieses Verzeichnis, um die alten Konfigurationseinstellungen zur neuen V5.1-Umgebung hinzuzufügen.
Schritte für diese Task
Auf dieser CD befindet sich ein Verzeichnis migration/bin. Dieses Verzeichnis enthält eine Sonderumgebung, die Sie zur Ausführung des Tools WASPreUpgrade verwenden können, ohne V5.1 zu installieren.
Speichern Sie die Konfiguration im Verzeichnis migration-specific-backup:
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver adminKnotenname
Stellen Sie sicher, dass der Administrationsserver der vorhandenen Umgebung aktiv ist.
Das Tool WASPreUpgrade gibt den Status auf den Bildschirm und in Protokolldateien im Verzeichnis migration-specific-backup aus. ASCII-Protokolldateinamen beginnen mit dem Text WASPreUpgrade und enthalten eine Datumszeitmarke.
Das Tool WASPreUpgrade speichert die ausgewählten Dateien aus dem Verzeichnis /bin der V3.5.x. Es exportiert auch die vorhandene Application Server-Konfiguration aus dem Repository von V3.5.x. Das Tool WASPreUpgrade ruft XMLConfig auf, um das vorhandene V3.5-Repository in die Datei websphere_backup.xml im Verzeichnis migration-specific-backup zu exportieren.
Wenn während der Ausführung des Tools WASPreUpgrade Fehler auftreten, müssen Sie gegebenenfalls Programmkorrekturen auf die V3.5-Installation anwenden, um den Exportschritt erfolgreich abschließen zu können. Die neuesten, gegebenenfalls erforderlichen Programmkorrekturen finden Sie auf der Seite der IBM Unterstützungsfunktion. Wenn Sie diese Informationen über das InfoCenter ansehen, klicken Sie auf Support, um eine Verbindung zur Seite der IBM Unterstützungsfunktion herzustellen.
Verwenden Sie ftp, gemeinsam benutzten Speicher oder einen anderen Mechanismus, um die Datei auf die neue Maschine zu kopieren.
Führen Sie auf der Maschine mit V5.1 von WebSphere Application Server - Express die folgenden Schritte aus.
Sie müssen die Datei kopieren, da Sie das Original im nächsten Schritt bearbeiten.
Nehmen Sie an der Datei die folgenden Änderungen vor:
Wenn Sie denselben Knotennamen für die V5.1-Maschine verwenden, den Sie für die ursprüngliche V3.5-Konfiguration verwendet haben, müssen Sie den Namen nicht ändern. Andernfalls müssen Sie alle Vorkommen des V3.5-Knotennamens in den Knotennamen ändern, den Sie für WebSphere Application Server V5.1 verwenden. Der Knotenname kommt in vielen XML-Zeilengruppen in der gesamten Datei vor. Wenn Sie nicht alle Vorkommen ändern, ist die Migration der Daten nicht vollständig.
Die Konfigurationsdatei bezieht sich auf Pfadnamen in vielen XML-Zeilengruppen in der gesamten Datei. Ändern Sie alle Verweise auf eine Datei außerhalb der V3.5-Verzeichnisstruktur auf das entsprechende Verzeichnis auf der neuen Maschine, auch wenn Sie dieses Verzeichnis vielleicht erst erstellen müssten. Als Folge der Konfiguration einer übereinstimmenden Umgebung müssen Sie das Originalverzeichnis gegebenenfalls auf die V5.1-Maschine kopieren. Oder Sie müssen die entsprechende Software installieren.
Sie müssen die Pfadspezifikationen korrigieren, wenn Sie sich von den auf der V5.1-Maschine verwendeten Spezifikationen unterscheiden. Wenn Sie beispielsweise von V3.5 auf einer Windows-Plattform auf V5.1 auf einer Linux-Plattform migrieren, müssen Sie alle Windows-spezifischen Pfade in der Konfigurationsdatei so ändern, dass Sie dem Linux-Pfadstil entsprechen. Ändern Sie "c:\mystuff\somepath" in "/opt/mystuff/somepath".
Sie müssen Benutzer-IDs und Kennwörter ändern, wenn Sie nicht mit den auf der V5.1-Maschine verwendeten identisch sind.
Wenn Sie ein verschlüsseltes Kennwort in ein Klartextkennwort ändern wollen, ändern Sie <password>{xor}LCoxayht</password> in <password>mypassword</password>.
Die Konfiguration enthält eventuell Verweise auf andere Softwareprodukte oder Konfigurationen, die auf der neuen Maschine nicht vorhanden sind. Auf der alten Maschine könnte eventuell eine Datenbank vorhanden sein. Die V5.1-Konfiguration soll möglicherweise weiter auf die Datenbank auf der alten Maschine verweisen. Ändern Sie die Datenquelle, sodass sie auf die Datenquelle auf der V3.5-Maschine zeigt.
Verwenden Sie das Tool WASPostUpgrade im Verzeichnis AppServer/bin des V5.1-Installationsstammverzeichnisses, um die V3.5-Konfiguration zur V5.1-Konfiguration hinzuzufügen.
WASPostUpgrade /opt/tmp/migration-specific-backup
Das Tool WASPostUpgrade zeichnet zu jeder Enterprise-Bean, die es implementiert, ausführliche Informationen in der Datei /migration-specific-backup/WASPostUpgrade.log auf.
Sie können das V5.1-Installationsprogramm verwenden, um die Migration von WebSphere Application Server - Express V5.0.x auf V5.1 auszuführen.
Schritte für diese Task:
Verwenden Sie dazu das Script stopServer.sh (oder stopServer.bat) aus dem Verzeichnis AppServer/bin des Installationsstammverzeichnisses:
stopServer.sh server1
Sie können einen V5.0.x-Knoten migrieren, ohne ihn zu stoppen. Es ist zum Migrieren seiner Konfiguration jedoch nicht erforderlich, dass der Knoten aktiv ist. Die Migrationstools können alle Konfigurationsdaten abrufen, auch wenn der Knoten gestoppt wurde. Sie müssen den Knoten jedoch stoppen, bevor Sie den V5.1-Knoten starten, den Sie installieren. Sie können den Knoten jetzt stoppen.
Wählen Sie die Migrationsoption aus, wenn sie angezeigt wird.
Verwenden Sie das Tool für Erste Schritte (First Steps), wenn es am Ende der Produktinstallation angezeigt wird, oder führen Sie den Funktionstest für die Installation selbst aus, falls das Tool eventuell nicht angezeigt werden sollte.
Sie können den V5.0.x-Server nach Bedarf deinstallieren.
Sie können mit den Migrationstools eine Migration zwischen zwei Maschinen ausführen.
Vorbereitungen
Sie würden in der Regel die Migrationstools WASPreUpgrade und WASPostUpgrade aus V5.1 von WebSphere Application Server zur Migration von V5.0.x auf V5.1 auf derselben Maschine verwenden.
Es gibt jedoch Situationen, in denen Sie die V5.0.x-Konfiguration auf einer Maschine auf V5.1 auf eine andere Maschine migrieren müssen. Eines dieser Szenarios ist das Installieren neuer Maschinen für Ihre neueste V5.1-Umgebung, wobei Sie die vorhandenen V5.0.x-Konfigurationen auf andere Maschinen migrieren müssen.
Diese Task beschreibt, wie Sie die V5.1-Migrationstools zur Ausführung der Migration verwenden.
Das Tool WASPreUpgrade speichert die vorhandene V5.0.x-Konfiguration in einem migrationsspezifischen Sicherungsverzeichnis migration-specific-backup. Das Tool WASPostUpgrade verwendet dieses Verzeichnis, um die alten Konfigurationseinstellungen zur neuen V5.1-Umgebung hinzuzufügen.
Schritte für diese Task
Auf dieser CD befindet sich ein Verzeichnis migration/bin. Dieses Verzeichnis enthält eine Sonderumgebung, die Sie zur Ausführung des Tools WASPreUpgrade verwenden können, ohne V5.1 zu installieren.
Speichern Sie die Konfiguration im Verzeichnis migration-specific-backup:
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver
Das Tool WASPreUpgrade gibt den Status auf den Bildschirm und in Protokolldateien im Verzeichnis migration-specific-backup aus. ASCII-Protokolldateinamen beginnen mit dem Text "WASPreUpgrade" und enthalten eine Datumszeitmarke.
Verwenden Sie ftp, gemeinsam benutzten Speicher oder einen anderen Mechanismus, um die Datei auf die neue Maschine zu kopieren.
Verwenden Sie das Tool WASPostUpgrade im Verzeichnis AppServer/bin des V5.1-Installationsstammverzeichnisses, um die V5.0.x-Konfiguration zur V5.1-Konfiguration hinzuzufügen.
WASPostUpgrade /opt/tmp/migration-specific-backup
Das Tool WASPostUpgrade zeichnet zu jeder Enterprise-Bean, die es implementiert, ausführliche Informationen in der Datei /migration-specific-backup/WASPostUpgrade.log auf.
Nehmen Sie die folgenden Änderungen vor:
Sie müssen Benutzer-IDs und Kennwörter ändern, wenn Sie nicht mit den auf der V5.1-Maschine verwendeten identisch sind.
Die Konfiguration enthält eventuell Verweise auf andere Softwareprodukte oder Konfigurationen, die auf der neuen Maschine nicht vorhanden sind. Auf der alten Maschine könnte eventuell eine Datenbank vorhanden sein. Ändern Sie die Datenquelle, sodass sie auf die Datenquelle auf der alten Maschine zeigt.
Sie können ein Release einer früheren Version von WebSphere Application Server Version 3.5.x oder der Version 5.0.x migrieren, das auf einem Betriebssystem ausgeführt wird, das Version 5.1 nicht unterstützt.
Schritte für diese Task
Es stehen zwei Optionen zur Auswahl. Sie können den Befehl im Verzeichnis migration\bin (oder migration/bin) im plattformstammverzeichnis der Version 5.1-CD-ROM ausführen. Alternativ können Sie die Dateien aus dem Verzeichnis auf der CD-ROM in ein Verzeichnis auf Ihrem Festplattenlaufwerk kopieren.
Geben Sie das Release der Version 3.5.x oder 5.0.x an sowie ein Sicherungsverzeichnis, in dem der Befehl die Konfigurationsdateien und migrierten Anwendungen aus der früheren Version speichert. Informationen zur Befehlssyntax finden Sie im Abschnitt zu WASPreUpgrade.
Geben Sie das Sicherungsverzeichnis und die Position der Konfigurationsdateien an.
CD_Laufwerk\WASPreUpgrade sicherungsverzeichnis dateipfad\WebSphere\AppServer IhrKnotenname
Wenn dies funktioniert, fahren Sie mit Schritt 4 fort. Wenn dies nicht funktioniert, führen Sie die Schritte 2B bis 2F aus.
Ändern Sie die folgenden Variablen:
Geben Sie das Sicherungsverzeichnis und die Position der Konfigurationsdateien an.
IhrVerzeichnisMigration\WASPreUpgrade sicherungsverzeichnis dateipfad\WebSphere\AppServer IhrKnotenname
Falls möglich, verwenden Sie auch erneut den alten Systemnamen und die zugehörigen Kennwörter des alten Systems. Stellen Sie alle Datenbankdateien, die zu Anwendungen gehören, die Sie migrieren, wieder in denselben Pfad, wie auf dem alten System. Versuchen Sie allgemein, die gleichen Pfade zu verwenden. Installieren Sie jedoch nicht Version 5.1 in dem Verzeichnis der vorherigen Version. Wenn Sie Pfade und Namen ändern, können Sie die XML-Konfigurationsdateien bearbeiten, um die Änderungen entsprechend nachzuvollziehen. Nehmen Sie solche Änderungen vor, bevor Sie den nachfolgend angegebenen Befehl WASPostUpgrade ausführen.
Geben Sie das Sicherungsverzeichnis (und alle vom Standard abweichenden Konfigurationsdateinamen) in dem Verzeichnis an, das der Befehl WASPreUpgrade erstellte. Informationen zur Befehlssyntax finden Sie im Abschnitt zu WASPostUpgrade.
installationsstammverzeichnis\bin\WASPostUpgrade WAS_HOME\migration
Dieses Kapitel behandelt die folgenden Migrationsaspekte:
In IBM WebSphere Studio Site Developer Version 5.1.1 wurde eine neue Server Targeting-Funktion hinzugefügt.Diese Funktion ist standardmäßig deaktiviert. Sie müssen sie auf der Benutzervorgaben-Seite von J2EE mit Fenster > Benutzervorgaben > J2EE aktivieren. Details zur Server Targeting-Funktion finden Sie in der Produktdokumentation zu IBM WebSphere Studio Site Developer.Wenn die Funktion aktiviert ist, können Sie einen bestimmten Anwendungsserver ansteuern. Dieses Feature wurde zur Unterstützung von JDK 1.4 implementiert. JDK 1.4 ist dasJRE für WebSphere Application Server Version 5.1, das mit IBM WebSphere Studio Site Developer Version 5.1.1 ausgeliefert wird. J2EE-Projekte, welche die Server Targeting-Unterstützung nutzen, sind nicht abwärtskompatibel mit früheren Versionen von IBM WebSphere Studio Site Developer. Sie können daher nicht gemeinsam mit Benutzern früherer Versionen von IBM WebSphere Studio Site Developer (z.B. IBM WebSphere Studio Site Developer Version 5.1, IBM WebSphere Studio Site Developer Version 5.0.1) genutzt werden.IBM WebSphere Studio Site Developerbietet eine Möglichkeit, Abwärtskompatibilität zu erhalten, wenn dieses Feature aktiviert ist. Dieser Vorgang ist in "Abwärtskompatibilität mit aktivierter Server Targeting-Unterstützung" beschrieben. Der Grund für die Inkompatibilität ist, dass die Server Targeting-Funktion die Datei .classpath für ein J2EE-Projekt ändert und die neuen Einträge in .classpath nicht von älteren Versionen von WebSphere Application Server - Express erkannt werden können.
Wenn die Server Targeting-Unterstützung aktiviert ist, kann die Zielunterstützung von J2EE-Projekten rückgängig gemacht werden,so dass diese Projekte die Server Targeting-Unterstützung nicht nutzen. Dies kann mit Hilfe der Option No target server specified im Dialog Modify Target Server eingestellt werden. Der Dialog Modify Target Server kann vom Kontextmenü (Zielserver > Ändern) eines J2EE-Projekts im Ressourcennavigator oder in der Sicht J2EE Perspektive gestartet werden. Der Zielserver kann auch von der J2EE-Eigenschaftenseite (Eigenschaften > J2EE) für EAR-, EJB-, Anwendungsclient- und Connector-Projekte in No target server specified umgeändert werden.Für ein Webprojekt befindet sich die Einstellung für den Zielserver auf der Seite mit Webeigenschaften (Eigenschaften > WEB). Details zur Änderung der Server Targeting-Funktion finden Sie in der Dokumentation zu IBM WebSphere Studio Site Developer.Wenn die Option No target server specified ausgewählt wird, wird erneut die Darstellung der Datei .classpath verwendet, die mit älteren Versionen von IBM WebSphere Studio Site Developer kompatibel ist, und die Datei .server wird aus dem Projekt entfernt.
Aufgrund einer Änderung im JDK 1.4 muss der Benutzer ein Java-Paket angeben, wenn er mit Hilfe der Assistenten für Datenbank-Webseiten und JavaBeans-Webseiten Seiten generiert, die unter IBM WebSphere Studio Site Developer Version 5.1.1 ausgeführt werden. Dieses Problem tritt dann auf, wenn die View Bean-Schablone für den Assistenten für JavaBeans-Webseiten oder das IBM Database Access Java Beans-Master-Detailmuster verwendet wird. Dies gilt auch für Projekte mit Seiten und .java-Dateien, die zuvor ohne Angabe eines Pakets mit Hilfe dieser Assistenten generiert wurden. Versetzen Sie bei zuvor generiertem Code die .java-Dateien in ein Paket. Aktualisieren Sie dann die .jsp-Dateien, die Importanweisungen und die Klasseninformationen. Aktualisieren Sie in der Projektdatei web.xml den Servletklasseneintrag.
Dieses Kapitel behandelt die folgenden Migrationsaspekte:
IBM WebSphere Studio Site Developer Version 5.1.1 basiert auf der neuen Eclipse-Basis WebSphere Studio Workbench (WSWB) 2.1.2. Es bestehen einige Unterschiede zwischen den Versionen 2.1.2 und 2.0.3 bzw. 2.0.2. Um detaillierte Informationen zu den Unterschieden zu erhalten, lesen Sie die Readme-Datei, die sich im Verzeichnis WS_installationsverzeichnis\eclipse\readme befindet. Hierbei ist WS_installationsverzeichnis der Pfad, in dem Sie IBM WebSphere Studio Site Developer installiert haben.
IBM WebSphere Studio Site Developer Version 5.0 beruhte auf der Eclipse-Basis WSWB 2.0.2, und IBM WebSphere Studio Site Developer Version 5.0.1 beruhte auf der Eclipse-Basis WSWB 2.0.3.Es gibt zwischen den Versionen 2.0.2 und 2.0.3 keine bedeutenden Unterschiede. Das Release IBM WebSphere Studio Site Developer Version 5.0.1 war ein Update Manager-Fixpack, das beim Installieren IBM WebSphere Studio Site Developer Version 5.0 überlagerte.
Wenn IBM WebSphere Studio Site Developer Version 5.1.1 zum ersten Mal mit Hilfe eines vorhandenen Arbeitsbereichs von IBM WebSphere Studio Site Developer Version 5.0 gestartet wird, wird ein Dialogfenster angezeigt, das eine Möglichkeit der Migration von Version 5.0 beschreibt. Klicken Sie auf OK, um vom Arbeitsbereich der Version 5.0 zu migrieren, oder klicken Sie aufAbbruch, um das Starten von IBM WebSphere Studio Site Developer zu verhindern.
Wenn der Arbeitsbereich migriert wurde, können Sie weiterhin den Arbeitsbereich mit Version 5.0 verwenden, da die Metadaten der neuen Projektmerkmale ignoriert werden und von Version 5.0 gelesen werden können. Sie können in Version 5.0 keine Änderungen an den Projekten im Arbeitsbereich vornehmen, die Auswirkungen auf die Metadaten haben oder die Metadaten der neuen Projektmerkmale überschreiben könnten.
Die Migration der Java-Projekte von Version 5 oder Version 5.0.1 ist unkompliziert und geschieht automatisch. Sobald die Projekte in den Arbeitsbereich der Version 5.1.1 geladen sind, treten keine Änderungen an den Metadaten in den .classpath-Dateien oder den .project-Dateien auf, es sei denn, Sie versuchen, eine der in Version 5.1.1 verfügbaren neuen Funktionen zu verwenden.
Besondere Aufmerksamkeit ist erforderlich, wenn ein Projekt aus einem Team-Repository von Entwicklern mit Hilfe von IBM WebSphere Studio Site Developer Version 5 und IBM WebSphere Studio Site Developer Version 5.1.1 geladen und betrieben wird. Das allgemeine Problem besteht darin, dass das Vorhandensein, der Inhalt und die Interpretation von Metadatadateien in Arbeitsbereichen für eine bestimmte Funktion oder Plug-in-Version spezifisch sein können und sich in den einzelnen Versionen unterscheiden. Die Arbeitsbereichskompatibilität garantiert nur die wichtigsten Fälle, in denen alle Entwickler ihre Arbeitsbereiche von IBM WebSphere Studio Site Developer in Sperrschritten upgraden. In diesen Fällen sollten keine Probleme mit gemeinsam benutzten Metadaten auftreten. Wenn jedoch einige Entwickler in IBM WebSphere Studio Site Developer Version 5.1.1 und andere zur selben Zeit in IBM WebSphere Studio Site Developer Version 5 arbeiten, kann keine Garantie gegeben werden. Dieser Abschnitt bietet Ihnen Informationen dazu, wie Sie vorgehen bzw. nicht vorgehen können.
Der Benutzer von IBM WebSphere Studio Site Developer Version 5.1.1 erhält den typischen Störungsmodus.Die Version 5.1.1-Metadaten gehen verloren, wenn ein Benutzer der Version 5 Änderungen speichert und anschließend die aktualisierten Metadatendateien dem Repository übergibt. Nachfolgend sind einige Dinge aufgeführt, die zu Problemen führen können:
Nachfolgend finden Sie eine Liste mit Punkten, die zu beachten sind, wenn ein Projekt gemeinsam von Benutzern der IBM WebSphere Studio Site Developer Version 5.1.1 und Benutzern der Version 5 oder Version 5.0.1 benutzt werden soll:
Diese Unterstützung wurde in IBM WebSphere Studio Site Developer Version 5.1.1 hinzugefügt. Informationen zu verknüpften Ressourcen werden in der .project-Datei aufgezeichnet.
Empfehlung: Nicht verwenden. Am besten inaktivieren Sie die verknüpften Ressourcen über die Seite mit den Benutzervorgaben, wählen Sie hierzu Workbench > Verlinkte Ressourcen aus.
Informationen zum Erstellungsprogramm für externe Tools werden in der .project-Datei aufgezeichnet. Das Format der Informationen wurde zwischen Version 5 und Version 5.1.1 geändert. Erstellungsprogramme, die in Version 5.1.1 erstellt oder geändert wurden, verwenden das neue Format, das von einem Version 5-Arbeitsbereich nicht verstanden wird. Erstellungsprogramme, die in Version 5 erstellt wurden, verwenden das alte Format und sind in Version 5.1.1 funktionsfähig.
Empfehlung: Erstellen oder editieren Sie Erstellungsprogramme für externe Tools über einen Version 5-Arbeitsbereich.
Diese Unterstützung wurde hinzugefügt.Diese Informationen werden in der .classpath-Datei aufgezeichnet.
Empfehlung: Geben Sie keine Ausschlussmuster an. Am besten inaktivieren Sie die Ausschlussmuster über die Seite mit den Benutzervorgaben, wählen Sie hierzu Java > Compiler > Erstellungspfad aus.
Diese Unterstützung wurde hinzugefügt.Diese Informationen werden in der .classpath-Datei aufgezeichnet.
Empfehlung: Geben Sie im gesamten Projekt nichts anderes als den Standardausgabeordner ein. Am besten inaktivieren Sie die verschiedenen Ausgabepositionen über die Seite mit den Benutzervorgaben, wählen Sie hierzu Java > Compiler > Erstellungspfad aus.
Wenn Sie eine Quellen-ZIP-Datei an eine JAR-Bibliothek im Java-Erstellungspfad anhängen, wird das Quellenrootpfadpräfix automatisch gewonnen. Dies hat sich ab Version 5 geändert, wo das Präfix noch explizit mit der Benutzerschnittstelle festgelegt und explizit in der .classpath-Datei aufgezeichnet werden konnte. Folglich könnte ein Java-Projekt, das in einem 5.1.1-Arbeitsbereich erstellt wurde, nicht die angehängte Quelle finden.
Verwenden Sie Version 5, um den Stammverzeichnispfad für Quellenanhänge anzugeben. In Version 5.1.1 wird eine zusätzliche Flexibilität für Quellenanhänge zur Verfügung gestellt. Sie können einen Ordner anstelle einer JAR- oder ZIP-Datei als einen Quellenanhang bereitstellen, und Sie können eine Quelle an einen Klassendateiordner anhängen. Diese Funktionalität ist in Version 5 nicht verfügbar, dort werden die Version 5.1.1-Informationen ignoriert.
Die Verwendung der Klassenpfadcontainer durch PDEs wurde hinzugefügt. Klassenpfadcontainer werden in der .classpath-Datei aufgezeichnet. Wenn PDE-Klassenpfadcontainer verwendet werden, dann wird ein Version 5-Arbeitsbereich über unaufgelöste Klassenpfadeinträge verfügen und daher werden die meisten Java-Funktionen (einschließlich der Kompilierung, Suche, Ausführung und Fehlerbehebung) nicht die gewünschten Ergebnisse erzielen.
Empfehlung: Stellen Sie sicher, dass die Einstellung auf der Seite mit den Benutzervorgaben Plug-in-Entwicklung > Java-Erstellungspfadsteuerung für die Verwendung von Klassenpfadcontainern inaktiviert ist, bevor Sie neue Plug-in- oder Fragmentprojekte erstellen.
Die Ordnernamen lauten Java-Quelle und Webinhalt.Die Standardordnernamen für neue Webprojekte sind über eine Benutzervorgabenseite konfigurierbar, wählen Sie hierzu Fenster > Benutzervorgaben > Web-Tools > Neues Projekt aus.Die Standardnamen lauten jetztJava-Quelle und Webinhalt. Diese Standardnamen werden nur für neue Webprojekte verwendet. Webprojekte, die in Versionen vor diesem Release erstellt wurden, verwenden weiterhin die alten Namen. Dasselbe gilt für statische Webprojekte.
Wenn Sie sich dafür entscheiden, die Quellordnernamen für 4.0.x- und 5.0-Projekte in Version 5.1.1 zu ändern, verwenden Sie die Kontextmenüaktion Umbenennen in der Sicht "Navigator".Die Kontextmenüaktion Umbenennen benennt die Ordnernamen um und legt den Java-Erstellungspfad für die 4.0.x- und 5.0.x-Webprojekte fest.
Für den Java-Quellenordner JavaSource funktioniert die Kontextmenüaktion Umbenennen in den Sichten "Projektnavigator" und "Paket-Explorer".Für den Ordner Webinhalt funktioniert die Kontextmenüaktion Umbenennen in den Sichten "Ressourcennavigator" und "Projektnavigator".
Falls Sie ein Webprojekt aus einer Version vor diesem Release in einem SCM-Repository speichern und dann in dieses Release laden, behält dieses Projekt die alte Struktur mit dem Quellen- und dem Webanwendungsordner (source und webApplication) bei.Beide Strukturen werden korrekt erstellt.
Die Laufzeit der Struts-Tools wurde von Version 1.1 Beta 2 in Version 5 auf Version 1.1 heraufgesetzt. In IBM WebSphere Studio Site Developer Version 5 (General Availability) haben Sie die Option bei Erstellung eines Webprojekts, Ihrem Projekt die Struts-Unterstützung hinzuzufügen. Sie können zwischen Struts 1.0.2 oder Struts 1.1 Beta 2 auswählen. In IBM WebSphere Studio Site Developer Version 5.1.1 wurde die letzte Auswahlmöglichkeit durch Struts 1.1 ersetzt. Wenn Sie Webprojekte von Struts 1.1 Beta 2 in IBM WebSphere Studio Site Developer Version 5 erstellt haben, können Sie diese in Struts 1.1 konvertieren, dies ist aber nicht erforderlich, da Struts 1.1 Beta 2 noch unterstützt wird. Wenn Sie über Webprojekte von Struts 1.1 Beta 2 verfügen, die Sie in Struts 1.1 konvertieren wollen, müssen Sie hierzu wie folgt vorgehen:
Alle obigen Informationen gelten ebenfalls, wenn Sie ein Webprojekt von Struts 1.1 Beta 3 in IBM WebSphere Studio Site Developer Version 5.0.1 auf Struts 1.1 heraufsetzen.
Die Web-Service-Tools haben zwei neue Laufzeitprotokolle von IBM WebSphere Application Server Version 5.0.2 hinzugefügt, die nur unter WebSphere Application Server Version 5.0.2 laufen. Es sollte zu keiner obligatorischen Migration kommen, da IBM WebSphere Studio Site Developer Version 5.1.1 und WebSphere Application Server Version 5.0.2 sowohl die alten als auch die neuen Laufzeitprotokolle unterstützen. IBM WebSphere Studio Site Developer wird drei Laufzeitprotokolle der Web-Service-Artefakte generieren und implementieren: das alte Laufzeitprotokoll "IBM SOAP", das unter WebSphere Application Server Version 4.x und Version 5.x läuft, und das neue Laufzeitprotokoll "IBM WebSphere 5.0.2-Laufzeit", das nur unter WebSphere Application Server Version 5.0.2 läuft; und das neue Laufzeitprotokoll "Apache Axis 1.0", das nur unter WebSphere Application Server Version 5.0.2 läuft.
Benutzer sollten in der Lage sein, ihre auf Version 5-Projekte und Web-Services bezogenen EAR- und WAR-Dateien ohne Änderungen in Version 5.1.1 wiederzuverwenden. Damit sie ihre Web-Services und Clients auf das neue Laufzeitprotokoll von IBM WebSphere 5.0.2 konvertieren und die JSR 101, 109, WS-I and WS-Sicherheitsstandards nutzen können, müssen sie diese über den Assistenten "Web-Services" erneut generieren. Der Web-Services-Explorer fährt automatisch fort die Favoriten des Benutzers zu lesen, obwohl die physische Datendatei automatisch an eine neue Speicherposition versetzt wird.
Wenn Sie einen Arbeitsbereich von Version 5 migrieren, dann erhalten Sie eine Fehlernachricht "Beim Wiederherstellen der Workbench sind Fehler aufgetreten". Diese Nachricht wird angezeigt, wenn die Perspektive "Profilermittlung" während der Migration geöffnet ist und wenn die Sichten "Informationen zum Heapspeicher" oder "Exemplarstatistik" in der Perspektive "Profilermittlung" sichtbar waren. Das kommt daher, weil die Sichten "Informationen zum Heapspeicher" und "Exemplarstatistik", die in Version 5 vorkamen, entfernt worden sind. Diese Nachricht wird auch angezeigt, wenn die Perspektive "Profilermittlung" während der Migration im Arbeitsbereich geöffnet ist. Die Fehlernachricht kann bedenkenlos ignoriert werden, indem Sie auf OK klicken.
Um eine in Version 5 erstellte, angepasste Schablone zu verwenden, sollten Sie die angepasste Schablone laden, die Verbindung zwischen ihr und der Datenbank wiederherstellen und sie speichern. Wenn Sie die gespeicherte angepasste Schablone das nächste Mal erneut laden, wird die Verbindung geprüft.
Die generierten J2EE 1.2-Artefakte, die in diesem Release erstellt wurden, können unter Umständen von IBM WebSphere Studio Site Developer Version 4.0.3 nicht gelesen und von Testumgebungen der Version 4.0.3 nicht ausgeführt werden. Da der Schablonenassistent nicht mit Version 4.0.3 ausgeliefert wurde, wird für diese Version keine Abwärtskompatibilität bereitgestellt.
Schablonenanwendungen, die in diesem Release generiert wurden, können unter Version 5 ausgeführt werden, wenn in den Benutzervorgaben der Webprojekte der Java-Quellenordner "Java Source" und der Webinhaltsordner "Web Content" genannt wird.
Das folgende Kapitel behandelt die Migration von IBM WebSphere Studio Site Developer Version 4.0.x auf Version 5. .
Es gibt zwei unterstützte Methoden, mit denen Sie Ihre Projekte von IBM WebSphere Studio Site Developer Version 4.0.x auf Version 5 migrieren können. Diese beiden Methoden werden im Folgenden ausführlich beschrieben.
Beachten Sie, dass durch die Migration von Version 4 auf Version 5 nicht automatisch die J2EE-Stufe von Projekten geändert wird, da Version 5 noch immer Erstellungs- und Deploymentoperationen für WebSphere Application Server Version 4 durchführen kann. Alle J2EE-Projekttypen, einschließlich der Webprojekte, können mit Hilfe des J2EE-Migrationsassistenten migriert werden, der in IBM WebSphere Studio Site Developer verfügbar ist. Wenn Sie auf den J2EE-Migrationsassistenten zugreifen möchten, klicken Sie mit der rechten Maustaste auf ein Projekt des Typs J2EE, und wählen Sie anschließend Migrieren > J2EE-Migrationsassistent aus.
Die folgende Liste enthält einen Ausschnitt der Funktionserweiterungen, die seit Version 4.0.x aufgenommen wurden:
Das WebSphere-InfoCenter [www.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/index.html] enthält folgende Informationen:
Migrating to WebSphere V5.0 An End-to-End Migration Guide stellt eine nützliche Informationsquelle für die Migration von Version 3.5 und Version 4.0 auf Version 5 dar [www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246910.pdf].
Auf der Seite mit den Downloads für WebSphere Application Server [www14.software.ibm.com/webapp/download/product.jsp?s=p&id=TDUN-49EVRT& type=s&dt=DIAGNOSTIC+TOOL] finden Sie Tools, die Sie bei der Konvertierung von Anwendungen unterstützen:
Wenn Ihre Projekte Schleifenabhängigkeiten aufweisen, meldet Version 5 einen Erstellungsfehler. In diesem Fall können Sie die Optionen Fenster > Benutzervorgaben > Java > Compiler auswählen und dann auf der Registerkarte Erstellungspfad das Markierungsfeld Erstellung bei Erstellungspfadfehlern abbrechen abwählen. Beachten Sie, dass die Erstellung dadurch nicht mehr gestoppt wird, jedoch ein oder mehrere Schleifenabhängigkeitsfehler bei der Erstellung noch immer auftreten, die in der Sicht "Tasks" angezeigt werden (selbst dann, wenn die Erstellung ansonsten erfolgreich verläuft). In diesem Fall können Sie diese Fehler in Warnungen ändern, indem Sie die Registerkarte Andere auswählen und dann die Vorgabe in der Dropdown-Liste Schleifenabhängigkeiten ändern.
In IBM WebSphere Studio Site Developer Version 5 gibt es Änderungen der internen Projektstruktur gegenüber Version 4.0.3. Eine J2EE 1.2-Web-WAR aus Version 5 kann, wenn sie mit Java-Quelle exportiert wird, in IBM WebSphere Studio Site Developer Version 4 importiert werden. Der Quellcodeordner wird automatisch in den richtigen Namen umgewandelt und problemlos erstellt. Das Webprojekt wird in WebSphere Application Server Version 4 genauso ordnungsgemäß ausgeführt, wie wenn ein Projekt aus Version 4 in Version 5 importiert wird, da der Name des Quellcodeordners automatisch in den richtigen Namen umgewandelt wird. Weitere Informationen zum Ändern von Ordnernamen finden Sie im Abschnitt "Strukturen von Webprojekten in IBM WebSphere Studio Site Developer".
Die interne Webprojektstruktur in IBM WebSphere Studio Site Developer Version 5 unterscheidet sich von IBM WebSphere Studio Site Developer Version 4.0.x. Dieser Unterschied ist nicht auf die Abweichungen zwischen J2EE 1.2 und J2EE 1.3 zurückzuführen, sondern beruht auf einer Änderung, die die Benutzerfreundlichkeit des Tools verbessert.
In Version 4 waren Webprojekte standardmäßig dynamische Webprojekte und wurden in der Sicht "Navigator" mit einem Quellenordner (source) und einem Webanwendungsordner (webApplication) angezeigt. Wenn Sie in Version 5 ein dynamisches Webprojekt erstellen, dann wird es anstatt des Quellenordners (source) mit einem Java-Quellenordner (Java Source) und anstatt des Webanwendungsordners (webApplication) mit einem Webinhaltsordner (Web Content) anzeigt.
Falls Sie jedoch ein Webprojekt aus Version 4 in einem SCM-Repository speichern und dann in Version 5 laden, behält dieses Projekt die alte Struktur mit dem Quellen- und dem Webanwendungsordner (source und webApplication) bei.Beide Strukturen werden in Version 5 korrekt erstellt.
In Version 5 können Sie sowohl statische als auch dynamische Webprojekte erstellen.
Statische Webprojekte enthalten nur statische Ressourcen wie HTML, Java-Scripts, Images, Text usw., aber keinen dynamischen Inhalt. Statische Webprojekte können von einem traditionellen HTTP-Web-Server ausgeführt und bedient werden; sie benötigen keinen Webanwendungsserver.
Dynamische Webprojekte enthalten neben den statischen Ressourcen noch dynamische J2EE-Ressourcen, wie z. B. Servlets, JSPs, Filter und zugeordnete Metadaten. Wenn Sie dynamische Webprojekte erstellen, können Sie gestaffelte Formatvorlagen und JSP-Tagbibliotheken mit einschließen, so dass Sie die Entwicklung mit einem umfangreicheren Satz Projektressourcen beginnen können. Dynamische Webprojekte sind immer in Unternehmensanwendungsprojekten eingebettet und werden nur auf Webanwendungsservern ausgeführt.
Diese Methode wird beim Versetzen von Arbeitsbereichen aus Version 4.0.x in IBM WebSphere Studio Site Developer Version 5 empfohlen, denn nur diese Methode migriert alle Daten inklusive der Informationen zum Projekterstellungspfad.
Tipp: In Version 4 war das Arbeitsbereichsverzeichnis standardmäßig ein Unterverzeichnis des Installationsverzeichnisses. In Version 5 wurde diese Standardeinstellung in ein Arbeitsbereichsverzeichnis (workspace) geändert, das sich im Verzeichnis "Eigene Dateien" (My Documents) befindet. Wenn Sie die Speicherposition für Ihre Arbeit überschreiben wollen, verwenden Sie hierzu beim Starten der Workbench die Option -data des Befehls .
Für ClearCase: Verwenden Sie einen leeren Arbeitsbereich von Version 5, und wählen Sie dann für jedes zu ladende Projekt Datei > Importieren > Vorhandenes WebSphere Studio 4.x-ClearCase-Projekt in Arbeitsbereich aus.
Hinweise für das Vorgehen nach der Migration:
Das Projekt wurde nicht erstellt, da es sich in einem Zyklus befindet oder da es Probleme mit dem Klassenpfad hat. Fehlender erforderlicher Quellenordner: /MyHomePageExample403/source.
EAR-IBM Anwendungserweiterungsdateien und Serverkonfigurationsdateien von Version 4 haben absolute Pfadverweise enthalten. Nach der Migration dieser Dateien auf Version 5 müssen Sie sie mit ihrem Editor öffnen (dadurch werden ihre alten absoluten Pfadverweise in neue relative Verweise geändert).
Die IBM Erweiterungsdatei enthält veraltete absolute Pfade. Dies kann automatisch korrigiert werden und sollte gespeichert werden. Diese Operation entfernt die Pfade aus der Datei und muss lediglich einmal ausgeführt werden. Soll die automatische Korrektur ausgeführt werden?
SCM-Plug-ins für IBM WebSphere Studio Site Developer werden auch von anderen SCM-Lieferanten zur Verfügung gestellt. Eine Liste aller Lieferanten finden Sie unter www.ibm.com/software/ad/studioappdev/partners/scm.html. Im Rahmen der Validierung Ready for IBM WebSphere Studio Software [www.developer.ibm.com/websphere/ready.html] haben alle SCM-Lieferanten, die ein Plug-in für Version 4 bereitgestellt haben, versichert, dass die vorstehend beschriebenen Migrationsschritte (Speichern aus Version 4 im SCM-Repository, Laden aus dem Repository in Version 5) auch bei ihren Systemen verwendet werden können.
Diese Methode wird teilweise unterstützt und führt zu einer unvollständigen Migration. Einstellungen für die Benutzerschnittstelle, Debugeinstellungen und die meisten Benutzervorgaben gehen hierbei verloren. Projektnamen, Projektquellendateien und Java-Projekterstellungspfade (Klassenpfade) bleiben zwar erhalten, aber die Erhaltung weiterer Daten kann nicht garantiert werden. Diese Methode sollte nur dann verwendet werden, wenn kein unterstütztes SCM-System eingesetzt wird und eine Beibehaltung der Informationen zum Projekterstellungspfad von wesentlicher Bedeutung ist (diese Informationen gehen verloren, wenn Sie Projekte importieren, die aus Version 4 exportiert wurden). Sie können den vorhandenen Arbeitsbereich aus Version 4.0.x verwenden, indem Sie folgendermaßen vorgehen:
Die Anweisungen zur Vorgehensweise nach der Migration, wie sie in Absolute Pfadverweise für EAR und Serverkonfiguration nach der Migration entfernen beschrieben sind, gelten auch hier.
Die folgenden Probleme können auftreten, wenn Sie versuchen, die Migration durch das Öffnen eines Arbeitsbereichs aus Version 4.0 in IBM WebSphere Studio Site Developer Version 5 vorzunehmen.
Mit den folgenden Schritten können Sie die Klassenpfadvariable JRE_LIB auf eine gültige Position zurücksetzen. Führen Sie dies auch dann durch, wenn der Wert beim ersten Öffnen des Fensters "Benutzervorgaben" korrekt zu sein schien.
Wenn Sie diesen Arbeitsschritt nicht ausführen, ist der Wert für JRE_LIB möglicherweise falsch, was viele Erstellungsfehler in Java-Dateien verursachen kann.
Als allgemeine Prüfmaßnahme sollten Sie die Werte aller Klassenpfadvariablen überprüfen.
Die Teamunterstützung wurde von Eclipse 1.0 auf Eclipse 2.0 in wesentlichen Punkten geändert. Auch die Methode für die gemeinsame Benutzung von Projekten über das Repository hat sich geändert.
In der Standardeinstellung werden Projekte im Arbeitsbereichsverzeichnis erstellt. Falls Sie die Standardeinstellung überschrieben und Projekte in anderen Positionen erstellt haben, müssen Sie alle Ihre Projekte öffnen, bevor Sie die Workbench schließen. Hierdurch kann die Datei .project für ein solches Projekt in die richtige Position geschrieben werden. Wenn Sie ein geschlossenes Projekt, dessen Verzeichnis nicht zum Arbeitsbereich gehört, nicht öffnen, entsteht ein Projekt, dass das eigentliche Projekt maskiert und das lediglich eine Datei .project enthält.
Sie müssen alle vorhandenen JSP-Unterbrechungspunkte entfernen und im migrierten Arbeitsbereich von Version 5 zurücksetzen.
Gehen Sie folgendermaßen vor, um relationale Daten von Projekten in IBM WebSphere Studio Site Developer 4.0.3 zu migrieren:
Die Artefakte der relationalen Daten werden wiederhergestellt.
Wenn Sie eine Web-Servicedatei von 4.0.x importiert haben, erhalten Sie möglicherweise folgende Fehlernachrichten:
Error The part 'result' has an invalid value 'anyElement' defined for its type. Type declarations must refer to valid values defined in a schema. (Fehler Für den Typ der Komponente 'result' ist ein ungültiger Wert 'anyElement' definiert. Typendeklarationen müssen sich auf gültige Werte beziehen, die in einem Schema definiert sind.) Error The part 'return' has an invalid value 'findPatientResult' defined for its element. (Fehler Für das Element der Komponente 'return' ist ein ungültiger Wert 'findPatientResult' definiert.) Element declarations must refer to valid values defined in a schema. (Elementdeklarationen müssen sich auf gültige Werte beziehen, die in einem Schema definiert sind.) Error The part 'response' has an invalid value 'findPatientResponse' defined for its element. (Fehler Für das Element der Komponente 'response' ist ein ungültiger Wert 'findPatientResponse' definiert.) Element declarations must refer to valid values defined in a schema. (Elementdeklarationen müssen sich auf gültige Werte beziehen, die in einem Schema definiert sind.)
Die Abhilfemaßnahme ist:
Um auf den J2EE-Migrationsassistenten in Version 5 zuzugreifen, führen Sie die folgenden Schritte aus:
Dieses Kapitel dokumentiert, wie Sie eine Migration von WebSphere Studio Version 4.0 (sowohl Advanced als auch Professional Edition) auf IBM WebSphere Studio Site Developer vornehmen. Die Migration von WebSphere Studio "Classic" Version 4.0 auf IBM WebSphere Studio Site Developer Version 5.0 umfasst die folgenden Schritte:
Die Komponente für die erweiterte Publikation (Zuordnung von Dateien zu Publikationsphasen) sowie die Komponente Page Detailer (Analyse von Webseiten) von WebSphere Studio "Classic" sind in IBM WebSphere Studio Site Developer nicht verfügbar. Einige andere Komponenten vom CD-Datenträgerpack von Version 4.0.x sind ebenfalls nicht mehr verfügbar. Dazu gehören beispielsweise die Komponente Page Detailer für die Analyse von Webdateien, die Komponente HotMedia(R) für speicherintensive Datenträgertypen, der XML-Editor Voice (jetzt in WebSphere Everyplace(TM) Toolkit und Portal Toolkit enthalten) sowie DataBaseWizard für Einheiten für Pervasive Computing.
Bitte beachten Sie die folgenden Einschränkungen, bevor Sie Daten aus WebSphere Studio migrieren:
Während des im Folgenden beschriebenen Migrationsprozesses erstellt WebSphere Studio eine JAR-Datei für einen Einzelserver, die alle Projektdateien, Publikationsangaben und Quelleninformationen enthält. Alle in der Sicht Publikation für den Standardserver angezeigten Dateien werden in der JAR-Datei gepackt. Sie können anschließend die JAR-Datei in IBM WebSphere Studio Site Developer importieren.
Wenn Sie vorhandene Projekte migrieren, gehen während der Migration alle Projekt- und Phaseninformationen dafür verloren. Falls Ihre Umgebung mit mehreren Servern arbeitet, bleiben nur die Dateien erhalten, die auf dem Standardserver publiziert wurden. Daher müssen Sie für die Migration eine neue Umgebung erstellen, die nur einen Server verwendet.
Falls Ihre aktuelle Umgebung mit mehreren Server arbeitet, können Sie auf die folgende Weise eine neue Umgebung mit dem Namen "Migration" erstellen, die nur einen Server verwendet:
Der Standardname der Deskriptordatei für die Webkonfiguration (serverName_web.xml) lautet im vorliegenden Szenario localhost_web.xml. Sofern Sie keine andere Position angeben, wird die Datei .xml im Verzeichnis WEB-INF gespeichert.
Jetzt können Sie Ihre Anwendung testen. Zum Testen der Anwendung auf dem Standardtestserver führen Sie die folgenden Schritte aus:
Informationen zum Testen Ihrer Anwendung in anderen Serverlaufzeitumgebungen finden Sie im Onlinehilfetext für die Komponente "Servertools".
Dieses Kapitel erläutert die Migration von VisualAge(R) für Java Professional Edition oder VisualAge für Java Enterprise Edition auf IBM WebSphere Studio Site Developer.
Der IBM Business Partner Instantiations, Inc. vertreibt ein Produkt
namens CodePro Studio, das Produktivitätserweiterungen für VisualAge für Java
und WebSphere Application Server - Express bereitstellt, darunter auch
Funktionen für Migration und Koexistenz. Damit Kunden, die VisualAge
für Java verwenden, mit der Migration beginnen können, bietet Instantiations
im Rahmen seiner zeitbegrenzten Probeversion von CodePro Studio die
Exportfunktion von VisualAge für Java nach IBM WebSphere Studio Site Developer
kostenlos und ohne Verwendungsbegrenzung an. Diese Probeversion können
Sie unter der Adresse www.instantiations.com/vaj-migrate
herunterladen. Weitere Informationen zur erweiterten
Koexistenzunterstützung sowie zur erweiterten Migrationsunterstützung von
Instantiations (inklusive vollständige bidirektionale Dateiexporte und
-importe, Erstellung von Export-/Importgruppen, Projektsynchronisierung und
Taskautomatisierung) finden Sie bei Instantiations, Inc. unter www.instantiations.com/codepro/ws.
Die folgende Liste enthält einen Ausschnitt der Änderungen seit VisualAge für Java:
Die folgenden Schritte skizzieren die Migration von VisualAge für Java. Details zu diesen Schritten finden Sie im weiteren Verlauf dieses Kapitels.
Die zusammengefasste Migration aller versionierten Projekte und Ressourcen aus dem Repository von VisualAge für Java wird nicht unterstützt. Sie können lediglich Projekte und Ressourcen migrieren, die sich im Arbeitsbereich von VisualAge für Java befinden. Wenn Sie die versionierte Kopie eines Projekts oder einer Ressource auf IBM WebSphere Studio Site Developer migrieren wollen, müssen Sie sie in den Arbeitsbereich von VisualAge für Java stellen und anschließend migrieren.
So können Sie Ihre Projekte in eine JAR-Datei exportieren:
Starten Sie IBM WebSphere Studio Site Developer, und erstellen Sie anschließend die entsprechenden Projekte. Die folgenden Angaben sind allgemeine Migrationsrichtlinien, die Ihnen bei der Entscheidung helfen, in welchen Projekttyp von IBM WebSphere Studio Site Developer Sie Ihre Dateien importieren sollten:
Falls Ihre Anwendung Servlets verwendet, müssen Sie die URL-Zuordnungen für die Servlets in der Datei web.xml definieren. Hierzu gehen Sie folgendermaßen vor:
Die folgenden Einstellungen von VisualAge für Java müssen Sie notieren und in IBM WebSphere Studio Site Developer konfigurieren:
Projektklassenpfad
In VisualAge für Java legen Sie den Projektklassenpfad auf der Seite Ressourcen des Fensters Optionen fest (Fenster > Optionen > Ressourcen). Nachdem Sie Ihre Projekte auf IBM WebSphere Studio Site Developer migriert haben, können Sie den Klassenpfad eines Projekts im Fenster Eigenschaften des Projekts festlegen. (Klicken Sie hierzu mit der rechten Maustaste auf das Projekt, und wählen Sie Eigenschaften > Java-Erstellungspfad aus.) Klicken Sie dann auf die Registerkarte Bibliotheken.) Sie können auch Klassenpfadvariablen im Fenster Benutzervorgaben festlegen (Fenster > Benutzervorgaben > Java > Klassenpfadvariablen.)
Ressourcenzuordnungen
Wenn Sie eine Zuordnung zwischen einem Dateityp und einer ausführbaren Datei definieren, können Sie eine Datei, die sich außerhalb der Workbench befindet, aus der Workbench heraus öffnen.
In VisualAge für Java legen Sie die Ressourcenzuordnungen im Fenster Optionen fest (Fenster > Optionen > Ressourcen > Ressourcenzuordnungen). Nachdem Sie die Ressourcendateien auf IBM WebSphere Studio Site Developer migriert haben, können Sie die Ressourcenzuordnungen im Fenster Benutzervorgaben definieren (Fenster > Benutzervorgaben > Workbench > Dateizuordnungen).
Codeformatierungsprogramm
In VisualAge für Java legen Sie Ihre Codeformatierungsoptionen auf der Seite Formatierungsprogramm des Fensters Optionen fest (Fenster > Optionen > Codierung > Formatierungsprogramm). Nachdem Sie Ihren Code auf IBM WebSphere Studio Site Developer migriert haben, können Sie die Codeformatierung im Fenster Benutzervorgaben definieren (Fenster > Benutzervorgaben > Java > Codeformatierungsprogramm).
WTE-Konfiguration
In VisualAge für Java sind die Laufzeiteinstellungen für die WebSphere-Einheitentestumgebung und für WebSphere Application Server in unterschiedlichen Dateien des folgenden Verzeichnisses gespeichert: VisualAge-Installationsverzeichnis\ide\project_resources\IBM WebSphere Test Environment\properties. Die Variable VisualAge-Installationsverzeichnis steht für das von Ihnen verwendete Produktinstallationsverzeichnis.
Falls Sie beispielsweise in der Eigenschaftendatei session.xml das erneute Schreiben der URL aktiviert haben, indem Sie die Eigenschaft durch die Angabe <url-rewriting-enabled>true</url-rewriting-enabled> auf "true" gesetzt haben, können Sie diese Eigenschaft in der Testumgebung von IBM WebSphere Studio Site Developer Version 4.0 konfigurieren. (Öffnen Sie in der Perspektive Server die Sicht Serverkonfiguration, klicken Sie mit der rechten Maustaste auf den gewünschten Server, und klicken Sie auf Öffnen. Klicken Sie auf die Registerkarte Web, und wählen Sie das Markierungsfeld Erneutes Schreiben der URL aktivieren aus.)
Java-Dateien und Projektressourcendateien
Die Eigenschaftendatei default.servlet_engine enthält das Stammverzeichnis für den Kontext (im Format <root-uri>) der Webanwendungen von VisualAge für Java. Beim Erstellen eines Webprojekts in IBM WebSphere Studio Site Developer enthält der Dialog Webprojekt erstellen ein Feld Stammverzeichnis für Kontext für diese Daten.
Webanwendungseinstellungen in Dateien wie VisualAgeInstallationsverzeichnis\ide\project_resources\IBM WebSphere Test Environment\hosts\default_host\default_app\servlets\default_app.webapp, die Sie selbst angepasst haben, sollten auf die Datei Ihr_Webprojekt\Web Content\WEB-INF\web.xml in IBM WebSphere Studio Site Developer migriert werden. Wenn Sie beispielsweise Servletnamen und Servletpfade in der Datei default_app.webapp geändert haben, müssen Sie die entsprechenden Änderungen auch in der Datei web.xml vornehmen.
Wenn es sich bei der Anwendung um ein Java-Projekt handelt, verwenden Sie zum Testen die normale Unterstützung Ausführen oder Debug für Java-Projekte von IBM WebSphere Studio Site Developer.
Verwendet die Anwendung WebSphere Application Server , verwendet Sie zum testen den integrierten WebSphere Application Server. Hierzu muss ein Standardtestserver erstellt und gestartet werden. Bei einem Webprojekt klicken Sie mit der rechten Maustaste auf die HTML-Hauptseite, und wählen Sie die Option Auf Server ausführen aus, um den Web-Browser zu starten.
Informationen zum Testen anderer Projekttypen finden Sie in der Onlinehilfe.
Wenn Sie WebSphere Application Server als Laufzeitumgebung verwenden, implementieren Sie Ihre Anwendung mit der Komponente "Server-Tools" von IBM WebSphere Studio Site Developer.
IBM WebSphere Studio Site Developer-Projekte (und ihre zugeordneten Einstellungen) können von Entwicklern gemeinsam benutzt werden. Hierzu speichern Sie ein Projekt im SCM-Server von IBM WebSphere Studio Site Developer. Anschließend extrahieren Sie es unter IBM WebSphere Studio Site Developer für ein anderes Teammitglied.
Informationen zur Teamunterstützung in IBM WebSphere Studio Site Developer Version 4.0 finden Sie unter www.ibm.com/websphere/developer/library/techarticles/0108_karasiuk/0108_karasiuk.html
Informationen zur Teamunterstützung in IBM WebSphere Studio Site Developer finden Sie außerdem im Installationshandbuch und in der Onlinehilfefunktion.
Dieses Kapitel enthält Anweisungen für die Migration von Anwendungen, die mit der Funktion "Visual Composition Editor" von VisualAge für Java erstellt wurden, auf Visual Editor für Java in WebSphere Application Server - Express:
Dieser Schritt ist optional, wird jedoch aus den folgenden Gründen sehr empfohlen (insbesondere dann, wenn Ihre Anwendung über Verbindungen verfügt).
Gehen Sie wie folgt vor, um die erweiterten Metadateninformationen vor der Migration zu speichern:
Ihre Klassen können jetzt in WebSphere Application Server - Expressimportiert werden. Lesen Sie die vorhergehenden Abschnitte in Kapitel 7, "Migration von VisualAge für Java auf IBM WebSphere Studio Site Developer". Nachdem die früheren Quellenprogramme aus Visual Composition Editor in WebSphere Application Server - Express importiert wurden, können Sie sie mit Visual Editor für Java verwalten.
Dieses Kapitel behandelt die folgenden Migrationsaspekte:
Eine ausführliche Erläuterung der involvierten Elemente können Sie im Artikel J2EE Class Loading Demystified (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer.html) (J2EE-Module und Klassenpfade) sowie zur Entwicklung von J2EE-Dienstprogramm-JARs (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer2.html) (Java-JARs in J2EE-Modulen) nachlesen. Diese Artikel vermitteln auf hervorragende Weise den technischen Hintergrund und liefern wertvolle Ratschläge.
Die empfohlene Methode für die Verwendung einer Dritthersteller-JAR in einem Webprojekt ist das Importieren der JAR (unter ihrer Beibehaltung als JAR-Datei) in den Bibliotheksordner des Webprojekts. Dies ist der einzige portierbare, von J2EE definierte Weg für die Verwendung einer JAR-Datei. Er stellt sicher, dass bei der Implementierung auf einem anderen Server keine Änderungen vorgenommen werden müssen.
Mit den folgenden Schritten können Sie eine externe JAR-Datei in einem einzelnen Webprojekt verwenden. Wenn Sie die JAR-Datei in mehreren Webprojekten verwenden wollen, führen Sie stattdessen die unter "Empfohlene Methode für die Verwendung von Dritthersteller-JARs mit mehreren Webprojekten" beschriebenen Schritte aus. .
Die empfohlene Methode für die Verwendung einer Dritthersteller-JAR in zwei oder mehreren Webprojekten ist das Importieren der JAR (unter ihrer Beibehaltung als JAR-Datei) in das Unternehmensanwendungsprojekt (EAR). Dies ist der einzige portierbare, von J2EE definierte Weg für die Verwendung einer JAR-Datei. Er stellt sicher, dass bei der Implementierung auf einem anderen Server keine Änderungen vorgenommen werden müssen.
Mit den folgenden Schritten können Sie eine externe JAR-Datei in mehreren Webprojekten verwenden. Wenn Sie die JAR-Datei nur in einem einzelnen Webprojekt verwenden wollen, führen Sie die im vorangegangenen Abschnitt beschriebenen Schritte aus.
Sie können die JAR-Datei auch außerhalb von WebSphere Application Server - Express belassen und sie sowohl zum Java-Erstellungspfad als auch zum Klassenpfad des Serverexemplars hinzufügen. Diese Vorgehensweise ist jedoch nicht zu empfehlen, weil das Portieren der Anwendung in diesem Fall schwierig ist. Wenn Sie auf einen anderen Server wechseln, müssen Sie immer den Klassenpfad des Servers aktualisieren. Außerdem müssen Sie sicherstellen, dass Ihre Klassendateien keine Konflikte mit anderen Versionen ähnlicher Klassendateien verursachen, die bereits im Klassenpfad des Servers vorhanden sind und durch den Server oder dessen andere Anwendungen benötigt werden. Sollten Sie sich dennoch für diese Methode entscheiden, führen Sie die folgenden Schritte aus:
WebSphere Application Server - Express enthält eine leistungsstarke Komponente für die automatische Erstellung, die die Erstellungsleistung bei komplexen Erstellungen für mehrere Projekte herabsetzen kann. Es gibt eine Reihe von Möglichkeiten, diese automatischen Erstellungen zu steuern (abhängige Dateien, aktive und inaktive Projekte sowie Projekte im Quellen- oder JAR-Format), aber diese Optionen können relativ kompliziert werden. Der folgende Artikel erläutert diese Optionen und zeigt, wie Sie die Erstellungsleistung optimieren können. Lesen Sie den Artikel "Optimizing Multi-Project Builds Using dependent Project JARs in WebSphere Studio Application Developer" in der WebSphere-Entwicklerdomäne (www.ibm.com/websphere/developer/library/techarticles/0204_searle/searle.html).
Wenn Sie Ant mit WebSphere Application Server - Express verwenden, können Sie die Produktionserstellungen automatisieren. Es gibt einen mehrteiligen Artikel, der die folgenden Aspekte erläutert:
Den entsprechenden Artikel Using Ant with WebSphere Studio Application Developer finden Sie in der WebSphere-Entwicklerdomäne unter www.ibm.com/websphere/developer/library/techarticles/0203_searle/searle1.html.
In diesem Kapitel können Sie anhand von Migrationsbeispielen mehr über die Migration von VisualAge für Java und WebSphere Studio "Classic" auf WebSphere Application Server - Express IBM WebSphere Studio Site Developer erfahren.
Beschreibung
Das Beispiel FindTheLeapYears wird mit VisualAge für Java Version 4.0 zur Verfügung gestellt. Informationen zu diesem Beispiel finden Sie in der Onlinehilfe von VisualAge für Java (Beispiele > Entwicklungsumgebung für JSP/Servlet).
Migrationsübersicht
Bitte führen Sie die unten angegebenen Schritte für die Migration des Beispiels aus VisualAge für Java auf IBM WebSphere Studio Site Developer aus.Diese Schritte werden später noch ausführlich erläutert:
Importieren Sie folgendermaßen die Java-Quellendateien in das Quellenverzeichnis des Projekts LeapYear:
Importieren Sie die Ressourcendateien wie folgt in das Projekt "LeapYear" unter dem Webinhaltsverzeichnis WebContent:
Nun müssen Sie alle Anwendungsänderungen vornehmen, die auf Grund der leicht geänderten Quellen-/Anwendungsstruktur erforderlich sind.
Jetzt wurde das Beispiel auf IBM WebSphere Studio Site Developer migriert. Sie müssen nur noch ein Serverprojekt in IBM WebSphere Studio Site Developer erstellen und das Beispiel in der WebSphere-Testumgebung testen.
Jetzt müssen Sie das EAR-Projekt in der Serverkonfiguration angeben:
Beschreibung
Bei diesem Beispiel müssen Sie WebSphere Studio "Classic" Version 4.0.x verwenden.
Sie arbeiten in diesem Fall mit dem Beispiel YourCo. Auf dieses Beispiel greifen Sie durch Öffnen der Onlinehilfe zu (Hilfe > WebSphere Studio 4.0 > Vorgehensweise > Mit Beispielen arbeiten > Übersicht). Zum Laden des Beispiels befolgen Sie die Anweisungen unter Studio-Beispiele öffnen (für WebSphere Application Server 4.0), und laden Sie die Datei YourCo.war.
Vorbereitungen
Migrationsschritte
Zur Migration dieses Beispiels aus WebSphere Studio "Classic" auf IBM WebSphere Studio Site Developer müssen Sie die folgenden Schritte ausführen. Jeder Schritt wird später noch detailliert erläutert.
(Optional) Normalerweise erstellen Sie bei einer Migration eine neue Umgebung. Für das vorliegende Beispiel verwenden Sie jedoch die Testumgebung, die Bestandteil von WebSphere Studio "Classic" ist. Dank der Testumgebung müssen Sie viele Servletzuordnungen in Schritt 8 nicht manuell bearbeiten.
Informationen zur Erstellung einer neuen Umgebung für die Migration finden Sie im Kapitel "Migration von WebSphere Studio "Classic" auf IBM WebSphere Studio Site Developer".
a. com.ibm.db erfordert databeans.jar, b. com.ibm.webtools.runtime erfordert webtlsrn.jar, c. com.ibm.ejs.ns.jndi erfordert ns.jar, d. com.ibm.webshpere.advanced.cm.factory erfordert cm.jar, e. com.ibm.ejs.models.base.extensions.webappext.ServletExtensions erfordert ws-base-extensions.jar
Zur Behebung dieses Fehlers müssen Sie den Java-Erstellungspfad für das Webprojekt ändern.
Jetzt wurde das Beispiel auf IBM WebSphere Studio Site Developer migriert. Sie müssen nur noch ein Serverprojekt in IBM WebSphere Studio Site Developer erstellen und das Beispiel in der WebSphere-Testumgebung testen.
Jetzt müssen Sie das EAR-Projekt in der Serverkonfiguration angeben:
Aktuelle Informationen zur Migration und zu anderen Themen finden Sie unter www.ibm.com/websphere/developer/zones/studio/transition.html.
Die folgenden Veröffentlichungen und Webseiten bieten allgemeine Informationen, die bei der Arbeit mit WebSphere Application Server - Express hilfreich sein können:
Weitere interessante Literatur:
Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschen Markt angeboten werden. Möglicherweise bietet IBM die in diesem Dokument beschriebenen Produkte, Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Dienstleistungen von IBM verwendet werden können. Anstelle der IBM Produkte, Programme oder Dienstleistungen können auch andere ihnen äquivalente Produkte, Programme oder Dienstleistungen verwendet werden, solange diese keine gewerblichen Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb von Fremdprodukten, Fremdprogrammen und Fremdservices liegt beim Kunden.
Für in diesem Dokument beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieses Dokuments ist keine Lizenzierung dieser Patente verbunden. Lizenzanfragen sind schriftlich und auf Englisch an folgende Adresse zu richten:
IBM Europe
Director of Licensing
92066 Paris La Defense
Cedex,
France
Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in diesem Handbuch werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen bzw. neuen Editionen der Veröffentlichung bekannt gegeben. IBM kann jederzeit ohne vorherige Ankündigung Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.
Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen mit der Zielsetzung: (i) den Austausch von Informationen zwischen unabhängigen, erstellten Programmen und anderen Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse:
Lab Director
IBM Canada Ltd. Laboratory
8200 Warden Avenue
Markham, Ontario, Canada L6G 1C7
Die Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.
Die Lieferung des im Handbuch aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt im Rahmen der IBM Kundenvereinbarung, in der internationalen IBM Vereinbarung für Programmlizenzen oder einer äquivalenten Vereinbarung.
Informationen über Produkte anderer Hersteller als IBM wurden von den Herstellern dieser Produkte zur Verfügung gestellt bzw. aus von ihnen veröffentlichten Ankündigungen oder anderen öffentlich zugänglichen Quellen entnommen. IBM hat diese Produkte nicht getestet und übernimmt im Hinblick auf Produkte anderer Hersteller keine Verantwortung für einwandfreie Funktion, Kompatibilität oder andere Ansprüche. Fragen hinsichtlich des Leistungsspektrums von Produkten anderer Hersteller als IBM sind an den jeweiligen Hersteller des Produkts zu richten.
Verweise in dieser Veröffentlichung auf Websites anderer Anbieter dienen lediglich als Benutzerinformationen und stellen keinerlei Billigung des Inhalts dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites geschieht auf eigene Verantwortung.
Diese Veröffentlichung enthält Beispiele für Daten und Berichte des täglichen Geschäftsablaufes. Sie sollen nur die Funktionen des Lizenzprogrammes illustrieren; sie können Namen von Personen, Firmen, Marken oder Produkten enthalten. Alle diese Namen sind frei erfunden, Ähnlichkeiten mit tatsächlichen Namen und Adressen sind rein zufällig.
COPYRIGHT-LIZENZ:
Diese Veröffentlichung enthält Beispielanwendungsprogramme, die in Quellensprache geschrieben sind. Sie dürfen diese Beispielprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, verwenden, vermarkten oder zu verteilen, die mit der Anwendungsprogrammierschnittstelle konform sind, für die diese Beispielprogramme geschrieben werden. Diese Beispielprogramme wurden nicht unter allen denkbaren Bedingungen getestet. Die in diesem Handbuch aufgeführten Beispiele sollen lediglich der Veranschaulichung und zu keinem anderen Zweck dienen. Sie dürfen diese Beispielprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, verwenden, vermarkten oder zu verteilen, die mit der IBM Anwendungsprogrammierschnittstelle konform sind, für die diese Beispielprogramme geschrieben werden.
Kopien oder Teile der Beispielprogramme bzw. daraus abgeleiteter Code müssen folgenden Copyrightvermerk beinhalten:
(C) (Name Ihrer Firma) (Jahr). Teile des vorliegenden Codes wurden
aus Beispielprogrammen der IBM Corp. abgeleitet.
(C) Copyright
IBM Corp. 2000, 2003. All rights reserved.
(C) Copyright IBM
Deutschland 2000, 2003. Alle Rechte vorbehalten.
Diese Informationen sollen Ihnen bei der Erstellung von Programmen unter Verwendung dieses Produkts helfen.
Allgemeine Programmierschnittstellen ermöglichen es Ihnen, Programme zu schreiben, die die Services der Tools dieses Programms verwenden.
Diese Informationen dokumentieren möglicherweise auch Informationen zur Diagnose, Modifizierung und Anpassung. Solche Informationen sollen Ihnen beim Debugging Ihrer Programme helfen.
Achtung: Verwenden Sie die Informationen zur Diagnose, Modifizierung und Anpassung nicht als Programmierschnittstelle, da sie ständig Änderungen unterliegen.
Die folgenden Namen sind in gewissen Ländern Marken oder eingetragene Marken der International Business Machines Corporation:
Java und alle Java-basierten Marken und Logos sind in gewissen Ländern Marken oder eingetragene Marken von Sun Microsystems, Inc.
ActiveX, Microsoft, Windows, Windows NT und das Windows-Logo sind in gewissen Ländern Marken oder eingetragene Marken der Microsoft Corporation.
UNIX ist eine eingetragene Marke von The Open Group.
Andere Unternehmens-, Produkt- und Dienstleistungsnamen, die durch doppelte Sterne (**) gekennzeichnet sind, können Marken oder Dienstleistungsmarken anderer Unternehmen sein.