Probleme mit URLClassLoader in Verbindung mit rmi

[mfernau]

Hallo!

Ich bin mal gespannt, ob mir hier einer helfen kann
Folgendes habe ich vor:
Ich möchte eine Client-Server anwendung schreiben. Die Kommunikation zw. Server und Client erfolgt per rmi. Ferner soll die Funktionalität auf beiden Seiten per Plugins erweiterbar sein. Kommt ein Plugin auf dem Server hinzu, muss der Client natürlich die erweiterten Funktionen auf dem Server nutzen können. Also braucht dieser das entsprechende Gegenstück zum Plugin.
Ziel ist es, dass man einen Server- und Client-Part für ein Plugin schreibt. Der Client-Part kennt natürlich die Funktionen des eigenen Server-Teils und nutzt diese. Ablaufen soll das wie folgt:

Ablegen eines JAR-Files in ein Verzeichnis 'plugins' auf dem Server sowie Client. In diesem JAR-File gibt es zwei vordefinierte Klassen -> ServerPlugin und ClientPlugin. Der Server instantiiert per URLClassLoader das ServerPlugin welches implizit eine von Remote abgeleitete Klasse exportiert (also für rmi).
Etwas ähnliches passiert auf der Client-Seite. Die existierende Klasse ClientPlugin wird vom Client instantiiert welche wiederum implizit über Standard-Funktionen des Clients per rmi auf den Server zugreift und sich eine Referenz auf die von Remote abgeleitete Klasse des Server-Plugins besorgt um diese dann fernzusteuern. Soweit alles klar?

Bis fast zum Schluss funktioniert auch alles. Einaden der Klassen per URLClassLoader funktioniert bestens. Der Server-Part des Plugins wird korrekt exportiert. Doch wenn sich der Client die Referenz auf den Remote-Part des Server-Plugins besorgen will, bekomme ich die folgende Exception:

java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: testplugin.TestPluginImpl_Stub (no security manager: RMI class loader disabled)

RMI ist also nicht in der Lage die Klasse 'testplugin.TestPluginImpl_Stub' zu finden. Diese befindet sich aber im JAR-File, welches über einen URLClassLoader eingeladen wurde! Der Server braucht sie doch ebenfalls zum exporteiren und dort hat es funktioniert. Dieselbe Vorgehensweise zum einladen des Clients schlägt aber in diesem Fall auf der Client-Seite fehl. Die Frage ist nun, warum RMI nicht auf die in meinem JAR-File befindlichen Files zugreifen kann? RMI scheint den Weg aus dem SystemClassLoader zu meinem URLClassLoader nicht zu finden.
Den URLClassLoader benutze ich so:

File jarFile = new File("/path/to/TestPlugin.jar");
URLClassLoader classLoader = new URLClassLoader(new URL[] {jarFile.toURL()}, getClass().getClassLoader());
Class classDef = classLoader.loadClass(className);
GenericPlugin plugin = (GenericPlugin)classDef.newInstance();

Ich bin verzweifelt am Suchen einer Lösung für dieses Problem. Wäre echt klasse, wenn mir da jemand von euch einen Tipp geben könnte, woran es liegt.

Wenn jemand Probleme hat zu verstehen was genau mein Programm tut, bin ich gerne bereit es etwas ausführlicher zu formulieren oder Code bereit zu stellen.

Grüsse,
Martin

 

[Bleiglanz]

"no security manager: RMI class loader disabled"

schon mal gegoogelt? Du brauchst einen SecurityManager (und eine Policy)

könnte auch sein, dass das so gar nicht geht (nur mal angedacht, bin mir da nicht sicher)

a) der Server schickt eine Instanz vom Stub übers Netz, die mit dem nötigen Zugriffsschamott ausgerüstet ist

b) der Client kann das Ding nur aktzeptieren, wenn er die Stub_Klasse kennt, aber die ist bei dir NICHT die gleiche wie die vom Server, weil sie von einem anderen Classloader geladen werden soll/worden ist???

Würde eher versuchen

- mit RMI-Codebase zu arbeiten und die Plugins alle am Server lassen

- oder auf die Java5 "stubless" RMI-Clients zu setzen (Stub wird automatisch als Dynamic Proxy erzeugt)

 

[mfernau]

"no security manager: RMI class loader disabled"

schon mal gegoogelt? Du brauchst einen SecurityManager (und eine Policy)

Und wie ich gegoogelt hab Ich hab auch schon mal mit dem RMISecurityManager gearbeitet und einfach alles zu erlauben (per policy) -> kein Erfolg

a) der Server schickt eine Instanz vom Stub übers Netz, die mit dem nötigen Zugriffsschamott ausgerüstet ist

b) der Client kann das Ding nur aktzeptieren, wenn er die Stub_Klasse kennt, aber die ist bei dir NICHT die gleiche wie die vom Server, weil sie von einem anderen Classloader geladen werden soll/worden ist???

Genau; Der Punkt b) leuchtet mir ein und den hab ich mir auch schon gedacht. Aber das muss doch machbar sein? Die Frage ist, mit welchem ClassLoader wird der Kram denn auf der Server-Seite eingeladen? Mit dem URLClassLoader oder mit dem SystemClassLoader? Entsprechendes 'müsste' doch Client-Seitig ebenfalls gehen? Auf der Server-Seite hat er ja nicht geklagt über dieses Vorgehen... Dort hat der den Stub doch auch benötigt und eingeladen!?

Würde eher versuchen

- mit RMI-Codebase zu arbeiten und die Plugins alle am Server lassen

Halte ich für keine gute Idee. Oder ich wüsste gerade nicht wie das funktionieren sollte. Klar ist schon mal, dass eine gewisse Grundfunktionalität clientseitig hinzugefügt werden MUSS. Sonst weiss ich ja gar nichts über die erweiterten Funktionen Serverseitig und was ich damit anstellen kann. Also da werden ich mindestens etwas auf der Client-Seite brauchen (Stichwort: GUI. Irgend eine neue Funktion auf dem Server stellt mir einen Chat zur Verfügung. Eine GUI für diesen Chat werde ich schon clientseitig benötigen).
Alles was ich mir vorstellen könnte wäre, dass ich die RMI benötigten Classes übers Netz besorge. Das würde aber bedeuten, dass ich zusätzlich noch einen Webserver (gehts auch anders?) benötige, der die class-Files explizit bekommen muss. Also mal eben per Plug+Play nen JAR-File ins plugins Verzeichnis kopieren auf der Server-Seite ist ja dann nicht mehr möglch. Ich brauche die für RMI benötigten Class-Dateien ja nochmal einzeln (oder geht das dynamische Laden auch mit einem JAR-File?) für den Webserver.

- oder auf die Java5 "stubless" RMI-Clients zu setzen (Stub wird automatisch als Dynamic Proxy erzeugt)

Uff... *angst*

 

[Bleiglanz]

http://java.sun.com/j2se/1.5.0/docs/guide/rmi/codebase.html#section4

In addition to downloading stubs and their associated classes to clients, the java.rmi.server.codebase property can be used to specify a location from which any class, not only stubs, can be downloaded.

Mal ne andere Frage: Wie soll das mit den Plugins clientseitig überhaupt aussehen, d.h. wozu benötigst du extra Stubs?

Beim Programmieren arbeitest du doch eh mit einem generischen Interface ("Generic Plugin"), warum lässt du dann das ganze nicht gleich auf dem Server?

und machst RemoteMethode:

String[] getServices

invokeService(String name)

usw. usf.

so dass man nur noch am Server jars hinzufügt??

 

[mfernau]

sicherlich kann ich auch anfangen Strings zu parsen und irgendwelche 'Dinge' übergeben, die ich dann Serverseitig einfach interpretiere. Aber dann kann ich auch gleich komplett von rmi weg und kann alles auf Sockets mit Strings oder von mir aus noch Objekten machen. Ich will das ja möglichst komfortabel für mich selbst machen und möglichst wenig Arbeit in den Server stecken. RMI erschien mir da schön einfach und komfortabel für so eine Aufgabe.
Ich hab mal eine Grafik erstellt (erstellen lassen), die ausdrückt, was ich versuche zu erreichen:

Hier kannst Du sehen, wie das ganze funktionieren soll. Der Client und der Server haben einen Core. Diese implementieren eine für Ihre Seite entsprechendes Interface (ClientCore und ServerCore eben). Über eine Referenz auf ein ClientCore (aus PluginSicht) kann ich mir den Server geben lassen, mit dem ich verbunden bin (getServer()). Dies liefert mir eine Referenz auf ein Objekt vom Typ ServerCore. Dies kann ich nun per rmi ansprechen. Bis hier hin dürften wir noch überein stimmen. Nun rufe ich eine Methode getPlugin(NameDesPlugins) Serverseitg auf. Diese Methode durchläuft alle angemeldeten Plugins und sucht nach dem passenden Plugin. Jedes Plugin, welches auf dem Server eingeladen wurde, implementiert ein GenericPlugin-Interface. Dort wird eine Methode 'getRemoteObject()' definiert, welche das per UnicasdtRemoteObject.exportObject(Remote object) exportierte Objekt zurück liefert. Eben ein Objekt vom Typ 'Remote', welches das Plugin ja mitliefert. Deswegen liefert die Methode 'getPlugin(name)' vom Server-Core ein Objekt vom Typ 'Remote' zurück. Das Plugin, welches diese Methode auf dem Server-Core aufgerufen hat, weiss ja, um welches konkrete Objekt es sich handelt und castet es entsprechend (also jetzt wieder das Plugin auf der Client-Seite). Hier entsteht nun die Exception, welches ja mein Problem darstellt. Angenommen ich hätte dieses Problem nicht und alles würde wunderbar klappen, so könnte ich nun ganz bequem die rmi-Methoden des Plugins auf der Server-Seite aufrufen, ohne den Umstand über irgendwleche indirekten Calls per String zu machen, die obendrein noch umständlich interpretiert werden müssten. Ganz zu schweingen von der Möglichkeit variable Objekte überteragen zu können für Plugins. Diese müsste ich dann in andere Objekte Kapseln und serverseitig wieder auspacken und benutzen. RMI liegt doch auf der Hand? Oder irre ich mich da? Für irgendwas MUSS das Zeug doch zu gebrauchen sein...

Gruß

 

[Bleiglanz]

ist schon gut

für mich sieht das fast so aus, als ob du die Registry nachprogrammieren willst??

das Problem ist wahrscheinlich nur der "dynamische Classloader", wenn sich deine Plugins nicht im Classpath befinden, dann hast du IMHO den Ärger mit den "verschiedenen Stubs"

hast du das schon mal getestet: mit ant starten und alle jars im Pluginverzeichnis in den Classpath mit aufnehmen (nur mal zum Testen obs dann funktioniert)

 

[mfernau]

ist schon gut

für mich sieht das fast so aus, als ob du die Registry nachprogrammieren willst??

Eigentlich nicht. So schlimm sehe ich das jetzt auch nicht Alles was ich im prinzip möchte ist, dass ich die vom Server zurückgelieferten Remote-Objekte fernsteuern kann. Ist so eigentlich erstmal gar nicht soo ungewöhnlich. Extra dafür gibts ja schließelich das UnicastRemoteObject.exportObject. Damit man nach belieben andere Remote-Objekte nach Außen zugreifbar machen kann

das Problem ist wahrscheinlich nur der "dynamische Classloader", wenn sich deine Plugins nicht im Classpath befinden, dann hast du IMHO den Ärger mit den "verschiedenen Stubs"

hast du das schon mal getestet: mit ant starten und alle jars im Pluginverzeichnis in den Classpath mit aufnehmen (nur mal zum Testen obs dann funktioniert)

Genau so sehe ich das auch. Es ist definitiv nur dieses eine Problem. Denn starte ich mein Programm so, dass ich die JAR-Datei in den Classpath einbeziehe, dann funktioniert das Programm ohne zu murren.

Werde mir das mit dem dynamischen Laden der Stubs per Codebase wohl mal genauer überlegen müssen. Vielleicht gibt es ja noch einen halbwegs brauchbaren Kompromiss. Dann lade ich die Stubs eben per http o.ä. - Obwohl alles bereits vorhanden ist *seufz*. Irgendwie blöde...