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.