JavaRush /Java Blog /Random-IT /Parte 6: Contenitori servlet

Livello 41

28 febbraio 2021
46 views
0 comments

Parte 6: Contenitori servlet

Questo materiale fa parte della serie "Introduzione allo sviluppo aziendale". Articoli precedenti:

Nell'ultimo articolo abbiamo conosciuto i servlet e abbiamo imparato come creare applicazioni web con il loro aiuto. È tempo di dare un'occhiata più da vicino a ciò senza cui questa vacanza non sarebbe possibile: i contenitori servlet.

Contenuto:

Cos'è un contenitore servlet

Questo è un programma che gira sul server e può interagire con i servlet che abbiamo creato. In altre parole, se vogliamo eseguire la nostra applicazione web su un server, distribuiamo prima un contenitore servlet e poi inseriamo al suo interno i servlet. Il modo in cui funziona è semplice: quando un client contatta il server, il contenitore elabora la sua richiesta, determina quale servlet deve elaborarla e la trasmette. Parte 6. Contenitori servlet - 2

Come utilizzare i contenitori servlet

Oltre all'instradamento delle richieste, il servlet container svolge altre funzioni:

Genera dinamicamente pagine HTML da file JSP.
Crittografa/decrittografa i messaggi HTTPS.
Fornisce accesso limitato per l'amministrazione del servlet.

In generale suona bene, non resta che capire come applicare il tutto. Bene, per imparare a usare qualcosa, devi solo... provare a usarlo :) Quindi oggi faremo pratica! Il contenitore servlet più popolare è Apache Tomcat . È open source e gratuito da usare. Scarica Tomcat per il tuo sistema operativo da questo link e vediamo come lavorare con i container in azione.

Installazione ed esecuzione di Tomcat

Per installare Tomcat è sufficiente decomprimere l'archivio scaricato nella directory desiderata.
Tieni presente che Tomcat richiede Java versione 8 o successiva per funzionare. Assicurati che la variabile d'ambiente JAVA_HOME si riferisca alla versione corrente di jdk.
Successivamente è necessario configurare l'accesso utente a Tomcat . Questa operazione viene eseguita nel file tomcat-users.xml, che si trova nella cartella conf.

Tomcat viene fornito con quattro ruoli preimpostati:
- manager-gui - accesso all'interfaccia grafica e alla pagina di stato;
- manager-script: accesso all'interfaccia testuale e alla pagina di stato;
- manager-jmx: accesso a JMX e pagina di stato;
- manager-status: accesso solo alla pagina di stato.
All'interno del tag <tomcat-users> scriveremo esplicitamente questi ruoli e li assegneremo al nostro utente:
```
<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"/>
```
Adesso è tutto pronto per il lancio!
Nella cartella bin, esegui il file startup.bat (startup.sh su Linux).
Dopo alcuni secondi, apri il collegamento http://localhost:8080/ nel tuo browser . Lì apparirà la gestione grafica:

Se vedi un menu di questo tipo, significa che Tomcat è in esecuzione.
Se non funziona, controlla manualmente le variabili d'ambiente JAVA_HOME e CATALINA_HOME:
- JAVA_HOME - deve fare riferimento alla versione corrente di Java 8+;
- CATALINA_HOME - deve fare riferimento a Tomcat o essere assente (non deve puntare a un'altra versione di Tomcat).

Distribuzione di un'applicazione a Tomcat

Siamo riusciti a lanciare Tomcat, quindi è ora di implementare una sorta di progetto al suo interno. Usiamo i servlet dell'articolo precedente . Servlet principale:

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");
   }
}

Prima della distribuzione, i nostri servlet devono essere impacchettati in un archivio di guerra. Di solito viene utilizzato Maven per questo, ma per creare un archivio di guerra è necessario un file web.xml in cui sono mappati tutti i servlet. Abbiamo scritto servlet utilizzando la nuova annotazione @WebServlet, quindi non abbiamo web.xml. Fortunatamente, IDEA può fare il lavoro sporco per noi e racchiudere il nostro progetto individualmente in un archivio di guerra. Per fare ciò, devi aprire la struttura del progetto (Ctrl + Maiusc + Alt + S) -> Artefatti -> Seleziona la build desiderata -> Seleziona la casella accanto a "Includi nella build del progetto" -> Fai clic su "OK". Parte 6: Contenitori servlet - 4

Costruisci un progetto usando la combinazione Ctrl + F9. Ora il nostro archivio war è nella directory di destinazione. Parte 6: Contenitori servlet - 5

Il file può essere rinominato in modo più semplice - ad esempio servlet.war - e spostato in una posizione più comoda - in C:\my\. Quando l'infuso è pronto per l'uso, metterlo in un contenitore . Questo può essere fatto in due modi.

Tramite GUI

Per fare ciò, seguire il collegamento http://localhost:8080/manager/html . Tomcat dovrebbe richiederti un login e una password.

Se hai ripetuto tutti i passaggi dopo di me, il login è user, la password è password .

Dopo l'autorizzazione verrà visualizzato Tomcat Web Application Manager. La sezione Applicazioni contiene già 5 applicazioni: si tratta di applicazioni di utilità Tomcat necessarie per semplificare il lavoro con esso. Possono essere rimossi in futuro.

Di seguito è riportata la sezione Distribuzione. Usandolo, puoi selezionare un archivio di guerra per lo schieramento. Inseriamo manualmente il percorso e il contesto:

Fare clic su "Deploy", vediamo che la nostra applicazione è apparsa nella sezione Applicazioni:
Utilizzando la GUI di Tomcat possiamo fermarlo, riavviarlo, impostare la durata della sessione ed eliminarlo. Durante la distribuzione, abbiamo specificato il contesto /demo, il che significa che è necessario accedere alla nostra applicazione tramite il collegamento http://localhost:8080/demo . Controlla, dovrebbe funzionare tutto.
Attraverso il file system

Per distribuire un'applicazione in questo modo, è necessario aprire la directory in cui è decompresso Tomcat e andare su webapps. Ecco le applicazioni di utilità che conosciamo:

Tutto quello che dobbiamo fare è spostare qui il nostro servlet.war.

Aspettiamo qualche secondo, vediamo che è apparsa una nuova cartella servlet, il che significa che la nostra applicazione è stata distribuita. Andiamo alla familiare interfaccia di Application Manager: http://localhost:8080/manager/ . Qui vediamo che la nostra applicazione è distribuita nel contesto /servlet:

Quando schierato in questo modo, il contesto viene automaticamente assegnato al nome dell'archivio di guerra schierato. Per cambiare contesto è possibile rinominare la cartella appena creata con l'applicazione, ma prima è necessario eliminare il file: altrimenti Tomcat ridistribuirà l'applicazione con il nome dell'archivio.

Come puoi vedere, distribuire applicazioni su Tomcat è molto più semplice di quanto possa sembrare. Ma le sue altre funzioni sono facili da usare. Controlliamo.

Utilizzo del protocollo HTTPS anziché HTTP

Se ricordi, abbiamo discusso la differenza tra HTTP e HTTPS in un articolo separato . HTTPS è lo stesso protocollo di HTTP, ma utilizza la crittografia dei dati trasferiti. Sul lato client, la crittografia è gestita dal browser e dobbiamo fornire la crittografia sul lato server. Poiché le richieste HTTP vengono accettate e instradate da Tomcat, sarebbe logico delegargli la crittografia. Per fare questo è necessario:

Generare un certificato autofirmato;
Effettuare impostazioni aggiuntive del server.

Facciamo pratica.

Generazione di un certificato

Il JDK viene fornito con un gran numero di utilità, indipendentemente dalla versione, una delle quali è keytool . Questo è uno strumento per generare chiavi di crittografia e lavorare con esse. Per utilizzarlo, utilizzando la riga di comando, vai alla directory C:\Program Files\Java\jdk1.8.0_181\bin ed esegui il comando keytool -genkey -alias tomcat -keyalg RSA .

keytool: avvia l'utilità con i parametri;
-genkey - indica che vogliamo generare una nuova chiave;
-alias Tomcat: crea un alias chiave;
-keyalg RSA: seleziona RSA come algoritmo di generazione della chiave.

Dopo aver eseguito il comando, l'utilità inizierà un dialogo con noi: Parte 6: Contenitori servlet - 11

inserisci le informazioni necessarie. Ora abbiamo creato un keystore nella nostra directory home (per Windows è C:\Users\{username}\.keystore) e una chiave Tomcat al suo interno. Abbiamo generato un semplice certificato che la maggior parte dei browser accetterà. Questo certificato non è adatto per applicazioni commerciali: può essere utilizzato solo a scopo di test. Sul server di produzione è necessario utilizzare un certificato emesso da un'autorità di certificazione (ad esempio https://letsencrypt.org/ ).

Configurazione del server

Ora che il certificato è pronto, devi regolare le impostazioni del server, ovvero il connettore SSL. Questo viene fatto nel file server.xml, che si trova in apache-tomcat-9.0.30/conf/ . Troviamo blocchi come:

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

e posiziona la nostra configurazione accanto ad essi:

<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"/>

Assegniamo ai parametri keystoreFile e keystorePass i valori che sono rilevanti per noi, salviamo e riavviamo Tomcat utilizzando i file shutdown.bat e startup.bat. Ora il server è pronto per elaborare le richieste https, solo leggermente all'indirizzo modificato: https://localhost:8443/demo/hello . Quando fai clic sul collegamento, vedrai un avviso relativo al certificato discutibile, il che non sorprende. Come descritto poco prima, per ottenere un certificato normale è necessario utilizzare i servizi di uno dei servizi di certificazione. Ma finora abbiamo raggiunto il nostro obiettivo: l'applicazione funziona utilizzando il protocollo HTTPS, e questa è la cosa principale!

Generazione dinamica di pagine HTML

Ora continuiamo la nostra revisione di altre funzionalità dei contenitori servlet: generazione dinamica di pagine HTML. Immagina un mondo ideale in cui, invece del noioso codice HTML statico, potresti scrivere codice JAVA utilizzando variabili, loop, array e altri costrutti del linguaggio. Hai immaginato? La buona notizia è che qualcosa di simile esiste, la cattiva notizia è che non esiste del tutto. Se non hai indovinato, stiamo parlando della tecnologia JSP (Java Server Pages). In breve, si tratta di una tecnologia che permette di inserire pezzi di codice JAVA in una pagina HTML. È vero, questo codice viene comunque trasformato in HTML prima di essere inviato al client, ma verrà generato dinamicamente tenendo conto di vari fattori. Ad esempio, puoi utilizzare costruzioni condizionali e offrire contenuti diversi a seconda di alcune condizioni. Pagina JSP di esempio:

<%@ 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>

Puoi leggere ulteriori informazioni su JSP qui . In realtà... non siamo qui per questo, ma per il bene dei contenitori servlet! Cosa c'entra JSP? È semplice: la trasformazione del codice JAVA da JSP in codice HTML viene effettuata dal contenitore servlet. Quando un servlet sta per restituire contenuto JSP come risposta, il contenitore se ne accorge e lo trasforma innanzitutto in una pagina HTML leggibile dal browser prima di inviare tale contenuto al client. Oggi ci sono molti analoghi della tecnologia JSP: Thymeleaf, FreeMarket, Moustache e altri. Funzionano tutti secondo un principio simile. Quale scegliere per il lavoro è una questione di gusti. Ciò vale anche per la scelta di un contenitore servlet. Negli esempi abbiamo utilizzato Tomcat, il contenitore più comune, ma alcuni progetti ne utilizzano altri. Vale la pena familiarizzare brevemente con quelli più popolari e osservare le loro differenze rispetto a Tomcat.

Alternative a Tomcat

GlassFish è un contenitore open source supportato da Oracle.

A differenza di Tomcat, è un server web a tutti gli effetti che, oltre ai servlet, può gestire altri componenti dal framework JavaEE. Allo stesso tempo, utilizza molta più RAM. Più flessibile nella messa a punto del server, che ne rende più difficile l'utilizzo. Vale la pena utilizzarlo quando si sviluppano applicazioni utilizzando il framework JavaEE.
WildFly - precedentemente Jboss . Anche open source. Sviluppato da RedHat. Il nome è stato cambiato per evitare confusione con un altro prodotto dell'azienda: JBoss Enterprise Application Platform.

WildFly, come GlassFish, è un server web a tutti gli effetti. A proposito, sotto il cofano WildFly utilizza Tomcat come contenitore servlet. A differenza di GlassFish, WildFly è più leggero e più facile da configurare.
Jetty - simile ai precedenti, è open source. Sviluppato da Eclipse.

Come Tomcat, è un semplice contenitore servlet, senza supporto per tutti i componenti del framework JavaEE. Allo stesso tempo è più leggero e può essere eseguito anche su un telefono cellulare. Si avvia e si ferma rapidamente e si ridimensiona bene. A differenza di Tomcat, ha una comunità e una base di conoscenza più piccole.
WebLogic è un software concesso in licenza che richiede l'acquisto prima dell'uso. Di proprietà di Oracle.

Rispetto a Tomcat, la sua funzionalità è un po' più ampia. Può funzionare con il protocollo ftp. Ma non è così flessibile durante lo sviluppo e il test delle applicazioni.
WebSphere (WebSphere Application Server per la precisione) è un software a pagamento. Sviluppato da IBM. Simile a WildFly e GlassFish, è un server di applicazioni a tutti gli effetti. Ma ha un'interfaccia di configurazione più semplice e un'elevata affidabilità operativa.

Lo svantaggio è che utilizza molte risorse, richiede molto tempo per avviarsi e arrestarsi, il che non è molto conveniente quando si sviluppano piccoli progetti.

Quale contenitore servlet o server applicativo scegliere dipende dal progetto specifico. Ci sono progetti in cui anche un ovvio estraneo sarà in grado di dimostrarsi con la massima qualità, ma all'inizio è meglio capire a fondo una cosa. Probabilmente il candidato ideale per questo è Tomcat. Noi abbiamo già mosso i primi passi per studiarlo, poi tocca a te! Negli articoli finali della serie "Introduzione allo sviluppo aziendale", conosceremo il modello MVC. Parte 7. Introduzione al pattern MVC (Model-View-Controller) Parte 8. Scrivere una piccola applicazione in spring-boot

Commenti

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