Не так давно в рамках поддержки корпоративного портала мы занимались обновлением его инфраструктуры и, в частности, переездом на новую версию портала Liferay. В процессе работы столкнулись с одной не самой очевидной, но все-таки важной вещью, не указанной в стандартном руководстве по сборке Liferay бандла на базе сервера приложений Wildfly. Рассмотрим случай подробнее
Допустим, стоит задача собрать новый чистый Liferay Wildfly бандл нужной версии, упаковать его в отдельный Docker образ, который можно будет использовать в конечном программном продукте. А по той причине, что занимались мы обновлением уже существующей системы, нужно еще и учитывать, что все текущие данные и настройки должны сохраниться. Для достижения цели необходимо скачать WAR-файл Liferay, архивы с OSGI-зависимостями и инструментами обновления, затем настроить сам wildfly, после чего пробовать запускать портал, добавив портлеты в директорию автодеплоя. Собственно процесс уже описан в Liferay help center и в других источниках, не будем повторять его еще раз
После того, как вы закончили выполнять действия, указанные в руководстве, может возникнуть соблазн проверить работоспособность собранного и запустить портал (например, через $WILDFLY_HOME/bin/standalone.sh). Если все работает, то возникает еще больший соблазн написать Dockerfile на базе подходящего образа (для контейнеров с Liferay мы обычно используем docker образ openjdk с необходимой версией Java в качестве базового), скопировать в него директорию с лайфреем, настроить entrypoint, собрать итоговый Liferay образ для использования в своих проектах -- и посчитать, что все готово. Однако верно это будет лишь отчасти. Если при обновлении портала мы откроем docker-compose файл, изменим там image на наш новый лайфрей бандл и пересоздадим контейнер, то при запуске посыпется огромное количество трудно дифференцируемых сообщений об ошибке, нечто похожее на то, что описывалось, например, в этом посте.
После нескольких часов изучения вопроса был сделан вывод о том, что в Liferay бандле удалены не все "временные" файлы, остались некоторые директории, содержимое которых препятствует корректной работе, из-за чего мы получаем сломанную конфигурацию Liferay. По этой причине в данной заметке обозначим то, какие файлы необходимо проверить перед тем, как собирать docker образ:
- Проверить содержимое
$LIFERAY_HOME/osgi/state, и $LIFERAY_HOME/osgi/work -- если они не пустые, то обязательно нужно все удалить, иначе проблем не избежать
- Проверить содержимое
$WILDFLY_HOME/standalone/tmp -- если там не пусто, то тоже нужно не забыть удалить
- Проверить содержимое
$WILDFLY_HOME/standalone/deployments -- там также стоит удалить любые следы предыдущих деплоев (вроде файлов ROOT.war.deployed и ROOT.war.failed), и создать дефолтный пустой файл ROOT.war.dodeploy
- Любого рода
logs директории лучше удалить, чтобы не путаться, хоть это и необязательно
После выполнения указанных действий новый Liferay бандл действительно стал "чистым" и при переезде портала на новую версию все прошло как надо
БОНУС: Что не забыть при переезде с Java 11 на более поздние версии языка
Если портал был создан давно, то может возникнуть ситуация, когда в качестве языка разработки была использована еще 11 версия Java. В современных версиях Liferay поддерживается минимум JDK 17, хотя и это уже устарело и ориентироваться надо на JDK 21. В случае обновления версии языка нужно обязательно изменить файл standalone.conf в конфиге Wildfly и в конец добавить вот такие строки:
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/sun.net.www.protocol.http=ALL-UNNAMED --add-opens=java.base/sun.util.calendar=ALL-UNNAMED --add-opens=jdk.zipfs/jdk.nio.zipfs=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED"
export JDK_JAVA_OPTIONS
Без этого непонятных сообщений об ошибках также будет не избежать да и сам портал подняться не сможет
