Reflection: NoSuchMethodException obwohl Methode existiert

[nocxsville]

Hi,

Ich möchte eine Instanz einer neuen (dynamisch geladenen) Klasse erzeugen. Ich verwende dazu folgenden (gekürzten) Code:

Class<?extends MySuperClass> clazz = loadClassFromByteArray(array);
MySuperClass instance = clazz.getConstructor(String.class, Integer.class).newInstance("Hallo", Integer.valueOf(12));

Hier die super Klasse:

public class MySuperClass<T> {

// ...

public MySuperClass(String name, Integer value) {
   // ...
}

// ...

}

Und hier die Klasse, die sich in der Datenbank befindet:

public class MySubClass extends MySuperClass<Integer> {

// ...

public MySubClass(String name, Integer value) {
   super(name, value);
   // ...
}

// ...

}

loadClassFromByteArray(byte[]) erzeugt mit Hilfe von ClassLoader.defineClass(...) die Klasse. Das byte[] wird (ohne Konvertierung) aus einer Datenbank geladen. Soweit so gut. Auf einigen Rechnern wirft getConstructor(...) eine NoSuchMethodException mit der Meldung, das es keinen Konstruktor mit den Parametern String, Integer gibt. Wie gesagt, die Exception wird nur auf einigen Rechnern geworfen, auf anderen Rechnern funktioniert der Code. Merkwürdig ist, dass wenn ich vor dem getConstrutor(..) Aufruf durch alle Konstruktoren iteriere, ich den Konstruktor finde. Sprich er existiert.

Ich habe nun schon einige Zeit geopfert, die Unterschiede der einzelnen Rechner zu analysieren.
- verschiedene JVM Versionen (32 Bit / 64 Bit)
- verschiedene Encodings

Leider ohne Erfolg.

Hat einer von euch eine Idee was man noch testen könnte, bzw. woran es liegen könnte? Könnte es evtl. an der Vererbung liegen (nur warum funktioniert es dann auf einigen Rechnern?

Vielen Dank im voraus

 

[musiKk]

Merkwürdig ist, dass wenn ich vor dem getConstrutor(..) Aufruf durch alle Konstruktoren iteriere, ich den Konstruktor finde. Sprich er existiert.

Das macht mich stutzig. Offenbar wird auf manchen Rechnern dort etwas nicht sofort geladen. Mein Rechner gehört "leider" zu denen, auf denen das funktioniert (zumindest in meiner schnell zusammengehackten Variante). Immerhin schließt das solche Fehlerfälle aus, in denen die Klasse aufgrund fehlerhafter Bytes nicht geladen werden konnte.

Hast Du mal die Java-Versionen verglichen (also nicht die Architekturen 32/64bit, sondern... naja... die Java-Version halt)? In meiner 1.6.0_17 von Sun unter 64bit funktionierts jedenfalls.
Das Problem kann eigentlich nichts mit Encodings zu tun haben. Schließlich sollten hier nur uninterpretierte Byte-Arrays im Umlauf sein.

Hast Du mal nach Bug-Reports bei Sun geschaut? Wenn ich dort nach getConstructor suche, finde ich einige. Vielleicht hat jemand anders ein ähnliches Problem.

Wie schauts denn mit [c]getMethod()[/c] aus? Sind dort auch ähnliche Probleme zu finden? Wenn ja, kann die Bug-Suche auch darauf erweitert werden.

 

[nocxsville]

Hi,

Vorab: Danke für den Hinweis.

Ich habe nun die Ursache für den Fehler gefunden. Ich befinde mich in einer Hudson Umgebung (sorry das hatte ich leider vergessen zu sagen). Dort gibt es einen "uber class loader" der alle geladenen Klassen (Hudson core + plug-ins) kennt. Diesen ClassLoader verwende ich als parent. Der eigentliche Fehler tritt auf, wenn mehrere Plug-ins Klassen eines dritten Plug-ins verwenden. Hintergrund: Die Klassen jedes Plug-ins werden in einem seperaten ClassLoader geladen (auch die verwendeten Klassen anderer Plug-ins). Sprich einige Klassen werden redundant (in verschiedneen ClassLoadern geladen. Wenn man nun dynamisch Klassen läd (byte[] > class) schaut der "uber class loader" ob die Klasse bereits geladen wurde und gibt den ersten Treffer zurück. Lieder ist das nicht immer der richtige. Ich habe nun einiges am Design geändert und nun scheint es zu funktionieren.

Grüße
nocxsville