Работает ли RequestDispatcher над несколькими веб-приложениями в одном контейнере сервлетов?

Работает ли RequestDispatcher через несколько веб-приложений?

Я спрашиваю, потому что у меня было одно веб-приложение, работающее нормально, которое использует RequestDispatcher, а не перенаправляет, поэтому состояние не теряется при отображении сообщений об ошибках и обратной связи.

Однако теперь мне нужно разделить некоторые функции между двумя веб-приложениями, поэтому первоначальный вызов выполняется с веб-страницы, размещенной в webapp1, вызывает webapp2, которая в конечном итоге возвращает пользователя на страницу, размещенную в webapp1.

Ясно, что если бы webapps и webapp2 находились на разных сайтах, использовать RequestDispatcher было бы невозможно, но это так, если оба веб-приложения были развернуты в одном и том же экземпляре контейнера сервлета (tomcat 7)

Обновить

Получил часть диспетчера запросов для работы, как объяснено в ответе, но я не могу получить данные, помещенные в мое webapp2, поэтому я использую его

т.е.

Вызывается webapp2, выполняет некоторую обработку, а затем отправляет jsp на webapp1.

protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException
{

    HttpSession userSession = request.getSession(true);
    String emailAddress = ......
    String nextPage     = /finish.jsp
    userSession.setAttribute("DATA", emailAddress);
    ServletContext otherContext = getServletContext().getContext("/webapp1");
    otherContext.getRequestDispatcher(nextPage).forward(request, response); 
}

JSP-файл webapp2 содержит

...
<p>Email()</p>
...

но всегда показывает ноль

 Обновление 2 **

Мне интересно, не понимаю ли я, что такое crossContext = "правда" на самом деле Делает ли он один и тот же HttpSession доступным в разных веб-приложениях, или он просто делает ServletContext из одного веб-сайта доступным для другого и, следовательно, позволяет одному веб-приложению видеть HttpSessions другого веб-приложения?

Я начинаю думать, что то, что я делаю, - плохая идея, так как я всегда стремился использовать настройки vanilla servlet и никогда не хотел привязывать себя к конкретной реализации. Я думаю, что это могло бы помочь, если бы я объяснил, почему я сначала решил разделить веб-приложения.

У меня было одно веб-приложение (webapp1), это был веб-сайт о продукте, который я разрабатываю, и код для покупки этого продукта с помощью Google Checkout (теперь Google Wallet).

Затем я добавил созданный новый веб-приложение для нового продукта (webapp2).

Затем я попытался добавить Google Checkout для нового продукта в webapp2, но понял, что не могу сделать это легко, потому что Google Checkout требует от меня предоставить ему URL-адрес, по которому он может вызывать приложение после обработки платежа, чтобы я мог затем отправить пользователю лицензия. URL был уже установлен на сервлет в webapp1, но это неДля webapp1 имеет смысл обрабатывать платежи для продукта 2.

Один из вариантов состоял в том, чтобы объединить webpp1 и webapp2 в одно webapp, но это противоречит моему общему мнению о сохранении модульности, это также означало бы, что каждый раз, когда я хотел бы сделать изменения для одного продукта, мне пришлось бы перераспределять все. Это также означало большие изменения в webapp1, которые я действительно не хотел изменять, поскольку он работал и работал стабильно.

Альтернативой было создание webapp3, и затем URL-адрес Google может указывать на это и использовать его для обработки покупок продукта 1 и продукта 2, что я и сделал. Но проблема в том, что при покупке продукта 1 начальная страница находится в webapp1, и после совершения покупки я хочу вернуться на страницу в webapp1, но только в webapp3 есть данные о пользователе, который только что совершил покупку, которую я хотел для отображения на странице в webapp1.

Ответы на вопрос(3)

Ваш ответ на вопрос