Wenn Sie eine Migration von einer Version vor Version 7 durchführen,
können Sie das Migrationstool von EGL Version 7.0 verwenden, um eine direkte Migration auf Version 7.5 durchzuführen.
Migration von Version 7.5 und späteren Versionen
Für den Wechsel von
Version 7.5 auf Version 8.0 müssen Sie kein Migrationstool ausführen. Beachten Sie jedoch die folgenden Hinweise
auf mögliche Probleme:
- Die Verzeichnisstruktur für Projekte wurde in Version 8 geändert.
In Version 8.0 speichert EGL den generierten Java-Code im neuen Verzeichnis
EGLGen/JavaSource in der höchste Ebene der Projektverzeichnisstruktur. EGL aktualisiert diesen Code bei jeder Generierung; dies schließt auch das Klicken auf
ein.
Verwenden Sie das 'JavaSource'-Verzeichnis der höchste Ebene für Java-Code, den Sie manuell geändert haben;
der Befehl Bereinigen nimmt in diesem Verzeichnis keine Änderungen vor.
Bei Rich UI-Projekten wird keine Vorgabe für den Generierungsmodus mehr verwendet,
um zu bestimmen, ob die Generierung zu Debuggingzwecken oder für die Laufzeitverwendung erfolgt. Stattdessen werden beide Codetypen automatisch in den Verzeichnissen
EGLGen/JavaScript/Debug und EGLGen/JavaScript/Target generiert.
Wenn Sie die Verzeichnisstruktur von Version 7 beibehalten, kann das Projekt in Version 8 normal
verwendet werden. Wenn Sie die Verzeichnisstruktur auf die neue Struktur von Version 8 aktualisieren,
kann das Projekt in Version 7 nicht mehr verwendet werden.
Aufgrund dieser Änderung werden Entwickler in der Regel
separate Projekte für die Java™-Generierung erstellen,
die dann zu einem einzelnen implementierten Projekt zusammengefügt werden. Wenn diese Projekte übergreifende Abhängigkeiten aufweisen, müssen Sie möglicherweise den
Java-Buildpfad ändern. Weitere Information finden Sie in Java-Buildpfad.
- Für Rational Business Developer Version 8 ist
Java 5 oder höher erforderlich;
weitere Informationen hierzu finden Sie in "Hinweise zu Java in
Rational Business Developer Version 8"
im vorliegenden Abschnitt.
- Der nicht deklarierte EGL-Typ NUMBER weist eine neue interne Darstellung
bei der Generierung für JavaScript auf.
In den meisten Fällen ist keine Aktion erforderlich, da das EGL-Standardverhalten bedeutet,
dass JavaScript automatisch neu erstellt wird,
wenn die EGL-Dateien zum ersten Mal in Version 8 importiert werden. Wenn Sie die Vorgabe
Nach Build generieren für JavaScript
inaktiviert haben, müssen Sie alle JavaScript-Dateien,
die den Typ NUMBER aufweisen, manuell generieren, bevor Sie sie in Version 8 verwenden.
Weitere Informationen finden Sie in Nicht deklarierte Typen
und Benutzervorgaben für die Generierung festlegen.
- Das bewährte Verfahren beim Wechsel zu einer neuen Version ist die Erstellung eines neuen Arbeitsbereichs.
- Wenn Sie EGL Rich UI verwenden und die Widgetbibliotheken beim Wechsel zu Version 8 nicht aktualisieren,
müssen Sie mögliche Kompatibilitätsprobleme beachten.
Weitere Informationen finden Sie in "Bekannte Kompatibilität in Widgetbibliotheken" im vorliegenden Abschnitt.
Hinweise zu Java
in Rational Business Developer Version 8
Für Version 8 ist
Java 5 (auch als Version 1.5.0 bezeichnet) oder eine höhere Version erforderlich. Diese Anforderung stellt ein Upgrade gegenüber Version 7 dar, in der
Java Version 1.4.0 erforderlich war. Version 8 enthält Java Runtime Environment (JRE)
für Java 6.
Diese JRE ist vollständig kompatibel mit dem in früheren EGL-Versionen generierten Code,
sodass Sie Ihre vorhandenen EGL-Programme nicht aufgrund der neuen JRE neu generieren müssen.
Wenn Sie EGL verwenden, können Sie Ihre Java-Batchprogramme
und den Tomcat-Server in der JRE ausführen, die mit dem Produkt installiert wurde.
Sie können diese Batchprogramme auch in jeder anderen auf dem System installierten
JRE ab Java Version 5 ausführen, mit Ausnahme der
JRE für WebSphere Application Server.
Diese JRE wird ausschließlich zusammen mit diesem Produkt verwendet. Sie benötigen darüber hinaus eine JRE für die Ausführung von generiertem Code, den Sie außerhalb von EGL oder
WebSphere Application Server implementieren.
Hierfür können Sie jede beliebige JRE ab Java Version 5 verwenden.
In den meisten Fällen verursacht die Änderung keine Probleme. Besteht jedoch eine Verpflichtung hinsichtlich Java 1.4
als Unternehmensstandard, führen Sie keine Migration auf Version 8 durch.
Bekannte Kompatibilität in Widgetbibliotheken
Das bewährte Verfahren
beim Versetzen von Rich UI-Projekten nach Version 8 ist die Aktualisierung der Widgetbibliotheken
für diese Projekte auf die neuesten Versionen. Anweisungen zum Importieren dieser Projekte finden Sie in Vom Produkt bereitgestellte Projekte importieren.
Wenn Sie Widgetbibliotheken aus einem älteren Release verwenden möchten,
müssen Sie beachten, dass nur bestimmte Bibliothekskombinationen getestet wurden. Die folgende Tabelle zeigt die Versionen der Widgetbibliotheken, deren Kompatibilität bekannt ist. Andere Kombinationen sind möglich, es kann jedoch nicht garantiert werden, dass
sie effizient zusammen verwendet werden können.
Tabelle 1. Widgetbibliotheken mit bekannter Kompatibilität| Produktversion |
Rich UI-Widgets |
Dojo-Widgets |
Dojo-Laufzeit |
| 8.0 |
2.0.0 |
1.0.0 |
1.5 |
| 7.5.1.5 |
1.0.3 |
0.8.0* |
1.4 |
| 7.5.1.4 |
1.0.2 |
0.7.1* |
1.3.2 |
| 7.5.1.3 |
1.0.1 |
nicht zutreffend |
nicht zutreffend |
| 7.5.1.2 und früher |
1.0.0 |
nicht zutreffend |
nicht zutreffend |
* Keine offizielle Unterstützung;
über das EGL Café verteilt.
Migration von Version 7.1 bis (aber nicht einschließlich) Version 7.5
Beim Starten des Produkts werden alle Projekte überprüft, um festzustellen, ob
eine Migration erforderlich ist. Diese Überprüfung findet auch statt, wenn Sie ein Projekt importieren oder
aus einem Quellcodemanager auschecken. Falls eine Migration erforderlich ist, zeigt der Arbeitsbereich eine Nachricht an
und Sie können die jeweiligen Projekte und Ressourcen für die Migration auswählen.
Bei der Migration von EGL Version 7.1 auf Version 7.5 gelten die folgenden Anforderungen
hinsichtlich der für die Codeänderungen benötigten Dateien bzw. Projekte:
- Für die 'ExternalType'-Funktionsparameter ist der Änderungswert in erforderlich.
- Der Pfad für die Apache-JAR-Dateien wurde geändert.
- BIRT-Berichtsdateien benötigen ICU4J-Unterstützung
(ICU4J = International Components for Unicode for Java).
Migration von Version 7.0 bis (aber nicht einschließlich) Version 7.1
Für die Migration von Version 7.0 auf 7.1 ist kein Programm zur Automatisierung vorhanden;
in den meisten Fällen ist keine Migration erforderlich. In zwei Fällen ist eine Migration erforderlich:
- Wenn Sie Formulare verwenden und eine Migration auf Version 7 durchgeführt haben,
müssen Sie vor der Ausführung von Version 7.1 den Code ändern. Da EGL Version 7 keine Formulare unterstützt, haben die meisten Benutzer keine Migration auf diese Version durchgeführt.
Nehmen Sie die folgenden Änderungen vor, um Formulare von EGL Version 7 auf Version 7.1 zu migrieren:
- Fügen Sie den Operator @ zu allen Eigenschaften
printFloatingArea und screenFloatingArea hinzu.
- Fügen Sie alle komplexen Eigenschaften @printFloatingArea
für ein Formular in die neue Eigenschaft printFloatingAreas ein.
- Fügen Sie alle komplexen Eigenschaften @screenFloatingArea
für ein Formular in die neue Eigenschaft screenFloatingAreas ein.
- Wenn Sie mit einem Webprojekt arbeiten, das für eine der Versionen von 7.0 bis 7.0.0.3 generiert wurde
und dessen Code in WebSphere Application Server
ausgeführt wird und auf Web-Services aller Plattformen zugreift, müssen Sie das Projekt ändern.
Wenn das Projekt auf einem Server ausgeführt werden soll, bei dem es sich nicht um
WebSphere Application Server handelt,
ist keine Änderung erforderlich.
Gehen Sie wie folgt vor, um ein Webprojekt, das
WebSphere Application Server verwendet, von
EGL Version 7.0 auf Version 7.1 zu migrieren:
- Ändern Sie das Klassenladeprogramm für die WAR-Datei in der zugehörigen EAR-Datei in PARENT_FIRST:
- Klicken Sie doppelt auf den Implementierungsdeskriptor ProjektnameEAR
im Stammverzeichnis des Webprojekts; dabei gibt Projektname den Namen des Projekts an. Bei diesem Implementierungsdeskriptor handelt es sich um einen J2EE-Implementierungsdeskriptor,
nicht um einen EGL-Implementierungsdeskriptor.
- Klicken Sie im Editor für den Implementierungsdeskriptor auf
die Registerkarte Implementierung.
- Suchen Sie nach dem Abschnitt für Anwendungen im unteren Bereich der Implementierungsseite.
- Wählen Sie in der Liste Anwendungen die WAR-Datei aus, die das Webprojekt darstellt.
- Wählen Sie in der Liste Modus des Klassenladeprogramms
die Option PARENT_FIRST aus.
- Speichern und schließen Sie den Implementierungsdeskriptor.
- Öffnen Sie die Ressourcenperspektive und entfernen Sie die folgenden JAR-Dateien
aus dem Verzeichnis Projektname/WebContent/WEB-INF/lib:
- axis.jar
- commons-discovery-0.2.jar
- commons-logging-1.0.4.jar
- eglwsdl.jar
- jaxrpc.jar
- saaj.jar
- wsdl4j-1.5.1.jar
- Um sicherzustellen, dass für die Builddeskriptoroption 'ServerType' die korrekte Version von
WebSphere Application Server festgelegt ist,
generieren Sie das Projekt neu.
Wenn Sie eine COBOL-Quelle oder Rich UI-Projekte migrieren,
müssen Sie möglicherweise weitere Änderungen vornehmen. Details finden Sie in "Migration von COBOL auf EGL" und in "Migration für Rich UI-Projekte".