Anonymous
Not applicable

Modulerstellung und Lucene-libs

Hallo liebe Community,

es ist bestimmt einfach nur eine Trivialität oder ein kleiner Schalter, aber vielleicht sehe ich einfach den Wald vor Bäumen nicht mehr.

Ich möchte ein Modul (FSM) erstellen, wo ein über Beanshell ausführbares executable enthalten ist. Dieses Modul enthält einige JAR-Dateien von Drittanbietern, welche von diesem Beanshell-Executable (welches NATÜRLICH das Interface "de.espirit.firstspirit.access.script.Executable" implementiert) benutzt werden soll.

Konkret handelt es sich hierbei um die Dependency "lucene-core-5.5.0.jar", welche die Klasse "org.apache.lucene.util.Version" enthält. Das Problem ist nun, dass in dem "fs-server.jar" ja bereits eine andere Version enthalten ist (ich weiß, dass es bereits mehrere Threads zu Thema Maven+FirstSpirit hier gibt), bekomme ich es einfach nicht hin, dass mein Modul eben NICHT die Version vom Server nimmt.

Eingesetzte FirstSpirit-Version: 5.2.103

Vielen Dank für jede Hilfe bereits im Vorraus.

----

Kleiner Nachtrag:

ich habe gerade folgende Diskussion gefunden: https://community.e-spirit.com/message/14185#14185 gilt das auch noch für FS 5.2 ?

Und hier noch die (anonymisierte) module.xml

<module>

    <name>someModule</name>

    <version>1.0.0-SNAPSHOT</version>

    <description>someModule description</description>

    <components>

        <public>

            <name>Some executable Task</name>

            <description>some fancy description</description>

            <class>somePackage.executables.DummyExecutable</class>

        </public>

    </components>

    <resources>

        <!-- some other dependencies, including the one containing "somePackage.executables.DummyExecutable" -->

        <resource scope="module">lib/lucene-analyzers-common-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-backward-codecs-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-core-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-grouping-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-highlighter-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-join-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-memory-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-misc-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-queries-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-queryparser-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-sandbox-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-spatial-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-spatial3d-5.5.0.jar</resource>

        <resource scope="module">lib/lucene-suggest-5.5.0.jar</resource>

        <resource scope="module">lib/xbean-asm-util-4.5.jar</resource>

        <resource scope="module">lib/xbean-bundleutils-4.5.jar</resource>

        <resource scope="module">lib/xbean-finder-4.5.jar</resource>

    </resources>

</module>

7 Replies
bIT_sosswald
Returning Responder

Hallo Danny,

im Extremfal hilft meistens das Maven Shade-Plugin: https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html

Damit kannst du z.B. die von dir mitgelieferten Libs in einen anderen Klassenpfad verschieben, wodurch Kollisionen beim Classloading vermieden werden sollten.

Grüße

Sandro

0 Kudos
Anonymous
Not applicable

Hallo Sandro,

leider kann ich das nicht machen, da ich auf die Lucene-Klassen nur indirekt zugreife, ich benutze noch eine andere 3rd-party-lib, welche auf die Lucene-Version-Klasse zugreift. Mein nächster Ansatz wird nun sein, dass ich meinen eigenen ClassLoader nutze (nicht die schönste Lösung, aber werde ich dann exemplarisch später hier im Thread reinwerfen).

Mich verwundert generell diese ClassLoader-Frickelei, wäre irgendwie cool, wenn man da von FS eine einfache Methode oder so bekommt um an den ClassLoader direkt zu kommen. Diese Custom-Lösung ist irgendwie mühsam und nicht nerven schonend.

Eine Implementierung mit OSGi wäre hier natürlich viel hilfreicher, gerade für die Isolierung solcher Dinge, eine saubere Isolierung der FS-Kernelemente von den integrierten libs könnte das Entwicklerleben sooo viel einfacher machen Smiley Wink

Noch zur Rückfrage: aber es ist aktuell noch immer so, dass im Modul-ClassLoader zuerst die FS-Klassen geliefert werden anstatt die von dem Modul?

mfiori2
I'm new here

Hallo Danny,

genau dieses Problem hatte ich auch schon öfters. Ob es mit Lucene, Tika oder nur den Apache Commons ist.

Die Lösung war teilweise ein eigener ClassLoader, Shading oder die Verwendung der selben, oft sehr veralteten, Version der Abhängigkeit die im fs-server.jar enthalten ist.

Ich kann dir nur zustimmen, dass e-Spirit die Entwicklung in diesem Bereich durch verschiedene Maßnahmen stark vereinfachen könnte. Beispielsweise wenn die von FirstSpirit genutzen Abhängigkeiten in der fs-server.jar geshadet wären. So könnten während der Modulentwicklung beliebige eigene Versionen der Abhängigkeiten genutzt werden.

Beste Grüße

Marvin

jsp
I'm new here

Hallo Danny,

die Lösung mit dem Shading wird sogar unmöglich, wenn die 3rd-Party-Library Klassen über Reflection aus Konfigurationen lädt, wie z.B. die Tika-Lib.

Siehe https://community.e-spirit.com/message/26906#26906.

Viele Grüße

Jan

Anonymous
Not applicable

Hi Marvin,

vielen Dank für die Bestätigung meiner Befürchtung Smiley Wink

Ich bin aktuell mit einem eigenen URLClassLoader (ohne Parent-CL) unterwegs, in den ich alle in dem Modul-ClassLoader enthaltenen JARs reinwerfe und dann dort via Reflection meine Klasse ausführe.

Da ich selbst diese Lucene-Klasse nicht direkt nutze, sondern eine andere 3rd-Party-Lib, ist ein Shading wirklich unmöglich gewesen.

Wäre schön, wenn einer von den FS-Devs mal einen Ausblick geben könnte, ob hier an dem Mechanismus gearbeitet wird?!

Hallo zusammen,

ich wäre auch an einer "offizielleren" Lösung interessiert.

Ich hatte hier auch schon ähnliche Probleme...

Viele Grüße

Michael

Hallo zusammen,

auf dem letzten Treffen der e-Spirit Usergroup hat ein Vöglein gezwitschert, dass das Classloading-Thema in einer der kommenen FS-Versionen stark geändert werden soll, so dass solche Probleme nicht mehr auftreten. Smiley Wink

Was das genau heißt und wann das kommt kann ich leider nicht sagen. Evtl. ließt ja jemand mit der hierzu genaueres erzählen kann...

Grüße

Sandro