Es gibt grundsätzlich zwei Möglichkeiten einem Tomcat-Server via JMX Informationen zu entlocken:

1. JMX-Proxy der Manager-Applikation des Tomcat
2. Aktivierung des JMX-Agenten der JVM (ab 1.5)

Beide Varianten glänzen erstmal dadurch, dass sie die Systemsicherheit kompromitieren (können). Da die sich potentiell auftuenden Löcher aber sehr unterschiedlich sind lassen sich beide Varianten hinsichtlich der Sicherheit aber schlecht vergleichen. Letzendlich muss man wohl wissen, welche Daten man auf welchem Weg erlangen möchte und damit den Hautptausschlag für eine der beiden Varianten geben.

JMX-Proxy der Manager-Applikation

Die Manager-Applikation des Tomcat beinhaltet auch ein Servlet zum Zugriff auf die per JMX vom Tomcat bereitgestellten Parameter. Einzige Voraussetzung - die Manager-Applikation muss installiert sein.

Der Aufruf der URL http://server:port/manager/jmxproxy zeigt eine längliche Liste aller verfügbaren JMX-Informationen an. Die Suche nach dedizierten Werten ist über einen Query-Parameter möglich. Beispielweise liefert der Request http://localhost:8080/manager/jmxproxy?qry=Catalina:type=ThreadPool,name=http-8080 Kenndaten über die vom Server aktuell gehaltenen Threads.

Leider gibt es meines Wissens keine Übersicht über alle möglichen Abfragen. Hier muss man wohl einfach ein bisschen rumsuchen.

Eine (sehr) kurze Einführung in das JMX-Proxy-Servlet gibt es auf der Tomcat-Seite.

Aktivierung des JMX-Agenten der JVM

Die Aktivierung des JMX-Agenten der JVM ist sicherlich die elegantere Lösung - bietet sich hier doch die Möglichkeit über vorhandene JMX-Konsolen auf die Daten zuzgreifen.

Die Aktivierung des JMX-Agenten wird bei Sun recht ausführlich beschrieben. Die Optionen reichen von einer Aktivierung nur für den Lokalen Zugriff bis hin zum Remote-Zugriff via SSL. Je höher die Sicherheitsaspekte um so höher leider auch der Aufwand bei der Konfiguration.

Zum Zugriff bietet sich die JMX-Konsole (jconsole) an, die von Java ab Version 1.5 mitgeliefert wird. Damit kann man recht komfortabel im Baum der vom JMX-Agenten bereitgestellten Informationen browsen.

Fazit

Wenn man weiss, welche Informationen man auslesen muss dann ist sicherlich das JMX-Proxy-Servlet ausreichend. Baut man in die Applikationen recht umfangreiche Möglichkeiten zum Management via JMX ein so ist die Aktivierung des JMX-Agenten vermutlich die bessere Lösung. Zumal sich dort auch die "besseren" Sicherheitsfeatures umsetzen lassen.

Selenium
Selenium IDE
Selenium in action

Noch ein paar allgemeinere Links zum Thema: http://jroller.com/page/theyogi?entry=soa_testing

Warum kann eine Software vor der Installation nicht einen Systemcheck machen und mir alle noch fehlenden Komponenten auflisten? Davon, dass diese Abhängigkeiten auch automatisch aufgelöst werden will ich mal gar nicht reden. Nein, da muss ich x-mal den Installer aufrufen um erst gesagt zu bekommen dass der Systeminstaller nicht aktuell ist. Beim nächsten Versuch ist es die Laufzeitumgebung einer wichtigen Programmiersprache. Danach noch Komponenten für Datenzugriffe.

Und als I-Tüpfel noch dass die Installation abbricht und man tief in den Resten der Installation rumwühlen muss um am Installer vorbei eine Clientkomponenten zu installieren.

Naja, sowas erwartet man von einer zusammengefrickelten Software an der sich eine handvoll Informatikstudenten im 3. Semester austoben. Doof nur, dass da nicht nur ein paar Leute dran rumfrickeln. Nein, das alles passiert einem, wenn man MS-SQL-Express auf Windows 2000 installieren will. Da soll noch einmal jemand über Frickelsoftware aus dem OpenSource-Lager meckern.

Mit so einer Scheisse versaut man sich nun den halben Arbeitstag. Können die Leute keine ordentlichen Datenbanken verwenden? Von mir aus auch Oracle - da kann ich mir wenigstens das OS raussuchen mit dem ich auf die Fresse fallen will.

Leider hat es aus Zeitgründen in diesem Jahr nicht mit einer aktive Teilnahme geklappt. Entgehen lassen wollte ich mir die Chemnitzer Linux-Tage trotzdem nicht.

Plus: mehr Aussteller in diesem Jahr - jedenfalls nach meinem Eindruck. Alte Bekannte wieder getroffen und trotz meiner knappen Zeit nett geschwatzt.

Minus: Von den drei Vorträgen, die ich mir anhören wollte fiel einer aus und die beiden anderen waren unter aller Sau. Der eine war letztendlich nur eine sehr einfache Demo einer mit einer kruden OS-Lizenz versehenen CMS-Software. Der andere war fachlich einfach nur flach. Wenn es darum geht, wie ich mit Eclipse RCP-Applikation bauen kann, dann reicht es eben nicht, zu erklären, was ist Java, was ist Eclipse und wie sieht dessen Bildschirmaufbau aus (das sollte man nämlich als Grundwissen voraussetzen) und ansonsten einmal alle Wizards für die Erstellung von Eclipse-Plugins durchzuklicken. Ebensowenig reicht es aus, als Lückenfüller ein Video-Statement von RMS laufen zu lassen, in dem er verkündet dass die Java Trap nun überwunden ist oder mal kurz bekannte RCP-Applikationen zu starten. Vielmehr hätte ich erwartet, dass zumindest die einzelnen Komponenten einer RCP-Applikation und die Grundsätze des Plugin-Konzepts unter Eclipse erläutert werden.

Fazit: nächstes Jahr selbst wieder aktiv mitmachen. Das bringt mich fachlich selbst ein bisschen voran und macht ein gutes Gefühl.