Category Archives: Java

Implementing your own JSF tabview component without Primefaces

At my current company we are finally transitioning away from our well-aged Primefaces 3.0 jsf library and have implemented our own (composite) components for all use cases where we used primefaces thus far. As I learned a few things while implementing the components, I thought I could share it with others as good tutorials for composite components are quite rare.

Our composite component which we will be developing here is a tabview component just like the one you see on this screenshot of primefaces showcase. The tabview needs to render 1-n different tabs which the user can switch through freely with a click to the tab header. It’s a standard widget found in every operating system and many widget frameworks.

We will develop it based on twitter bootstrap markup and you can use it without any additional client javascript, you don’t even need the bootstrap.js as the switching of tabs is entirely done on the server side (we are talkng about JSF here!). The main advantages of it over the primefaces tabview are that you have learned something about jsf and that you can freely change the html markup as you need it. You can use any CSS styling framework you like.

The component should work with every JSF 2.x version.


You can download the complete source code in my tabview github repository. You have to copy the templates and classes to your project manually. Don’t forget to adjust the package name of the class and the component name inside the class. If you have any question or suggestion just leave a comment.

Continue reading Implementing your own JSF tabview component without Primefaces

Creating open source code is helping me as a developer

When creating the github project and transferring the code for jsf-updates-angular I realized that opening up my code to the public, is helping me being a developer.

While creating the company internal code that jsf-updates-angular is based on, it was done as a part of a bigger code base. It was only a small part in a test branch. I did not really pay attentention to implement it in the most clean way. I mean … it was not bad code. But it was embedded and not meant to be used as a standalone library. It used jQuery, naturally, because jQuery is part of this project. It was a part of an existing module which was easy because it was already there.

jsf-updates-angular (jua) does not really need jQuery. When I would try to, I could do the DOM work on my own. Currently, even the released version of jua is using jQuery. I would only need to ready some articles to make myself familiar with the original browser API to the DOM. That can’t be that hard.

Ripping the code out and releasing it as a standalone module already gave me a new look onto my code. I already have tweaked it and thought about how others will likely use it. The code is now better than before. I did not think about this while writing this code in my company because … no one will take the file and use it somewhere else. No need to optimize it. Its just there.

But while releasing it, I looked on my code with other eyes. Maybe I saw it like I was an external code reviewer. Maybe I saw it as I would see it when I was the customer.

My company will benefit when I release open source software, because I’m learning.

And the next version of jua will not need jQuery.

JSF-updates-angular. How to use angularJS directives to replace JSF components

Writing JSF components is hard and complicated. No one in their right mind writes them. Except when you are a framework developer.

My team is struggling for some time now with Primefaces and its (natural) limitations where one cannot simply change the HTML output to the designers need. So, I spent some days this fall, to try to replace PrimeFaces components with an angular solution, so that PrimeFaces can be completely removed from the application and all components like dialogs or growls are replaced with angular directives.

I didn’t want to use AngularFaces as its trying to put too much magic into the application (for my personal taste). Its very interesting on paper, but when you use it, it seems that every single developer needs to understand exactly both lifecycles of JSF and angularJS and how both frameworks are working. This seems to be a challenge for every decent sized team.

Luckily, the XML parser of JSF leaves HTML tags it does not know of (aka: angularJS directives) alone and just outputs them in the rendered HTML. In a way, that works like the passthrough attributes in JSF 2.2.

As I wanted to use angularJS only as a “widget factory” in a JSF application, I had to solve only a short list of problems:

  • adding the ng-app attribute to the h:body tag is not possible when not using JSF 2.2, Solution: manual bootstrapping like described in angularjs documentation or wrapping your JSF template with a div and the ng-app attribute.
  • inform angularJS about DOM changes after a JSF AJAX request
  • implement a solution so that directives can make JSF AJAX requests, which is not possible out of the box as they can’t have a JSF ID in JSF versions < 2.2

Besides the first, the last two problems were the challenge.

Inform angularJS about DOM changes after a JSF AJAX request

When you load angularJS on page load in a JSF page, its working as expected: its doing its thing and enhances the DOM according to the registered directives. If you don’t use any AJAX requests at all, you are basically done.

The challenge with AJAX requests is, that angularJS needs to be informed about those changes, as they happen outside of an angularJS digest but can contain new DOM nodes with angularJS directives or are destroying/changing existing directives. AngularFaces solved it in a brute-force-like-way: the angularJS app will be completely destroyed and recreated after every JSF AJAX request. But as I only wanted to use directives, that seemed a little harsh for me.

So, after a little experimenting I’m presenting you:

JSF-Updates-Angular (or short: JUA).

Its a (very small) library to update angularJS after every JSF AJAX request:

  • adds 2 event listeners to the JSF JS library for the ajaxComplete and ajaxSuccess events
  • when ajaxComplete event happens, the DOM nodes that are updated by JSF are still unchanged. JUA will iterate through them, searching for nodes with a scope or isolate scope and call the $destroy method on those scopes. Destroying of scopes is done by angularJS itself.
  • when ajaxSuccess event happens, the DOM nodes that are updated by JSF are successfully updated and this library will compile them via angularJS $compile service.

The result is that even DOM nodes which are updated via JSF AJAX requests are enhanced by angularJS directives.

The current state of JUA is not production ready. It was only tested on a few developer machines in a Mojarra JSF 2.1.7 environment (JBoss 7.1.1.). But as I don’t see any JSF dependencies, it should work with any JSF version, provided the JSF AJAX event listener callback interface was not changed.

Trigger JSF AJAX requests inside of directives

When not using JSF 2.2 angularJS directives (aka HTML tags) can’t have JSF IDs and therefore can’t be the source of an JSF AJAX request. But even with JSF 2.2 or when you use a JSF component as a source, you have to build the requests yourself, which is … not so easy.

I made a short-cut here and am using the great OmniFaces library by balusC. With OmniFaces you have a o:commandScript JSF component which registers a global Javascript function to trigger a JSF request. The request can even send a payload with it (PrimeFaces has a similar component). When a angularJS directive needs to send AJAX requests to a managed bean, I’m just using a commandScript call, instead of inventing the wheel again. Works quite nice.

<tabview on-tab-change="makeTabActive">
	<h:panelGroup id="tabs">
		<tab id="detailTab" title="#{msgs.auftrag}" active="#{bean.detailTabActive">
			<h:form id="form">							 
				<o:commandScript name="makeTabActive"
				                 action="#{bean.onTabChangeMethod()}" />
				<h:outputText value="Detail Tab Content" />

(tabView and tab are angularJS element directives)


Use OmniFaces. Really, this library is great!

Re-implement your application in angularJS instead of JSF.

Execute javascript after AJAX request is complete

As pure JSF doesn’t have an easy way (is ANYTHING easy in JSF?) to execute Javascript after a JSF AJAX request, you can use OmniFaces Ajax.oncomplete() for this. Or (if you want) use the onComplete/onCompleteEvent function of JUA which guarentees that your callback listener is called AFTER angularJS was updated:

<h:commandLink value="Do Ajax stuff" action="#{bean.method()">
    <f:ajax update="@form" execute="@this" 
            onevent="jua.onCompleteEvent(" />

Register global function in your directives to call them outside of angularJS digest

My dialog directive – which will be replacing the primefaces dialog component – registers a global javascript function for every dialog name, so that it just can be used like the primefaces dialog. Call anywhere (even in click handlers of JSF components) to show the dialog and dialog.hide() to close it. For developers who don’t know anything about the implementation details, the new dialog behaves just like the PrimeFaces dialog.

$window[scope.dialog] = {
	show: function () {
		$window.jua.ensureExecutionAfterAjaxRequest(function () {
			$scope.apply(function () {
				addOverlay(); = true;
	hide: function () {

(this code is run inside an angularJS directive)

Make use of OmniFaces library components

Use o:messages of OmniFaces to output JSF messages to mimic the PrimeFaces growl component. With o:messages you can control the HTML output of messages and can give an angularJS directive all needed parameters to mimic a growl message.

<messages sticky="true"
	<h:panelGroup id="messages">
		<o:messages var="message" showSummary="true" showDetail="true">
			<message summary="#{message.summary}" detail="#{message.detail}"

(messages and message are angularJS element directives)


Appcache Manifest erstellen und in einer angularJS App integrieren

Wer eine ausgewachsene App entwickelt, die aus rein statischen Dateien (*js, *.css, *.html) besteht und die dynamischen Daten ausschließlich über einen REST-Server nachlädt, sollte sich in jedem Fall mal mit dem HTML5 Appcache beschäftigen. In so einem Fall kann man die (z.B. bei alistapart etwas übertriebenen beschriebenen) Nachteile nämlich ruhig ignorieren.

Der Vorteil für den Nutzer die kompletten statischen Daten immer sofort auf dem Gerät parat zu haben und außer dem REST-Request überhaupt keine HTTP-Requests zum Laden der App zu benötigen, ist speziell für mobile Anwendungen ein ungeheurer Performancegewinn.

Wie ein Appcache-Manifest aufgebaut ist, wird z.B. auf HTML5 Rocks beschrieben.

Nun will man die Datei aber natürlich möglichst automatisch erstellen. Wir haben uns – da wir grunt als Buildtool verwenden – für grunt-contrib-manifest entschieden. Für mich ein weiterer Grund sehr zufrieden mit unserer Entscheidung zu sein, grunt zu verwenden. Es gibt für praktisch alle Anforderungen im Bereich Webentwicklung bzw. Frontend-Entwicklung bereits ein Plugin. [highlight1]”Da gibts ein Plugin für”[/highlight1] statt “Da gibt’s eine App für” sozusagen 🙂

Die Konfiguration ist simpel und selbsterklärend, da muss ich nicht weiter drauf eingehen. Und funktioniert bisher problemlos.

Was etwas mehr nachdenken erfordert hat, war, wie man auf das Event “updateready” reagieren soll, das der Browser erzeugt, wenn er die Dateien im Appcache vollständig aktualisiert hat und die neue Version der App geladen werden muss. Dass eine nicht wegklickbare Info-Box erscheinen sollte, die der Nutzer nur mit einem Klick auf “Neu laden” schließen können sollte, war recht schnell klar. Das eigentliche “Problem” war, das solche DOM-Manipulationen nicht in einen angularJS Controller gehören. Schließlich sollen die auf jeden Fall auch ohne DOM unittest-bar bleiben.

Also war eine Direktive notwendig.

Wir haben es momentan mit dieser Direktive gelöst. Das Popup benutzt jQuery Mobile.

function AppcacheUpdated() {
	var elementScope;

	window.applicationCache.addEventListener('updateready', function() {
		if (window.applicationCache.status === window.applicationCache.UPDATEREADY) {
			window.applicationCache.swapCache(); = true;
			if (!elementScope.$$phase) {

	return {
		template:" <div data-role='popup' class='appcachePopup ui-content' data-theme='e'>" +
			" <p><translate>Neue Version</translate></p><br />" +
			"<a ng-click='reload()' data-role='button'>Neu laden</a> </div>",
		controller: function ($scope){
			$scope.$watch("show", function(value) {
				if (value) {
					$(".appcachePopup").popup("open", {dismissible:false});

			$scope.reload = function() {

			$ = false;
		link: function (scope) {
			elementScope = scope;

angularModule.directive("appcacheUpdated", AppcacheUpdated);

Die Direktive zu verwenden ist simpel, einfach in jede HTML-Seite, auf der sie verwendet werden soll, irgendwo einbauen:


Das ist so ziemlich meine erste Direktive. Mal schauen ob sie auch weiterhin so funktionieren wird, wie sie es momentan tut. Oder ob es dort noch Fallen gibt, über die ich bisher nicht gestolpert bin. Vor allem bin ich mir momentan noch etwas unsicher, ob es günstig ist, sich den “element.$scope” in einer Closure zu merken.

Die Komplexität um angularJS-Direktiven zu schreiben, ist aber in jedem Fall deutlich geringer als JSF-Komponenten zu schreiben. Ich bin immer mehr der Überzeugung, dass JSF für mich keine Zukunft mehr hat, wenn es um Frontend-Entwicklung geht. Der Ansatz auf dem Server das HTML zu rendern und den Client darstellen zu lassen, hat sich in den letzten Jahren einfach überlebt.

Die Entwicklung mit angularJS ist erstens deutlich einfacher und zweitens … macht es einfach Spass. 🙂


JBoss und JaxRS: Warum Jersey die bessere Implementierung ist

Wir benutzen momentan die JBoss 7.1.1 Community Edition, wobei wir momentan – auch wegen der JaxRS Implementierung, aber bei weitem nicht nur – prüfen, die Enterprise Edition zu kaufen.

Als JEE6-Container muss JBoss natürlich auch eine JaxRS (Restful Webservices) Implementierung mitliefern. Statt der Referenzimplementierung Jersey hat Red Hat/JBoss sich für eine eigene Implementierung entschieden: RestEasy. Wobei ich mittlerweile der Meinung bin, dass diese Implementierung das Wort “easy” im Namen nicht verdient hat.
Continue reading JBoss und JaxRS: Warum Jersey die bessere Implementierung ist


Milestone-Releases von JSF 2.2 auf Glassfish 3.1 testen

Markus Eisele hat heute eine Anleitung veröffentlicht, wie man aktuelle Milestone-Releases von Mojarra JSF 2.2 auf Glassfish testen kann, sodass man keinen JEE7 Container wie Glassfish 4 mehr braucht.

Trotz dass Mojarra JSF 2.2 eigentlich kompatibel zu JEE6 Containern ist und somit eigentlich keine Probleme machen sollte, muss man in der aktuellen Version von Glassfish die im Glassfish gebundelte Version von JSF austauschen. Eine Projekt-Abhängigkeit reicht wohl nicht aus.

Markus beschreibt das recht anschaulich und es ist z.B. deutlich einfacher als im JBoss 7.1 ein Myfaces 2.1 einzubauen (was praktisch gar nicht funktioniert).

Somit kann man sich jetzt schon mal mit dem neuen HTML5-Modus in JSF 2.2 beschäftigen.

HTML5 Friendly Markup in JSF 2.2

Ed Burns (Spec Lead für JSF) hat heute in seinem Blog ein paar Informationen zum Thema JSF 2.2 veröffentlicht: HTML5 Friendly Markup in JSF 2.2

Leider hat sein Blog-Parser den Beispiel-Code völlig zerpflückt, sodass nicht mehr viel zu erkennen ist. Als Quintessenz aus seinem Text entnehme ich, dass er in Zeiten von modernen Single Page Web-Apps, die immer mehr UI-Logik auf den Client verlagern, weiterhin Sinn und Nutzen sieht, aber sie mit JSF 2.2 einen (grossen) Schritt auf moderne Anforderungen zugehen möchten, in dem sie Entwiklern die Möglichkeit geben, Anwendungen in purem HTML5 schreiben zu schreiben und nur mit ein paar JSF-Anreicherungen zu versehen, um auf dem Server von JSF’ Stärken zu profitieren:


  • quick to build
  • maintainable
  • localizable
  • accessible
  • secure
  • device independent
  • good looking and fun to use


(schamlos kopiert aus seinem Vortrag auf der Java One)

Wie soll das nun aussehen? Der Code in seinem Blogpost ist wie gesagt momentan leider nicht lesbar, aber in genanntem Vortrag gibt es ein kleines Beispiel, was kombiniert mit dem Code aus seinem Blog Post so aussehen würde:

     xmlns:jsf="" xmlns:f="">
  <head jsf:id="head">
  <body jsf:id="body">
    <input type="color" jsf:value="#{colorBean.color} />
    <input type="date" jsf:value="#{}>
      <f:ajax execute="@this" render="@form"/>

Für HTML5-Neulinge: die beiden Input-Felder nutzen 2 von den neuen Input-Typen und rendern eine browser-generierte Farbauswahl-Box und einen Datepicker (ganz ohne weitere Komponenten).

Ich denke man kann schon ganz gut sehen, wohin die Reise geht. Man hat nun die Möglichkeit komplett auf die JSF-UI-Logik und JSF-UI-Komponenten zu verzichten und sich für das User Interface auf pures HTML zu verlassen. Im HTML-Quellcode wird dann von JSF nur noch wenig zu sehen sein, ausser ein paar Anreicherungen für den Submit/Postback oder wenn etwas ajaxifiziert werden soll. Das passt dann auch gut zum neuen HTML5-Standard-Doctype.

Die Idee finde ich an sich gar nicht so schlecht und ist definitiv ein notwendiger Schritt, um JSF aus seiner angestaubten Ecke zu holen, wo alles auf dem Server passiert und der Client nur zum Anzeigen des Renderergebnisses und dem Postback der Daten dient. So funktioniert moderne Webentwicklung einfach nicht mehr.

Aber ist das wirklich ein überzeugendes Argument für die Zukunft von JSF? Werden dadurch mehr Leute JSF in neuen Projekten einsetzen? Die oben genannten Stärken treffen alle auch auf die Kombination (Single Page) Client-Side Webapp + REST-Schnittstelle (JaxRS) zu, was ich jedenfalls in einem komplett neuen Projekt JSF deutlich vorziehen würde.

The Power of preRenderComponent

Seit Jahren führen wir immer wieder Diskussionen über die richtige Methode wann und wo die Daten in einem JSF-Controller geladen werden sollen.

In JSF 1.x waren solche Konstrukte durchaus üblich:

public List<Car> getCars() {
  if (cars == null) {
     cars = myService.loadCars();

  return cars;

Die Daten wurden also in einem getter einer JSF-Komponente geladen, wenn das Datenobjekt noch null ist.

Dieser Code ist nicht nur hässlicher Stil und missbraucht den Sinn von getter-Methoden, sondern man ist auch immer darauf angewiesen, dass die getter-Methoden von JSF in der erwarteten Reihenfolge aufgerufen werden. Wenn ein Entwickler an der XHTML-Struktur etwas ändert, ist das aber nicht mehr gegeben und man produziert dadurch nur schwer nachzuvollziehende Fehler.

Noch problematischer ist nur noch, in gettern wirklich komplexe Logik unterzubringen, die bei jedem Aufruf ausgeführt wird, also z.B. Service-Aufrufe, die die Daten immer frisch aus der Datenbank lädt. JSF ruft getter nämlich nicht nur einmal auf, sondern je nach Komplexität der Seite auch mehrfach. Ich kann mich an einen Extremfall erinnern, wo JSF eine get-Methode für ein einzelnes Rendern 27 Mal aufgerufen hat. Der Tod jeder Performance, wenn jedes Mal die Datenbank befragt wird.

Seit JSF 2.0 kennt JSF eine einfache Möglichkeit, sich an bestimmte Events zu hängen und eigenen Code auszuführen. Seit einiger Zeit nutze ich den [highlight1]preRenderComponent[/highlight1]-Event, um meine Daten zu laden. Diesen kann man bequem im XHTML-Code definieren und kann zuverlässig auf das Rendern einer bestimmten Komponente reagieren und gegebenenfalls fehlende Daten laden. Die getter-Methoden können dann wieder das tun, wofür sie gemacht wurden: ein Attribut einer Klasse zurückgeben.

  <f:event type="preRenderComponent" listener="#{controller.preRender}" />

  <h:dataTable value="#{}>
public void preRender(ComponentSystemEvent event) {
  cars = myService.loadCars();

public List<Car> getCars() {
  return cars;

OmniFaces – Das Schweizer Taschenmesser für JSF-Entwickler

Wer sich ein bisschen bei Google nach JSF-Tipps umsieht, wird schnell auf stackoverflow stossen, wo der Autor [highlight2]balusc[/highlight2] schon lange eine Koryphäe ist.

Seit einem halben Jahr stellt er eine eigene JSF-Bibliothek zum Download zur Verfügung, die man durchaus als Schweizer Taschenmesser für JSF-Entwickler bezeichnen könnte: OmniFaces.

OmniFaces ist keine Komponenten-Bibliothek wie PrimeFaces oder RichFaces, sondern ist eine Sammlung von kleinen bis grossen Helferlein, die einem das Leben als JSF-Entwickler deutlich erleichtern.

Der Grund warum ich es in unserem Projekt eingeführt habe, ist der [highlight1]Combined Resource Handler[/highlight1], der JSF endlich ein (fast) vernünftiges Resource-Rendering beibringt.

Wer sich mit Web-Performance auseinandersetzt, wird seit Jahren die immer gleichen Empfehlungen finden: pro Seite genau eine CSS-Datei so früh wie möglich im Header einbinden und genau eine Javascript-Datei möglichst ganz am Ende des HTML-Body einbinden (mit Ausnahme von Ressourcen von einem CDN). Beides ist mit JSF nicht möglich, wenn man Komponenten-Bibliotheken wie PrimeFaces, etc. pp. einsetzt. Der Grund ist, dass JSF 2.0 zwar mittlerweile einen eigenen Resource-Handler hat, aber dieser nur 2 Modi kennt, wie die Ressourcen einer Komponente gerendert werden: im HTML-Kopf in der Reihenfolge wie sie im Code definiert sind oder an der Stelle wo sie im Code definiert sind.

Der Combined Resource Handler von OmniFaces ersetzt den Original JSF Resource Handler und rendert die Resourcen, die normalerweise als Einzel-Ressourcen im HTML-Kopf ausgegeben werden sollen, zusammengefasst als jeweils eine CSS-Datei und eine Javascript-Datei. Beide Dateien bleiben zwar weiterhin im Kopf und werden nicht im Body-Ende gerendert (das würde wegen dem zweiten Modus, dass Ressourcen direkt im Code ausgegeben werden auch gar nicht gehen) aber bei uns hat das schon dazu geführt, dass auf komplexen Seiten statt 4 PrimeFaces-Ressourcen + der Standard-JSF-Javascript-Bibliothek nur noch 1 Javascript-Datei ausgegeben wurde. Genauso bei den Primefaces-CSS-Dateien. search multiple domain names

Wenn man jetzt noch dafür sorgt, dass die eigenen Ressourcen immer am Ende vom HTML-Body stehen, hat man eine (fast) perfekte Ladeperformance von externen Ressourcen erreicht.

Neben dem Combined Resource Handler bietet OmniFaces aber noch eine ganze Menge anderer Funktionen, z.B. ein [highlight1]HTML5-Renderkit[/highlight1] oder diverse Validatoren, um mehrere Felder gemeinsam zu validieren. Eine Übersicht findet man im OmniFaces Showcase


Automatisches Styling von nicht validen Eingabe-Komponenten

Cagatay Civici (Lead Developer von PrimeFaces) hat heute in seinem Blog einen Artikel veröffentlicht, der beschreibt, wie man Input Elementen auf einfachem Weg ein anderes Styling verpasst, wenn die Validierung fehlgeschlagen ist: Styling Invalid Input Fields with JSF.

Die vorgestellte Möglichkeit setzt dabei auf einen PostValidationListener, der am Ende der Validierungsphase aufgerufen wird und alle zu diesem Zeitpunkt invaliden Elementen eine zusätzliche CSS-Klasse gibt, die dann z.B. dem Text einen roten Hintergrund gibt.

Der Nachteil dieser Lösung ist, dass alle Änderungen am Zustand von Komponenten, die nach der Validierungsphase gemacht werden, nicht über diesen Listener laufen und somit auch kein Fehler-Styling bekommen.

So schön die Validierungsphase im JSF ist, ist es aber zumindest in meinen Projekten oft so, dass noch zusätzliche Validierungen in der Application-Phase notwendig sind, die natürlich auch in der GUI irgendwie dargestellt werden müssen. Das spätere Validieren ist z.B. oft notwendig, wenn es Abhängigkeiten zwischen verschiedenen Feldern gibt (z.B. ein Datum ist nur dann gültig, wenn es nach einem anderen Datum liegt) oder wenn ein eingegebener Wert komplexe Logik erfordert, die über EJB/JPA/Hibernate laufen muss und somit eine Transaktion und einen Datenbankzugriff erfordert.

Um dies nicht für jeden Einzelfall neu implementieren zu müssen oder pro Komponente einzeln im Template definieren zu müssen, setze ich einen PhaseListener ein, der in der Render-Phase aktiv wird (also nach der Validierungs- und nach der Aplication-Phase) und allen Komponenten, an denen direkt eine FacesMessage hängt, eine zusätzliche CSS-Klasse gibt. Der Code sieht ungefähr so aus:

public class CssStylePhaseListener implements PhaseListener {
	private static final String INVALID_INPUT_STYLE_CLASS = "error";
    public PhaseId getPhaseId() {  
		return PhaseId.RENDER_RESPONSE;  

	public void beforePhase(PhaseEvent arg0) {
		FacesContext context = FacesContext.getCurrentInstance();  
		UIViewRoot root =  context.getViewRoot();  
		Iterator<String> i = context.getClientIdsWithMessages();

		while (i.hasNext()) {  
			String id =;  
			if (id==null||id.isEmpty()) {
			UIComponent component = root.findComponent(id);  		
			if (component instanceof UIInput) {  
				String style = (String) component.getAttributes().get("styleClass");  
				style = style == null ? "" : " " + style;  
				component.getAttributes().put("styleClass", INVALID_INPUT_STYLE_CLASS + style);  

Ein Eintrag in der faces-config.xml ist auch hier noch notwendig:


Der PhaseListener geht dabei von der Annahme aus, dass direkt an einer Komponente ausschließlich Fehlermeldungen vorliegen und allgemeine Meldungen der Anwendung nicht direkt an einer Komponente hängen. Die automatisch erzeugten JSF-Fehlermeldungen aus der Validierungsphase erfüllen diese Voraussetzung immer. Möchte man eine Fehlermeldung aus der Anwendung heraus direkt an eine Komponente hängen, muss man dessen Client-ID kennen:

public void invalidateComponent(String id, String message) {
	UIComponent component = FacesContext.getCurrentInstance().getViewRoot().findComponent(id);
	UIInput input = (UIInput) component;
	FacesContext.getCurrentInstance().addMessage(input.getClientId(), new FacesMessage(message));

Als Entwickler muss man jetzt nur noch wissen und beachten, dass man Validierungs-Fehler bzw. “richtige” Fehlermeldungen an eine Komponente hängen muss, um dem Benutzer automatisch einen optische Rückmeldung zu geben, dass hier eine Fehleingabe vorliegt.

Ich finde diesen Ansatz kompletter, als den Ansatz von Cagatay, wobei auch mein Ansatz durchaus noch Abhängigkeiten hat, die man als Entwickler kennen muss, so z.B. die ID-Ermittlung der Komponente, die man entweder hard-codieren muss oder die – wenn man sie wie oben beschrieben ermitteln möchte – die verschiedenen NamingContainer auf der Seite berücksichtigen muss, siehe den JavaDoc-Kommentar von “findComponent”.