Java Plugin System (ohne OSGI)

[samatthias]

Hallo Zusammen

Ich benötige für meine Applikation ein Plugin System. Bitte keine Vorschläge wie OSGI und JPF.

Ich habe folgende Anforderungen resp Ausgangslage:
Das Plugin kann X beliebige viele JAR Dateien als Abhängigkeit haben. Jedes Plugin kann andere oder sogar dieselben JAR Dateien als Abhängigkeit haben, oder dieselbe Abhängigkeit mit anderer Version.
Über Java Reflection soll dann das Plugin ausgeführt werden (das geht auch ganz ok, man kann ja über den URLClassloader dies erledigen). Über Interfaces soll das Plugin geschrieben werden (auch kein Problem). Es wird ein Maven Architype dafür geben (Pipifax).

Beispiel:
Plugin 1 (Verzeichnis):
- Plugin1.jar
- log4j-1.2.0.jar
- commons-io-2.5.jar

Plugin 2 (Verzeichnis):
- Plugin2.jar
- log4j-1.0.0.jar
- commons-io-2.0.jar

Plugin 3 (Verzeichnis):
- Plugin3.jar
- commons-math3.jar

Hinweis: Tatsächlich wäre es denkbar neben all den JAR Dateien für das Plugin noch Metadaten in Form einer XML Datei mitzugeben bswp. Klassenname, Methodennamen, usw. Falls darauf verzichtet werden kann, umso besser.

Hinweis 2: Auf Hotdeployment, sowie Start und Stop Automatiken kann verzichtet werden (keine Anforderung).

So dies mal zur Ausgangslage. Jetzt zu den Fragen ;-):
1) Habt ihr eine Idee wie ich das am besten realisiere? Stichworte genügen.
2) Meiner Meinung nach müssen die Plugins einen eigenen Classpath haben, sonst gibt's Wirrwarr oder?
3) Muss ich alle Klassen aus allen JAR Dateien in denselben Classloader bringen oder? Oder gibt's hier eine elegante Lösung, dass ich nur diejenigen lade, die auch tatsächlich verwendet werden? So etwas wie JLink zur Analyse von Abhängigkeiten resp. Imports?

Danke für eure aufgewendete Zeit. Ich wünsche euch allseits eine gute Zeit.

Beste Grüsse
Matthias

 

[Janrupf]

Hi,
ich programmiere zur Zeit auch ein solches Plugin-System, auch wenn bei mir alle Plugins in einem Ordner liegen...
Du liegst mit deinem URLClassLoader schon richtig, ich würde in deinem Fall über die Verzeichnisse iterieren und alle .jar oder .zip (Zip würde hier auch gehen, es sei denn du benötigst das Minifest von Jar's) Dateien suchen.
Du kannst ohne Probleme für jede Datei einen neuen URLClassLoader anlegen, solange du ihn auf null setzt wird der GC ihn auch entfernen. Am sinnvollsten ist es in jedes Plugin (also IN die Jar) eine plugin.info/plugin.xml/plugin.wasweißichdenn zu packen wo z.b. die Main-Klasse eines Plugin steht, Infos über die Version, den Author, möglicherweise eine home Seite... Diese musst du dann über den URLClassLoader hohlen (getResourceAsStream) und parsen.
Wenn du diese Infos hast kannst du mit dem laden der Klassen beginnen. Hierzu nimmst du dir einen ZipInputStream und suchst dir mithilfe dessen alle Klassen-Namen raus. Google einfach nach "Java find classes in Jar".
Für jeden .class Eintrag rufst du dann <classloader>.loadClass(<angepasster Eintrag>) auf. Wenn du auf deine Main-Klasse stößt speicherst du sie dir in einer variable. WICHTIG: Dies lädt nur Klassen und instanziert sie nicht!
Java kennt jetzt alle Klassen! Das ist wichtig weil es sonst dazu kommt das Methoden aufgerufen werden und die ganze JVM ohne Exception hängt. Du kannst nun deine Main-Klasse instanzieren (<main class>.newInstance(<argumente>)). <argumente> könnten Argumente sein die deine Plugins im Konstruktor nehmen, macht aber selten Sinn und alles noch komplizierter. Deine Libraries kannst du zum ClassPath laden, leider geht das nur mit Reflection:
- ClassLoader.getSystemClassloader()
- Zum URLClassLoader casten
- die Methode addUrl(URL) aufrufen mit der URL zu deiner Library
Ich weiß allerdings nicht was passiert wenn verschiede Versionen von Libraries geladen werde, wahrscheinlich werden die alten geladenen Klassen einfach ersetzt.
Ich weiß nicht ob es eine schönere Lösung gibt die Libraries zu laden, aber versuch einfach mal sie mit dem Plugin ClassLoader zu laden, also wieder über alle Klassen in der Library iterieren und mit loadClass laden.
Noch eine Sache zum laden der benötigten Klassen: Sollte nicht nötig sein, die JVM lädt auch erstmal alles und entscheidet dann.

Hoffe ich konnte helfen
MFG, Jannis

 

[samatthias]

Hi Jannis

Danke für Deinen ausführlichen Post. Inzwischen habe ich auch noch bisschen getestet und kann noch zwei Sachen hinzufügen die noch interessant sein könnten:

1) Der URLClassLoader kann ja mehrere JAR Dateien auf einmal laden, das habe ich auch nach längerem studieren erst gesehen. Mein Fehler. Tatsächlich ist es so, dass wenn Du ein Plugin geschrieben hast, dass mehrere JAR als Abhängigkeiten definierst und dieses Zusammen mit allen anderen JAR Dateien im Classloader lädst. Deine eine Klasse instanzierst, die alles macht (main oder auch eine andere völlig egal.) Dann kann Java automatisch die richtigen Imports rauspflücken. Das sagst Du ja in Deinem Post ja auch (ganz unten).

2) Tatsächlich gibt es aber ein Problem: Wenn das Coreframework schon eine JAR Datei hat (und im classpath ist), die ein Plugin auch verwendet gibt's Probleme mit den Versionen. Dies kann Java nicht richtig auflösen. Soweit ich gelesen habe ist dann gilt first-come-first serve. Um auch dieses Problem zu umgehen müsste man auch das Coreframework über reflection laden. Dies habe ich bis jetzt noch nicht bedacht. Doch dann sollte es ohne Probleme gehen.

Beste Grüsse
Matthias

 

[Janrupf]

Hi,
Es stimmt schon das der URLClassLoader mehrere Jars laden kann, aber ob es sinnvoll ist ist manchmal die andere Sache . Zumindest ist es einfacher für jede Jar einen neuen zu instanzieren, und naja, die Resourcen, sind wohl auch geschenkt wenn der GarbageCollector drüber läuft . Könnte eigentlich sogar ein bisschen testen, aber eclipse hat sich entschieden 50 Jahre lang für update alternativen zu suchen und sich erst mal unbenutzbar zu machen, also heißt es für mich jetzt erst mal warten.
Hat eigentlich ein URLClassLoader wenn man ihn ohne ParentClassLoader erstellt schon etwas im ClassPath? Manche behaupten halt ja und manche Nein. Aber wegen der oben genannten Problematik kann ich gerade nicht testen

Nachtrag: Eventuell könntest du deine Plugins dazu zwingen ihre Abhängigkeiten über Maven oder so zu hohlen, aber wäre natürlich nicht schön. So hättest du zumindest Kontrolle über die Abhängigkeiten.

 

[mrBrown]

2) Tatsächlich gibt es aber ein Problem: Wenn das Coreframework schon eine JAR Datei hat (und im classpath ist), die ein Plugin auch verwendet gibt's Probleme mit den Versionen. Dies kann Java nicht richtig auflösen. Soweit ich gelesen habe ist dann gilt first-come-first serve. Um auch dieses Problem zu umgehen müsste man auch das Coreframework über reflection laden. Dies habe ich bis jetzt noch nicht bedacht. Doch dann sollte es ohne Probleme gehen.

Man müsste den ClassLoader so überschrieben können, dass über des Parent als letztes geladen wird. Dann wird erst die gebrauchte Version über den eigenen ClassLoader geladen, und die falsche Version, die der Parent schon geladen hat, nie.

Es stimmt schon das der URLClassLoader mehrere Jars laden kann, aber ob es sinnvoll ist ist manchmal die andere Sache . Zumindest ist es einfacher für jede Jar einen neuen zu instanzieren, und naja, die Resourcen, sind wohl auch geschenkt wenn der GarbageCollector drüber läuft.

Warum sollte es weniger sinnvoll und einfacher sein, jede jar einzeln zu laden?

Nachtrag: Eventuell könntest du deine Plugins dazu zwingen ihre Abhängigkeiten über Maven oder so zu hohlen, aber wäre natürlich nicht schön. So hättest du zumindest Kontrolle über die Abhängigkeiten.

Warum wäre das nicht schön?
Man macht sich damit nur weniger Probleme , Maven hat auf das Laden zur Laufzeit ja eh keinen Einfluss.

 

[samatthias]

Hallo Jannis

Hi,
Es stimmt schon das der URLClassLoader mehrere Jars laden kann, aber ob es sinnvoll ist ist manchmal die andere Sache . Zumindest ist es einfacher für jede Jar einen neuen zu instanzieren, und naja, die Resourcen, sind wohl auch geschenkt wenn der GarbageCollector drüber läuft .

Das müsstest Du mir auch nochmals erklären, wie Du das genau gemeint hast. Denn es ist ja grad von Vorteil, wenn alle Jars die zu einem Plugin gehören über den Classloader geladen werden. So hast Du sichergestellt, dass Du nur diese in diesem Classloader hast.

Nachtrag: Eventuell könntest du deine Plugins dazu zwingen ihre Abhängigkeiten über Maven oder so zu hohlen, aber wäre natürlich nicht schön. So hättest du zumindest Kontrolle über die Abhängigkeiten.

Das verstehe ich im Moment auch nicht, was hier Deine Idee war. Kannst Du dies nochmals erläutern? Maven kann zur Laufzeit fast gar nichts. Es ist eher zur Kompilezeit sehr angenehm, wenn es die Abhängigkeiten manageg kann. Aber zur Laufzeit wäre mir nicht dies nicht bekannt.

Beste Grüsse
Matthias

 

[JuKu]

Ich glaube dieses Tutorial könnte dir weiterhelfen:
https://www.java-blog-buch.de/d-plugin-entwicklung-in-java/

 

[mrBrown]

Ich glaube dieses Tutorial könnte dir weiterhelfen:
https://www.java-blog-buch.de/d-plugin-entwicklung-in-java/

So ziemlich jede hier gestellte Frage geht über das dort erklärte weit hinaus...

 

[JuKu]

Ja, es ist eben nur der Ansatz.
Den Rest muss er selber machen.

 

[mrBrown]

Ja, es ist eben nur der Ansatz.
Den Rest muss er selber machen.

Allerdings geht der gesamte Post hier schon deutlich über den Ansatz hinaus, der für diesen Problem auch größtenteils untauglich ist...

 

[samatthias]

Hallo JuKu

Das Tutorial kenne ich und mrBrown hat teilweise recht. Das Tutorial erwähnt in keinem Zuge bswp. wie mit weiteren JAR Abhängigkeiten umgegangen werden muss. Man muss allerdings zu Gute halten, wenn man den Code sehr genau und aufmerksam liesst, sich die Lösung erschliesst.

Der Satz:
"Damit Sie Klassen laden können, die nicht beim Start Ihrer Anwendung über den Classpath eingebunden wurden, benötigen Sie einen eigenen ClassLoader."

Finde ich ein wenig cryptisch formuliert, beinhaltet jedoch die Antwort auf meine frage.

Es gibt übrigens noch eine weitere Variante: ServiceLoader von Java. Sei hier nur kurz erwähnt dies jemanden interessiert. Allerdings habe ich dort auch noch nicht ganz verstanden wie das mit den weiteren JAR Abhängigkeiten gemanaged werden muss.

Beste Grüsse
Matthias