Es kommt immer wieder vor, dass der Browser nach der APEX-Installation oder nach einem Upgrade eben keine Login-Seite anzeigt, sondern mit Fehlermeldungen oder gar leeren (weißen) Seiten antwortet. In diesem Community-Tipp haben wir häufig auftretende Ursachen für diese Probleme zusammengestellt.

Leere Seiten

Nach Installation von bzw. Upgrade auf 4.2.1 ruft man im Browser die APEX-Seite zur Anmeldung am Workspace auf und es erscheint eine leere Seite (Abbildung 1).

Abbildung 1: Anstelle der Anmeldeseite erscheint eine leere Seite

In einem solchen Fall empfiehlt sich ein erster Blick auf den HTML-Quelltext der Seite ( wurde vom Server wirklich nichts geliefert?). Hier hilft schon der Browser weiter: ein Blick auf den HTML-Quelltext der Seite zeigt folgendes Bild.

Abbildung 2: HTML Quelltext der leeren Anmeldeseite

Man sieht sehr schön, dass die APEX-Engine durchaus eine Seite geliefert hat, diese wird vom Browser aber nicht dargestellt. Seit einigen Jahren macht auch die APEX-Anmeldeseite sehr starken Gebrauch von JavaScript und CSS. Wenn die nötigen Dateien fehlen, zeigt der Browser schlicht nichts mehr an. Nun kann zuerst geprüft werden, ob die statischen Dateien (Bilder, CSS, JavaScript) korrekt auf dem Server vorliegen und unter dem URL-Präfix, der bei Installation festgelegt wurde (meist /i/), abgerufen werden können. Am einfachsten ist es, die folgende URL zu testen:

http://{hostname}:{port}/i/apex_version.txt

Abbildung 3 zeigt, dass die statischen Dateien noch zur APEX Version 4.1 gehören. Passen diese nicht zur zur installierten APEX-Version (hier: 4.2.1), hat das den gleichen Effekt, wie wenn sie fehlen würden.

Abbildung 3: Hier stehen unter /i/ die statischen Dateien von APEX 4.1 bereit

Es könnte auch sein, dass die Dateien gar nicht vorhanden sind. Dann sieht das Ergebnis des Tests wie in Abbildung 4 aus.

Abbildung 4: Die statischen Dateien (Bilder, CSS, JavaScript) fehlen völlig

In beiden Fällen müssen die statischen Dateien bereitgestellt werden. Wie das geht, hängt vom verwendeten APEX-Webserver ab.

• Wenn Sie den Apache Webserver mit mod_plsql verwenden, muss der Alias /i/ so konfiguriert werden, dass er auf das Verzeichnis $APEX_HOME/apex/images zeigt. $APEX_HOME ist das Verzeichnis, in das Sie das heruntergeladene APEX-Archiv ausgepackt haben (Abbildung 5).
• Wenn Sie das PL/SQL Embedded Gateway verwenden, laden Sie die Bilder mit dem Skript $APEX_HOME/apxldimg.sql in die Datenbank. Dieses Skript erwartet ein Verzeichnis als Parameter. Vorsicht: Das Skript hängt an den von Ihnen übergebenen Verzeichnispfad noch "/apex/images" an und lädt die Inhalte dieses Verzeichnisses hoch. Geben Sie also auch hier das Verzeichnis an, in welches Sie das ZIP-Archiv ausgepackt haben, an. Wenn Sie das Skript wie folgt aufrufen ...

  SQL> @apxldimg D:\
  

  ... dann erwartet das Skript die Bilddateien im Verzeichnis "D:\apex\images".
• Wenn Sie den APEX Listener verwenden, erstellen Sie aus den Inhalten des Verzeichnisses $APEX_HOME/apex/images wie folgt ein Java-Archiv.

  $ cd $APEX_HOME/apex/images
  $ jar -cf i.war *
  

  Die Datei i.war "deployen" Sie dann im Java-Application Server (Glassfish, Weblogic) als neue Webanwendung - die bereits vorhandene einer älteren APEX-Version löschen Sie.

Abbildung 5: Verzeichnis "images" im APEX ZIP-Archiv

Machen Sie, wenn Sie fertig sind, nochmals einen Test mit der URL /i/apex_version.txt. Die zurückgegebene APEX-Version muss zu der in der Datenbank installierten Version passen.

Browser-Fehlermeldungen

Andere Probleme äußern sich dadurch, dass man, anstelle einer leeren Seite, eine Seite mit einer HTTP-Fehlermeldung sieht. Im folgenden sind einige Beispiele dargestellt.

• HTTP 503: Service temporarily unavailable
  
  
• HTTP 403: Forbidden
  
  
• HTTP 404: Not Found
  
  

Je nach verwendetem Webserver sehen diese Fehlerseiten anders aus. APEX ist in diesen Fällen typischerweise noch "gar nicht zum Zuge" gekommen - die Fehler entstehen bereits vorher. Zur Diagnose kann man in die Logdateien sehen oder die Ausgabe des tatsächlichen Fehlers auf dem Bildschirm erzwingen. Letzteres wird wie folgt gemacht:

• Wenn Sie den Apache mit mod_plsql verwenden, fügen Sie der DAD-Konfiguration (Datei dads.conf) folgende Zeile hinzu.

  PlsqlErrorStyle      DebugStyle
  

  Anschließend müssen Sie den Apache Webserver neu starten. Alternativ kann man natürlich auch einfach in die Datei error_log sehen.
• Wenn Sie das PL/SQL Embedded Gateway verwenden, setzen Sie (als SYS) folgendes Kommando ab:

  exec dbms_epg.set_dad_attribute('APEX', 'error-style', 'DebugStyle');
  

  Die Änderung ist sofort wirksam. Möchte man die Fehlermeldungen dagegen in einer Logdatei protokolliert haben, muss ein weiterer DAD-Parameter gesetzt werden - der Community Tipp Einrichtung und Nutzung des PL/SQL Embedded Gateways enthält dazu mehr Informationen.
• Wenn Sie den APEX Listener verwenden, setzen Sie die Property debug.printDebugToScreen in der XML-Konfigurationsdatei auf true.

Nun erscheint anstelle der lapidaren Fehlermeldung HTTP 403 eine ausführlichere Information (Abbildung 9).

Abbildung 09: Ausführliche Fehlermeldung im Browser

Hier haben wir also ein Problem mit dem Passwort des Users APEX_PUBLIC_USER. Das könnte abgelaufen sein. Beim PL/SQL Embedded Gateway sieht die generierte Fehlerseite etwas anders aus - enthält aber die gleiche Information. Das Beispiel in Abbildung 10 zeigt die PL/SQL-Fehlermeldung, die auftritt, wenn man an die URL einer APEX-Seite noch zusätzliche Parameter hängt, die APEX nicht kennt - bspw. "&myparameter=coolvalue".

Abbildung 10: Ausführliche Fehlermeldung im Browser beim Embedded PL/SQL Gateway

In den meisten Fällen dürfte die so sichtbare Fehlermeldung eine große Hilfe bei Diagnose und Lösung des Problems sein.

Tauchen hier unverständliche Fehlermeldungen auf, die auf ein tiefergehendes Problem in APEX hinweisen, empfiehlt sich zunächst ein Blick in die während der APEX-Installation bzw. des Upgrades geschriebene Logdatei.

$ pwd
/opt/oracle/product/11.2.0.2/db/apex
$ ls
apex_epg_config_core.sql  apxe111.sql    apxxepwd.sql
apex_epg_config.sql       apxe112.sql    builder
apexins.sql               apxexit.sql    catapx.sql
apex_rest_config.sql      apxexp         core
apexvalidate.sql          apxexpsplit    coreins.sql
appins.sql                apxldimg.sql   devins.sql
apxchpwd.sql              apxpatch.sql   endins.sql
apxconf.sql               apxprereq.sql  images
apxdbmig.sql              apxrelod.sql   install2012-10-15_08-59-01.log
apxdevrm.sql              apxremov.sql   load_trans.sql
apxdvins.sql              apxrtins.sql   owa
apxe101.sql               apxsqler.sql   utilities
apxe102.sql               apxxemig.sql

Darin kann nun mit nach "ORA-" nach Fehlermeldungen, die während des Installationsvorgangs aufgetreten sind, gesucht werden. Wenn all diese Hinweise nicht weiterhelfen, können Oracle-Kunden Hilfe über MyOracle Support in Anspruch nehmen.

Wichtig zu erwähnen ist noch, dass Sie bei einem fehlgeschlagenen APEX-Upgrade sehr einfach wieder zur alten APEX-Version zurückgehen können. Ein APEX Upgrade installiert zunächst die neue Version neben der alten. Danach werden alle APEX-Anwendungen und Workspaces von der alten Version in die neue kopiert. Schließlich "biegt" APEX die Public Synonyms um und macht die neue Version so aktiv. Wenn diese nun nicht funktioniert, kann man also problemlos zurück zur alten Version wechseln - es müssen ja nur die Public Synonyms "zurückgebogen" und die neue APEX-Version gelöscht werden: Der Abschnitt Cleaning Up After a Failed Installation im APEX Installation Guide beschreibt die Vorgehensweise.

Zurück zur Community-Seite