Zum Hauptinhalt gehen

Modulerstellung und Lucene-libs

Kommentare

7 Kommentare

  • Zendesk API User
    Author: bIT_sosswald - 6/16/2016 6:23

    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
  • Zendesk API User
    Author: Anonymous - 6/16/2016 7:49

    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 :smileywink:

    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?

    0
  • Zendesk API User
    Author: mfiori2 - 6/16/2016 9:48

    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

    0
  • Zendesk API User
    Author: jsp - 6/16/2016 14:00

    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

    0
  • Zendesk API User
    Author: Anonymous - 6/16/2016 14:09

    Hi Marvin,

    vielen Dank für die Bestätigung meiner Befürchtung :smileywink:

    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?!

    0
  • Zendesk API User
    Author: Sunforest - 6/16/2016 14:32

    Hallo zusammen,

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

    Ich hatte hier auch schon ähnliche Probleme...

    Viele Grüße

    Michael

    0
  • Zendesk API User
    Author: bIT_sosswald - 6/16/2016 15:35

    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. :smileywink:

    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

    0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.