Czy RequestDispatcher działa na wielu aplikacjach internetowych?

Pytam, ponieważ miałem jedną poprawną aplikację webapp, która używa RequestDispatcher zamiast przekierowań, więc stan nie jest tracony podczas wyświetlania komunikatów o błędach i sprzężeniach zwrotnych.

Jednak teraz muszę podzielić pewną funkcjonalność między dwie aplikacje internetowe, więc początkowe połączenie jest wykonywane ze strony internetowej hostowanej na webapp1, wywołuje webapp2, która ostatecznie zwraca użytkownika na stronę hostowaną na webapp1.

Oczywiście, jeśli webapps i webapp2 byłyby na różnych stronach internetowych za pomocą RequestDispatcher, nie byłoby to możliwe, ale czy oba webappy są wdrażane w tej samej instancji kontenera serwletów (tomcat 7)

Aktualizacja

Dostałem część dyspozytora żądania, aby działała jak wyjaśniono w odpowiedzi, ale nie mogę pobrać danych umieszczonych w moim webapp2, dlatego używam go

to znaczy

webapp2 dzwonił, przetwarzał, a następnie wysyłał do jsp na 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); 
}

Plik jsp webapp2 zawiera

...
<p>Email(<%=((String)session.getAttribute("DATA"))%>)</p>
...

ale zawsze wyświetla null

 Aktualizacja 2 **

Zastanawiam się, czy nie rozumiem, co tak naprawdę robi crossContext = „true”. Czy to sprawia, że ​​ta sama HttpSession jest dostępna w różnych webappach, czy też po prostu sprawia, że ​​ServletContext z jednej strony internetowej jest dostępna dla innego, a zatem pozwala jednej aplikacji internetowej zobaczyć HttpSessions innej aplikacji internetowej?

Zaczynam myśleć, że to, co robię, jest złym pomysłem, ponieważ zawsze chciałem używać ustawień serwletu waniliowego i nigdy nie chcieliśmy wiązać się z konkretną implementacją. Myślę, że może to pomóc, jeśli wytłumaczę, dlaczego w pierwszej kolejności potrzebuję podzielić aplikacje internetowe.

Miałem jeden webapp (webapp1), który był stroną internetową o produkcie, który rozwijam i kodem do zakupu tego produktu za pomocą Google Checkout (obecnie Portfel Google).

Następnie dodałem nową aplikację internetową dla nowego produktu (webapp2).

Następnie próbowałem dodać usługę Google Checkout dla nowego produktu do webapp2, ale zdałem sobie sprawę, że nie mogę tego zrobić łatwo, ponieważ usługa Google Checkout wymaga podania adresu URL, który może wywołać przez aplikację po przetworzeniu płatności, aby następnie wysłać użytkownikowi licencja. Adres URL został już ustawiony na serwlet w webapp1, ale webapp1 nie miałoby sensu przetwarzać płatności za produkt 2.

Jedną z opcji było scalenie webpp1 i webapp2 w jedną aplikację internetową, ale jest to sprzeczne z moim ogólnym poglądem o zachowaniu modularności, oznaczałoby to również, że czas eve, który chciałbym zrobić dla jednego produktu, musiałem ponownie wdrożyć wszystko. Oznaczało to również duże modyfikacje webapp1, których naprawdę nie chciałem modyfikować, ponieważ działał i był stabilny.

Alternatywą było utworzenie webapp3, a następnie google url może wskazać na to i użyć go do przetwarzania zakupów produktu 1 i produktu 2, co zrobiłem. Problem polega jednak na tym, że przy zakupie produktu 1 strona startowa znajduje się w webapp1, a po dokonaniu zakupu chcę wrócić do strony w webapp1, ale tylko webapp3 ma dane użytkownika, który właśnie dokonał zakupu, który chciałem wyświetlać na stronie w webapp1.