Предположим, что у приложения следующий ландшафт:
+-----------------+
| App server |
+-----------------+
| | +-------+
| ear1 | | |
| +-web1 (/ctx1) +--<-- http://localhost/ctx1/xxx/ --+ +--<-- http://www.example.com/xxx/
| | | |
| | | proxy |
| ear2 | | |
| +-web2 (/ctx2) +--<-- http://localhost/ctx2/yyy/ --+ +--<-- http://abc.example.com/yyy/
| | | |
+-----------------+ +-------+
Как видите, прокси-сервер (nginx
в моем случае) перенаправляет запросы на один экземпляр сервера приложений, который, в свою очередь, имеет несколько веб-серверов. модули с разными контекстными путями. Конечно, я не хочу, чтобы мой общедоступный сервер открывал корни внутреннего контекста, а прокси хорошо справляется со своей задачей, упаковывает и разворачивает http-запросы и т. д. Но есть еще одна большая проблема: html-код, сгенерированный JSF (ссылки, ресурсы css, js, форма действия) содержит контекстные пути, в моем случае /ctx1
и /ctx2
. Вот чего я хочу избежать.
На данный момент у меня нет решения, кроме как использовать все больше и больше различных экземпляров (доменов) сервера приложений, что приводит к исчезновению моих аппаратных ресурсов. Насколько я понимаю, мне нужно расширить мои JSF-приложения некоторыми обертками, потенциально зарегистрированными в faces-config.xml
, которые удалят префикс контекста в сгенерированном html. Любые другие решения также приветствуются.
Пожалуйста, укажите мне правильное направление.