Ich habe Methoden zur Remoteverwaltung in meinem Anwendungsserver mithilfe von JMX durch Erstellen einer MXBean-Schnittstelle und einer Klasse zum Implementieren von Methoden verfügbar gemacht. In dieser Schnittstelle sind Operationen zum Festlegen von Attributen auf meinem Server und zum Abrufen des aktuellen Werts von Attributen enthalten. Nehmen Sie zum Beispiel die folgenden Methoden:
%Vor%Das WordsObject ist eine benutzerdefinierte serialisierbare Klasse, die zum Abrufen von Daten über den Status des Servers verwendet wird. Dann habe ich auch eine WordManager-Klasse, die die obige Schnittstelle implementiert. Ich erstelle dann einen JMX-Agenten, um meine Ressource zu verwalten:
%Vor%Ich habe einen Client erstellt, der diese Methoden aufruft, und das funktioniert wie erwartet. Ich möchte jedoch diese aktuelle Konfiguration erweitern, indem ich benutzerdefinierte Ausnahmen hinzufüge, die an meinen Client zurückgeschickt werden können. Also würde ich gerne meine Schnittstelle zu etwas wie diesem ändern:
%Vor%Meine WordAlreadyExistsException sieht folgendermaßen aus:
%Vor%Wenn ich die addWord () -Methode in meinem Client aufruft, möchte ich eine WordAlreadyExistsException zurückholen, wenn das Wort bereits existiert. Wenn ich dies jedoch tue, erhalte ich einen Fehler wie folgt:
%Vor%Die WordAlreadyExistsException, das WordsObject und das WordManagerMXBean-Interface befinden sich alle in einer einzigen JAR-Datei, die sowohl für den Client als auch für den Server verfügbar ist. Wenn ich die Methode getWords () aufruft, hat der Client keine Probleme mit dem WordsObject. Wenn jedoch eine benutzerdefinierte Ausnahme wie die obige ausgelöst wird, gibt der Client den oben angezeigten Fehler aus. Ist es möglich, JMX so zu konfigurieren, dass diese Ausnahme im Client korrekt gehandhabt wird?
Nach einer Suche habe ich festgestellt, dass es eine MBeanException-Klasse gibt, die zum Umbrechen von Ausnahmen verwendet wird. Ich bin mir nicht sicher, ob diese Umhüllung vom Agenten automatisch ausgeführt wird, oder ob ich selbst die Umhüllung machen soll. Ich habe beides versucht, aber in beiden Fällen bekomme ich den gleichen Fehler auf dem Client.
Ich habe das auch mit aktivierten und deaktivierten Ausnahmen versucht, wieder der gleiche Fehler auftritt.
Eine Lösung besteht darin, einfach die Fehlerzeichenfolge innerhalb eines generischen Fehlers zurückzugeben, da alle Standard-Java-Ausnahmen funktionieren. Aber ich würde es vorziehen, die tatsächliche Ausnahme für die Verarbeitung durch den Client zurück zu bekommen.
Ist es möglich, benutzerdefinierte Ausnahmen in JMX zu behandeln? Wenn ja, irgendwelche Ideen wie?
BEARBEITEN: Einschließlich vollständiger Stapel-Trace
%Vor%Ich habe versucht, das Problem zu reproduzieren, aber es funktioniert gut für mich ;-(. Siehe die Ausnahme Ausgabe unten. Ich würde auch wetten, dass es wirklich ein Problem beim Laden von Klassen auf der Clientseite ist. Ist es möglich, dass Sie könnten posten (eine abgespeckte Version) Ihres Client-Jar (und vielleicht auch die Quelle)?
%Vor%Was passieren kann, ist, dass Ihre benutzerdefinierte Ausnahme serialisiert und dann wieder in den Anwendungsserver deserialisiert wird, aber in einem anderen, für das Fehlen eines besseren Wortes, "Classloader-Namespace".
Versuchen Sie, die JAR-Datei (c) mit den benutzerdefinierten Ausnahmeklassen zusammen mit Ihren JMX-JAR-Dateien zu platzieren, die der AppServer verwendet. Stellen Sie sicher, dass Sie die alten Gläser vom alten Standort entfernen (ich nehme an, dass es irgendwo in WEB-INF / lib ist.
Es ist definitiv möglich, benutzerdefinierte Ausnahmen auszulösen, obwohl dies nicht empfohlen wird. Von JMX-Best Practices :
Es wird empfohlen, Ausnahmen, die von MBeans ausgelöst werden, aus der Standardsatz, der in den Paketen Java. * und Javax. * auf der Java SE definiert ist Plattform. Wenn eine MBean eine nicht standardmäßige Ausnahme auslöst, ein Client, der Wenn diese Ausnahmeklasse nicht vorhanden ist, wird wahrscheinlich eine weitere Ausnahme angezeigt wie zum Beispiel ClassNotFoundException.
Daher würde ich etwas Geld investieren, dass Ihr Kunde die WordAlreadyExistsException -Klasse einfach nicht geladen hat. Sie können das ganz einfach überprüfen - schreiben Sie eine Methode in den Client , die diese Ausnahme auslöst, rufen Sie sie auf und sehen Sie, was passiert. Wenn alles OK war (OK = benutzerdefinierte Ausnahme wurde ausgelöst, no ClassNotFoundException ), stellen Sie sicher, dass Ihr Client und Ihr Server dieselbe Version von jar haben, die WordAlreadyExistsException enthält. Selbst die geringste Abweichung (z. B. im Paketnamen) kann die Ursache für Ihr Problem sein.
Ihre Ausnahme muss von
ausgehen %Vor%oder
%Vor%falls es sich um eine RuntimeException handelt.
Anstatt RuntimeMBeanException zu erweitern, übergeben Sie einfach Ihre RuntimeException als Konstruktorargument für RuntimeMBeanException und lösen diese Ausnahme aus. Stellen Sie sicher, dass JAR-Dateien im CLASSPATH vorhanden sind.
Das Erweitern von RuntimeMBeanException funktioniert möglicherweise auch, vorausgesetzt, die JAR-Datei ist im Klassenpfad vorhanden, aber ich habe das nicht getestet
Tags und Links java exception-handling jmx