Что делать, если после апгрейда или инсталляции APEX вместо стартовой страницы браузер показывает сообщение об ошибке или пустую белую страницу? В данной статье собраны наиболее частые причины и методы решения подобных проблем.

Отображается пустая страница

После инсталляции или апгрейда вместо стартовой страницы авторизации в Workspace показывается пустая страница с белым фоном.

В этом случае рекомендуется просмотреть исходный HTML-код страницы, чтобы убедиться, что сервер передал хоть какую-то информацию.

Мы видим, что HTML-страница была корректно сформирована сервером, но не была отображена в браузере. Страница авторизации APEX содержит большое количество JavaScript-кода и CSS. Если доступ к этим файлам отсутствует, браузер показывает пустую страницу. Следовательно, необходимо проверить, что статические файлы (Изображения, CSS, JavaScript) были корректно размещены на сервере и могут вызываться с URL-префиксом, указанным при инсталляции (как правило /i/). Наиболее простой метод – открыть в браузере следующий URL:

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

Скриншот показывает, что статические файлы относятся к версии 4.1.
Если полученная версия не совпадает с установленной версией APEX (здесь 4.2.1), то эффект будет таким же, как если бы эти файлы отсутствовали.

Также может случиться, что файл не доступен. Тогда полученный результат будет выглядеть как на рисунке ниже.

В обоих случаях необходимо проверить корректность установки статических файлов. Как это сделать, зависит от используемого веб-сервера.

Если используется Apache Webserver c mod_plsql, то алиас /i/ должен быть сконфигурирован таким образом, чтобы указывать на директорию $APEX_HOME/apex/images. $APEX_HOME – это каталог, в который был разархивирован дистрибутив Апекса.
Если используется PL/SQL Embedded Gateway, статические файлы должны быть загружены в БД с помощью скрипта $APEX_HOME/apxldimg.sql. Этот скрипт использует в качестве параметра имя каталога. Внимание: скрипт добавляет к указанному в параметре каталогу путь "/apex/images" и загружает содержимое получившегося в результате конкатенации каталога в БД. Таким образом, при запуске скрипта необходимо указывать только каталог с разархивированным дистрибутивом Апекса.
Если скрипт вызывается командой
```
SQL> @apxldimg D:\ 
```
тогда скрипт будет ожидать наличие статических файлов в каталоге «D:\apex\images».
При использовании APEX LISTENER последний создаёт из каталога $APEX_HOME/apex/images ajax-архив, содержащий все статические файлы.
```
$ cd $APEX_HOME/apex/images 
$ jar -cf i.war *
```
Файл i.war должен быть инсталлирован (deploy) на Java-Application Server (Glassfish, Weblogic, Tomcat) как новое веб-приложение – прежнее, относящееся к предыдущей версии апекс, должно быть удалено.

После обновления веб-приложения необходимо вновь провести тест: открыть в браузере URL /i/apex_version.txt. Версия Апекс в этом файле должна совпадать с версией Апекса в БД.

Ошибки соединения

Также бывают случаи, когда вместо пустой страницы браузер показывает HTTP-ошибку.

TTP 503: Service temporarily unavailable

HTTP 403: Forbidden

HTTP 404: Not Found

В зависимости от используемого Веб-сервера сообщения об ошибке выглядят по разному. Апекс сам по себе в большинстве случаев здесь не при чём – ошибка возникает в других модулях. Для диагностики можно посмотреть логи или вывести описание ошибки на экран. Рассмотрим подробнее последний метод:
Если используется Apache c mod_plsql, то необходимо добавить в DAD-файл (dads.conf) следующую строчку:

PlsqlErrorStyle      DebugStyle

и перезапустить веб-сервер. В качестве альтернативы конечно можно просто посмотреть файл error_log, но это не так наглядно.
Если используется PL/SQL Embedded Gateway, необходимо выполнить в БД под пользователем SYS следующую команду:

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

Изменения вступают в силу немедленно.

Если используется APEX Listener, необходимо установить свойство debug.printDebugToScreen в XML-конфигурационном файле в true.

Теперь вместо безликой ошибки 403 будет показана исчерпывающая информация:

На примере выше видна проблема с паролем пользователя APEX_PUBLIC_USER. Например, мог истечь срок его действия. При использовании PL/SQL Embedded Gateway сайт с сообщением об ошибке выглядит по другому – но содержит в себе такую же информацию. Пример ниже показывает ошибку PL/SQL, которая возникает, если к URL Апекс-сайта добавить дополнительный параметр, который Апекс не может распознать – например "&myparameter=coolvalue".

В большинстве случаев подобные наглядные сообщения об ошибках облегчают диагностику и помогают решить проблему.
Если же сообщения об ошибках выглядят загадочными и непонятными, указывают на проблему внутри модулей APEX, рекомендуется исследовать лог установки или апгрейда APEX на предмет ошибок.

В лог-файле удобно искать ошибки, возникшие во время установки, по префиксу «ORA-». Если исследование лог-файла не помогло выявить проблему, то, в случае наличия платной лицензии, можно воспользоваться техподдержкой.

Важно знать, что в случае апгрейда Апекс на кардинально новую версию (например с 4.0 на 4.2, не установка хотфиксов) можно легко «откатиться» на старую версию, так как новая версия устанавливается не «поверх», а «рядом» со старой. При этом все Апекс-приложения и рабочие пространства (Workspaces) просто копируются в новую версию. Затем инсталляционный скрипт «перенаправляет» публичные синонимы на новую версию и таким образом делает новую версию активной. Если новая версия отказывается работать – можно без проблем «откатиться» к старой версии – нужно лишь «перенаправить» синонимы обратно и удалить новую версию Апекс.

Диагностика проблем после инсталляции или апгрейда ORACLE APEX