Niedawno zaktualizowałem mój serwer tomcat z wersji 6.x do najnowszej wersji 7.x.
Wpadłem z niewielkimi problemami, mając nadzieję na pomoc.
Mam aplikację o nazwie MyApp
Na tomcat6, kiedy poszedłem na stronę http://www.example.com/MyApp/page/ , zwykle uzyskałem pożądany wynik.
Teraz na tomcat7, odwiedzając ten sam dokładny adres URL (z ukośnikiem końcowym), pojawia się błąd: „Zasób nie jest dostępny”, ponieważ tomcat uważa, że / MyApp / page / to cała nazwa aplikacji internetowej zamiast nazwy żądań strona w aplikacji internetowej MyApp.
Potrzebuję ukośnika na końcu mojego adresu URL, ponieważ w przeciwnym razie pojawia się błąd: „HTTP Status 405 - Metoda żądania„ GET ”nie jest obsługiwana”, co jest prawidłowe, ponieważ tak naprawdę nie zezwalam na metodę GET na żądanie „strony” .
Jeśli ktoś wie, jak powiedzieć tomcatowi, że końcowy ukośnik po ścieżce istniejącej aplikacji internetowej nie powinien zakładać, że przekieruje ją do nowej aplikacji internetowej wywołującej cały „ciąg” i po prostu przetworzy żądanie jak na tomcat6, byłoby świetnie!
web.xmlmapowanym jest domyślny serwlet/*? W przeciwnym razie tomcat używa listy plików powitalnych. Zwykle tylko pierwszy segment ścieżki jest interpredetowany jako kontekstowy katalog główny. Dlatego nie wydaje się, aby znalezienie Twojej aplikacji internetowej było problemem.MyAppaplikację internetową skonfigurowaną z tą nazwą, tomcat użyje tego kontekstu aplikacji internetowej, używając pozostałej ścieżkipage/. Jeśli nie, wyszukaROOTkontekst, korzystając z pełnej ścieżki wyszukiwania.Odpowiedzi:
Pradawne pytanie, ale odkąd ostatnio walczyłem z końcowym ukośnikiem w Tomcat 8, wiem, że problemy z ukośnikiem nadal nękają świat użytkowników Tomcat. :-)
To, na co możesz natknąć się, to zmiany w sposobie, w jaki Tomcat obsługuje przekierowania podczas ładowania kontekstu głównego. Sprawdź błąd 58660 i przeczytaj część dyskusji programistów. Może być konieczne wyłączenie domyślnego elementu mapującego poprzez modyfikację
mapperContextRootRedirectEnabledatrybutuContextelementu wconf/context.xml.źródło
Sprawdź listę plików powitalnych ... poniżej spekulacje ...
Uważam, że istotą problemu jest to, że Tomcat jest prezentowany z / - Ma kilka opcji - Iteruj po liście plików powitalnych - Na niczym nie ma - pokaż listę katalogów (jeśli jest włączona)
Tutaj zaczyna się zabawa ... Wielu ludzi chce używać * .do do takich rzeczy jak rozpórki. Dlatego chcą, aby index.do było stroną główną. Lub wspólny jest index.jsp, gdzie * .jsp jest mapowany na JspServlet.
Tutaj jest zabawa. Powiedzmy, że twoje pliki powitalne to index.jsp, index.do.
To, co robi Tomcat (IIRC), to najpierw iteracja listy plików powitalnych w poszukiwaniu zasobów o tej nazwie.
Następnie wykona drugie przejście w poszukiwaniu pasujących mapowań. Więc jeśli indeks.jsp jest określony na liście powitalnej, a * .jsp jest mapowany. Następnie tomcat spróbuje przekazać dalej do index.jsp, a otrzymasz 404.
Zgaduję, że masz mapowanie serwletu i nakładanie się plików powitalnych. A zachowanie tego serwletu nie obsługuje GET. (Stąd 405)
źródło
Jeśli Twój projekt korzysta z dynamicznego modułu WWW w wersji 2.2, musisz jawnie utworzyć co najmniej jeden plik (może to być pusty plik HTML) znajdujący się w pliku web.xml (np .: index.html) w treści WWW.
źródło