Нестатический псевдоним веб-приложения

Question

Нестатический псевдоним веб-приложения

1

Я хотел бы знать, если есть чистый способ получить запрос, на который отвечает webapp, чье имя не отображается в URL-адресе запроса. В некотором роде URL должен быть псевдонимом webapp. Кроме того, псевдоним не должен быть статичным или фиксированным с помощью одного единственного веб-приложения, но мне нужно иметь возможность легко менять webapp за псевдонимом для увеличения версии. То, что приходит мне в голову, это

создать "фасад" webapp для перенаправления запросов
переименуйте полный webapp

Обе идеи не приводят к желаемому результату. Я хотел бы иметь более легкое решение.

Это возможно?

tareq 02 апр. 2015, в 00:14

Источник

0

Как правило, это достигается с помощью сетевых систем переднего плана, либо устройства балансировки нагрузки, либо установки apache / nginx, которая перезаписывает данные.
Affe 01 апр. 2015, в 21:30
0

@ Да ладно, но это звучит как накладные расходы? Я не хочу, чтобы весь мой трафик перенаправлялся, просто запрашиваю одно веб-приложение внутри моего контейнера. Не могли бы вы уточнить сценарий использования simpe?
ulrich 01 апр. 2015, в 21:40
0

Что вы сейчас используете в качестве внешнего интерфейса? Вы выставляете кота прямо в интернет? nginx.org/en/docs/http/ngx_http_rewrite_module.html
Affe 01 апр. 2015, в 21:51
0

Что ж, на веб-приложения tomcat (веб-сервисы) в первую очередь ссылаются приложения java или php. Кроме того, некоторые веб-приложения предназначены для использования в API, доступном извне, поэтому существует необходимость в псевдониме.
ulrich 02 апр. 2015, в 08:21

Показать ещё 2 комментария

Теги:

java

tomcat

web-services

web-applications

2 ответа

1

Если вы хотите сделать это только с помощью tomcat, вы можете статически сопоставить свой путь webapp в tomcat context.xml определяющий контекст и отображающий request path ("путь") к директории webapp dir ("docBase").

Просто добавьте это в свой <tomcatDir>/conf/context.xml:

<Context 
  path="" 
  docBase="/<pathToYourWebapp>/<yourApp>" 
/>

Это имеет побочный эффект, что вы можете иметь только один webapp, конечно, потому что каждый запрос und / отображается на ваш webapp.

Для получения дополнительной информации см. Http://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Common_Attributes.

Alexander 01 апр. 2015, в 21:23

0

Это будет иметь тот недостаток, что мне придется поддерживать один файл context.xml для каждого открытого веб-приложения и изменять его, если веб-приложение, стоящее за контекстным файлом, изменится. Я прав? Кроме того, я думаю, мне нужно будет перезапустить Tomcat после этих модификаций.
ulrich 02 апр. 2015, в 10:14
0

Если вы добавите этот узел <Context/> в context.xml ( conf/context.xml ), это будет один узел на веб-приложение в одном и том же context.xml . Я думаю, что вы также можете добавить один context.xml для каждого веб-приложения в conf/Catalina/localhost/<webappName> , но это другая история. @Affe предложил другой способ («... устройство балансировки нагрузки или apache / nginx») - без настройки tomcat, но с настройкой чего-либо до
Alexander 02 апр. 2015, в 11:28

Ещё вопросы

Как правило, это достигается с помощью сетевых систем переднего плана, либо устройства балансировки нагрузки, либо установки apache / nginx, которая перезаписывает данные.
@ Да ладно, но это звучит как накладные расходы? Я не хочу, чтобы весь мой трафик перенаправлялся, просто запрашиваю одно веб-приложение внутри моего контейнера. Не могли бы вы уточнить сценарий использования simpe?
Что вы сейчас используете в качестве внешнего интерфейса? Вы выставляете кота прямо в интернет? nginx.org/en/docs/http/ngx_http_rewrite_module.html
Что ж, на веб-приложения tomcat (веб-сервисы) в первую очередь ссылаются приложения java или php. Кроме того, некоторые веб-приложения предназначены для использования в API, доступном извне, поэтому существует необходимость в псевдониме.
Это будет иметь тот недостаток, что мне придется поддерживать один файл context.xml для каждого открытого веб-приложения и изменять его, если веб-приложение, стоящее за контекстным файлом, изменится. Я прав? Кроме того, я думаю, мне нужно будет перезапустить Tomcat после этих модификаций.
Если вы добавите этот узел <Context/> в context.xml ( conf/context.xml ), это будет один узел на веб-приложение в одном и том же context.xml . Я думаю, что вы также можете добавить один context.xml для каждого веб-приложения в conf/Catalina/localhost/<webappName> , но это другая история. @Affe предложил другой способ («... устройство балансировки нагрузки или apache / nginx») - без настройки tomcat, но с настройкой чего-либо до

tareq · Accepted Answer · 2015-04-16T06-46-00.000Z

Благодаря сообщению от Александра я нашел правильный трек, но я использовал дополнительную работу, которая является более или менее фасадным webapp, упомянутым в пункте 1) из моего первоначального вопроса. Я покажу весь свой подход для всех желающих:

Во-первых, у меня есть все мои стандартные веб-приложения, развернутые в /tomcat/webapps с одним стандартным режимом context.xml и autoDeploy. Чтобы поймать все остальные запросы, которые не соответствуют одному из развернутых контекстов, я настроил новый webapp, который действует как веб-приложение по умолчанию для несоответствующих запросов. Позвольте называть его dispatcher-app.

Чтобы сделать это, я должен установить его как ROOT. Чтобы развернуть его под своим первоначальным именем, я /tomcat/webapps2 его под /tomcat/webapps2 и связанным с ним context.xml в /tomcat/conf/Catalina/localhost/ROOT.xml. Для предотвращения двойного развертывания в tomcat необходимо включить его вне /webapps с режимом autoDeploy, используемым для других webapps. Дополнительную информацию об этом можно найти здесь: http://tomcat.apache.org/tomcat-7.0-doc/config/context#Naming

ROOT.xml выглядит так:

<Context
    path=""
    docBase="/path/to/tomcat-base/webapps2/dispatcher-app"
    crossContext="true"
/>

В web.xml dispatcher-app убедитесь, что он использует

<servlet-mapping>
    <url-pattern>/</url-pattern>
 </servlet-mapping>

dispatcher-app внутри ищет исходный путь, запрошенный пользователем с помощью uriInfo.getAbsolutePath(). Затем он сопоставляет приложение с URL-адресами с приложениями, которые запускаются в tomcat, известными из пользовательского файла конфигурации. Если есть совпадение, файл конфигурации знает, к какому приложению следует сделать переадресацию. Например, пользователь запрашивает myserver/webapp-1/test?param=value и перенаправляется на myserver/webapp-1.1.2/test?param=value. Webapp to forward to может быть обновлен в файле конфигурации вручную, если версия приложения изменится.

Фактический вперед должен быть сделан с использованием

RequestDispatcher dispatcher=servletContext.getRequestDispatcher(redirectTo);
dispatcher.forward(request, response);

потому что прямой не будет видимым для пользователя.

Поскольку я не мог выполнить этот запуск (см. Пересылку запроса перекрестного контекста в tomcat, результат в java.lang.ClassCastException: org.glassfish.jersey.message.internal.TracingLogger), я просто использовал перенаправление 307 на данный момент.

return Response.status(307).location(new URI(redirectTo)).build();

Недостатком этого является то, что браузер отобразит URL-адрес переадресации в адресной строке.

UPDATE: RequestDispatcher работает сейчас, только не для этого особого случая /webapp, упомянутого выше. Поэтому я предпочитаю этот подход по переадресации.

Следует отметить, что аутентификация на основе контейнеров (например, realm) на втором веб-папе не будет эффективной (так как мы выполняем форвард "сзади"), так что dispatcher-app нуждается в самом методе аутентификации, или аутентификация должна быть с другим механизмом, таким как RequestFilter.