Hallo zusammen.
Ich hänge jetzt schon den halben Tag an einem Problem und hoffe ihr könnt mir weiterhelfen.
Das Szenario ist folgendes.
Ich habe eine Applikation die bspw auf einem Rechner läuft und auf deren Oberfläche man bestimmte Objekte modellieren kann. Auf einem anderen Rechner / dem Server müssen anhand dieser Modellierungen geeignete Wrapper-Klassen generiert werden, um mit eingehenden Daten entsprechend umgehen zu können. Soweit so gut was die Anforderungen angeht.
Ich bin soweit, dass aus den Modellen zur Laufzeit, die Wrapper-Klasse generiert/kompiliert wird. Um sie dann zur Laufzeit zu verwenden, habe ich mir zusätzlich einen eigenen ClassLoader geschrieben. Dieser liest die .class Datei ein und gibt mir per defineClass-Methode der Vaterklasse "ClassLoader" den Zugriff auf die Klasse. Soweit funktioniert auch alles.
Es soll dem Anwender aber natürlich möglich sein, diese Modelle auch zu verändern. Die Veränderung zieht eine Neu-Generierung der Wrapper-Klassen auf serverseite nach sich, was ebenfalls zur Laufzeit möglich sein soll. Ich lösche demnach zuerst die alte .class Datei, versuche alle Referenzen auf diese Klasse zu löschen und durchlaufe anschließend den obe beschriebenen Schritt der Generierung. Hier kommt es dann aber zum Fehler, da die defineClass Methode abbricht mit der Fehlermeldung, dass die Klasse bereits bekannt ist. Dabei handelt es sich aber um die alte Klasse, die ich überschreiben will. Also scheint es, als habe jeder ClassLoader bzw die VM einen eigenen Class-Cache, auf den ich keinen Zugriff habe.
Deshalb meine Frage, ob ihr mit sowas schon Erfahrung gemacht habt und mir an der Stelle weiterhelfen könnt. Ich habe auch schon den Tag lang nach Lösungen im Internet gesucht, aber die Spuren verliefen sich irgendwann alle im Sande.
Vielen Dank im voraus für alle Antworten.
PS:
Ich habe als Workaround zunächst immer eine neue ClassLoader Instanz erzeugt, um die defineClass Methode aufzurufen, was zwar das Problem zunächst behebt, aber an anderen Stellen wieder neue Probleme aufwirft. Ergo leider keine nutzbare Lösung.
Ich hänge jetzt schon den halben Tag an einem Problem und hoffe ihr könnt mir weiterhelfen.
Das Szenario ist folgendes.
Ich habe eine Applikation die bspw auf einem Rechner läuft und auf deren Oberfläche man bestimmte Objekte modellieren kann. Auf einem anderen Rechner / dem Server müssen anhand dieser Modellierungen geeignete Wrapper-Klassen generiert werden, um mit eingehenden Daten entsprechend umgehen zu können. Soweit so gut was die Anforderungen angeht.
Ich bin soweit, dass aus den Modellen zur Laufzeit, die Wrapper-Klasse generiert/kompiliert wird. Um sie dann zur Laufzeit zu verwenden, habe ich mir zusätzlich einen eigenen ClassLoader geschrieben. Dieser liest die .class Datei ein und gibt mir per defineClass-Methode der Vaterklasse "ClassLoader" den Zugriff auf die Klasse. Soweit funktioniert auch alles.
Es soll dem Anwender aber natürlich möglich sein, diese Modelle auch zu verändern. Die Veränderung zieht eine Neu-Generierung der Wrapper-Klassen auf serverseite nach sich, was ebenfalls zur Laufzeit möglich sein soll. Ich lösche demnach zuerst die alte .class Datei, versuche alle Referenzen auf diese Klasse zu löschen und durchlaufe anschließend den obe beschriebenen Schritt der Generierung. Hier kommt es dann aber zum Fehler, da die defineClass Methode abbricht mit der Fehlermeldung, dass die Klasse bereits bekannt ist. Dabei handelt es sich aber um die alte Klasse, die ich überschreiben will. Also scheint es, als habe jeder ClassLoader bzw die VM einen eigenen Class-Cache, auf den ich keinen Zugriff habe.
Deshalb meine Frage, ob ihr mit sowas schon Erfahrung gemacht habt und mir an der Stelle weiterhelfen könnt. Ich habe auch schon den Tag lang nach Lösungen im Internet gesucht, aber die Spuren verliefen sich irgendwann alle im Sande.
Vielen Dank im voraus für alle Antworten.
PS:
Ich habe als Workaround zunächst immer eine neue ClassLoader Instanz erzeugt, um die defineClass Methode aufzurufen, was zwar das Problem zunächst behebt, aber an anderen Stellen wieder neue Probleme aufwirft. Ergo leider keine nutzbare Lösung.