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>

Der dritte Container

Auf dem PC-Markt ist die Konsolidierung schon längst erfolgt. Die Zielplattform heißt hier Windows. Im Web ist die Schlacht noch im vollen Gange. Der Ausgang sehr ungewiss.

Es treten verschiedene Hersteller, Programmiersprachen und Ideologien gegeneinander an.

Java-Portale sind die strategischen Bemühungen der Java-Lobby zur der IBM, SAP und Oracle angehören. Doch was sind Java-Portale - und in wie weit unterscheiden sie sich von Java-Web-Anwendungen. Java-Portale sind der nächste Schritt in der Standardisierung der serverseiten Java-Welt. Der Gedanke dahinter ist recht einfach. Die Hersteller schreiben Anwendungen und Komponenten, die dann in so genannten J2EE-Application-Server ausgeführt werden.

Ein J2EE-Application-Server besteht aus mehreren Containern.

Aktuell sind dies der Web-Container und der EJB-Container.

Die Portal-Anhänger hoffen auf eine auf eine Aufnahme in den J2EE-Standard.

Dann gebe es den dritten container - den Portlet-Container, dem man mittels des portlet.xml konfigurieren könnte.

Das ist aber mit der Version 6 von J2EE nicht der Fall.

Das bedeutet, dass die Portlets frühestens mit J2EE 7 in den Java-Standard aufgenommen werden können.