Servlet renvoie «HTTP Status 404 La ressource demandée (/ servlet) n’est pas disponible»

J’ai un formulaire HTML dans un fichier JSP dans mon dossier WebContent/jsps . J’ai une classe de servlet servlet.java dans mon package par défaut dans le dossier src . Dans mon web.xml il est mappé en tant que /servlet .

J’ai essayé plusieurs URL dans l’atsortingbut action du formulaire HTML:

 
  
  
  

Mais aucun de ces travaux. Ils continuent tous à retourner une erreur HTTP 404 comme ci-dessous dans Tomcat 6/7/8:

Statut HTTP 404 – / servlet

Description : La ressource demandée (/ servlet) n’est pas disponible.

Ou comme ci-dessous dans Tomcat 8.5 / 9:

Statut HTTP 404 – Introuvable

Message : / servlet

Description : le serveur d’origine n’a pas trouvé de représentation actuelle de la ressource cible ou ne souhaite pas en divulguer une

Pourquoi ça ne marche pas?

Mettez la classe de servlet dans un package

Tout d’abord, placez la classe de servlet dans un package Java. Vous devez toujours placer les classes Java publiquement réutilisables dans un package, sinon elles sont invisibles pour les classes contenues dans un package, tel que le serveur lui-même. De cette façon, vous éliminez les problèmes potentiels spécifiques à l’environnement. Les servlets sans packag ne fonctionnent que dans des combinaisons Tomcat + JDK spécifiques et il ne faut jamais s’y fier.

Dans le cas d’un projet IDE “ordinaire”, la classe doit être placée dans la structure de son paquet dans le dossier “Ressources Java” et non pas “WebContent”, c’est-à-dire pour les fichiers Web tels que JSP. Vous trouverez ci-dessous un exemple de la structure de dossiers d’un projet Web dynamic Eclipse par défaut, telle que vue dans la vue Navigateur :

 EclipseProjectName |-- src | `-- com | `-- example | `-- YourServlet.java |-- WebContent | |-- WEB-INF | | `-- web.xml | `-- jsps | `-- page.jsp : 

Dans le cas d’un projet Maven, la classe doit être placée dans sa structure de paquet à l’intérieur de main/java et donc pas par exemple main/resources , c’est pour les fichiers non-class . Vous trouverez ci-dessous un exemple de la structure de dossiers d’un projet Webapp Maven par défaut, tel qu’il apparaît dans la vue Navigateur d’Eclipse:

 MavenProjectName |-- src | `-- main | |-- java | | `-- com | | `-- example | | `-- YourServlet.java | |-- resources | `-- webapp | |-- WEB-INF | | `-- web.xml | `-- jsps | `-- page.jsp : 

Notez que le sous-dossier /jsps n’est pas ssortingctement nécessaire. Vous pouvez même vous en passer et placer le fichier JSP directement dans webcontent / webapp root, mais je ne fais que reprendre votre question.

Définit l’URL du servlet dans un url-pattern

L’URL de servlet est spécifiée comme “modèle d’URL” du mappage de servlet. Ce n’est absolument pas par définition le nom de classe / nom de fichier de la classe de servlet. Le modèle d’URL doit être spécifié en tant que valeur de l’annotation @WebServlet .

 package com.example; // Use a package! @WebServlet("/servlet") // This is the URL of the servlet. public class YourServlet extends HttpServlet { // Must be public and extend HttpServlet. // ... } 

Si vous souhaitez prendre en charge des parameters de chemin tels que /servlet/foo/bar , utilisez plutôt un modèle d’URL de /servlet/* . Voir aussi Paramètres de servlet et de chemin d’access, tels que / xyz / {value} / test, comment mapper dans web.xml?

@WebServlet ne fonctionne que sur Servlet 3.0 ou plus récent

Pour utiliser @WebServlet , il vous suffit de vous assurer que votre fichier web.xml , le cas échéant (facultatif depuis Servlet 3.0), est déclaré conforme à la version Servlet 3.0+ et donc non conforme à la version 2.5 ou inférieure . Ci-dessous, une version compatible Servlet 3.1 (qui correspond à Tomcat 8+, WildFly 8+, GlassFish 4+, etc.).

 < ?xml version="1.0" encoding="UTF-8"?>    

Ou, si vous n’êtes pas encore sur Servlet 3.0+ (pas Tomcat 7 ou plus récent, mais Tomcat 6 ou plus ancien), supprimez l’annotation @WebServlet .

 package com.example; public class YourServlet extends HttpServlet { // ... } 

Et enregistrez le servlet à la place dans web.xml comme ceci:

  yourServlet com.example.YourServlet   yourServlet /servlet   

Notez donc que vous ne devez pas utiliser les deux manières. Utilisez la configuration basée sur les annotations ou la configuration XML. Lorsque vous disposez des deux, la configuration basée sur XML remplace la configuration basée sur les annotations.

Vérification de la construction / du déploiement

Si vous utilisez un outil de génération tel que Eclipse et / ou Maven, vous devez vous assurer que le fichier de classe de servlet compilé réside dans sa structure de package dans le dossier /WEB-INF/classes du fichier WAR produit. En cas de package com.example; public class YourServlet package com.example; public class YourServlet , elle doit se trouver dans /WEB-INF/classes/com/example/YourServlet.class . Sinon, vous rencontrerez en cas de @WebServlet une erreur 404, ou en cas de une erreur HTTP 500 comme ci-dessous:

Statut HTTP 500

Erreur lors de l’instanciation de la classe de servlet com.example.YourServlet

Et trouvez dans le journal du serveur une java.lang.ClassNotFoundException: com.example.YourServlet , suivie d’un java.lang.NoClassDefFoundError: com.example.YourServlet , suivi à son tour par javax.servlet.ServletException: Error instantiating servlet class com.example.YourServlet .

Un moyen simple de vérifier si le servlet est correctement compilé et placé dans classpath consiste à laisser l’outil de génération produire un fichier WAR (par exemple, projet Rightclick, Exporter> fichier WAR dans Eclipse), puis inspecter son contenu avec un outil ZIP. Si la classe de servlet est manquante dans /WEB-INF/classes , le projet est mal configuré ou certaines valeurs par défaut de la configuration de l’EDI / du projet ont été annulées (par exemple, Project> Build Automatically a été désactivé dans Eclipse). Au cas où vous ne le sauriez pas, le mieux est de redémarrer à partir de zéro et de ne pas toucher aux valeurs par défaut de la configuration IDE / projet.

Test individuel du servlet

A condition que le serveur s’exécute sur localhost:8080 et que le déploiement de WAR s’effectue avec succès sur un chemin d’access contextuel de /contextname (qui /contextname défaut le nom du projet IDE, sensible à la casse!) Et l’initialisation du servlet les journaux pour tous les messages de réussite / échec de déploiement / servlet et le chemin de contexte et le mappage de servlet), puis un servlet avec un modèle d’URL de /servlet est disponible à l’ http://localhost:8080/contextname/servlet .

Vous pouvez simplement le saisir directement dans la barre d’adresse du navigateur pour le tester par Si son doGet() est correctement doGet() et implémenté, sa sortie apparaîtra dans le navigateur. Ou si vous ne possédez pas de doGet() ou s’il appelle incorrectement super.doGet() , une erreur ” HTTP 405: méthode HTTP GET n’est pas prise en charge par cette URL ” s’affichera comme un 405 est la preuve que le servlet lui-même est réellement trouvé).

Le service() prioritaire service() est une mauvaise pratique, à moins que vous ne réinventiez un framework MVC – ce qui est très improbable si vous débutez avec des servlets et que vous n’avez aucune idée du problème décrit dans la question actuelle; applications basées .

Quoi qu’il en soit, si le servlet retourne déjà 404 lorsqu’il est testé par erreur, il est inutile d’essayer un formulaire HTML à la place. Logiquement, il est donc tout à fait inutile d’inclure un formulaire HTML dans les questions concernant les erreurs 404 d’une servlet.

Référencement de l’URL du servlet à partir de HTML

Une fois que vous avez vérifié que le servlet fonctionne correctement lorsqu’il est appelé individuellement, vous pouvez passer au format HTML. En ce qui concerne votre problème concret avec le formulaire HTML, la valeur

doit être une URL valide. Il en va de même pour . Vous devez comprendre comment fonctionnent les URL absolues / relatives. Vous savez, une URL est une adresse Web que vous pouvez entrer / voir dans la barre d’adresse du navigateur Web. Si vous spécifiez une URL relative en tant qu’action de formulaire, c’est-à-dire sans le schéma http:// , elle devient alors relative à l’URL actuelle, comme vous le voyez dans la barre d’adresse de votre navigateur http:// . Il ne s’agit donc absolument pas de l’emplacement du fichier JSP / HTML dans la structure du dossier WAR du serveur, comme semblent le penser beaucoup de participants.

Donc, en supposant que la page JSP avec le formulaire HTML soit ouverte par http://localhost:8080/contextname/jsps/page.jsp , et que vous devez soumettre à un servlet situé dans http://localhost:8080/contextname/servlet , voici plusieurs cas (notez que vous pouvez remplacer

par ici) en toute sécurité:

  • L’action de formulaire est soumise à une URL avec une barre oblique.

     

    La barre oblique / marque l’URL par rapport au domaine, ainsi le formulaire soumettra à

     http://localhost:8080/servlet 

    Mais cela entraînera probablement un 404 car il se trouve dans le mauvais contexte.


  • L’action de formulaire est soumise à une URL sans barre oblique.

     

    Cela rend l’URL relative au dossier actuel de l’URL actuelle, donc le formulaire soumettra à

     http://localhost:8080/contextname/jsps/servlet 

    Mais cela entraînera probablement un 404 car il se trouve dans le mauvais dossier.


  • L’action de formulaire soumet à une URL qui affiche un dossier.

     

    Cela va aller un dossier vers le haut (exactement comme dans les chemins du système de fichiers de disque local!), Donc le formulaire soumettra à

     http://localhost:8080/contextname/servlet 

    Celui-ci doit travailler!


  • L’approche canonique consiste toutefois à rendre l’URL du domaine apparenté de sorte que vous n’ayez plus besoin de réparer les URL lorsque vous déplacez les fichiers JSP dans un autre dossier.

     

    Cela va générer

     

    Qui sera donc toujours soumis à la bonne URL.


Utiliser des citations droites en HTML

Vous devez absolument vous assurer que vous utilisez des guillemets droits dans les atsortingbuts HTML comme action="..." ou action='...' et donc pas de guillemets comme action=”...” ou action='...' . Les guillemets ne sont pas pris en charge en HTML et feront tout simplement partie de la valeur.

Voir également:

  • La page wiki de nos servlets – Contient des exemples de bonjour au monde
  • Comment appeler la classe de servlet à partir du formulaire HTML
  • doGet et doPost dans les servlets
  • Comment passer l’élément actuel à la méthode Java en cliquant sur un lien hypertexte ou un bouton dans la page JSP?

Autres cas d’erreur HTTP Status 404:

  • Statut HTTP 404 – Servlet [ServletName] non disponible
  • Statut HTTP 404 – La ressource demandée (/ NomProjet /) n’est pas disponible
  • Statut HTTP 404 – La ressource demandée (/) n’est pas disponible
  • JSP dans / WEB-INF renvoie “HTTP Status 404 La ressource demandée n’est pas disponible”
  • Le référencement d’une ressource placée dans le dossier WEB-INF dans le fichier JSP renvoie HTTP 404 sur la ressource
  • Le navigateur ne peut pas accéder / rechercher des ressources relatives telles que les CSS, les images et les liens lors de l’appel d’un servlet vers une JSP

Solution pour le HTTP Status 404 dans NetBeans IDE: Faites un clic droit sur votre projet et accédez aux propriétés de votre projet, puis cliquez sur Exécuter, puis saisissez l’URL relative à votre projet comme index.jsp .

  1. Projet-> Propriétés
  2. Cliquez sur Run
  3. URL relative: /index.jsp (Sélectionnez l’URL racine de votre projet)

entrer la description de l'image ici

Scénario n ° 1: vous avez été accidentellement redéployé à partir de la ligne de commande alors que tomcat était déjà en cours d’exécution .

Réponse courte: arrêtez Tomcat, supprimez le dossier cible , le package mvn, puis réinstallez


Scénario n ° 2: request.getRequestDispatcher (” MIS_SPELLED_FILE_NAME .jsp”)

Réponse courte: Vérifiez l’ orthographe du nom de fichier, assurez-vous que le cas est correct.


Scénario n ° 3: Exceptions à la classe introuvable (Réponse mise à jour car: Question n ° 17982240) (Exception java.lang.ClassNotFoundException pour servlet dans Tomcat avec éclipse ) (marqué comme duplicata et dirigé ici)

Réponse courte # 3.1: web.xml a un chemin de package incorrect dans la balise de classe de servlet.

Réponse courte # 3.2: le fichier java a une déclaration d’importation incorrecte.


Vous trouverez ci-dessous d’autres détails sur le scénario 1:


1: Stop Tomcat

  • Option 1: Via CTRL + C dans le terminal.
  • Option 2: (terminal fermé pendant que Tomcat est toujours en cours d’exécution)
  • ———— 2.1: appuyez sur: Windows + R -> tapez: ” services.msc
  • ———— 2.2: Trouver “Apache Tomcat #. # Tomcat #” dans la colonne Nom de la liste.
  • ———— 2.3: Clic droit -> ” stop

2: Supprimez le dossier “target”. (mvn clean ne vous aidera pas ici)

3: paquet mvn

4: YOUR_DEPLOYMENT_COMMAND_HERE

(Mine: java -jar target / dependency / webapp-runner.jar –port 5190 target / *. War)

Full Back Story:


Accidentellement ouvert une nouvelle fenêtre git-bash et essayé de déployer un fichier .war pour mon projet heroku via:

java -jar target / dependency / webapp-runner.jar –port 5190 target / *. war

Après l’échec du déploiement, j’ai réalisé que deux fenêtres git-bash étaient ouvertes et que CTLR + C n’avait pas été utilisé pour arrêter le déploiement précédent .

J’ai été rencontré avec:

Statut HTTP 404 – Rapport d’état du type introuvable

Message /if-student-test.jsp

Description Le serveur d’origine n’a pas trouvé de représentation actuelle de la ressource cible ou ne souhaite pas en divulguer l’existence.

Apache Tomcat / 8.5.31

Vous trouverez ci-dessous plus de détails sur le scénario n ° 3:


SCENARIO 3.1: Le chemin du package de classe de servlet est incorrect dans votre fichier web.xml.

Il doit correspondre à la déclaration de package en haut de votre classe de servlet Java.

Fichier: my_stuff / MyClass.java :

  package my_stuff; 

Fichier: PRJ_ROOT / src / main / webapp / WEB-INF / web.xml

   my_stuff.MyClass  

SCÉNARIO 3.2:

Vous mettez la mauvaise instruction ” package ” en haut de votre fichier myClass.java.

Par exemple:

Le fichier se trouve dans le dossier ” / my_stuff

Vous écrivez par erreur:

 package com.my_stuff 

C’est difficile parce que:

1: Le build maven (package mvn) ne signalera aucune erreur ici.

2: la ligne de classe de servlet dans web.xml peut avoir un chemin de package correct. Par exemple:

  my_stuff.MyClass  

Stack Used: Blocnotes ++ + GitBash + Maven + Application Web Heroku Runner + Tomcat9 + Windows10 :