Es bietet eine gute Möglichkeit die Entkopplung der einzelnen Schichten einzuhalten und mit der Kombination von Facelets, kann sogar ein Grafiker einfacher damit arbeiten.

Bei JSF sind bestimmte “Aktionen” einer Methode zugeordnet. (Methode aus dem ManagedBean, normale Klasse welche in faces-config.xml festgeleg wird, bzw. bei Spring-Einsatz kann man das auch weglassen). D.h. eine Aktion “Kunde anlegen”, welches als Button dargestellt wird, wird mit der Methode CustomerController.add() gebunden.

Oft funktioniert das auch ohne Probleme. Man füllt das Formular aus und drückt den Button. JSF konstruiert den ComponentTree, stellt die Daten wieder in die Objekte und sollte irgendwann auch unsere Methode CustomerController.add() aufrufen. Jaein.

<h:form enctype=”multipart/form-data”>

Man beachte <code>enctype=”multipart/form-data” </code>. Das ist das Problem. Ein einfaches

<h:form>

funktioniert. Dann wird die Methode wieder auch aufgerufen!

Wie man bei [1] sehen kann, unterstüzt WebSphere 6.1 Servlet 2.4 und JSP 2.0 – das entspricht etwa einem Tomcat 5.5.x [2]. Möchte man nun JSF 1.2 (mittels MyFaces 1.2.x) nutzen hat man da ein kleines Problem.
JSF 1.2 benötigt nämlich Servlet 2.5, JSP 2.1 und Java 5 oder später. Genau das kann WebSphere 6.1 mit seiner integrierten JSF 1.1 Implementierung nicht bieten.

Erst bei WebSphere Application Server 7 werden die gewünschten Versionen unterstützt. Wenn man jetzt nicht auf Version 7 umsteigen will/kann, und nicht unzählige Bibliotheken in WebSphere 6 ersetzen will, kann man es sich “einfach” machen und auf JSP verzichten. Das geht. Und zwar mit JSF und Facelets [4] als View-Technologie. D.h. es ist kein JSP mehr notwendig und WebSphere kann irgendeine Version anbieten.

Ich werde jetzt hier nicht Facelets beschreiben, das ich mach vielleicht mal später. Speziell geht es hier gerade um die Nutzung von JSF 1.2 mit Facelets in WebSphere Application Server 6.x.

Dazu muss in dem WEB-INF/lib-Ordner alle benötigten Bibliotheken aufgeführt werden. Das sind mindestens diese:

• commons-beanutils-1.7.0.jar
• commons-codec-1.3.jar
• commons-collections-3.2.jar
• commons-digester-1.8.jar
• commons-discovery-0.4.jar
• el-api-1.0.jar
• el-impl-1.0.jar
• jsf-facelets-1.1.11.jar
• jstl-1.2.jar
• myfaces-api-1.2.5.jar
• myfaces-impl-1.2.5.jar
• myfaces-shared-impl-3.0.5.jar

Wie man vielleicht bemerkt hat, commons-logging.jar ist nicht dabei. Denn diese existiert schon in WebSphere App Server und sollte rausgenommen werden. Weiter sind die el-*.jars auch drin. Die hat WebSphere gar nicht und werden von Facelets benötigt.

Nachdem man nun das WAR-Archiv in WebSphere Application Server deployed hat, muss man noch die Reihenfolge des Classloaders ändern, damit zuerst die eigenen Bibliotheken genutzt werden und nicht z.B. JSF 1.1 von WebSphere. Das wählt man in “Modul verwalten”, wenn man das Web-Modul ausgewählt hat aus, und selektiert in der Select-Box den Eintrag, damit der Classloader der Anwendung zuerst gewählt wird (intern auch als “PARENT_LAST” bekannt).

Nun kann die Anwendung gestartet werden und sollte ohne Probleme laufen. Im Endeffekt einfach. Wenn man weiß wie!

Links:
[1] WebSphere supported Specifications and API
[2] Tomcat
[3] MyFaces
[4] Facelets