JARs austauschen zur Laufzeit

[yaster]

Hi Leute,

ich habe folgendes Problem:
Zur Laufzeit soll anhand einer Versionsnummer entschieden werdeb welches JAR geladen wird. Davon abhängig kann es passieren, dass danach ein anderes JAR geladen wird. In den JARs sind die Klassenpfade gleich. Die Ausführenden Klassen, sowie Resourcen (Text-Dateien) unterscheinden sich auch vom Namen.

Ich weis, dass ich über einen neuen ClassLoader einzelne Klassen (aus einer JAR) laden kan. Kann ich aber auch eine ganze JAR laden gleichzeitig laden?

Für Hilfe wäre ich sehr dankbar.

Grüße


Bsp:

ver_02.jar
    + de.beispiel.Main.class
    + version.txt
    + v01_01.txt
    + v01_02.txt
    \ v01_03.txt


ver_05.jar
    + de.beispiel.Main.class
    + de.beispiel.Spezial.class
    + version.txt
    + v05_01.txt
    + v05_02.txt
    \ spezialSkript.txt

Wird auf dem System die Version 01 gefunden, so soll zuerst de.beispiel.Main aus ver_02.jar und danach aus ver_05.jar ausgeführt werden. Ansonsten gleich de.beispiel.Main aus ver_05.jar.
In version.txt stehen zusätzliche Informationen zur "Versionierung". D.h. der Text unterscheided sich je nach Verison.

 

[FArt]

Es werden nie ganze JARs geladen. Ressourcen werden geladen, wenn sie benötigt werden.

Was du brauchst sind einzelne Classloader (wie schon erwähnt) und eine Organisation dieser untereinander (z.B. hierarchisch).

 

[yaster]

(Bezugnehmend auf das Beispiel von obne)
Standardmäßig ist im Programm ver_05.jar eingebunden. Wenn jetzt zum Beispiel die Version 01 vorliegt lade ich über den ClassLoader de.beispiel.Main aus ver_02.jar. Diese Klasse greift aber auf die Resource version.txt aus ver_05.jar zu. Wie kann ich das umgehen?

Einbindung der ver_02.jar:

File file = new File("path/ver_02.jar");
URL url = file.toURI().toURL();
ClassLoader cl = new URLClassLoader(new URL[]{url});
Class<?> clazz = cl.loadClass("de.beispiel.Main");

Properties properties = (Properties)getProperties();
Object instance = clazz.getConstructor(Hashtable.class).newInstance(properties);
clazz.getDeclaredMethod("execute").invoke(instance);

Beim "execute" werden eben nicht die Resourcen aus dem eigen Jar (bzw. ClassLoader) herangezogen, sondern (wenn vorhanden) aus dem anderen Jar.

 

[FArt]

Das ist das Standardverhalten der Classloader. Du möchtest ein alternatives Verhalten, somit musst du das nach deinen Vorstellungen implementieren.

Zusatz: viele solche Anforderungen (oder Anforderungen die sich so anhören) lassen sich oft einfacher lösen. Die Frage ist, was du eigentlich damit erreichen möchtest?
Es geht um eine versionierte Applikation? Versionierte Ressourcen? Ressourcen, die kontextabhängig geladen werden sollen?

 

[yaster]

Es wird in einem Installations-Tool verwendet.
Wärend der Installation greift man auf die DB zu ließt dort die DB-Version aus. Wenn die zu alt ist, müssen vorher ältere Skripte ausgeführt werden, bevor die aktuelle DB-Version installiert werden kann.
Das Update der DB geschiet über ein Tool, dass in den Installer eingebunden ist. Das Tool hat nun schon einige Jahre hintersich gebracht und wurde ständig erneuert. Die Kernfunkion (und Path) ist allerdings geblieben. Je nach dem wie alt das Tool ist werden unterschiedliche Skripte geladen (da diese mit der Zeit verändert wurden).
Neben dieser erwähnten version.txt exitieren auch noch Propertie-Klassen die ebenfalls mitlerweile andere Keys und Values haben.
Es ist zwar ein Tool für sich, aber sollte trotzdem nicht über irgendwelche Zeilen-Kommandos ausgeführt werden, sondern über Instanzieirung. Dafür müsste man aber eine JAR "aushängen" und an stelle diese eine andere JAR "einbinden" können.
Ist sowas möglich? Auch wenn ich dafür mehrere Klassen schreiben muss...

Meine Idee war es eben die Main-Klasse über einen eigenen ClassLoader zu laden. Ich dachte eigentlich, dass diese Main-Klasse ebenfalls die ganzen Klassen bzw. Resourcen dann aus dem gleichen JAR nachläd. Das mit den Klassen wäre nicht weiter schlimm, da sich nur wenige verändert haben. Aber wie kann ich dann ALLE Resourcen nachladen, ohne sie einzeln aufzulisten?

Wenn jemand hierfür eine Lösung, BITTE antworten

DANKE!!!

 

[FArt]

Das ist möglich, aber nicht so wirklich trivial.

Im Prinzip ist das ein Plugin-Mechanismus, wobeil die Core-Applikation dein Hauptteil ist, die verschiedenen Versionen sind die "Plugins".

Grob musst du folgendes Realisieren:
- erzeuge für jede Version einen Classloader
- ermittel die Updateskripten in diesen Versionen
- lege (anhand der ermittelten Versionen) die Ausführungsreihenfolge fest
- führe die Aktionen nacheinander aus (wichtig: jede Einzelaktion nur mit Ressourcen aus der Version, die auch das Skript enthält)

 

[yaster]

Ursprünglich war ja das aktuelle Tool im Installer integriert, d.h. es wurde in den Klassenpath geladen.

Wenn ich nun für jedes jar einen eigenen ClassLoader erstelle, so werden ja die zu benutzenden Klassen und Resourcen in den Klassenpath geladen. Außerdem muss ich jede Klasse die angesprochen wird explizit laden; oder gibt es hierfür einen Automatismus?
Wie mache ich das dann, dass er nicht die schon geladenen Klassen und Resourcen benutzt, wenn ich die Main-Klasse des nächsten ClassLoader ausführe.

Wie stelle ich sicher, dass die Klassen und Resourcen herangezogen werden die innerhalb des Jars?

 

[FArt]

Noch mal zurück: das alles hier zu diskutieren würde zu weit führen, so lange du mit Classloadern nicht sattelfest bist.

Wie gesagt: alles andere als trivial.

Such dir mal an Doku bzgl. Classloader. Versuche zu verstehen, wie der Standard fuktioniert, danach wie man einen Plugin-Mechanismus realisiert.
Schaue mal nach Tutorials und Beispielen bzgl. "custom classloading" u.Ä.
Es gibt bekannte Tools, die das Standardverhalten der Classloader nach ihren Bedürfnissen verändern (z.B. JUnit, ANT, ...). So etwas kann dir als Basis dienen. Andere (z.B. JBoss oder Tomcat) haben noch komplexere Verhalten, können aber als Anregung bzw. zum Spicken dienen.
Wenn du das alles drauf hast, dann kannst du noch mal die von mir angerissenen groben Punkte ansehen.
Jetzt sollte klar sein, wie der Hase läuft bzw. es sollte nur noch konkrete Probleme geben, die man hier gut diskutieren kann.

 

[yaster]

Ist ok, werd es mir ansehen.

Danke trotzdem für deine Antworten.

 

[maki]

Íst dafür nicht auch OSGi da?

 

[FArt]

Íst dafür nicht auch OSGi da?

Ich glaube so einfach ist das nicht, lasse mich aber gerne diesbezüglich belehren... deckt OSGi die Anforderungen wirklich ab, denn es geht ja nicht nur darum die richtige Version anzuliefern?

 

[maki]

Mein "Wissen" oder besser "nicht-Wissen" was OSGi betrifft ist rein theoretisch, vielleicht kommt ja noch jemand der wikrlich etwas darüber weiss. (Wildcard?)