JAR Library

[hasso]

Hallo,

ich habe ein Programm geschrieben und daraus eine JAR-Datei erzeugt. Diese JAR-Datei habe ich jetzt in ein anderes Java-Programm eingebunden und kann auch problemlos auf die Funktionen zugreifen.
Probleme entstehen wenn ich auf Funktionen in der JAR zugreife die wiederrum selbst auf ein eingebundes JAR zugreifen.

Okay klingt unverständlich, probiere es nochmal anders:

Ich hab ein Programm geschrieben welches 3 JARs einbindet und aus diesem Programm wieder ein JAR exportiert. Wenn ich dieses jetzt irgendwo einbinde und auf eine Funktion zugreife die auf Funktionen einer der 3 JARs zugreift stürzt mir das Programm ab und er sagt er kann die JAR nicht finden.

Werden die gar nicht mit eingebunden ? Oder kann ich das irgendwo einstellen ?

Grüße

 

[Spacerat]

Das klingt mir sehr nach Jar-in-Jar-Export. Die inneren Jars müssen natürlich vor ihrer Verwendung in den Classpath extrahiert werden, sonst wird das nichts.

 

[hasso]

Richtig.

Hab die Häckchen vergessen bei "Order und Export" für die drei JARs.

Danke!

 

[hasso]

Hallo,

okay so ganz hab ichs doch nicht verstanden, wobei ich schwören könnte gestern hats funktioniert und heute jetzt nicht mehr.

Ich habe ein:

Programm A <---- Jar B <---- Jar C

welches ein Jar B hinzugefügt bekommt. Jar B wiederrum benutzt Jar C.
C ist hierbei eine externe Jar auf die ich keinen Zugriff habe.

Im Programm B hab ich diese Jar C hinzugefügt und kann sie dort normal benutzen. In den Project Properties hab ich im "Java Build Path" ein Häckchen bei Order und Export (Build Class Path) gesetzt für Jar C . Was für mich soviel bedeutet dass das Jar C in den Classpath übernommen wird.

Wenn ich die nun erzeugte Jar B in Programm A einbinde kann ich zwar alle Funktionen aus B problemlos benutzen aber wehe B greift auf eine Klasse aus C zu, dann fliegt er mir um die Ohren mit einer ClassDefNotFound runtime exception.

Wie kann ich denn jetzt rauskriegen WO er sucht und WO er diese Jar erwartet ? Ich hab keine Idee mehr was ich noch anders machen sollte. Kann ich irgendwie überprüfen ob die Jar C in den ClassPath übernommen wurde ?

Grüße

 

[hasso]

Okay,

wenn ich die Jar C auch noch in Programm A einbinden funktioniert es.

Aber das kann ja nicht die Lösung sein, Jar C ist ja jetzt doppelt eingebunden, einmal in Jar B (wo seine Funktionen genutzt werden) und einmal in Programm A.

 

[trääät]

hatte mal ein ähnlich witziges problem bei nem plugin-system ...

das plugin-system selbst war als lib ausgelagert und nur über einen URLClassLoader geladen ... also nicht direkt im classpath gewesen ...
folglich konnte das programm selbst natürlich nur mit der über den URLClassLoader zur verfügung gestellten schnittstelle arbeiten ...

so bald nun über die schnittstelle das system zum laden von plugins aufgefordert wurde flogen mir auch einige exceptions um die ohren das klassen aus dem über den URLClassLoader geladenen plugin-system-jar angeblich nicht gefunden werden konnten ... von den plugins selbst mal abgesehen ...

das problem liegt vermutlich in irgendeiner art und weise im class-loader system von java und darin das der classloader es nicht packt das wenn B.jar in A.jar im manifest steht und C.jar im manifest von B.jar das manifest von B.jar so zu verarbeiten das automatisch daduch rekursiv C.jar mit eingebunden wird was zu fehlern führt ...

lösung : B.jar muss so gebaut sein das es selbst URLClassLoader nutzt und C.jar unabhängig laden kann ... oder C.jar muss im manifest von A.jar liegen ...

 

[Spacerat]

Also in Eclipse und auch zur Laufzeit müssen die Jars mit den Klassen auf welche die Libs zugreifen natürlich erreichbar sein.
Wenn ein Jar in einem anderen steckt und andere auch damit arbeiten wollen (bzw. sollen), muss das innere Jar in den Classpath extrahiert werden.
In einem PI-System kann man das noch ein wenig anders gestalten und zwar so, dass einer Anwendung nur die Klasse des PI-Loaders und die Strukturen des verwendeten Plugins bekannt sind. Der PI-Loader wäre dann für das Laden der PI-Klassen verantwortlich und das kann er von sonst wo (also von Pfaden die nur der PI-Loader kennt) per URL-Classloader machen. In diesem Fall sollte es der Anwendung egal sein, woher die Klassendefinition des PIs kommt, hauptsache der Loader kann Instanzen davon bereitstellen. Das PI-Loader-Archiv kann dazu natürlich die PI-Archive beinhalten, extrahieren muss er sie (zumindest die von der Anwendung geforderten) vor der Verwendung trotzdem.

 

[trääät]

dieses beispiel stammt nur aus einer sehr frühen version eines sehr alten systems mit dem ich begonnen habe modular zu entwickeln ...
mitlerweile bin weiter und habe dieses problem gelöst ... und zwar sowohl wenn das lib-jar im classpath der anwendung liegt als auch wenn es nur über einen URLClassLoader geladen wird ...
jedoch scheint das problem von to daran zu liegen wie die verwendete lib des moduls zu verwenden ist ... vermutlich ist dies inkompatibel zu dem von to verwendeten system ...
genaueres könnte man nur anhand von code-ausschnitten sagen