Servlets
Le composant qui traite une requête HTTP, et le contrat que le conteneur vous impose.
Servlets Java
Une servlet est la seule chose qui, dans une application Jakarta EE, transforme réellement une requête HTTP en réponse. Tout le reste — JSP, JSTL, filtres, frameworks entiers comme Spring MVC — est construit par-dessus. Quand vous écrivez un @RestController Spring, il finit sa course dans une servlet nommée DispatcherServlet. Comprendre cette classe, c'est comprendre le socle de tout le web Java.
Le problème que résout la servlet est celui de la concurrence. Cent visiteurs frappent votre serveur en même temps. Faut-il créer cent objets ? Cent threads ? Qui les détruit ? La réponse de la spécification est contre-intuitive et lourde de conséquences : le conteneur crée une seule instance de votre servlet et la fait traverser par tous les threads simultanément. Cette décision, prise pour vous, explique la moitié des bugs de production dans les applications Java web : un champ d'instance dans une servlet est un état partagé entre tous les utilisateurs.
Cette leçon suit une requête de bout en bout : comment le conteneur choisit quelle servlet appeler, quand il instancie et détruit l'objet, comment lire les paramètres et les en-têtes, comment décider entre une redirection et un transfert, et comment retrouver un visiteur d'une requête à la suivante alors que HTTP n'a aucune mémoire.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion