Anwendungsfehler frühzeitig erkennen mit JSF Development Stages

Development Stages sind eines der mit JSF 2.0 eingeführten neuen Features. Das Konzept wurde von Ruby on Rails übernommen und ermöglicht es Anwendungsentwicklern der  Laufzeitumgebung mitzuteilen an welcher Stelle im Software Entwicklungszyklus sich die Anwendung befindet.

Die JSF-Laufzeitumgebung verhält sich je nach Stage unterschiedlich:

In der Development-Stage werden Resourcen nicht gecached, somit können z.B. Scripte ohne erneutes deployment angepasst werden. Fehlermeldungen sind sprechender und werden gut sichtbar im gerenderten Markup dargestellt. Dadurch werden Entwickler und Tester auf Probleme aufmerksam gemacht, ohne Logfiles inspizieren zu müssen. Nicht behandelte FacesMessages werden gesondert ausgegeben. Gerade dieses Verhalten ist besonders nützlich, da “vergessene” FacesMessages meist auf Programmierfehler, Seiteneffekte oder noch nicht abgeschlossene Implementierungsaufgaben zurückzuführen sind.

In der Production Stage werden die oben beschriebenen Debug- und Fehlermeldungen auf den gerenderten Seiten unterdrückt und die Laufzeit hinsichtlich Performance optimiert. So wird das Standard-Javascript z.B. komprimiert ausgeliefert und das Resource-Caching aktiviert.

Neben Production und Development sind noch zwei weitere Stages im Standard definiert: SystemTest und UnitTest. Diese führen zu keiner Veränderung des Laufzeitverhaltens, können aber von Entwicklern genutzt werden, um selbst auf die Stages zu reagieren.

Project Satges werden als Context-Parameter in der web.xml definiert, zulässige Belegungen sind

  • Development
  • Production
  • UnitTest
  • SystemTest

Beispiel:

<context-param>
 <param-name>javax.faces.PROJECT_STAGE</param-name>
 <param-value>Development</param-value>
</context-param>
Short URL for this post: https://wp.me/p4nxik-C9
This entry was posted in Build, config and deploy, Java Web Frameworks and tagged , , . Bookmark the permalink.

2 Responses to Anwendungsfehler frühzeitig erkennen mit JSF Development Stages

  1. Avatar Stefan Frank says:

    In servlet4.2 wird dann vermutlich auch das hot-deployment out-of-the-box funktionieren, so dass man davon ausgehen kann, dass der jee-frontend-stack spätestens 2018 zu Rails1.0 aufgeschlossen haben wird… Nee, aber im Ernst, man wundert sich schon, dass bei jsf das Testen immer so furchtbar schwer ist, dass die meisten es sich gleich ganz sparen. Das das Leben hier einfacher wird, war dringend notwendig…

    Unterstützen denn eigentlich die gängigen jsf-implementierungen dass denn auch schon?

    • Thomas Asel Thomas Asel says:

      Poject-Stages werden sowohl von Mojarra als auch MyFaces unterstützt. Vor JSF 2.0 konnte man das über eigene Context-Parameter und unterschiedliche Komnfiguration je Stage erreichen (macht den Buildprozess nicht eben einfacher), jetzt ist es etwas handlicher geworden.

      JSF gilt ja allgemein als schwerfällig, diese Auffassung teile ich nur sehr bedingt. Was (Web)Testing angeht ist allerdings ganz klar ein gewisser und, je nach Technologie mit der verglichen wird, auch höherer Aufwand notwendig. JSFUnit ist sehr hilfreich: Wenn man den Aufwand nicht scheut, lässt sich damit aber auch so ziemlicher jeder Aspekt der Web-Anwendung testen, nicht nur der JSF-spezifische Teil. So lässt sich ein hohes Qualitätsniveau erreichen.

      Von der Erfahrung, dass auch auf notwendige Tests verzichtet wird, weil der Aufwand vom Kunden als zu hoch angesehen wird, bleibt wohl niemand verschont…

Leave a Reply to Stefan Frank Cancel reply