Umieść klasę serwletu w pliku package
Przede wszystkim umieść klasę serwletu w Javie package. Powinieneś zawsze umieszczać w pakiecie klasy Java, które można ponownie wykorzystać, w przeciwnym razie będą one niewidoczne dla klas znajdujących się w pakiecie, takich jak sam serwer. W ten sposób eliminujesz potencjalne problemy specyficzne dla środowiska. Serwlety bez pakietów działają tylko w określonych kombinacjach Tomcat + JDK i nigdy nie należy na tym polegać.
W przypadku „zwykłego” projektu IDE, klasę należy umieścić w strukturze pakietu w folderze „Java Resources”, a nie „WebContent”, dotyczy to plików internetowych, takich jak JSP. Poniżej znajduje się przykład struktury folderów w domyślnym projekcie Eclipse Dynamic Web Project w widoku Nawigatora :
EclipseProjectName
|-- src
| `-- com
| `-- example
| `-- YourServlet.java
|-- WebContent
| |-- WEB-INF
| | `-- web.xml
| `-- jsps
| `-- page.jsp
:
W przypadku projektu Maven klasa musi być umieszczona w strukturze pakietu wewnątrz, main/java a więc nie dotyczy to npmain/resources . Plików nieklasowych . Poniżej znajduje się przykład struktury folderów w domyślnym projekcie aplikacji internetowej Maven, jak widać w widoku Nawigatora Eclipse :
MavenProjectName
|-- src
| `-- main
| |-- java
| | `-- com
| | `-- example
| | `-- YourServlet.java
| |-- resources
| `-- webapp
| |-- WEB-INF
| | `-- web.xml
| `-- jsps
| `-- page.jsp
:
Zwróć uwagę, że /jspspodfolder nie jest bezwzględnie potrzebny. Możesz nawet obejść się bez tego i umieścić plik JSP bezpośrednio w katalogu głównym zawartości sieciowej / aplikacji internetowej, ale przejmuję to z twojego pytania.
Ustaw adres URL serwletu w url-pattern
Adres URL serwletu jest określony jako „wzorzec adresu URL” odwzorowania serwletu. Absolutnie nie jest to nazwa klasy / nazwa pliku klasy serwletu. Wzorzec adresu URL należy określić jako wartość @WebServletadnotacji.
package com.example;
@WebServlet("/servlet")
public class YourServlet extends HttpServlet {
}
Jeśli chcesz obsługiwać parametry ścieżki, takie jak /servlet/foo/bar, /servlet/*zamiast tego użyj wzorca adresu URL . Zobacz także parametry serwletu i ścieżki, takie jak / xyz / {wartość} / test, jak mapować w web.xml?
@WebServlet działa tylko na Servlet 3.0 lub nowszym
Aby użyć @WebServlet, musisz tylko upewnić się, że twój web.xmlplik, jeśli taki istnieje (jest opcjonalny od Servlet 3.0), jest zadeklarowany zgodnie z wersją Servlet 3.0+, a zatem nie jest zgodny, np. W wersji 2.5 lub niższej . Poniżej znajduje się kompatybilny z Servlet 4.0 (który pasuje do Tomcat 9+, WildFly 11+, Payara 5+ itp.).
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0"
>
</web-app>
Lub, jeśli nie korzystasz jeszcze z Servlet 3.0+ (np. Tomcat 6 lub starszy), usuń @WebServletadnotację.
package com.example;
public class YourServlet extends HttpServlet {
}
Zamiast web.xmltego zarejestruj serwlet w następujący sposób:
<servlet>
<servlet-name>yourServlet</servlet-name>
<servlet-class>com.example.YourServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>yourServlet</servlet-name>
<url-pattern>/servlet</url-pattern>
</servlet-mapping>
Zwróć uwagę, że nie powinieneś używać obu sposobów. Użyj konfiguracji opartej na adnotacjach lub konfiguracji opartej na języku XML. Gdy masz oba, konfiguracja oparta na języku XML zastąpi konfigurację opartą na adnotacjach.
Weryfikacja kompilacji / wdrożenia
Jeśli używasz narzędzia do budowania, takiego jak Eclipse i / lub Maven, musisz mieć absolutną pewność, że skompilowany plik klasy serwletu znajduje się w swojej strukturze pakietu w /WEB-INF/classesfolderze utworzonego pliku WAR. W przypadku package com.example; public class YourServlet, musi znajdować się w /WEB-INF/classes/com/example/YourServlet.class. W przeciwnym razie napotkasz @WebServletrównież błąd 404 lub <servlet>błąd HTTP 500, jak poniżej:
Stan HTTP 500
Błąd podczas tworzenia instancji klasy serwletu com.example.YourServlet
I znajdź w dzienniku serwera a java.lang.ClassNotFoundException: com.example.YourServlet, po którym z java.lang.NoClassDefFoundError: com.example.YourServletkolei następuje a, po którym następuje javax.servlet.ServletException: Error instantiating servlet class com.example.YourServlet.
Łatwym sposobem sprawdzenia, czy serwlet jest poprawnie skompilowany i umieszczony w ścieżce klas, jest pozwolenie narzędziu budującemu na utworzenie pliku WAR (np. Projekt kliknięcia prawym przyciskiem, eksport> plik WAR w Eclipse), a następnie sprawdzenie jego zawartości za pomocą narzędzia ZIP. Jeśli brakuje klasy serwletu /WEB-INF/classeslub jeśli eksport powoduje błąd, to projekt jest źle skonfigurowany lub niektóre domyślne ustawienia IDE / projektu zostały omyłkowo przywrócone (np. Projekt> Buduj automatycznie został wyłączony w Eclipse).
Musisz również upewnić się, że ikona projektu nie ma czerwonego krzyżyka wskazującego błąd kompilacji. Dokładny błąd można znaleźć w widoku Problemy ( Okno> Pokaż widok> Inne ... ). Zwykle komunikat o błędzie można umieścić w Google. Jeśli nie masz pojęcia, najlepiej jest uruchomić ponownie od zera i nie zmieniać żadnych domyślnych ustawień IDE / projektu. W przypadku korzystania z Eclipse instrukcje można znaleźć w artykule Jak zaimportować interfejs API javax.servlet do mojego projektu Eclipse?
Testowanie serwletu indywidualnie
Pod warunkiem, że serwer działa localhost:8080i że WAR jest pomyślnie wdrożony na ścieżce kontekstu /contextname(która domyślnie jest nazwą projektu IDE, z uwzględnieniem wielkości liter!), A inicjalizacja serwletu nie zakończyła się niepowodzeniem (odczyt dzienników serwera dla każdego wdrożenia / komunikaty o powodzeniu / niepowodzeniu serwletu oraz rzeczywista ścieżka kontekstowa i mapowanie serwletu), to serwlet z wzorcem adresu URL /servletjest dostępny pod adresem http://localhost:8080/contextname/servlet.
Możesz po prostu wpisać go bezpośrednio w pasku adresu przeglądarki, aby przetestować go niezauważalnie. Jeśli doGet()jest poprawnie zastąpiony i zaimplementowany, zobaczysz jego wynik w przeglądarce. Lub jeśli nie masz żadnego doGet()lub jeśli wywołuje to nieprawidłowo super.doGet(), to zostanie wyświetlony błąd „ HTTP 405: metoda HTTP GET nie jest obsługiwana przez ten adres URL ” (który jest nadal lepszy niż 404, ponieważ 405 jest dowodem, że aplet faktycznie znajduje się).
Zastępowanie service()jest złą praktyką, chyba że odkrywasz na nowo framework MVC - co jest bardzo mało prawdopodobne, jeśli dopiero zaczynasz od serwletów i nie masz pojęcia o problemie opisanym w bieżącym pytaniu;) Zobacz także aplikacje internetowe wzorce projektowe .
Niezależnie od tego, jeśli aplet już zwraca 404, gdy jest testowany przypadkowo, to całkowicie bezcelowe jest próbowanie zamiast tego z formularzem HTML. Logicznie rzecz biorąc, jest zatem całkowicie bezcelowe dołączanie jakichkolwiek formularzy HTML w pytaniach dotyczących błędów 404 z serwletu.
Odwoływanie się do adresu URL serwletu z HTML
Po upewnieniu się, że serwlet działa dobrze, gdy jest wywoływany indywidualnie, możesz przejść do HTML. Jeśli chodzi o konkretny problem z formularzem HTML, <form action>wartością musi być prawidłowy adres URL. To samo dotyczy <a href>. Musisz zrozumieć, jak działają bezwzględne / względne adresy URL. Wiesz, URL to adres internetowy, który możesz wpisać / zobaczyć na pasku adresu przeglądarki internetowej. Jeśli określasz względny adres URL jako akcję formularza, tj. Bez http://schematu, staje się on względny w stosunku do bieżącego adresu URL, jak widać na pasku adresu przeglądarki internetowej. W związku z tym absolutnie nie jest to związane z lokalizacją pliku JSP / HTML w strukturze folderów WAR serwera, jak wydaje się sądzić wielu początkujących.
Tak więc, zakładając, że strona JSP z formularza HTML otwiera http://localhost:8080/contextname/jsps/page.jspi trzeba złożyć do serwletu znajduje się http://localhost:8080/contextname/servlettu kilka przypadków (zauważ, że można bezpiecznie zastąpić <form action>z <a href>tutaj):
Akcja formularza jest przesyłana do adresu URL z początkowym ukośnikiem.
<form action="/servlet">
Początkowy ukośnik /wyznacza adres URL względem domeny, więc formularz zostanie przesłany do
http://localhost:8080/servlet
Ale prawdopodobnie spowoduje to 404, ponieważ jest w złym kontekście.
Akcja formularza jest przesyłana do adresu URL bez początkowego ukośnika.
<form action="servlet">
To sprawia, że adres URL jest powiązany z bieżącym folderem bieżącego adresu URL, a zatem formularz zostanie przesłany do
http://localhost:8080/contextname/jsps/servlet
Ale prawdopodobnie spowoduje to 404, ponieważ znajduje się w niewłaściwym folderze.
Akcja formularza jest przesyłana do adresu URL, który przechodzi o jeden folder w górę.
<form action="../servlet">
Spowoduje to przejście o jeden folder w górę (dokładnie tak, jak w przypadku ścieżek systemu plików na dysku lokalnym!), A zatem formularz zostanie przesłany do
http://localhost:8080/contextname/servlet
Ten musi działać!
Jednak podejście kanoniczne polega na tym, że adres URL jest zależny od domeny, aby nie trzeba było ponownie naprawiać adresów URL, gdy zdarzy się przenieść pliki JSP do innego folderu.
<form action="${pageContext.request.contextPath}/servlet">
To wygeneruje
<form action="/contextname/servlet">
Który w ten sposób zawsze zostanie przesłany pod właściwy adres URL.
Używaj prostych cudzysłowów w HTML
Musisz mieć absolutną pewność, że używasz prostych cudzysłowów w atrybutach HTML, takich jak action="..."lub, action='...'a zatem nie używasz cudzysłowów takich jak action=”...”lub action=’...’. Cudzysłowy nie są obsługiwane w HTML i staną się po prostu częścią wartości. Uważaj podczas kopiowania i wklejania fragmentów kodu z blogów! Wiadomo, że niektóre silniki blogów, zwłaszcza Wordpress, domyślnie używają tak zwanych „inteligentnych cudzysłowów”, które w ten sposób również zniekształcają cytaty we fragmentach kodu. Z drugiej strony, zamiast kopiować i wklejać kod, spróbuj po prostu wpisać kod samodzielnie. Dodatkową zaletą faktycznego przechodzenia kodu przez mózg i palce jest to, że w dłuższej perspektywie znacznie lepiej zapamiętasz i zrozumiesz kod, a także staniesz się lepszym programistą.
Zobacz też:
Inne przypadki błędu HTTP stanu 404:
