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

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.