Ciclo di vita di JSP: fasi e diagramma spiegati

⚡ Riepilogo intelligente

Il ciclo di vita di JSP descrive come un contenitore traduce una pagina in una servlet, la compila, carica la classe, crea un'istanza, la inizializza, gestisce ogni richiesta tramite il metodo di servizio generato e infine la distrugge.

  • 🔄 Sette fasi: Traduzione, compilazione, caricamento delle classi, istanziazione, inizializzazione, elaborazione delle richieste e distruzione vengono eseguite in quest'ordine prestabilito.
  • 📄 La traduzione: Il contenitore convalida la pagina, quindi scrive un Java file sorgente, quindi demo.jsp diventa demo_jsp.java prima che venga eseguito qualsiasi comando.
  • ⚙️ Compilazione: Il codice sorgente generato viene compilato in demo_jsp.class, che Tomcat conserva nella sua directory di lavoro insieme al file .java.
  • 🚀 Tre metodi: jspInit() prepara la pagina una sola volta, _jspService() risponde a ogni richiesta e jspDestroy() rilascia le risorse al termine.
  • 🚫 Una regola: La funzione _jspService() viene generata dal container e non deve mai essere scritta o sovrascritta dall'autore della pagina.
  • 🗃️ Gancio per la pulizia: Sovrascrivere il metodo jspDestroy() è il punto corretto per chiudere le connessioni al database e aprire i file.

Fasi del ciclo di vita di JSP, dalla traduzione alla distruzione.

Che cos'è il ciclo di vita di JSP?

Ciclo di vita di JSP Si definisce servlet la traduzione di una pagina JSP in una servlet, poiché una pagina JSP deve essere convertita in una servlet prima di poter elaborare le richieste di servizio. Il ciclo di vita inizia con la creazione della JSP e termina con la distruzione dell'istanza di servlet generata da essa.

Poiché la classe generata è una servlet ordinaria, tutto ciò che già sai sulla servlet contract è ancora valido. Il Java Il codice scritto dal container è quello che viene effettivamente eseguito; il file JSP è solo il codice sorgente che devi gestire.

Diverse fasi del ciclo di vita di JSP

Quando il browser richiede una pagina JSP, il motore JSP verifica innanzitutto se è necessario compilarla. Se la pagina JSP non è mai stata compilata o se è stata modificata dall'ultima compilazione, il motore JSP la compila.

Il processo di compilazione di una pagina JSP prevede tre fasi:

  • Analisi di JSP
  • Trasformare JSP in servlet
  • Compilazione della servlet

Diagramma del ciclo di vita di JSP

Il ciclo di vita JSP è rappresentato nel diagramma sottostante, che traces una singola pagina dal file sorgente fino alla classe eseguita dal contenitore.

Diagramma del ciclo di vita JSP che mostra traduzione, compilazione, caricamento, istanziazione, inizializzazione, elaborazione della richiesta e distruzione

I seguenti passaggi spiegano il ciclo di vita di JSP:

  1. Traduzione della pagina JSP
  2. Compilazione della pagina JSP (compilazione della pagina JSP in _jsp.java)
  3. Caricamento della classe (_jsp.java viene convertito nel file di classe _jsp.class)
  4. Creazione di un'istanza (viene creato un oggetto della servlet generata)
  5. Inizializzazione (il metodo jspInit() viene richiamato dal contenitore)
  6. Elaborazione della richiesta (il metodo _jspService() viene richiamato dal container)
  7. Distruggi (il metodo jspDestroy() viene richiamato dal contenitore)

Fasi del ciclo di vita di JSP spiegate

Analizziamo ora ciascuno dei punti sopra elencati più nel dettaglio.

1) Traduzione della pagina JSP:

A Java Il file servlet viene generato da un file sorgente JSP. Questo è il primo passaggio del ciclo di vita di JSP. Nella fase di traduzione, il container convalida la correttezza sintattica della pagina JSP e dei file di tag.

  • Il contenitore JSP interpreta le direttive e le azioni standard e le azioni personalizzate che fanno riferimento alle librerie di tag (sono tutte parte della pagina JSP e sono coperte nel Elementi JSP tutorial) utilizzato in questa pagina JSP.
  • Nella descrizione grafica sopra riportata, demo.jsp viene tradotto in demo_jsp.java nel primo passaggio

Prendiamo come esempio il file “demo.jsp”, come mostrato di seguito:

Demo.jsp

<html>
<head>
<title>Demo JSP</title>
</head>
<%
int demvar=0;%>
<body>
Count is:
<% Out.println(demovar++); %>
<body>
</html>

Nota relativa all'inserzione sopra riportata: è riprodotto esattamente come pubblicato in modo che corrisponda allo screenshot del servlet generato che segue. Due ortografie al suo interno non verranno compilate se copiate letteralmente: la variabile è dichiarata come demvar ma stampato come demovare l'oggetto di output implicito è out in minuscolo, non OutCorreggi entrambi gli errori prima di avviare la pagina.

Code Spiegazione per Demo.jsp

Code Riga 1: tag di apertura html

Code Riga 2: Etichetta superiore

Code Riga 3 – 4: Tag del titolo, ovvero Demo JSP, e tag di chiusura head

Code Riga 5 – 6: Tag Scriptlet in cui viene inizializzata la variabile demo

Code Riga 7 – 8: Nel tag body, un testo da stampare nell'output (Il conteggio è: )

Code Riga 9: Tag Scriptlet in cui proviamo a stampare la variabile demovar con il suo valore incrementato

Code Riga 10 – 11: Tag Body e HTML chiusi

La pagina Demo JSP viene convertita nella servlet demo_jsp mostrata nel codice seguente.

Sorgente del servlet demo_jsp.java generata da demo.jsp durante la traduzione

Code spiegazione per Demo_jsp.java

Code Riga 1: La classe Servlet demo_jsp estende la classe padre HttpServlet

Code Riga 2 – 3: Sovrascrittura del metodo di servizio della JSP, ovvero _jspService, che ha come parametri gli oggetti HttpServletRequest e HttpServletResponse.

Code Riga 4: Metodo di apertura

Code Riga 5: Chiamata del metodo getWriter() dell'oggetto di risposta per ottenere una stampaWriter oggetto (stampa una rappresentazione formattata degli oggetti in un flusso di output di testo)

Code Riga 6: Chiamata al metodo setContentType dell'oggetto di risposta per impostare il tipo di contenuto

Code Riga 7: Utilizzo del metodo write() di PrintWriter oggetto da analizzare html

Code Riga 8: Inizializzazione della variabile demovar a 0

Code Riga 9: Chiamata al metodo write() di PrintWriter oggetto per analizzare il testo

Code Riga 10: Chiamata del metodo print() di PrintWriter oggetto per incrementare la variabile demovar da 0 + 1 = 1. Quindi, l'output sarà 1

Code Riga 11: Utilizzo del metodo write() di PrintWriter oggetto da analizzare html

Produzione:

Il browser visualizza quindi il contatore, come mostrato nello screenshot qui sotto.

Output del browser di demo.jsp: Count is: 1

  • Qui puoi vedere che nello screenshot l'output è 1, perché demvar viene inizializzato a 0 e poi incrementato a 0 + 1 = 1

Nell'esempio sopra,

  • demo.jsp è una pagina JSP in cui una variabile viene inizializzata e incrementata. Questa pagina JSP viene convertita in una servlet (demo_jsp.class) in cui il motore JSP carica la pagina JSP e la converte in contenuto servlet.
  • Quando avviene la conversione, tutto il testo del modello viene convertito in istruzioni println() e tutti gli elementi JSP vengono convertiti in Java codice.

Ecco come una semplice pagina JSP viene tradotta in una classe servlet.

2) Compilazione della Pagina JSP

  • Il generato Java Il file servlet viene compilato in un Java classe servlet
  • La traduzione del Java Il passaggio dalla pagina sorgente alla sua classe di implementazione può avvenire in qualsiasi momento tra il deployment della pagina JSP nel container e l'elaborazione della pagina JSP stessa.
  • Nella descrizione grafica sopra riportata, demo_jsp.java viene compilato in un file di classe chiamato demo_jsp.class.
  • Su Apache Tomcat entrambi gli artefatti vengono scritti nella directory di lavoro del server, in work/Catalina/localhost/<app>/org/apache/jsp, che è il primo posto in cui guardare quando è necessario diagnosticare un errore di traduzione

3) Caricamento delle classi

  • La classe servlet generata dal codice sorgente JSP è ora caricata nel container

4) Istanziazione

  • In questa fase viene generato l'oggetto, ovvero l'istanza della classe.
  • Il container gestisce una o più istanze di questa classe in risposta a richieste e altri eventi. In genere, un container JSP viene creato utilizzando un container di servlet. Un container JSP è un'estensione di un container di servlet, poiché entrambi supportano JSP e servlet.
  • L'interfaccia JspPage, fornita dal contenitore, dichiara i metodi jspInit() e jspDestroy().
  • Esiste un'interfaccia HttpJspPage che gestisce le richieste HTTP e contiene anche il metodo di servizio. La sua firma dipende dal protocollo, motivo per cui il container genera tale metodo anziché richiederne la dichiarazione all'autore della pagina.

5) Inizializzazione

public void jspInit()
{
	//initializing the code
}
  • Il metodo jspInit() inizializza l'istanza della servlet generata dalla JSP e viene richiamato dal container in questa fase.
  • Una volta creata l'istanza, il metodo init viene richiamato immediatamente dopo.
  • Viene chiamato una sola volta durante il ciclo di vita di una JSP e il metodo per l'inizializzazione è dichiarato come mostrato sopra

6) Elaborazione della richiesta

void _jspservice(HttpServletRequest request HttpServletResponse response)
{
	//handling all request and responses
}
  • Il metodo _jspService() viene richiamato dal container per tutte le richieste generate dalla pagina JSP durante il suo ciclo di vita.
  • In questa fase, la pagina deve attraversare tutte le fasi precedenti, e solo allora può essere richiamato il metodo del servizio.
  • Trasmette gli oggetti di richiesta e risposta
  • Questo metodo non può essere sovrascritto, perché il contenitore lo scrive durante la traduzione.
  • Il metodo è illustrato sopra. È responsabile della gestione di tutti i metodi HTTP, ovvero GET, POST e gli altri.

7) Distruggi

public void _jspdestroy()
{
            //all clean up code
}
  • Anche il metodo jspDestroy() viene richiamato dal contenitore
  • Questo metodo viene chiamato quando il container decide di non aver più bisogno dell'istanza del servlet per gestire le richieste.
  • Una volta effettuata la chiamata al metodo destroy, la servlet è pronta per la raccolta dei rifiuti.
  • Questa è la fine del ciclo di vita.
  • Possiamo sovrascrivere jspDestroy() quando eseguiamo operazioni di pulizia, come il rilascio delle connessioni al database o la chiusura dei file aperti.

Una nota di denominazione che vale la pena portare avanti: da Jakarta EE 9 in poi questi tipi vivono nel jakarta.servlet.jsp pacchetto piuttosto che javax.servlet.jspPertanto, le importazioni precedenti devono essere aggiornate quando un'applicazione viene spostata su un server corrente.

DOMANDE FREQUENTI

Hanno lo stesso ciclo di vita dopo la traduzione. Una JSP aggiunge due fasi in anticipo, traduzione e compilazione, che trasformano la pagina in un file sorgente e una classe servlet. Dal caricamento della classe in poi il servlettract si applica senza modifiche.

Nella directory di lavoro del server, in work/Catalina/localhost/ /org/apache/jsp. Sia il codice sorgente .java generato che il file .class compilato vengono salvati in questa directory, quindi home.jsp diventa home_jsp.java e home_jsp.class.

Il contenitore lo genera dal corpo della pagina durante la traduzione. La sua firma dipende dal protocollo di richiesta, quindi la specifica lo esclude dall'interfaccia JspPage e vieta agli autori delle pagine di dichiararlo autonomamente.

La servlet generata implementa già il metodo init() per memorizzare la sua ServletConfig, quindi chiama jspInit(). Gli autori delle pagine sovrascrivono jspInit() in modo che la configurazione del container non venga mai saltata, il che è esattamente ciò che si rischia di fare con una sovrascrittura manuale di init().

La precompilazione traduce e compila ogni pagina in fase di build o di distribuzione, anziché alla prima richiesta. Elimina il ritardo iniziale, individua gli errori di traduzione prima del rilascio e consente la distribuzione senza la necessità di un compilatore sul server.

Rimane supportato come Jakarta Server Pages. La principale modifica riguarda lo spazio dei nomi del pacchetto: a partire da Jakarta EE 9, l'API è passata da javax.servlet.jsp a jakarta.servlet.jsp, pertanto le importazioni legacy devono essere riscritte prima dell'esecuzione su un server attuale.

Gli assistenti IA leggono lo stack _jsp.java generato trace mappano un errore di compilazione fino alla riga dello scriptlet incriminato, che è la parte più difficile degli errori di traduzione. Segnalano anche gli scriptlet che appartengono a un file di tag o a una servlet.

Sì. Copilot genera scriptlet, blocchi JSTL, gestione dei moduli e classi servlet corrispondenti a partire da un commento. RevVisualizza l'output per il namespace del pacchetto jakarta e per gli scriptlet che dovrebbero essere in linguaggio di espressione, poiché i suggerimenti spesso seguono tutorial più vecchi.

Riassumi questo post con: