Search the FirstSpirit Knowledge Base
Hallo,
ich verwende in einem Modul ein JAR, dass Google Guava (com.google.guava:guava:jar:11.0.1) benutzt.
Unter FirstSpirit 5 lief das Modul problemlos, unter FirstSpirit 4.2. R4 bekam ich erst eine ClassNotFound Exception, bis ich die Guava
Library explizit in meiner FSM als Resource hinterlegt habe.
Seitdem erhalte ich folgenden Fehler:
java.lang.NoSuchMethodError: com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
Diese Methode steckt laut Internet wohl in dem google-collections jar, das Konflikte mit Guava hat.
Kann mir jemand sagen, was genau da in FirstSpirit 4.2 R4 verwendet wird, und ob es eine Lösung für mich gibt, dieses Problem zu umgehen.
Viele Grüße,
Thomas Kloppe
Hallo,
das ist leider ein bekanntes Classloader-Problem. (siehe auch dieses Posting)
FS4.2 setzt das google-collect-1.0.jar ein welches in FS5.0 durch das guava-11.0.2.jar ersetzt wurde.
Wenn der Classloader in 4.2 also nach guava sucht, wird es nicht gefunden, solange es nicht explizit eingebunden wird.
Solange die Bibliothek nicht in einer WebApp oder einem Service benötigt wird, könnte es funktionieren in der module.xml den scope der resource auf "module" zu setzen:
<resources>
<resource scope="module">lib/LIBRARY.jar</resource>
</resources>
Viele Grüße
Rouven
Hallo Thomas,
solltes du weiter Problem haben, kannst du dir mal JarJar anschauen, damit kannst du solche Versions Problem umgehen.
Gruß
Thorsten
Hallo,
konnten Rouvens und Thorstens Antworten die Frage beantworten, so dass dieser Beitrag als beantwortet gekennzeichnet werden kann, oder benötigen Sie weitere Hilfe für das beschriebene Problem?
Viele Grüße
Michaela
Guten Tag,
dieses Problem lässt darauf schließen, dass der gerade aktive ClassLoader die systemweit-sichtbare Klasse com.google.common.base.Objects aus dem Archiv google-collections.jar von FS 4.2 R4 geladen hat und nicht die der guava-11.0.1.jar. Aus diesem Grund tritt auch der Fehler java.lang.NoSuchMethodError auf, da die Methode firstNonNull mit der Signatur (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; in der Klasse com.google.common.base.Objects, die es in google-collections.jar ebenfalls gibt, nicht existiert. An anderer Stelle könnte es eventuell auch zu einer ClassNotFoundException kommen, falls eine neu hinzugekommene Klasse einer neueren Version im gleichen Namensraum residiert.
Eine Lösung für Maven-basierte Module ist die Nutzung des Shade-Plugins, mit dem man solche Konflikte durch eine "Relocation", also einer Transformation des Namespace (Paketstruktur), lösen kann. Eine andere Lösung scheint mir die Verwendung von Scopes im Modul-Deskriptor zu sein, damit explizit ein Modul-ClassLoader beim Laden der für das Modul benötigten Klassen zum Einsatz kommt, der dann die im Modul-Deskriptor definierten Resourcen vor die global geladenen Resourcen stellt. Ob und wie das aber richtig funktioniert, kann ich an dieser Stelle noch nicht sagen.
Viele Grüße