JavaRush /Blog Java /Random-FR /Partie 6 : Conteneurs de servlets

Niveau 41

28 février 2021
46 views
0 comments

Partie 6 : Conteneurs de servlets

Ce matériel fait partie de la série « Introduction au développement d'entreprise ». Articles précédents :

Dans le dernier article, nous nous sommes familiarisés avec les servlets et avons appris à créer des applications Web avec leur aide. Il est temps d'examiner de plus près ce sans quoi ces vacances ne seraient pas possibles : les conteneurs de servlets.

Contenu:

Qu'est-ce qu'un conteneur de servlets

Il s'agit d'un programme qui s'exécute sur le serveur et peut interagir avec les servlets que nous avons créés. En d'autres termes, si nous souhaitons exécuter notre application Web sur un serveur, nous déployons d'abord un conteneur de servlets, puis y plaçons les servlets. Le fonctionnement est simple : lorsqu'un client contacte le serveur, le conteneur traite sa requête, détermine quelle servlet doit la traiter et la transmet. Partie 6. Conteneurs de servlets - 2

Comment utiliser les conteneurs de servlets

En plus du routage des requêtes, le conteneur de servlets remplit d'autres fonctions :

Génère dynamiquement des pages HTML à partir de fichiers JSP.
Crypte/déchiffre les messages HTTPS.
Fournit un accès restreint pour l’administration des servlets.

En général, ça sonne bien, il ne reste plus qu'à trouver comment appliquer tout cela. Eh bien, pour apprendre à utiliser quelque chose, il vous suffit de... essayer de l'utiliser :) Alors aujourd'hui, nous allons pratiquer ! Le conteneur de servlets le plus populaire est Apache Tomcat . Il est open source et gratuit à utiliser. Téléchargez Tomcat pour votre système d'exploitation à partir de ce lien et voyons comment travailler avec les conteneurs en action.

Installer et exécuter Tomcat

Pour installer Tomcat, décompressez simplement l'archive téléchargée dans le répertoire souhaité.
Veuillez noter que Tomcat nécessite Java version 8 ou supérieure pour fonctionner. Assurez-vous que la variable d'environnement JAVA_HOME fait référence à la version actuelle de jdk.
Ensuite, vous devez configurer l'accès des utilisateurs à Tomcat . Cela se fait dans le fichier tomcat-users.xml, qui se trouve dans le dossier conf.

Tomcat est livré avec quatre rôles :
- manager-gui - accès à l'interface graphique et à la page d'état ;
- manager-script - accès à l'interface texte et à la page d'état ;
- manager-jmx - accès à JMX et à la page d'état ;
- manager-status - accès uniquement à la page d'état.
Dans la balise <tomcat-users>, nous écrirons explicitement ces rôles et les attribuerons à notre utilisateur :
```
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<user username="user" password="password"
    roles="manager-gui, manager-script, manager-jmx, manager-status"/>
```
Maintenant, tout est prêt à démarrer !
Dans le dossier bin, exécutez le fichier startup.bat (startup.sh sous Linux).
Après quelques secondes, ouvrez le lien http://localhost:8080/ dans votre navigateur . Le gestionnaire graphique y apparaîtra :

Si vous voyez un tel menu, cela signifie que Tomcat est en cours d'exécution.
Si cela ne fonctionne pas, vérifiez manuellement les variables d'environnement JAVA_HOME et CATALINA_HOME :
- JAVA_HOME - doit faire référence à la version actuelle de Java 8+ ;
- CATALINA_HOME - doit faire référence à Tomcat ou être absent (ne doit pas pointer vers une autre version de Tomcat).

Déployer une application sur Tomcat

Nous avons réussi à lancer Tomcat, il est donc temps d'y déployer une sorte de projet. Utilisons les servlets de l'article précédent . Serveur principal :

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.io.PrintWriter;

@WebServlet("/hello")
public class MainServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       HttpSession session = req.getSession();
       Integer visitCounter = (Integer) session.getAttribute("visitCounter");
       if (visitCounter == null) {
           visitCounter = 1;
       } else {
           visitCounter++;
       }
       session.setAttribute("visitCounter", visitCounter);
       String username = req.getParameter("username");
       resp.setContentType("text/html");
       PrintWriter printWriter = resp.getWriter();
       if (username == null) {
           printWriter.write("Hello, Anonymous" + "
");
       } else {
           printWriter.write("Hello, " + username + "
");
       }
       printWriter.write("Page was visited " + visitCounter + " times.");
       printWriter.close();
   }
}

IndexServlet :

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/")
public class IndexServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       resp.sendRedirect(req.getContextPath() + "/hello");
   }
}

Avant le déploiement, nos servlets doivent être empaquetés dans une archive de guerre. Maven est généralement utilisé pour cela, mais pour créer une archive de guerre, vous avez besoin d'un fichier web.xml dans lequel toutes les servlets sont mappées. Nous avons écrit des servlets en utilisant la nouvelle annotation @WebServlet, nous n'avons donc pas web.xml. Heureusement, IDEA peut faire le sale boulot à notre place et envelopper notre projet individuellement dans une archive de guerre. Pour ce faire, vous devez ouvrir la structure du projet (Ctrl + Shift + Alt + S) -> Artefacts -> Sélectionnez la build souhaitée -> Cochez la case à côté de « Inclure dans la build du projet » -> Cliquez sur « OK ». Partie 6 : Conteneurs de servlets - 4

Construisez un projet en utilisant la combinaison Ctrl + F9. Maintenant, notre archive war se trouve dans le répertoire cible. Partie 6 : Conteneurs de servlets - 5

Le fichier peut être renommé quelque chose de plus simple - par exemple, servlet.war - et déplacé vers un endroit plus pratique - dans C:\my\. Lorsque l'infusion est prête à être utilisée, placez-la dans un récipient . Ceci peut être fait de deux façons.

Via l'interface graphique

Pour ce faire, suivez le lien http://localhost:8080/manager/html . Tomcat devrait vous demander un identifiant et un mot de passe.

Si vous avez répété toutes les étapes après moi, alors le login est user, le mot de passe est password .

Après une autorisation réussie, vous verrez Tomcat Web Application Manager. La section Applications contient déjà 5 applications - ce sont des applications utilitaires Tomcat nécessaires pour simplifier son utilisation. Ils pourront être supprimés à l’avenir.

Vous trouverez ci-dessous la section Déployer. En l'utilisant, vous pouvez sélectionner une archive de guerre à déployer. Entrons manuellement le chemin et le contexte :

Cliquez sur « Déployer », nous voyons que notre application est apparue dans la section Applications :
En utilisant l'interface graphique de Tomcat, nous pouvons l'arrêter, le redémarrer, définir la durée de la session et la supprimer. Lors du déploiement, nous avons précisé le contexte /demo, ce qui signifie que notre application doit être accessible via le lien http://localhost:8080/demo . Vérifiez, tout devrait fonctionner.
Via le système de fichiers

Pour déployer une application de cette manière, vous devez ouvrir le répertoire dans lequel Tomcat est décompressé et accéder aux webapps. Voici les applications utilitaires que nous connaissons :

Tout ce que nous avons à faire est de déplacer notre servlet.war ici.

On attend quelques secondes, on voit qu'un nouveau dossier servlet est apparu, ce qui signifie que notre application est déployée. Passons à l'interface familière d'Application Manager - http://localhost:8080/manager/ . Nous voyons ici que notre application est déployée dans le contexte /servlet :

Lorsqu'il est déployé de cette manière, le contexte est automatiquement attribué au nom de l'archive de guerre déployée. Pour changer le contexte, vous pouvez renommer le dossier nouvellement créé avec l'application, mais avant cela vous devez supprimer le fichier : sinon Tomcat redéployera l'application avec le nom de l'archive.

Comme vous pouvez le constater, le déploiement d'applications sur Tomcat est beaucoup plus simple qu'il n'y paraît. Mais ses autres fonctions sont faciles à utiliser. Allons vérifier.

Utiliser le protocole HTTPS au lieu de HTTP

Si vous vous en souvenez, nous avons discuté de la différence entre HTTP et HTTPS dans un article séparé . HTTPS est le même protocole que HTTP, mais utilise le cryptage des données transférées. Côté client, le chiffrement est géré par le navigateur, et nous devons assurer le chiffrement côté serveur. Les requêtes HTTP étant acceptées et acheminées par Tomcat, il serait logique de lui déléguer le chiffrement. Pour ce faire, vous avez besoin de :

Générer un certificat auto-signé ;
Définissez des paramètres de serveur supplémentaires.

Pratiquons cela.

Générer un certificat

Le JDK est livré avec un grand nombre d'utilitaires, quelle que soit la version, dont keytool . Il s'agit d'un outil permettant de générer des clés de cryptage et de travailler avec elles. Pour l'utiliser, à l'aide de la ligne de commande, accédez au répertoire C:\Program Files\Java\jdk1.8.0_181\bin et exécutez la commande keytool -genkey -alias tomcat -keyalg RSA .

keytool - lancez l'utilitaire avec les paramètres ;
-genkey - indique que nous voulons générer une nouvelle clé ;
-alias tomcat — crée un alias de clé ;
-keyalg RSA - sélectionnez RSA comme algorithme de génération de clé.

Après avoir exécuté la commande, l'utilitaire entamera un dialogue avec nous : Partie 6 : Conteneurs de servlets - 11

Entrez les informations nécessaires. Nous avons maintenant créé un magasin de clés dans notre répertoire personnel (pour Windows, il s'agit de C:\Users\{username}\.keystore) et une clé Tomcat dedans. Nous avons généré un certificat simple que la plupart des navigateurs accepteront. Ce certificat n'est pas adapté aux applications commerciales : il ne peut être utilisé qu'à des fins de tests. Sur le serveur de production, vous devez utiliser un certificat d'une autorité de certification (par exemple, https://letsencrypt.org/ ).

Configuration du serveur

Maintenant que le certificat est prêt, vous devez ajuster les paramètres du serveur, à savoir le connecteur SSL. Cela se fait dans le fichier server.xml, qui se trouve dans apache-tomcat-9.0.30/conf/ . On retrouve des blocs comme :

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true">
        <SSLHostConfig>
            <Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
                         type="RSA" />
        </SSLHostConfig>
 </Connector>

et à côté d'eux nous plaçons notre configuration :

<Connector
       protocol="org.apache.coyote.http11.Http11NioProtocol"
       port="8443" maxThreads="200"
       scheme="https" secure="true" SSLEnabled="true"
       keystoreFile="C:\Users\user\.keystore" keystorePass="mypass"
       clientAuth="false" sslProtocol="TLS"/>

Nous attribuons aux paramètres keystoreFile et keystorePass les valeurs qui nous concernent, enregistrons et redémarrons Tomcat à l'aide des fichiers shutdown.bat et startup.bat. Le serveur est maintenant prêt à traiter les requêtes https, juste un peu à l'adresse modifiée - https://localhost:8443/demo/hello . Lorsque vous cliquez sur le lien, vous verrez un avertissement indiquant que le certificat est douteux, ce qui n'est pas surprenant. Comme décrit un peu plus tôt, pour obtenir un certificat normal, vous devez recourir aux services de l'un des services de certification. Mais pour l'instant nous avons atteint notre objectif : l'application fonctionne grâce au protocole HTTPS, et c'est l'essentiel !

Génération dynamique de pages HTML

Continuons maintenant notre examen des autres fonctionnalités des conteneurs de servlets - la génération dynamique de pages HTML. Imaginez un monde idéal dans lequel, au lieu d'un code HTML statique ennuyeux, vous pourriez écrire du code JAVA à l'aide de variables, de boucles, de tableaux et d'autres constructions de langage. Avez-vous imaginé ? La bonne nouvelle est que quelque chose de similaire existe, la mauvaise nouvelle est qu’il n’existe pas pleinement. Si vous ne l'avez pas deviné, nous parlons de la technologie JSP (Java Server Pages). En bref, il s'agit d'une technologie qui permet d'insérer des morceaux de code JAVA dans une page HTML. Certes, ce code est toujours transformé en HTML avant d'être envoyé au client, mais il sera généré dynamiquement en tenant compte de divers facteurs. Par exemple, vous pouvez utiliser des constructions conditionnelles et proposer un contenu différent en fonction de certaines conditions. Exemple de page JSP :

<%@ page language="java"" %>
<html>
<head>
<title>JSP</title>
</head>

<body>
<%
String firstName="name";
String secondName="surname";

    if(firstName.equals("name")){
      out.print("Hello :"+firstName+"<br>");
    }

    if(firstName.equals("name") && secondName.equals("surname"))
    {
      out.print("Hello, my dear friend! <br>");
    }
    else
    {
      out.print("I don’t know you. Go away! <br>");
    }
%>
</body>
</html>

Vous pouvez en savoir plus sur JSP ici . En fait... nous ne sommes pas là pour ça, mais pour le bien des conteneurs de servlets ! Qu’est-ce que JSP a à voir avec ça ? C'est simple : la transformation du code JAVA de JSP en code HTML est effectuée par le conteneur de servlet. Lorsqu'une servlet est sur le point de renvoyer du contenu JSP en réponse, le conteneur en prend note et le transforme d'abord en une page HTML lisible par le navigateur avant d'envoyer ce contenu au client. Il existe aujourd'hui de nombreux analogues de la technologie JSP - Thymeleaf, FreeMarket, Moustache et autres. Ils fonctionnent tous sur un principe similaire. Lequel choisir pour le travail est une question de goût. Cela s'applique également au choix d'un conteneur de servlet. Dans les exemples, nous avons utilisé Tomcat, le conteneur le plus courant, mais certains projets en utilisent d'autres. Cela vaut la peine de vous familiariser brièvement avec les plus populaires et d’examiner leurs différences par rapport à Tomcat.

Alternatives à Tomcat

GlassFish est un conteneur open source pris en charge par Oracle.

Contrairement à Tomcat, il s'agit d'un serveur Web à part entière qui, en plus des servlets, peut faire fonctionner d'autres composants du framework JavaEE. En même temps, il utilise beaucoup plus de RAM. Plus flexible lors du réglage fin du serveur, ce qui rend son utilisation plus difficile. Cela vaut la peine de l'utiliser lors du développement d'applications à l'aide du framework JavaEE.
WildFly - anciennement Jboss . Également open source. Développé par Red Hat. Le nom a été modifié pour éviter toute confusion avec un autre produit de l'entreprise : JBoss Enterprise Application Platform.

WildFly, comme GlassFish, est un serveur Web à part entière. À propos, sous le capot, WildFly utilise Tomcat comme conteneur de servlets. Contrairement à GlassFish, WildFly est plus léger et plus facile à configurer.
Jetty - similaire aux précédents, est open source. Développé par Eclipse.

Comme Tomcat, il s'agit d'un simple conteneur de servlets, sans prise en charge de tous les composants du framework JavaEE. En même temps, il est plus léger et peut même être exécuté sur un téléphone mobile. Il démarre et s'arrête rapidement et évolue bien. Contrairement à Tomcat, sa communauté et sa base de connaissances sont plus petites.
WebLogic est un logiciel sous licence qui nécessite un achat avant utilisation. Propriété d'Oracle.

Par rapport à Tomcat, ses fonctionnalités sont un peu plus larges. Peut fonctionner avec le protocole FTP. Mais il n’est pas aussi flexible lors du développement et du test d’applications.
WebSphere (WebSphere Application Server pour être précis) est un logiciel payant. Développé par IBM. Semblable à WildFly et GlassFish, il s'agit d'un serveur d'applications à part entière. Mais il possède une interface de configuration plus conviviale et une fiabilité opérationnelle élevée.

L'inconvénient est qu'il utilise beaucoup de ressources, prend beaucoup de temps pour démarrer et s'arrêter, ce qui n'est pas très pratique lors du développement de petits projets.

Le conteneur de servlets ou le serveur d'applications à choisir dépend du projet spécifique. Il existe des projets dans lesquels même un étranger évident sera en mesure de faire ses preuves avec la plus haute qualité, mais au début, il est préférable de bien comprendre une chose. Le candidat idéal pour celui-ci est probablement Tomcat. Nous avons déjà fait les premiers pas pour l’étudier, et ensuite à vous de jouer ! Dans les derniers articles de la série « Introduction au développement d'entreprise », nous nous familiariserons avec le modèle MVC. Partie 7. Introduction au modèle MVC (Model-View-Controller) Partie 8. Écriture d'une petite application avec Spring-boot

Commentaires

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION