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>