Mein Projekt verwendet einen einfachen Plugin-Mechanismus, der auf mehreren Anwendungskontexten basiert, die in Plugin-Jars definiert sind. Damit dies funktioniert, muss ich alle Plugin-Jars in den Klassenpfad einschließen. Es wäre schön, wenn Spring automatisch Jars laden und eigene Komponenten enthalten könnte, die zum Beispiel im Unterverzeichnis "plugins" meines Projekts abgelegt sind.
Gibt es dafür eine Lösung?
Ich ging ein bisschen weiter und versuchte, dies mit Jar Class Loader zu lösen.
Da ich den Spring-Anwendungskontext manuell instanziiere, kann ich Folgendes tun:
%Vor%Das funktioniert jedoch nicht. Aus dem Protokoll von Spring kann ich sehen, dass es die XML-Definition im Plugin-Jar nicht liest. Wenn ich den unteren Block durch
ersetze %Vor%es findet und lädt die XML-Definitionsdatei und Beans aus dem Jar. Auf diese Weise bin ich fest der XML-Ressource-Name für ein Plugin, das ich nicht will. Wie kann ich den Mustervergleich mit JCL durchführen?
Vielleicht möchten Sie OSGi als Plugin-Lademechanismus verwenden.
Das Open Source-Projekt Eclipse Virgo stellt eine OSGi-Laufzeitumgebung bereit, die für Ihr Projekt geeignet ist, da Spring integriert ist. Virgo bietet Tomcat- und Jetty-basierte Server und einen eigenständigen Kernel an, der alleine oder zum Aufbau anderer Servertypen verwendet werden kann. Siehe die Virgo-Website für Funktionen und Vorteile .
OSGi hat einen ganz anderen Design-Punkt als Sie in Java gewohnt sind. Es bietet eine kontrollierte Isolation zwischen Plugins, die als Bundles bekannt sind, im Gegensatz zu einem linearen Klassenpfad. Die Bundles sind in einem Abhängigkeitsdiagramm miteinander verbunden und unterstützen Versionierung und dynamische Lebenszyklusvorgänge.
Die bevorzugte Möglichkeit für ein Bundle, die Einrichtungen anderer Bundles zu verwenden, erfolgt über die OSGi-Service-Registry. Das Projekt Spring DM ermöglicht die Veröffentlichung normaler Spring-Beans in der Service-Registry und die Suche in der Service-Registry. Spring DM ist auch in Jungfrau eingebaut. Spring DM wurde als das Projekt Gemini Blueprint an Eclipse gespendet.
Um Virgo zu verwenden, würden Sie jedem Ihrer Plugins im META-INF / spring-Verzeichnis eine Spring DM-Konfiguration hinzufügen. Diese Konfiguration, bei der es sich um eine normale XML Spring-Konfigurationsdatei handelt, kann auf Beans in Ihren anderen Spring-Dateien verweisen und diese Beans in der Serviceregistrierung veröffentlichen oder Beans für Services bereitstellen, die in der Service-Registry gesucht werden und auf die dann verwiesen wird in, Bohnen in Ihren anderen Spring-Dateien.
Sie würden dann Ihre Plugins mit einem der unterstützten Mechanismen in Virgo deployen. Sie könnten sie einfach in Abhängigkeitsreihenfolge in das Pickup-Verzeichnis legen. Oder Sie können die Web-Admin-Konsole oder die Shell-Konsole zur Bereitstellung verwenden.
Alternativ, und dies würde Ihrer Anforderung eher entsprechen, könnten Sie Plugins installieren, die Pakete für andere Plugins im Virgo-Repository bereitstellen, indem Sie sie in repository / usr einfügen und dann die Plugins bereitstellen, die (transitiv) von den Repository-Plugins abhängen über das Abholverzeichnis oder die Web-Admin-Konsole. Virgo wird automatisch die Abhängigkeiten vom Repository bereitstellen, wenn die abhängigen Plugins bereitgestellt werden.
Sie können Plugins auch in einem Archiv zusammenfassen, das als PAR bezeichnet wird, oder indem Sie sie im Virgo-Repository speichern und dann in einer XML-Datei, einem sogenannten Plan, referenzieren Sie würden dann das PAR oder den Plan wie oben beschrieben bereitstellen. Sie können sogar einige der Abhängigkeiten in das Virgo-Repository einfügen und den PAR reduzieren oder planen, nur die abhängigen Plugins zu enthalten.
Wenn Sie weitere Informationen über Jungfrau wünschen, fragen Sie einfach im Virgo Community Forum .
Es scheint, dass JCL ClassLoader # findResource (String)
nicht überschreibtJarClassLoader.java AbstractClassLoader.java
PathMatchingResourcePatternResolver JavaDocs state:
Intern geschieht dies über einen Aufruf von ClassLoader.getResources ()
JavaDocs für ClassLoader #getResources (String) verweist auf Dokumentation für ClassLoader # findResource (String), das besagt:
Findet die Ressource mit dem angegebenen Namen. Klassenladeprogrammimplementierungen sollten diese Methode überschreiben, um anzugeben, wo Ressourcen zu finden sind.
Obwohl meine Antwort nur darauf beruht, ein paar Dokumente zu lesen, würde ich vermuten, dass JCL dies nicht unterstützt, da die dokumentierten Methoden nicht überschrieben werden.
Sie könnten dies testen, indem Sie JarClassLoader ableiten und findResource (String) implementieren, um meine Hypothese zu testen.
Natürlich könnte ich völlig falsch liegen.
Tags und Links java plugins spring classloader