Oracle Fusion Middleware Blog

WebCenter Spaces ist ja bekanntlich eine ADF 11g Anwendung und kann, wie im Whitepaper „ExtendingWebCenter Spaces“ beschrieben, mit eigenem Navigationsmodell, eigenem Layout (Shell),  mit eigenen Skins,  eigener Resource Palette (Business Repository) usw. erweitert werden. Beim Customizing von WebCenter Spaces werden die Änderungen in ein eigenes Web Application Archive gepackt und zur Spaces Anwendung hinzudeployt. Somit kann durch einfaches Undeployment des eigenen WARs der ursprünglichen Zustand von Spaces wiederhergestellt werden. Das bedeutet also, dass auch ein eigenes Skin nur über das „CustomWebCenterSpacesWAR“ erstellt und der Spaces Anwendung hinzugefügt werden kann.

Man definiert also zuerst ein Skingrundgerüst, am besten durch Kopieren eines in der Customizing App vorhandenen Skins und fügt es der Spaces Anwendung wie im Whitepaper beschrieben bei. Hinweis: Bitte achten Sie genau auf die Reihenfolge und die Zeitpunkte des Stoppens und Startens des Managed Servers für Spaces.

Die Herausforderung ist nun, aus den umfangreichen ADF Faces UI Komponenten die in Spaces verwendeten herauszufinden und gezielt in einem eigenen Skin zu verändern. Dazu kann der Blogeintrag „ADF Faces Stylesheet rückverfolgen“ als Anleitung dienen. Hier wird beschrieben, das man über die web.xml der Applikation die CSS Komprimierung deaktivieren sollte, um die verwendeten Stylesheetklassen zu erkennen und dann auf den Skineintrag schließen zu können. In unserem Falle bedeutet dies, die web.xml der Spaces Anwendung zu bearbeiten und nicht in der „CustomWebCenterSpacesWAR“.

Hier die Vorgehensweise in der Übersicht. Man muß nun das webcenter.ear Archiv finden, öffnen, das darin enthaltene webcenter.war öffnen und dort die web.xml mit dem entprechenden Parameter wie im o.g. Blogeintrag beschrieben  ändern. Anschließend alle Archive wieder einpacken und das webcenter.ear updaten.

• Webcenter.ear finden

Hierzu geht man am besten auf die WLS Konsole des AdminServers und klickt auf Deployment. In der Liste der deployten Anwendungen geht man zum Eintrag webcenter, wählt den Eintrag an und klickt auf updaten.

Dort sieht man dann den Pfad des Archivs, z.B. . D:\Oracle\Middleware\Oracle_WC1\archives\applications\webcenter.ear

Bitte die Seite so stehen lassen. Hier wird dann später das Update erfolgen.

• Archiv auspacken und Web.xml bearbeiten

In dem angegebenen Pfad finden Sie dann das webcenter.ear. Bitte machen Sie eine Sicherheitskopie davon. Packen Sie das EAR File aus (zum Beispiel mit Zip). Dann finden Sie darin das webcenter.war.

Packen Sie das webcenter.war File aus und Sie finden dann im Pfad  WEB-INF die web.xml. Bearbeiten Sie diese.

Fügen Sie zwischen dem letzen Tag für <context-param> und  dem ersten Tag für <resource-ref> den <Context-param> für die CSS Dekomprimierung ein, also zum Beispiel so:

<context-param>
 <param-name>
 CpxFileName
 </param-name>
 <param-value>
 oracle.webcenter.webcenterapp.bindings.DeploymentDataBindings
 </param-value>
 </context-param>
<!-- Customize Skin-->      
 <context-param>
 <description>Disable CSS Compression</description>
 <param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION</param-name>
 <param-value>true</param-value>
 </context-param>
 <resource-ref>
 <res-ref-name>
 jdbc/WebCenterDS
 </res-ref-name>
 <res-type>
 javax.sql.DataSource
 </res-type>
 <res-auth>
 Container
 </res-auth>
 </resource-ref>

• Archive einpacken

Packen Sie als erstes wieder das WAR Archiv zusammen, z.B. mit Zip. Achten Sie bitte dabei auf Beibehaltung der originalen Verzeichnisstruktur. Packen Sie anschließend wieder das EAR  mit dem so geänderten WAR Archiv zusammen. Achten Sie bitte darauf, dass das EAR File im o.g. Pfad liegt und das alte EAR überschrieben wird, in unserem Beispiel D:\Oracle\Middleware\Oracle_WC1\archives\applications\webcenter.ear

• Webcenter Anwendung updaten

Sollte der Managed Server für Spaces nicht laufen, so starten Sie ihn bitte vor dem Update der Anwendung. Kehren Sie zur oben geöffneten Seite in der WLS Console (Update Webcenter Anwendung) Maske und klicken Sie nun auf „Finish“. Damit wird dann Ihre Webcenter Spaces Anwendung redeployt und Sie finden nun im Source Code der Spaces Seite die nicht komprimierten CSS Klassen vor.

Verfahren Sie nun, wie im bereits oben referenzierten Blogeintrag beschrieben, fort, um Ihren Spaces Stylesheet zu definieren.

<DM>

Seit 01. Juli ist das Release 11g zum Download auf  OTN verfügbar. Die JDeveloper Studio Edition enthält diesmal nicht die Erweiterungen für WebCenter und SOA. Diese müssen über das Updatecenter geladen werden. Wer dies nicht aus dem JDeveloper heraus tun möchte oder kann, oder wer dies in mehreren JDeveloper Installationen tun möchte, kann auch die Extensions hier runterladen und dann offline über die Updatefunktion einspielen. Die Erweiterungen findet man zum Download auf http://www.oracle.com/technology/products/jdev/101/update/fmw_products.xml

Hier eine kurze Anleitung für das Online Update.

<DM>

Problem:

Wie finde ich die entsprechende Styledefinition einer UI Komponente in einem ADF Faces Skin, um diese wie gewünscht zu gestalten.

Lösungsvariante 1:

Man kennt die ADF Faces UI Komponenten und schaut in deren Dokumentation, um die notwendigen Stylesheet Klassen in einer eigenen Skindefinition anzugeben.

Lösungsvariante 2:

Man verfolgt den im Browser ankommende Stylesheet zurück bis zur Definition im ADF Faces Skin. Aber wie ?

An dieser Stelle sei nochmal erwähnt, dass ein Skin eine auf CSS 3.0 Syntax basierende Stylesheetdefinition ist. Skins benutzen also CSS, um die Darstellung von ADF Faces und Trinidad UI Komponenten zu definieren.

Für Variante 1 ist die im Blogeintrag vom 11.Februar beschriebene Lösung ein gutes Hilfsmittel. Deshalb behandeln wir nun Variante 2. Als Beispiel dazu dient eine ADF Faces Rel. 11 Anwendung, die mit einem Standard ADF Faces Skin („blafplus-rich„) versehen ist.

Bild 1: ADF Beispielanwendung

Wir wollen nun die CSS Definition für bestimmte Oberflächenelemente ermitteln, um sie wunschgemäß anpassen zu können. Schauen wir zunächst auf den im Browser ankommenden HTML Sourceode und suchen den Link zur Stylesheet Definition, die der Browser umsetzt.

… <link rel=“stylesheet“ charset=“UTF-8″ type=“text/css“ href=“/HRSystem-ViewController-context-root/adf/styles/cache/blafplus-rich-desktop-f72ien-ltr-gecko-1.9.0.8-cmp.css“>…

Hier erkennen wir, dass dies aber nicht die eigentliche CSS Definition aus dem Skin ist, sondern ein vom ADF Faces Renderer zur Laufzeit generierter Stylesheet. Dabei liest der ADF Faces Renderer die Skindefinition aus  und erstellt eine browserspezifische CSS Datei mit dynamischen, komprimierten Klassennamen. Wie schließen wir aber aus den dynamischen CSS Klassen im Browser auf den originär im Skin definierten Style der betreffenden UI Komponente?

Über die Firefox Community gibt es ein paar nützliche Add-Ons, die wir hier gut gebrauchen können. Es empfehlt sich, die Firebug- und die Web Developer – Erweiterungen runterzuladen und zu installieren, falls nicht schon geschehen.

Nach erfolgreicher Installation der Plugins starten wir nocheinmal die ADF Anwendung, um jetzt beispielsweise die Darstellung eines Tabreiters vom Browser bis zur ursprünglichen Definition im Skin zurückzuverfolgen. Dazu klickt man mit der rechten Maustaste auf den Tabreiter und wählt „Inspect Element“ aus.

Bild 2: Aufruf Firebug Erweiterung in Firefox

Firebug öffnet sich und stellt im unteren Fenster den HTML Source Code sowie im rechten Fenster die im Browser anliegenden CSS Settings dar.

Bild 3: Ansicht Firebug Erweiterung in Firefox

Bewegt man nun den Mauszeiger im Source Code Fenster über andere Codpassagen, so wird im oberen Darstellungsfenster die betreffende HTML Komponenten markiert.

Eine schöne Möglichkeit, gleich an Ort und Stelle in der laufenden Anwendung verschiedene CSS Attribute auszutesten, bietet die Web Developer Erweiterung. Mit Ctrl + Shift + E gelangt man in den CSS Editor und sieht nocheinmal den geladenen Stylesheet.

Bild 4: Ansicht Web Developer Erweiterung - Stylesheet Editor

Man kann in dieser Liste Attribute von CSS Klassen verändern und gleich die Auswirkungen auf der Seite sehen.

Über Firebug findet man also die gültige CSS Klasse der betreffenden UI Komponente (hier Tabreiter) und über Web Developer kann man diese gezielt verändern. In unserem  Beispiel möchten wir den Text des Tabreiters ShowDetailItem1 rot einfärben. Wir klicken daher im Browserfenster mit der rechten Maustaste auf den Text ShowDetailItem1 und wählen Inspect Element aus. Wir sehen, dass hier die CSS Klasse .xs4 verwendet wird.

Bild 5: Ad-Hoc Änderungen von Stylesheet Attributen im Web Developer

Im CSS Editorfenster links suchen wir nun die CSS Klasse  .xs4. p_AFSelected und deren Attribut [color:#000000], welches wir dann auf [color:#FF0000] ändern. Man sieht sofort, dass sich der Text des Tabreiters rot färbt.

Bleibt nur noch die Frage, wie man von der dynamisch erzeugten CSS Klasse .xs4 im Browser auf die tatsächliche Styledefinition im ADF Faces Skin schließt? Dort werden ja die für die jeweilige UI Komponente festgelegten CSS Klassen definiert, die nicht xs4 oder ähnlich heissen, sondern irgendwie den Komponentennamen enthalten. Man muss zuerst in der web.xml der JSF Anwendung die Kompression der CSS Klassen deaktivieren. Damit werden keine dynamischen Klassennamen vom Renderer generiert, sondern die Klassennamen des Skins verwendet. Man öffnet im JDeveloper im Projekt der JSF unter Web-INF die web.xml und fügt unter Context Initialization Parameters einen neuen Parameter org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION mit dem Wert True hinzu.

Bild 6: Einschalten der CSS Dekompression in der web.xml

Nun startet man die Anwendung neu und schaut über Firebug auf den Tabreiter. Die Stylesheet Klasse des Tabreitertextes heißt in unserem Beispiel nun .af_PanelTabbed _tab-text-link (Zur Erinnerung: vorher war der CSS Klassenname .xs4)

Bild 7: dekomprimierte Stylesheet Klassenamen

Auf OTN kann man sich die Skindefinition dieser UI Komponente anschauen und weiß nun, welche Klassen in der CSS Datei des eigenen Skins definiert werden müssen, um ein gewünschtes Layout der Komponente zu erhalten. Man kann aber auch aus aus dem im Browser anliegenden Klassennamen auf die CSS Klasse im Skin schließen, in dem man .af_ mit .af| und dann jedes weitere _ mit :: ersetzt. In gegebenen Beispiel würde man .af_PanelTabbed _tab-text-link mit .af|PanelTabbed ::tab-text-link ersetzen und hätte ohne nachzuschauen den Klassennamen für die eigene Skindefinition.

Wie man eine eigene ADF Faces Skindefinition anlegt,  ist in der ADF Faces Doku beschrieben oder in diversen BLOG Postings zu finden.

<DM>

Wer sich mit komponentenbasierter Oberflächenentwicklung beschäftigt, wird mit Sicherheit bei JSF, MyFaces und ADF Faces landen. Die Frage, die sich dabei immer wieder stellt ist, welche Komponente nun für das zu bearbeitende Anwendungsdetail geeignet ist. Die mit jedem Release wachsende Zahl an Komponenten in den jeweiligen UI Frameworks kann man kaum noch soweit verinnerlichen, dass man, ohne nachzuschauen, weiß, welche Komponente in der IDE ausgewählt werden soll. Entweder schaut man in irgendwelche statischen Dokumentationen oder man nutzt mehr oder weniger immer die selben Komponenten, die man kennt (Oder man erinnert sich an diesen Blogeintrag ).

Man benötigt also eine irgendwie geartete Übersicht aller Komponenten und deren Anwendungsbereiche und Gestaltungsmöglichkeiten. Für ADF Faces Release 11 ist seit geraumer Zeit eine solche Übersicht in Form einer interaktiven Anwendung entweder Online oder als Offline Version zum Downloaden verfügbar.

Hier kann man gut strukturiert auf Layoutkomponenten und deren Gestaltungsmöglichkeiten schauen. Eine sehr schöne Hilfe und Erleichterung für jeden ADF Entwickler.

<DM>

Vorstellung der Beispielanwendung Flugauskunft

In diesem Blog möchte ich an einem Beispiel erläutern, wie man ein Remote Debugging eines Portlets im JDeveloper durchführt. Schauen wir zuerst auf eine kleine Beispielanwendung, an Hand derer das Debugging erläutert werden soll.

Beispielanwendung Flugauskunft

Wir sehen eine einfache WebCenter JSF Page, auf der oben ein Suchportlet und unten ein Ergebnisportlet eingebettet und über die JSF Seitendefinition miteinander gekoppelt sind (Interportlet Kommunikation). Das obere Portlet ist ein Parameterportlet aus der Bibliothek der fertigen WebCenter Portlets. Das untere Portlet ist eine JSP mit einer Java Klasse zur Ausgabe von Flugdaten. Portlets und Portalseite sind physich voneinander getrennte Anwendungsfragmente und auf zwei Application Server verteilt. Zur besseren Verdeutlichung sei hier ein Schaubild des Aufbaus dargestellt.

Applikationsarchitektur Flugauskunft

Das Portlet ListTours.jsp wird per WSRP Request (HTTP) von der Portalseite Tours.jspx aufgerufen. Gehen wir davon aus, dass der Entwickler die Java Klasse TourData des Portlets debuggen muss, um einen Fehler zu finden. Das Problem besteht darin, dass das Portlet ListTours.jsp nicht direkt ohne Mitgabe eines Portalkontexts gestartet werden kann. Das heißt man muss über den gesamten Portalkontext die Applikation auf Funktionsfähigkeit überprüfen und ggf. debuggen. Im Prinzip unterscheidet sich ein Portlet Remote- Debugging nicht wesentlich von einem herkömmlichen Remote-Debugging, wie es in der Dokumentation zum JDeveloper beschrieben ist. Man muss nur beachten, dass das Portal eine definierte Zeit auf Anwort des Portlets wartet (Timeout). Wird aber ein Debugging des Portlets vorgenommen, dann hält die Abarbeitung der Portletlogik an, das Portal wartet aber weiter auf Antwort. Nach der in der Providerregistratur definierten Wartezeit wird der Portletrequest vom Portal (hier Tours.jspx) abgebrochen mit der entsprechenden Abbruchmeldung. Das kann je nach funktionalen Abhängigkeiten zu anderen Portlets oder Seitenkomponenten zu unerwünschten Nebeneffekten auf der Portalseite führen. Daher sollte in den Vorbereitungen zum Debuggen die Portlet Request Timeout Zeit in der Provider Registratur der  Webcenter anwendung sehr hoch eingestellt werden, damit das Portal, also WebCenter, genug Zeit zum Debuggen zuläßt, ohne abzubrechen. Die Vorgehensweise des Remote-Debuggings sei hier nocheinmal im Ganzen beschrieben.

Starten des Portletcontainers im Remote Debug Modus

Der J2EE Container, der das Flugauskunftsportlet ListTours.jsp enthält, ist hier der „pre-seeded OC4J“, welcher automatisch in der JDeveloper Studio Edition ab 10.1.3.2 enthalten ist. Start und Stop dieses Containers wird über ein Shellscript als „external Tool“ ausgeführt. Um den Debug Modus beim Starten dieses Containers zu aktivieren, muss in dessen Startscript %JDEV_HOME%\extensions\oracle.adfp.seededoc4j.10.1.3\bin\adfp_oc4j.cmd die Zeilen 223 und 231 mit dem OC4J Startbefehl von

…
c4j
if /I „%VERBOSE%“==“on“ (
echo Executing: %JAVA_HOME%\bin\java %JVMARGS% -jar „%OC4J_JAR%“ %CMDARGS%
echo.
)
if not EXIST %OC4J_JAR% (
echo Error: Can not find %OC4J_JAR%.
goto end
)
%JAVA_HOME%\bin\java %JVMARGS% -jar %OC4J_JAR% %CMDARGS%
goto end
…

nach

…
c4j
if /I „%VERBOSE%“==“on“ (
rem echo Executing: %JAVA_HOME%\bin\java %JVMARGS% -jar „%OC4J_JAR%“ %CMDARGS%
echo Executing: %JAVA_HOME%\bin\java %JVMARGS% -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4000 -jar %OC4J_JAR% %CMDARGS%
echo.
)
if not EXIST %OC4J_JAR% (
echo Error: Can not find %OC4J_JAR%.
goto end
)
rem %JAVA_HOME%\bin\java %JVMARGS% -jar %OC4J_JAR% %CMDARGS%
%JAVA_HOME%\bin\java %JVMARGS% -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4000 -jar %OC4J_JAR% %CMDARGS%
goto end
…

geändert werden. Wie man sieht, soll für die Kommunikation zwischen JDeveloper und externem Portletcontainer der Port 4000 verwendet werden. Das muss man dem Remote Debugger des JDevelopers mitteilen.

Einstellungen auf Projektebene im JDeveloper

Im Projekt mit den Portlet Sources (ListTours.jsp und Tourdata.java) muss nun noch der Debugger mit dem Kommunikationsport 4000 des Portletcontainers zusammengebracht („attached“) werden. Dazu bitte mit rechter Maustaste auf Portletprojet -> Project Properties -> Run/Debug -> Run Configurations „Default“ ->Edit gehen. In dem sich öffnenden Fenster bitte auf Remote Debugger klicken und die Einstellungen wie folgt vornehmen.

Einstellungen Remote Debugger

Selbstverständlich wird hier unter Host der aktuelle Hostname des Portlet Containers eingetragen.

Portletrequest Timeout erhöhen

Die Registratur des Portletproducers sollte wie oben bereits erwähnt mit einer sehr hohen Timeout Zeit versehen werden. In WebCenter sind alle Portletproducer der Applikation unter „Portlet Producers“ aufgelistet. Bitte diesen Zweig öffnen, mit der rechten Maustaste auf den betreffenden Producer klicken und Edit anwählen (hier im Beispiel „Veeva Producer“).

Aufruf Portlet Producer Registratur

Im sich öffnenden Producer Registratur Fenster bitte auf Registration Details klicken und die Timeout Zeit erhöhen.

Portlet Produer Timeout

Starten des Remote Debuggers

Im JDeveloper oben in der Menüleiste die grüne Ampel anwählen und somit den „preseeded OC4J“ (mit dem Portlet ListTours.jsp) starten. Im Message Fenster müsste zu sehen sein, dass der Container auf Port 4000 hört. Zur Kontrolle kann man noch in einer DOS Shell durch netstat –a sehen, ob der Port 4000 in Gebrauch ist. Nun kann man im Projekt Portlets in der entsprechende Klasse die gewünschten Breakpoints setzen und den Remote Debugger (roter Käfer in der Menüleiste) starten. Dieser verbindet sich auf den Port des Portletcontainers. Abschließend wird die Portalseite, hier Tours.jspx, normal gestartet (rechte Maus -> Run) und in dem Monent, wo das Portlet ListTours.jsp angefordert wird, mdeldet sich der Debugger im JDeveloper und man kann sich den Stack ansehen

Breakpoints setzen

Nun müssen Sie nur noch den Fehler finden. Viel Erfolg. <DM>