Migration von IBM-JSF auf MyFaces mit der neuen Portlet-Bridge

Wir verwenden aktuell die JSF-Implementierung von IBM in der Version 1.1 mit der Proprietären Portlet-Brige von IBM.
Ziel der gesamten Bemühung wäre es auf die STD-Bridge umzuschalten und die neuen JSF-Komponenten von MyFaces zu Verwenden.

Wir nehmen stark an, dass IBM seine proprietären Implementierungen aufgeben wird und
apache MyFaces in seiner Anwendung verbauen wird.
Man kann z.B. sehen, dass MyFaces als Teil der WebSphere-APIs mit ausgeliefert wird (wesphere_apis7.0.jar).

Der LifeCyle einer JSF ist mit das Zentrale problem, dass zu lösen ist.
in der normalen JSF-Welt (Ohne Portal verwendt man den ener-class>com.sun.faces.config.ConfigureListener. Wenn man Auf Websphere 7 entwickelt, so muß man nicht angeben, da IBM sein websphere_apis7.0.jar so konfiguriert ist, dass nicht gemacht werden muß. Ich konnten das Ganze erst mit dem org.apache.myfaces.webapp.StartupServletContextListener im Tomcat zum Laufen bringen.



Nach unserem Test mußten wir feststellen, dass dies nicht so einfach möglich ist.
So raten wir den Entwicklern - JSF nicht zu verwenden, sondern einen JSP-Ansatz.


Trotzdem sei an dieser Stelle beschrieben was bei einer Migration zu beachten ist.


com.ibm.faces.portlet.FacesPortlet -> javax.portlet.faces.GenericFacesPortlet

Umstellunge pro Porlet in der portlet.xml

alt:

<init-param>
<name>com.ibm.faces.portlet.page.view</name>
<value>/jsp/suche/ALMA_SucheView.jsp</value>
</init-param>


Ner:

<init-param>
<name>javax.portlet.faces.defaultViewId.view</name>
<value>/jsp/suche/ALMA_SucheView.jsp</value>
</init-param>




Bei meinen Versuchen konne ich das Ganze nur mit der RI von Sun zum laufen bringen.
Ich habe folgenden Komponenten verwendet:
Bridge von MyFaces portlet-bridge-api-2.0.0 alpha 2.jar (Version 2.0)
JSF-RI von Sun (Version 1.2)




So funktioniert die STD-J2EE-Auth innerhalb eines Portlet-Containers....
der Portletrequest muß einfach als Renderrequest gecastet werden,
von dort aus hat man Zugriff auf die Sicherheit.

Alle Anderen Möglichkeiten sind illegal und funktionieren nicht in allen Containern.
---

if (portletRequest instanceof RenderRequest) {
RenderRequest renderRequest = (RenderRequest) portletRequest;
isMember = renderRequest.isUserInRole(j2eeRole);
}

if (portletRequest instanceof RenderRequest) {
RenderRequest renderRequest = (RenderRequest) portletRequest;
userId = renderRequest.getUserPrincipal().getName();
}





Um Zugriff auf den PorletRequest zu bekommen hat die WW folgendes Util verwendet.
:de.wwag.arch.portal.apps.util.faces.FacesUtils.getPortletRequest()

Dies sollte auf den STD-Zugriff umgebaut werden.
FacesContext.getCurrentInstance().getExternalContext().getRequest();

STATE_SAVING_METHOD

JSF-Komponenten einer JSF-Seite werden in einem Komponentenbau verwaltet. In jedem Request-Response-Cyclus muß dieser Baum wieder aufgebaut werden.
Es gibt 2 Möglichkeiten.

• Severseitig -


• Clientseitig - Der Komponentebaum wird in der HTML-Seite verwaltet

<context-param>
  <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
  <param-value>client</param-value>
</context-param>

Apache JMeter

Bevor man eine Anwendung produktiv setzt sollte man einen Lasttest durchgeführt haben. Es gibt verschiedene Anbieter die ein Produkt anbieten.

Zugriff auf den ServletRequest aus einem Portlet heraus.

Wenn man auf die J2EE-Authentifizierung zugreifen will, muß man Zugriff auf den ServletRequest bekomment. Doch das ist nicht so trivial.

Um aus einem portletRequest auf den httpRequest zuzugreifen muß man ein paar tricks anwenden. Der Request ist durch verschiedene "Wrapper" gut verpackt, die durchstöbert werden müssen. Den folgenden Beispiel-Code kann man dann in eine eigene Util-Klasse zur wiederverwendung ablegen. Die Methode ruft sich rekursiv auf.
z.B.


PortletUtil.getRequest(portletRequest);

Dies ist das was in der Utility geschrieben wurde.


public static HttpServletRequest getRequest(Object r)
{
if (r instanceof PortletRequestWrapper)
{
PortletRequestWrapper portletRequestWrapper = (PortletRequestWrapper) r;
return getRequest(portletRequestWrapper.getRequest());
}

if (r instanceof ServletRequestWrapper)
{
ServletRequestWrapper servletRequestWrapper = (ServletRequestWrapper) r;
return getRequest(servletRequestWrapper.getRequest());
}
return (HttpServletRequest) r;
}


Java VM vs Flex Plugin

Ein Kritikpunkt an Java-Applets ist, dass eine Java-VM installiert sein muß.

Wenn man einen Link zu seinem Applet verschickt und auf dem lokalen System ist kein Java installiert, dann schaut man in die Röhre. Es passiert einfach nichts.

Das deployJava.js Java-Script hilft einem Dabei die zu vermeiden.

Sollte man kein java installiert haben, so wird man zur Dowload-Seite des Plugins verwiesen.

<script src="http://java.com/js/deployJava.js"></script> <script> var attributes = {
code:"org.apache.pivot.wtk.BrowserApplicationContext$HostApplet", archive:"lib/pivot-core-1.4.jar,lib/pivot-wtk-1.4.jar,lib/pivot-wtk-terra-1.4.jar,lib/pivot-charts-1.4.jar,lib/pivot-jfree-1.4.jar,lib/pivot-jfree-demos-1.4.jar,lib/jcommon-1.0.16.jar,lib/jfreechart-1.0.13.jar", width:640, height:480 }; var parameters = {


application_class_name:"biz.ixnay.pivot.demos.charts.jfree.ChartsDemo", codebase_lookup:false
}; var version = "1.6"; deployJava.runApplet(attributes, parameters, version); </script>

retrieveMasagesFromServerOnGetMessage=true

Sprechende DB2-Fehlermeldungen mit Java

Um in Eclipse schöne Fehlermeldungen zu bekommen (Mit Erklärung),
müßt ihr einfach eueren Connection-String um das Attribut retrieveMessagesFromServerOnGetMessage=true; ergänzen.
Funktioniert in jedem Java-Programm, das erspart einem evtl die IBM-Doku lesen zu müssen.

Ohne Message

Als URL

jdbc:db2://myservername:50128/SAMPLE:retrieveMessagesFromServerOnGetMessage=true;

Oder im Code:.


Properties conProperties = new Properties();
conProperties.put("user", "pdqpot");
conProperties.put("password", "pdqpot123");
conProperties.put("portNumber", "50000");
conProperties.put("databaseName", "SAMPLE");
conProperties.put("deferPrepares", "false");
conProperties.put("retrieveMessagesFromServerOnGetMessage", "true");
conProperties.put("emulateParameterMetaDataForZCalls", "1");
conProperties.put("clientApplicationInformation", "T4Driver");
conProperties.put("clientWorkstation", "192.168.10.125");
conProperties.put("defaultIsolationLevel", java.sql.Connection.TRANSACTION_READ_COMMITTED);
conProperties.put("jdbcCollection", "NULLIDR1");
conProperties.put("driverType", "4");

JSF - Wert nicht göltig

Als JSF-Entwickler könnte es peinlich werden, wenn die folgende Fehlermeldung aus als folge einer Validierung aus dem Bildschirm erscheint: Wert nicht göltig. Wie macht man dem Kunden klar, dass nicht unsere JSF-Anwendung schuld ist, sondern das teuer eingekaufte Portal (In unserem Fall der WebSphere-Portal-Server 6.1).

Der peinliche Fehler resultiert aus einer falschen Übersetzung der Fehlermeldungen der Referenzimplementierung von JSF 1.1 . Die Datei Messages_de.properties wurde von IBM 1:1 von der Referenzimplementierung übernommen.

javax.faces.component.UISelectOne.INVALID=Validierungs-Fehler: Wert nicht g\u00F6ltig.

javax.faces.component.UISelectMany.INVALID=Validierungs-Fehler: Wert nicht g\u00F6ltig.

Der Fehler war nicht so einfach zu finden, da die Übersetzungen in Unicode codiert sind.

\u00F6 ist ein kleines ö. Eine Volltextsuche durch die vorhandenen Jars führte deshalb nicht zum gewünschten Erfolg. Am Anfang dachte ich, es würde sich um einen Fehler in der IBM-Implementierung von JSF handeln. War es aber nur in direkt im Header (Kommentar) der Datei kann man erkennen, dass es sich um einen Fehler in der Referenzimplementierung handelt:

# Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.

Der Schreibfehler befindet sich in der Datei Messages_de.properties. In meinem Fall (da wir die Implementierung von IBM verwenden befand sich diese Datei in websphere_apis-6.1.jar.

Um den Fehler zu fixen müsste man eigentlich die Datei "reparieren" oder man wendet den hier beschriebenen Work-Around an. Ein "reparieren" wäre dabei nicht so einfach möglich gewesen, da die JSF-Implementierung als Teil des WebSphere-Applikationsserver ausgeliefert wird. Durch eine "reparieren" könnte man den Server ernsthaft beschädigen. Also kam nur der Workaround in Frage.

1. Erstellung einer zusätzlichen Messages_de.properties (Enthält die 2 Keys mit der Korrektur)

2. Anpassung der faces-config.xml (deklaration eines zusätzlichen Message-Bundles.

<faces-config>

<application>

<message-bundle>de.nikem.jsf.Messages</message-bundle>

</application>

<locale-config>

<default-locale>de</default-locale>

</locale-config>

</faces-config>