Isolation im Isolated Mode nachvollziehen / Relevanz von "Dependency on internal e-Spirit class NON_API_USAGE"
Author: choff
Publication Date: 9/24/2021 12:43
Hallo zusammen.
Wir stellen auf den Isolated Mode um und haben dazu unsere Module mit dem FSM-Checker prüfen lassen. Es gibt einige Finding vom Typ "Dependency on internal e-Spirit class (NON_API_USAGE)". Dazu folgende Fragen:
1. Müssen wir so etwas beheben, um den Code lauffähig zu halten, oder ist es derzeit nur eine Empfehlung?
2. Im unten stehenden Beispiel lässt sich das Modul auch im Isolated Mode weiterhin bauen, installieren und das Executable, welches die interne Klasse verwendet, fehlerfrei aufrufen. Das wundert mich. Sollten im Isolated Mode nicht die internen Klassen unsichtbar sein? Warum läuft der Code fehlerfrei durch?
3. Was wäre ein Beispiel für Code, der nicht ausführbar ist, weil er interne Klassen verwendet und diese im Isoated Mode unsichtbar sind und somit nicht verwendet werden können?
Hier das Beispiel, auf das sich Punkt 2. bezieht:
in module.xml und module-isolated.xml ist unter <components> jeweils
<public>
<name>BarExecutable</name>
<class>de.XXX.YYY.foo.BarExecutable</class>
</public>
vorhanden. <resources> in module-isolated.xml ist<resources>
<resource scope="server" mode="isolated">lib/${project.artifactId}-${project.version}-jar-with-dependencies.jar</resource>
</resources>
und so<resources>in module.xml. In BarExecutable.java haben wir
<resource scope="server">lib/${project.artifactId}-${project.version}-jar-with-dependencies.jar</resource>
</resources>package de.XXX.YYY.foo;
import de.espirit.common.base.Logging;
import de.espirit.firstspirit.access.BaseContext;
import de.espirit.firstspirit.access.script.Executable;
import de.espirit.firstspirit.access.store.Store;
import de.espirit.firstspirit.access.store.globalstore.GlobalStoreRoot;
import de.espirit.firstspirit.access.store.globalstore.ProjectProperties;
import de.espirit.firstspirit.agency.StoreAgent;
import de.espirit.firstspirit.store.access.globalstore.ProjectPropertiesImpl;
import java.io.Writer;
import java.util.Map;
public class BarExecutable implements Executable {
@Override
public Object execute(Map<String, Object> map, Writer writer, Writer writer1) {
BaseContext context = (BaseContext) map.get("context");
GlobalStoreRoot store = (GlobalStoreRoot) context.requireSpecialist(StoreAgent.TYPE).getStore(Store.Type.GLOBALSTORE);
ProjectProperties projectProperties = store.getProjectProperties();
Logging.logInfo("hallo123", this.getClass());
if (projectProperties instanceof ProjectPropertiesImpl) {
Logging.logInfo("yes it is", this.getClass());
}
else {
Logging.logInfo("not it is not", this.getClass());
}
return null;
}
}
Wenn wir BarExecutable über ein Kontextmenüskript im SiteArchitect verfügbar machen und auf irgendeinem Knoten ausführen, wird das ins Log geschrieben:
INFO 24.09.2021 13:07:31.599 (de.XXX.YYY.foo.BarExecutable): hallo123
INFO 24.09.2021 13:07:31.599 (de.XXX.YYY.foo.BarExecutable): yes it is
Also scheint der Zugriff auf die interne Klasse ProjectPropertiesImpl auch im Isolated Mode problemlos möglich zu sein. Warum ist das so?
Vielen Dank vorab für alle Unterstützung und viele Grüße,
Christian
-
Author: fmb - 2/1/2022 8:19
Hallo ,
leider kann ich auch nicht mit einer Antwort aufwarten. Vielmehr möchte ich mich erkundigen, ob sich hier in der Zwischenzeit abseits des Forums neue Erkenntnisse ergeben haben. Wir befinden uns wohl gerade in einem ähnlichen Zustand und fragen uns, weshalb es nach der Umstellung auf "Isolated" nicht zu Fehlermeldungen kommt. Nun möchten wir entsprechend sicher gehen, ob das nun erst einmal so ist oder ob uns noch eine wichtige Einstellung zum Vollenden der Umstellung fehlt.
Im "About" zum FSM Checker heißt es an sich im Absatz zu "Dependencies on internal e-Spirit classes": "These classes are available in the isolated runtime and will not cause errors when run with the tested FS version, but they are subject to change without prior notice and are therefore not future-proof." Aber wir haben auch Meldungen im Abschnitt "Dependency on class not available in isolated mode", für die das wohl nicht gilt.
Viele Grüße
Frank
0 -
Author: choff - 2/3/2022 15:58
Hallo Frank,
danke für den Hinweis auf das "About" im FSM-Checker. Das beantwortet meine Frage, warum die "Dependencies on internal e-Spirit classes" auch im Isolated Mode erst mal weiter funktionieren.
"Dependency on class not available in isolated mode (IMPL_USAGE)" haben wir keine.
Neue Erkenntnisse zum Vorgehen bei der Umstellung habe ich keine weiter: mit einigen Änderungen aufgrund von Findings im FSM-Checker und dem Befolgen der Doku im ODFS haben die Tests gut funktioniert, so dass ich bei der in den nächsten Wochen anstehenden produktiven Umstellung nicht mit Problemen rechne.
Viele Grüße,
Christian0 -
Author: fmb - 2/7/2022 8:58
Guten Morgen Christian,
vielen Dank für die Rückmeldung. Das untermauert für uns, dass wir - zumindest bzgl. der "Dependencies on internal e-Spirit classes" - nicht zwangsläufig auf einem falschen Pfad sind. Freut mich, dass ich selbst noch einen Hinweis beisteuern konnte.
Dann drücke ich die Daumen für die anstehende produktive Umstellung, viele Grüße
Frank
0 -
Author: daniel_witt - 2/8/2022 15:45
Hi,
du nutzt in deinem Beispiel
import de.espirit.firstspirit.store.access.globalstore.ProjectPropertiesImpl;Hier wird eine Impl Klasse verwendet und daher kommt dann vermutlich auch die Meldung. Was passiert wenn du das "Impl" einfach weglässt?
Ich vermute, dass in deinem lokalen Classpath irgendwo noch ein fs-access, fs-client oder fs-server rumschlummert. Eigentlich müsste das auch in deinem Code-Editor der Wahl angemerkt werden, wenn du nur das fs-isolated-runtime verwendest.
Gruß,
Daniel
0 -
Author: choff - 2/15/2022 17:26
Hallo Daniel,
danke für den Hinweis auf fs-isolated-runtime! Wir nutzen tatsächlich noch fs-access und client als Maven-Dependencies. Die Umstellung auf fs-isolated-runtime scheint an mir vorübergegangen zu sein, obwohl ich eigentlich dachte, die Modul-Migrationsanleitung von Legacy auf Isolated Mode genau befolgt zu haben. Dank deines Hinweises habe ich jetzt aber mal gezielt im ODFS nach fs-isolated-runtime gesucht und bin fündig geworden. Da kann ich dann bei Gelegenheit genauer nachlesen wie es aktuell gedacht ist, welche FirstSpirit-Bibliotheken bei der Modulentwicklung eingebunden werden sollen.
Der Code oben mit ProjectPropertiesImpl war ja nur ein Test. Ich habe diese Klasse genommen, weil wir in einem Modul einer Stelle ProjectPropertiesImpl irgendwo in den Tiefen gewisser Workflows verwenden - vermutlich von früher her, als es ProjectProperties noch nicht gab bzw. man die an der Stelle nicht verwenden konnte. Bei Gelegenheit würde ich prüfen, ob dort inzwischen auch ProjectProperties funktioniert. Aber da es auch in der bisherigen Form funktioniert, drückt da nichts. Ich hatte nur nicht verstanden, _warum_ es noch funktioniert.
Also, danke nochmal für deinen Beitrag und viele Grüße!
Christian
0
Please sign in to leave a comment.
Comments
5 comments