Download JDK 1.5

Der Download von JDK 1.5 über die Java-Homepage ist nur noch über ein Registrierungsformular möglich, in dem man seine Email-Adresse und seinen Namen angeben muss.

Hintergrund ist, dass Java 1.5 seit 3. November 2009 nicht mehr weiterentwickelt wird (End of Service Life, EOSL) und der Download eigentlich nicht mehr möglich sein soll. Siehe Previous Releases auf der Java-Homepage.

Benötigt man aber trotzdem ein JDK 1.5, kann man das oben genannte Formular ausfüllen und sich eine Email mit dem Download-Link schicken lassen oder gleich den folgenden Download-Link benutzen:

http://java.sun.com/javase/downloads/5u22/jdk

Porlet und AJAX

Wie funktioniert AJAX mit Portlets?
Harmonisieren diese 2 Techniken überhaupt miteinander?

Die erste Version der Porlets war nicht für AJAX geeignet.
Um trotzdem AJAX machen zu könnnen mußt der XHR-Request am Porletkontainer vorbeischießen, um dem Anfrager die passende Anwort zusenden zu können.
Dies war/ist kein schöner Designansatz, da der Portalgedanke ausgehebelt wird.
Man benötigt ein zusätzliches Servlet, dass die AJAX-Anfragen entgegen nimmt.




Mit dem neuen JSR 286 sieht, das nun anders raus.
Durch die serveResource()-Methode kann man nun dem Anfrage Inhalte liefert,
die durch diesen angefragt wurden (z.B. XML, PDFs, TXT und JSON).




Normalerweise besteht, das Porlet aus 2 Teilen, dem eigentlichen Portlet und einer JSP, die für die Darstellung verwendet wird.

Um innerhalb einer JSP die serverResource()-Methode des Porlets aufrufen zu können verwendet man den <portlet:resourceURL>-Custom-Tag. Diesem Tag kann man optionale parameter mitschicken, die dann vom porlet ausgewertet werden können.

<a href="http://www.blogger.com/%3Cportlet:resourceURL%3E%09%09%09%09%09%09%09%09%3Cportlet:param%20name=" resource="" value="weitereAnliegen">
<portlet:param name="method" value="view">
<param name="weiteresAnliegenId" value="${actAnliegen.id}">
</portlet:param>" onclick="de_wwag_alma_showPopup(this.href,'pop','1000','900','auto');return false;">${actAnliegen.lfdNr}</portlet:param></a>

SQL - Spezial insert - select - update - mal anders

Auch wenn Hibernate und Java super Dienste leisten können ist SQL bisweilen praktikabler und performanter.


Die Ergebnisse eines selects verwenden um eine Datenmanipulation vorzunehmen.

insert into GRUND_TREE_OE_TREE (GRUND_TREE_ID,OE_TREE_ID,AKTIV) (
    select GRUND_TREE_ID,90000002,'1' from GRUND_TREE_OE_TREE where oe_tree_id=50026709
);

Der update-Befehl scheint implizit auch ein select zu machen - sonst könnte ich mir das ergenis dieses updates nicht erklären. Um die gleiche Manipulation der Daten mit Java-Mitteln zu machen, hätte ich bedeutend mehr Ernergie aufwenden müssen.

update ANLIEGEN set sub_oe_tree_id = oe_tree_id where sub_oe_tree_id is null

PortletServices - Die Portletregistry

Die Porletservices von IBM werden mittels iner Porletregistry verwaltet.

Das folgende Screenshot zeigt di aktuell auf meinem System konfigurierten Services.

Java Portlets und CSS

Pluto ist die Referenzimplementierung der Java-Portlet-Spezifikation.

Eine nähere Betrachtung lohnt sich auf jeden Fall. In Pluto gibt es den so genannte Portal-Driver (pluto.war). In diesem war-Archiv findet man unter anderem die Dateien portlet-spec-1.0.css und portlet-spec-2.0.css.
Diese 2 Dateien enthalten alle CSS-Selektoren die man in einem Portal verwenden sollte.
z.B. .portlet-msg-error.


Außerdem sind die Dateien portlet-skin.jsp und pluto-default-theme.jsp enthalten. An diesen zwei Dateien läßt sich einfach illustrieren was ein Skin und was ein Theme ist. Ein Skin ist das Layout eines Portlets und beinhaltet unter anderem die Controlls um das Porlet zu minimieren, maximieren und wieder auf die normale größe zu schlaten.

Das Theme betrifft das komplette Layout des Portals.

RESTART WITH

Im DB2 und Derby gibt es die Möglichkeiten sich primärschlüssel generieren zu lassen.

CREATE TABLE ALMAUSR.WEITER_BEARB (
ID INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH 1) PRIMARY KEY,
USER_ID VARCHAR(8) NOT NULL,
NAME VARCHAR(250) NOT NULL, -- Nur zur Info im Pflegedialog
AEND_USER VARCHAR(8) NOT NULL,
AEND_DAT TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
SYS_DAT DATE DEFAULT CURRENT_DATE NOT NULL
)

Nachdem man per INSERT-Befehl manuell ein paar Datensätze hinzu gefügt hat (mit man. ID) muß man dem System sagen bei welcher Nummerierung es weiter machen soll. Dies muß manuell erfolgen. Im folgenden Beispiel wird dem System gesagt, dass der Zähler ab der ID 28 weiter hochzählen soll.

ALTER TABLE table-name ALTER COLUMN RESTART WITH 28

Eventuell macht es Sinn dies in der Applikation einzubauen, so das der Befehl nicht manuell eingegeben werden muß. z.B. in Kombination mit einem select max-Befehl.

SELECT MAX(id-col) from table-name

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();