Einleitung / Modulentwicklung "Isolated"

Modulentwicklung "Isolated"

Inhaltsverzeichnis

Wenn man ein Modul neu entwickelt, sollte es auch den Anforderungen des „Isolated Mode“ entsprechen. Wir empfehlen, zur Modul-Entwicklung Gradle mit dem FirstSpirit-Module-Plugin einzusetzen, da es einem viel Arbeit abnimmt - insbesondere das Erstellen und die im Folgenden beschriebenen Anpassungen der module-isolated.xml.

Modul-Namensschema

Es ist sinnvoll ein Namensschema zu entwickeln, mit dem Module und Modul-Komponenten benannt werden. Durch die Namen muss Eindeutigkeit innerhalb eines FirstSpirit-Servers gewährleistet werden. Außerdem entstehen basierend auf den Namen auch Verzeichnisse, die lesbar sein sollten.

Generelle Empfehlung

  • Kleinschreibung
  • Keine Leerzeichen
  • Trennung mit Bindestrich
  • ggf. Präfix für Produkt-Familien (im Beispiel: mpl und xxx)
  • Modul-Name bildet Präfix für Kompenenten-Namen

Beispiel

1. Modulname: mpl-example-login

  • Komponenten
    • Public (Abhängig vom Anwendungsfall benennen)
      • Die eine Config bereitstellt: mpl-example-login-config
      • Eine Schedule-Task-Factory: mpl-artifactory-deployment-scheduletask
      • ...
    • Service : mpl-example-login-service
    • Webapp: mpl-example-login-webapp

2. Modulname: xxx-example-integration

  • Project-App: xxx-example-integration-projectapp (oder …-projectconfig)

Displaynamen

  • CamelCase
  • Mit Leerzeichen
  • Bsp: Maple Example Login Module (I,L)

Isolierte Ressourcen

Damit ein Modul die Vorteile des Isolated Mode nutzen kann, müssen alle vom Modul benötigten Bibliotheken als Ressource im Modul enthalten sein.
Zunächst sollte der Modulentwickler also definieren, welche Bibliotheken vom Modul benötigt werden. Diese Ressourcen müssen dem Modul (als Komponente) hinzugefügt werden (siehe Ressourcen (→Entwicklerhandbuch für Komponenten)).

Im Der Komponenten-<components>-Deskriptor-Teil (→Entwicklerhandbuch für Komponenten) müssen dazu neben einem eindeutigen Namen noch weitere Eigenschaften definiert werden:

Eindeutige Namen für Ressourcen vergeben

Ressourcen haben eindeutige Namen. Wird eine Bibliothek als Ressource zu einem Modul hinzugefügt, muss im Der Komponenten-<components>-Deskriptor-Teil (→Entwicklerhandbuch für Komponenten) ein eindeutiger Name für die Ressource definiert werden.

Es wird empfohlen, die Namen nicht nur eindeutig, sondern auch einheitlich (nach Maven-Schema) zu vergeben, um die Identifikation gleicher bzw. kompatibler Ressourcen zu ermöglichen, z. B.:

<web-resources>
<resource name="org.apache.httpcomponents:httpclient" version="4.4">lib/httpclient-compatibility.jar</resource>
</web-resources>

Der Name (nach Maven) beinhaltet zuerst eine „groupID“ (hier: org.apache.httpcomponents) und anschließend eine „artifactID“ (hier: httpclient) getrennt durch einen Doppelpunkt. Die „groupID“ ist eine Gruppierungsbezeichnung (ähnlich den Java-Package-Namen) und dient zur eindeutigen Identifikation des Herstellers. Sie entspricht normalerweise dem umgekehrten Domainname des Herstellers. Die „artifactID“ ist der Name der Ressource (siehe Maven conventions).

Anhand des Namens und weiterer Eigenschaften (s.u.) kann ermittelt werden, ob unterschiedliche Ressourcen (hier: Bibliotheken) kompatibel sind. Abhängigkeiten zu anderen Produktbestandteilen und Migrationsaufwände können dadurch oft vermieden werden.

Versionierung von Ressourcen

Bei identischen Namen wird versucht herauszufinden, ob Ressourcen miteinander kompatibel sind. Dazu werden neben dem eindeutigen Bezeichner („name“) auch die mitgelieferte Version der Ressource („version“) sowie (optional) die Angabe der minimal kompatiblen Version („minVersion“) und der maximal kompatiblen Version („maxVersion“) benötigt:

<web-resources>
<resource name="org.apache.httpcomponents:httpclient" version="4.4" minVersion="4.4" maxVersion="4.5.2">lib/httpclient-compatibility.jar</resource>
</web-resources>

Dabei ist für „maxVersion“ auch folgende Angabe zulässig:

minVersion="4.4" maxVersion="4.9.9"

sofern die Bibliothek innerhalb einer Minor-Linie stabil bleibt (auch wenn diese Version der Bibliothek zum Zeitpunkt der Modulerstellung noch nicht existiert).

Liegt eine Ressource in mehreren unterschiedlichen Versionen vor, kann anhand dieser Informationen die beste Schnittmenge zwischen den Ressourcen ermittelt werden.

Es gilt:

  • Fehlt bei gleichem Namen für eine oder beide Ressourcen eine Versionsangabe („version“), sind die Ressourcen nicht kompatibel.
  • Fehlt bei gleichem Namen und unterschiedlichen Versionsangaben („version“) die Angabe von „minVersion“ und „maxVersion“, sind die Ressourcen kompatibel.
  • Ist bei gleichem Namen und unterschiedlichen Versionsangaben („version“) ein Kompatibilitätsraum durch die Angabe von „minVersion“ und „maxVersion“ vorhanden, wird immer die neueste (aktuellste) Ressource verwendet, die zu allen Modulen kompatibel ist.
    • fehlt die Angabe von „minVersion“, ist der Kompatibilitätsraum nicht durch eine untere Grenze beschränkt (0 bis „maxVersion“)
    • fehlt die Angabe von „maxVersion“, ist der Kompatibilitätsraum nicht durch eine obere Grenze beschränkt („minVersion“ bis unendlich)

Beispiele für die Ressourcendefinition (Kompatibilitätraum für Bibliotheken)

 

version

minVersion

maxVersion

Modul A

1.0

1.0

-

Modul B

1.5

1.5

1.999

Modul C

2.0

-

2.999

Ergebnis

Verwendet wird: Version 1.5 aus Modul B
v1.0 ist kompatibel zu Module A und C,
v1.5 ist kompatibel zu allen Modulen,
2.0 ist kompatibel zu Module A und C

    
 

version

minVersion

maxVersion

Modul A

1.0

1.0

1.999

Modul B

1.5

1.5

-

Modul C

2.0

2.0

2.999

Ergebnis

Konflikt:
keine Version ist zu allen Modulen kompatibel

v1.0 ist kompatibel zu Module A,
v1.5 ist kompatibel zu Module A und B,
v2.0 ist kompatibel zu Module B und C

    

Classloading-Modus definieren (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.

  • isolated: Es wird das „neue“ Classloading-Verfahren für die Ressource verwendet.
    Das betreffende Modul muss alle benötigten Bibliotheken selbst mitliefern, ein Zugriff auf interne Ressourcen des FirstSpirit-Servers ist nicht mehr uneingeschränkt möglich. Siehe dazu auch Classloading im "Isolated Mode"
  • legacy: Es wird das „alte“ Classloading-Verfahren für die Ressource verwendet.
    Die betreffende Ressource hat Zugriff auf interne Implementierungen und Bibliotheken des Servers. Siehe dazu auch Classloading: bisheriges Verhalten.
    Ist das Attribut nicht gesetzt, wird für die betreffende Ressource der Legacy mode angewendet.

Das Attribut ist nur im Tag <resource> verfügbar, nicht für das umliegende <resources>.
Beispiel:

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

Mit dem Attribut scope kann die Sichtbarkeit von Bilbliotheken festgelegt werden. Siehe Kapitel Hintergrund: Classloading

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