Werden auf dem Tomcat viele einzelne Anwendungen bereit gestellt, steht im Normalfall jede Anwendung in der Pflicht eine eigene, bestenfalls der CI angepasst, Fehlerseite bereit zu stellen. Ab einer gewissen Menge von Anwendungen ist es allerdings außerordentlich mühsam diese im Nachhinein zu integrieren, zu pflegen, geschweige denn alle Versionen auf dem gleichen Stand zu halten.
Einfacher wäre es doch, wenn eine zentrale Custom-Fehlerseite zu sehen ist. Die gute Nachricht? Der Tomcat liefert ja bereits solche Fehlerseiten aus! Die schlechte Nachricht allerdings ist, dass die Seiten nicht so leicht änderbar sind.
Einfacher wäre es doch, wenn eine zentrale Custom-Fehlerseite zu sehen ist. Die gute Nachricht? Der Tomcat liefert ja bereits solche Fehlerseiten aus! Die schlechte Nachricht allerdings ist, dass die Seiten nicht so leicht änderbar sind.
Warum nicht? Die Fehlerseiten, die an dieser Stelle zu sehen sind, werden direkt aus einem Valve heraus erzeugt. Per Default werden die Ausgaben vom org.apache.catalina.valves.ErrorReportValve erzeugt. Dieser sorgt in der Methode protected void report(Request request,Response response,Throwable throwable) dafür, dass die bereits bekannten Fehlerseiten gerendert werden. Und genau an dieser Stelle muss angesetzt werden, wenn die Standard-Fehlerseiten nicht mehr gerendert werden sollen.
In der server.xml wird der Host konfiguriert, und genau diesem kann das Attribut errorReportValveClass mitgegeben werden. Die dort angegeben Klasse muss auf dem Classpath des Tomcat verfügbar sein und das Interface Valve implementieren. Es wird also ein einfaches Maven-Projekt erstellt:
Für die Implementierung sind noch weitere Dependencies notwendig, die natürlich ergänzt werden müssen.
Die aus diesen Dependencies bezogenen Klassen werden natürlich später vom Tomcat selbst bereitgestellt, so dass an dieser Stelle der <scope> auf provided gestellt wird.
Die Implementierung des eigenen ErrorReportValves ist straight-forward. Im ersten Schritt wird nichts anderes gemacht, als von der eigentlichen Implementierung geerbt.
Damit ist nicht wirklich mehr erreicht, als dass weiterhin die Anzeige der Standard-Fehlerseite realisiert wurde. Die Implementierung hat sich nicht geändert. Daher wird nun die bereits erwähnte Methode protected void report(Request request,Response response,Throwable throwable) überschrieben.
In dieser - eigenen - Implementierung wird die Ausgabe von dem Entwickler selbst erzeugt. Natürlich deutlich minimalistischer als die Standard-Fehlerseiten. Das Artefakt wird nun paketiert und auf dem Classpath des Tomcat bereitgestellt.
Nun fehlt nur noch der Eintrag in der server.xml ...
... und schon kann ein erneuter Test durchgeführt werden.
Somit ist erkennbar, dass die neue Konfiguration erfolgreich war. Die Fehlerbehandlung wird nun von dem CustomErrorReporterValve durchgeführt. Nun ist die einfache Ausgabe eines Fehlertextes noch nicht wirklich spannend, denn das Ziel ist ja eigentlich, dass die Default-Fehlerseiten des Tomcats aufgepeppt werden.
Im CustomErrorReporterValve ist es vollkommen egal welche Rückgabe wir an den Browser liefern, so dass wir auch text/html ausliefern können. Es wird also eine einfache Webseite erstellt, diese im resource-Verzeichnis des JARs hinterlegt und mit im Tomcat ausgeliefert. Die Methode zur Auslieferung der Fehlerseite wird etwas erweitert...
... und schon ist die Fehlerseite deutlich individueller gestaltet.
Mit dieser Konfiguration ist es also sehr leicht möglich, dass alle Anwendungen die in einem Tomcat bereitgestellt werden auf eine zentral konfigurierte und bereitgestellte Fehlerseite geleitet werden. Die Anwendungen müssen selbst keine weiteren Fehlerseiten mitbringen und können sich ganz allein auf die Standardmechanismen des Tomcat verlassen.
Keine Kommentare:
Kommentar veröffentlichen