Einleitung / Module: Umstellung (Migration)

Module auf Isolated Mode umstellen

Inhaltsverzeichnis

Bestehende kundenspezifische Module können einfach Schritt für Schritt auf den Isolated Mode umgestellt werden.

Zu Informationen, wie ein bestehende FirstSpirit-Server auf den Isolated Mode umgestellt werden kann, siehe Seite Server: Installation und Umstellung.

1) Nicht-isolierte Ressourcen ermitteln

Zunächst sollte in bestehenden Modulen ermittelt werden, ob es nicht-isolierte Ressourcen gibt und welche das sind. Dazu kann das Tool „FSM Checker“ verwendet werden (für Zugangsdaten wenden Sie sich bitte an den Technical Support).
Der FSM Checker zeigt alle Abhängigkeiten des Moduls an, wobei zwischen internen Abhängigkeiten (zu FirstSpirit-Klassen) und externen Abhängigkeiten (Klassen, die weder im Modul noch in FirstSpirit enthalten sind) unterschieden wird. Die internen Abhängigkeiten werden darüber hinaus nach verschiedenen Kriterien bewertet (z. B im Isolated Mode nicht verfügbar, Nutzung von deprecated API, Nutzung von internen Klassen, die sich nicht in der API befinden usw.).

Alle benötigten Bibliotheken müssen dem Modul hinzugefügt werden.

2) Kompatibilität herstellen (module-isolated.xml)

Module, die auf den Isolated Mode umgestellt werden, sollten vorübergehend in beiden Modi betrieben werden können: legacy und isolated.
Im Legacy mode kann das umzustellende Modul bereits betrieben werden, hier sind keine Änderungen erforderlich.
Damit das Modul auch im Isolated Mode betrieben werden kann, sollten die zusätzlich erforderlichen Ressourcen (Bibliotheken) dem Modul hinzugefügt werden.

Zusätzlich zur Datei

module.xml

soll eine Datei

module-isolated.xml

vorhanden sein. Siehe dazu auch Kapitel Der Modul-Deskriptor (→Entwicklerhandbuch für Komponenten).

In dieser Datei sollten die Ressourcen definiert sein, die für den Isolated Mode erforderlich sind. Dazu kann die Datei module.xml kopiert und dann umbenannt und angepasst werden.

Enthält ein Modul diese beiden xml-Dateien, kann es sowohl auf FirstSpirit-Server betrieben werden, die noch im Legacy mode, als auch auf FirstSpirit-Servern, die bereits im Isolated Mode betrieben werden (siehe dazu Seite Server: Installation und Umstellung): Wird der Server im Isolated Mode betrieben, wird die Datei module-isolated.xml berücksichtigt, läuft der Server im Legacy Mode, wird die Datei module.xml berücksichtigt. Ist keine module-isolated.xml-Datei vorhanden, wird als Fallback auch im Isolated Mode die Datei module.xml verwendet.

3) Attribut "name" beibehalten

Der Name des legacy Moduls muss auch für das Isolated Modul verwendet werden (Attribut name). Nur dann ist gewährleistet, dass das Modul sauber von älteren Versionen aktualisiert werden kann. Eine Änderung des Attributs name würde dazu führen, dass das geänderte Modul zusätzlich zu dem vorhandenen installiert wird, anstatt dieses zu ersetzen.

4) Unterscheidung per "displayname"

Es wird empfohlen, über das Attribut displayname anzugeben, auf welchem Server-Typ das betreffende Modul betrieben werden kann:

  • (L): Das Modul kann nur auf Servern verwendet werden, die im Legacy mode betrieben werden.
  • (I): Das Modul kann nur auf Servern verwendet werden, die im Isolated mode betrieben werden.
  • (I, L): Das Modul kann sowohl auf Legacy- als auch auf Isolated-Servern verwendet werden.

Beispiel:

...
<module>
<name>MyModuleName</name>
<displayname>Module XYZ (I, L)</displayname>
<description>Module supported in legacy and isolated mode</description>
...
</module>

5) Isolated Mode für Ressourcen aktivieren (Attribut "mode")

Damit ein Modul im Isolated Mode betrieben werden kann, muss das Attribut mode für die gewünschten Ressourcen des Moduls definiert werden, und zwar mit dem Wert isolated.

Beispiel:

<module>
...
<resources>
<resource name="..." version="..." scope="..." mode="isolated">lib/isolated.jar</resource>
</resources>
</module>

6) Webanwendungen

Im Unterschied zum FirstSpirit-Server kann auf dem Application Server der Zugriff auf die im Isolated Mode „abgeschirmten“ Funktionalitäten nicht gesteuert werden. Das bedeutet: Alle Module, die Webanwendungen verwenden, haben bei einer Verwendung auf einem Isolated Server keinen Zugriff mehr auf Bibliotheken, die Bestandteil der FirstSpirit Webanwendung waren (siehe Abbildung unten). Damit stehen ad hoc eine ganze Reihe von Klassen nicht mehr zur Verfügung.

Beispiel: Das Modul nutzt Funktionen der Apache Commons Logging API für das Logging innerhalb einer Webanwendung. Im Legacy mode ist diese Bibliothek Bestandteil der Datei fs-webrt.jar. Das bedeutet, die entsprechenden Klassen können innerhalb der Modulimplementierung direkt verwendet werden, ohne dass der Modulentwickler diese Bibliothek dem Modul hinzufügen muss.

Im Isolated Mode ist dies nicht mehr ohne Weiteres möglich, da keine Möglichkeit zum Zugriff auf die Bibliothek mehr besteht („Shading“). In diesem Fall müssen die entsprechenden Bibliotheken als web-resource mitgebracht werden, indem sie in der Datei module-isolated.xml entsprechend hinzugefügt werden.

7) Verwendung

Wurde das Modul anschließend neu erstellt, kann es wie gewohnt über den FirstSpirit ServerManager installiert bzw. aktualisiert werden.

Während des Deployments einer Webanwendung (→Entwicklerhandbuch für Komponenten) werden alle im Modul definierten Ressourcen anhand deren Namen mit denen anderer Komponenten abgeglichen und Duplikate wie für den Parameter version beschrieben herausgefiltert. Werden bei dieser Prüfung Konflikte erkannt, wird das Ausrollen der Webanwendung mit einem entsprechenden Fehler abgebrochen.

Hinweis: Zum Erstellen eines Moduls sollte das FirstSpirit-Module-Gradle-Plugin verwendet werden.

© 2005 - 2024 Crownpeak Technology GmbH | Alle Rechte vorbehalten. | FirstSpirit 2024.4 | Datenschutz