RMI-Schnittstelle in ein Eclipse-Plugin einbauen

achimheynen

Grünschnabel
Hallo
Ich werkel seit ein paar Tagen an folgendem Problem herum:
Ich habe für Eclipse ein paar Plugins geschrieben, die später in Client-Server-Struktur laufen sollen. Die Kommunikation soll per RMI umgesetzt werden und geschrieben wird der Kram unter Java 5.
Geplant ist, dass das Hauptplugin des Servers diverse andere Plugins über Extensionpoints instanziiert/startet und eines davon soll der UserManager sein, der eine RMI-Schnittstelle für die Clients anbietet. Durch die Benutzung von Extensionpoints wird die Klasse aber nicht wie in den meisten (allen?) RMI-Beispielen einzeln und über die main-Methode gestartet sondern eine Instanz erzeugt, die den Constructor aufruft. Aus dem Grund habe ich erstmal versucht, des Binden des RMI-Servers in den Constructor zu legen. Hier ein Codeausschnitt des Usermanagers:
Code:
public class UserManager extends UnicastRemoteObject implements IUserManager {

	private static Registry rmiRegistry;

	public UserManager() throws RemoteException {
		super();
		try {
			getRmiRegistry(RMI_PORT).rebind("rmi://localhost/" + RMI_NAME, this);
		} catch (Exception ex) {
			// TODO error handling
		}
	}

	protected static Registry getRmiRegistry(int port) {
		if (rmiRegistry == null) {
			try {
				// try to create a new registry
				rmiRegistry = LocateRegistry.createRegistry(port);
			} catch (RemoteException ex) {
				// registry already existed on this machine, so connect to it
				try {
					rmiRegistry = LocateRegistry.getRegistry(port);
				} catch (RemoteException rex) {
					// TODO error handling
				}
			}
		}
		return rmiRegistry;
	}
}

Das wirft zumindest keine Exception ;) In einem von Toms Tutorials hatte ich folgendes gefunden (Code an mein Beispiel angepasst):

Code:
IUserManager stub = (IUserManager) UnicastRemoteObject.exportObject(this, 0);
getRmiRegistry(1099).rebind("rmi://localhost/" + RMI_NAME, stub);

Wenn man den Code anstelle des rebind in den Constructor packt, raucht es allerdings in der ersten Zeile mit folgender Exception-Message ab:
java.rmi.StubNotFoundException: Stub class not found: de.upb.swt.amfibia.engine.usermanagement.UserManager_Stub; nested exception is:
java.lang.ClassNotFoundException: de.upb.swt.amfibia.engine.usermanagement.UserManager_Stub

Da gibt's also offensichtliche Probleme, den Stub zu finden/zu erstellen. Da man zur automatischen Stub-Erstellung ja auch einen Parameter beim Start mitgeben muss, habe ich das natürlich versucht. Da die Plugins von Eclipse selber gestartet werden, habe ich in den Run/Debug-Einstellungen der VM folgende Parameter (Arguments) mit auf den Weg gegeben:
-Djava.rmi.server.ignoreStubClasses=true
-Djava.rmi.server.codebase=file://${workspace_loc}/de.upb.swt.amfibia.engine/
Wenn ich dass dann starte, kommt aber sofort die Fehlermeldung, dass es keine main-Methode gibt. Ich weiß leider gar nicht, welche Klasse als erste instanziiert wird. Wenn ich in die Activator.java des Hauptplugins eine main-Methode einfüge, bringt das nichts.
Da es auf den Weg schon beim Erstellen des RMI-Servers Fehler gibt, habe ich die oben zitierte Variante ohne exportObject weiter verfolgt. Wenn sich der RMI-Client dann aber verbinden will, gibt es diese Exception:
java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
Zu der Fehlermeldung habe ich nichts gefunden, was mich da weitergebracht hat - immerhin bin ich darüber auf dieses Forum gestoßen und würde mich sehr freuen, wenn mir einer von euch weiterhelfen könnte.
 
Hallo!

Wenn ich dass dann starte, kommt aber sofort die Fehlermeldung, dass es keine main-Methode gibt. Ich weiß leider gar nicht, welche Klasse als erste instanziiert wird. Wenn ich in die Activator.java des Hauptplugins eine main-Methode einfüge, bringt das nichts.
Dann hast du sicherlich bei der Angabe der JVM Argumenten einen Fehler gemacht. In der Java Launch/Debug Konfiguration gibt man die Main Klasse separat von den JVM Argumenten an.

Gruss Tom
 
Hallo und Danke, Tom!

Ich habe das Problem nun lösen/umgehen können. Wenn ich keinen SecurityManager benutze, funktioniert es ohne Probleme. Mit SecurityManager geht es erstmal in die Hose, doch weiß ich inzwischen, dass man die Startparameter für die policy und die codebase per System.setProperty(...) zur Laufzeit setzen kann. Da habe ich zwar bisher noch nicht die richtige Einstellung gefunden, aber das hat andere Gründe (es knallt wegen Schreibrechten auf Logfiles). Da es ohne den SecurityManager funktioniert, werde ich erstmal so weitermachen.
Vielen Dank!
 
Zurück