Während meines Jahreswechselurlaubes versuche ich immer ein wenig Bildungsurlaub zwischenzuschieben. Dazu zählt der chaos communication congress ebenso wie manche Fingerübung. Aus einer dieser Fingerübung entstand ein kleines Projekt, das bis zu einem GitHub-Repository gewachsen ist...

Nachdem ich einen Log4J-Appender gebaut hatte, der die einzelnen Log-Messages in einer Swing-GUI anzeigen kann wollte ich diese Idee ein wenig ausbauen - zunächst schwebte mir eine Stand-Alone-JMX-Anwendung vor, die die Log-Events per JMX gemeldet bekommt und in der man dann eine GUI hat, mit der man Filter konfigurieren und einzelne Logger und Log-Level ein- und ausschalten kann.

Dafür wäre es allerdings nötig gewesen, dass ich eine JMX-Verbindung lokal zu einer laufenden Java-Anwendung aufbauen kann. Meine verzweifelte Suche nach Informationen, wie die Connect-URL in diesem Fall aussehen muss bescherte mir Einblicke in die internen Funktionen einer Oracle-VM: wer schon einmal die JConsole gestartet hat, hat wahrscheinlich gesehen, dass man sich damit zu jeder aktuell laufenden Java-Anwendung verbinden kann.

Das bedeutet nicht, dass die Anwendungen per default immer einen Port für das JMX-Protokoll öffnen. Vielmehr ist es so, dass jede VM eine Schnittstelle hat, über die man sie verwalten und steuern kann (die Attach-Schnittstelle). Verbindet sich die JConsole nun mit einer Anwendung, bringt sie eine Instrumentierung über diese Schnittstelle ein, die den VM-seitigen Port für das JMX-Protokoll darstellt. Erst danach wird die lokale Verbindung zu diesem Port aufgebaut.

Wollte man dies in eigenen Applikationen nachstellen, nüsste man Klassen aus proprietären Paketen nutzen und das Ganze wäre so komplex und fragil, dass es mit einem Bugfix-Release für die JRE wahrscheinlich schon wieder zunichte gemacht werden würde.

An dieser Stelle mit meinen Versuchen angekommen fluchte ich bereits wieder auf die JConsole denn meiner Meinung nach hat Sun/Oracle hier beim Verbindungsmanagement versagt. Ich erinnerte mich an VisualVM und machte damit weiter.

Einer der Appender hatte ja bereits die Möglichkeit geboten, Log4J Log-Events als JMX-Notifications zu versenden. Die JConsole bietet allerdings keinerlei Filtermöglichkeiten für JMX-Notifications ann - entweder man wird mit allen zugeschüttet oder man erhält gar keine. Meine Idee also: vielleicht kann die VisualVM besser mit JMX und speziell mit Notifications umgehen?

Ich wurde zunächst desillusioniert: In VisualVM existiert nichts zu JMX - keine Unterstützung für Notifications und nicht einmal für MBeans. Das konnte ich nicht glauben und suchte im Internet - siehe da: Die Unterstützung existiert - allerdings in Form eines Plugins, das man erst nachinstallieren muss.

Das tat ich und nun hatte ich exakt dieselbe Funktionalität, die in der JConsole zur Verfügung steht. Dass brachte mich aber auf eine Idee: wenn es eine Plugin-Architektur gibt, muss es doch eine API und Dokumentation dafür geben - damit wäre ich in der Lage, ein eigenes Plugin zu schreiben: Dann würde die Instrumentierung und der Aufbau der JMX-Kommunikation von VisualVM erledigt und ich könnte mich auf das Filtern,... der Notifications konzentrieren.

Die Dokumentation war schnell gefunden - als ich allerdings bereits zu Anfang las: Öffne Netbeans und lege ein neues Projekt vom Typ Netbeans-Modul an... Ich habe viele Jahre lang gern und mit Erfolg Netbeans als IDE benutzt. Aber immer wenn Vendor Lock-In auch nur entfernt erahnbar ist kriege ich Fieberbläschen!!

Das Projekt war damit schon fast gestorben, als ich aus den Augenwinkeln ein VisualVM-Plugin erspähte, das es gestattete JConsole-Plugins in VisualVM zu nutzen. Das sah ich mir näher an und siehe da: Nicht nur war die Schnittstelle wesentlich simpler als die für die direkte Integration in VisualVM, es gab auch Beispiele dafür und ich konnte damit Plugins schreiben, die in beiden Anwendungen nutzbar waren und war nicht auf eine bestimmte IDE festgelegt. Dazu kommt noch, dass es sehr einfach ist, neue Plugins als Maven-Projekte zu realisieren. Man kann eigene Projekte auf diversenBeispielen GitHub einsehbar.

Artikel, die hierher verlinken