Dyn. Nachladen von veränderten Klassen in Multiprozesssystem

[babuschka]

Hallo zusammen

Ich habe hier eine kleine aber feine Problemstellung. Prof. Meixner meinte dazu, "Ein nicht triviales Problem".

Es geht um folgendes:
Wir haben drei Klassen A, B und C. Jede dieser Klassen besitzt Attribute mit allen erlaubten Modifiern und stellt Methoden bereit.
A hat wie auch C eine Referenz auf ein B-Objekt. (die _gleiche_ Referenz)
A hat zusätzlich eine Referenz auf ein C-Objekt.
B hat eine Referent auf ein C-Objekt.

A ---> B <---> C
|              ^
|              |
+--------------+

Nun gibt es _zwei_ Prozesse P1 und P2 (zwei main-Threads, nicht zwei Threads in einer main), die beide auf die Klassen zugreifen.
P1 -> A, B
P2 -> B, C
=> B wird in beiden Prozessen per implizitem ClassLoading geladen und verwendet.

Nun zum Problem:
B wird verändert (Methode löschen, ändern, hinzufügen, usw.).
Wie ist es möglich B in die _laufenden_ Prozesse einzuschleusen? Was passiert mit den bestehenden Referenzen in A und C auf B? Müssen A und C auch neu geladen werden?
Und zuletzt wie realisiert man dieses Szenario?


Lösungsansatz:
URLClassLoader verwenden. (hab ehrlich gesagt nicht zu 100% verstanden, was er bringt)
In diesem Buch [OpenBook: Java ist auch eine Insel] wird eine ähnliche Problematik angesprochen. Sie hilft _mir_ nur leider nicht weiter.


Ich würde mich freuen, wenn ihr mir helfen könntet.

Mit freundlichen Grüßen
Jojo

 

[oldshoe]

Ich glaube da könntest du mit Semaphoren für Interprozesskommunikation weiterkommen.

 

[Noctarius]

Wenn du Interfaces injectest anstatt den festen Implementierungen kannst du Implementierungen zur Laufzeit neu laden und auf das Interface zurückcasten.

 

[babuschka]

@oldshoe
Dumme Frage, aber was sind "Semaphoren" ?

@Noctarius
Ja klar verwende ich Interfaces. Aber ich möchte nicht, wenn ich eine Klasse ändere gleich ihren Namen ändern. Das wäre zwar eine simple Lösung den veränderten Namen per Configreload zu injezieren und anschließend per Refelection die neue Klasse zu erstelle, aber ehrlich gesagt ... find ichs nicht schön :-(
Oder hast du dir das anders vorgestellt ?

 

[Noctarius]

Wieso umbenennen?

 

[babuschka]

sonst wird sie doch nicht mehr neu geladen...

Ich änder in der Factory-Klasse den Namen der Klasse, die sie erstellt und somit muss auch die Klasse umbenannt werden ...

Oder wie hast du dir das gedacht ?

 

[Noctarius]

Sicher kannst du sie jederzeit neu laden. Du schmeisst den alten URLClassLoader weg, nimmst nen neuen, lädst die Klasse neu.

Deswegen ja ClassLoader1.Foo != ClassLoader2.Foo

Aber da du immer auf das Interface zurückcasten kannst benutzt du die neue Klasse ganz normal weiter.

 

[babuschka]

okay ...

Dann werd ich mir mal das mit dem URLClassLoader genauer anschauen. Falls sich weitere Fragen auftun, werd ich wieder vorbeischauen.

Mir ist nur etwas unklar was passiert, wenn ich ein Interface ändere.

 

[Noctarius]

Ein Interface kannst du nicht ändern, da das Interface vm Standardclassloader geladen werden muss, sonst steht es hinterher nicht mehr zur Verfügung.

 

[babuschka]

Also ist das System auf Klassen eingeschränkt, die Interfaces implementieren, nie direkt sondern nur über Interfaces angesprochen werden und nicht vom Standard-ClassLoader geladen werden können ?

 

[Noctarius]

Genaustens verstanden

 

[babuschka]

Siehst du eine Möglichkeit diese Einschränkungen zu minimieren ?
Zumindest soweit, dass man auch Interfaces "HotSwap"-en kann.

Ich habe mir gerade ein kleines Testprogramm zusammengebaut.
Wenn ich die Klasse B lade und auf ein Interface casten will ...
ClassCastException

Das Beispiel zum Testen kommt gleich ;9

 

[Noctarius]

Jein. Du kannst das System natürlich ausdehnen:

SystemClassLoader -> ApplicationClassLoader (Standard) -> InterfaceClassLoader (läd die Interfaces) -> ImplementationClassLoader

Mit so einer Hierarchie kannst du auch die Interfaces neuladen, Musst allerdings dann alle dahinter liegenden Implementierungen auch "aktuallisieren".

Zeig mal deinen Beispielcode.

 

[babuschka]

Beispielcode

// Interface C
public interface C { }

// Class B
public class B implements C {
	static {
		System.out.println("Loading B:");
		System.out.println("Loader = " + B.class.getClassLoader().getClass().getName());
		System.out.println();
	}
}

// Tester
public class Tester {
	public static void main(String[] args) throws Exception {
		URL u = (new File("bin/")).toURI().toURL();
		URLClassLoader loader = new URLClassLoader(new URL[] {u}, null);
		
		Class<?> clazz = loader.loadClass("misc.B");
		C c = (C) clazz.newInstance();
	}
}

Das Ergebnis bei mir ist:

Loading B:
Loader = java.net.URLClassLoader
UID = 2

Exception in thread "main" java.lang.ClassCastException: misc.B cannot be cast to misc.C
	at process.Process.main(Process.java:16)

 

[Noctarius]

Geb dem URLClassLoader den aktuellen Classloader als Parent mit

 

[babuschka]

Hab ich auch schon ausprobiert.
Also im Prinzip das ", null" rauslöschen -> AppClassLoader wird als Parent genommen.
Dann wird die Klasse nur einmal geladen.
-> Cast funktioniert aber

Allerdings läd jetz der AppClassLoader die Klasse.
-> Ist aber auch logisch. Er darf ja _vor_ dem URLCL arbeiten.


Nochmal zurück zum Problem:
Wie du vorhin schon geschrieben hast müsste ich mein System ausweiten um auch Interfaces nachladen zu können. Genau das brauche ich.
Das System um das es sich hier handelt ist folgendes.

Das Programm wird entwickelt. Es entstehen mehrere hundert Klassen.
Um eine bessere Skalierbarkeit zu erhalten wird das Programm in Prozesse aufgeteilt. Jeder Prozess kann beliebige Klassen verwenden. Es gibt einen Wächterprozess, der alle Prozesse ansprechen und Befehle übermitteln kann.
Einer der Befehle wird sein:

Reload de.xxx.yyy.misc.B

Wenn nun eine beliebige Änderung am Programm vorgenommen wird, loggt man sich beim Wächter ein und schickt die "Reload"-Befehle an alle Prozesse, die registriert sind.
Somit sollten Änderungen on-the-fly in das laufende System injiziert werden können.

Wichtig ist, dass es wirklich _beliebige_ Änderungen sein sollen.

 

[maki]

Schon mal was von OSGi gehört?
Oder muss es eine Eigenentwicklung sein?

 

[babuschka]

mhm ...
OSGi
gehört, ja. Aber noch nicht genauer angesehen.
Meinst du dass mir das weiterhilft ?

 

[maki]

Ja, meine ich, zumindest wenn ich mir deine Anforderungen anhöre.

Hello, OSGi, Part 1: Bundles for beginners - JavaWorld
Hello, OSGi, Part 2: Introduction to Spring Dynamic Modules - JavaWorld
Hello, OSGi, Part 3: Take it to the server side - JavaWorld

 

[babuschka]

ahhhhhh

Das hört sich echt interessant an
Danke für die Links. Werd ich mir mal reinziehen.

 

[babuschka]

sodala

Mein Prof hat mir gerade einen Tipp gegeben.
JBoss.

Hast du da auch ähnliche Infos wie zu OSGi ?
Ansonsten würd ich mich mal auf die Suche begeben.

 

[Noctarius]

Also wenn du dich schon in irgendwas einarbeiten magst würde ich ServiceMix empfehlen anstatt JBoss Ich mag die SpringDM Integration.

Aber gleich zu Anfang OSGi hat eine sehr steile Lernkurve, die gilt es vorab zu erklimmen. Hast du das einmal geschafft wird es mit der Zeit immer einfacher. Aber die ersten Dinge sind echt hart zum Laufen zu bewegen. Wobei neue Projekte immer schneller gehen als bestehende zu wrappen wie ich es musste

 

[babuschka]

Du meinst also ich sollte zuerst OSGi "erlernen" bevor ich mich an JBoss bzw. ServiceMix mache?

 

[Noctarius]

ServiceMix ist OSGi mit Spring (DM) Integration, was den Einstieg in OSGi um LÄngen vereinfachen kann. Daher würde ich immer entweder direkt den SpringDM Server von SpringSource oder alternativ den auf Felix (eine OSGi Implementierung von Apache) basierenden ServiceMix (mein Favorit) benutzen. Gerade beim Einstieg.

OSGi Grundwissen / -verständnis brauchst du aber trotzdem. Hier sind aber genug Leute die dir beim Einstieg in OSGi beistehen können, weil ohne Menthor ist das extrem schwer (finde ich).

 

[babuschka]

Evtl. "dumme" Frage:
Du bist dir sicher, dass SpringDM oder Felix den, von meinem Prof. vorgeschlagenen JBoss, ersetzen kann?

Wärst du bereit mich ein wenig beim Einstieg in OSGi zu unterstützen?

 

[Noctarius]

JBoss ist ein EJB Server, während SpringDM und ServiceMix die EJB Spezifikation nur bedingt unterstützen (mit richtigem OSGi Bundle). SpringDM und ServiceMix bieten dir grundlegend einen OSGi Kern mit einigen bereits mitgelieferten Features, z.B. einem MessageBus, Routingdienste und ähnlichen. Bei beiden werden die Spring Dynamic Modules unterstützt (daher heißt auch der SpringSource Server SpringDM) welche versuchen viel interna des OSGi nach Außen hin ein wenig zu kapseln und zu vereinfachen.

Mit dem passenden Maven Plugin (z.B. dem Felix Bundler oder dem von SpringSource) geht ein einfaches TestBundle auch fix von der Hand, zumal man dank Spring Unterstützung nahezu jedes Springbean OSGifizieren kann.

Felix selbst ist kein "Server" sondern eine OSGi Implementierung wie z.B. auch Equinox, welches unter Eclipse sein Werk verrichtet.

Auf was der JBoss basiert bin ich mir jetzt nicht mal ganz sicher, ich meine der benutzt auch Equinox, würde mich aber nicht darauf versteifen.

Zum Thema "In OSGi einarbeiten":
Ich würde sagen wenn Fragen auftreten immer allgemein im Forum fragen, hier gibt es genug Leute die täglich mit OSGi kämpfen (sorry wildcard *gg*). Also Fragen solltest du immer recht zügig beantwortet bekommen. Ich selbst habe vor etwa 6-8 Wochen angefangen mich stärker mit OSGi zu beschäftigen, hatte aber eben nen Kollegen der da schon etwas länger dran rumkämpfte und den ich immer fragen konnte wenn es zwickte.