JSP-livssyklus: Faser og diagram forklart

by: James Hartman James Hartman
Hours oppdatert

⚡ Smart oppsummering

JSPs livssyklus beskriver hvordan en container oversetter en side til en servlet, kompilerer den, laster inn klassen, oppretter en instans, initialiserer den, betjener hver forespørsel gjennom den genererte tjenestemetoden og til slutt ødelegger den.

  • 🔄 Syv faser: Oversettelse, kompilering, klasseinnlasting, instantiering, initialisering, forespørselsbehandling og destruksjon kjøres i den faste rekkefølgen.
  • 📄 Oversettelse: Containeren validerer siden, og skriver deretter en Java kildefilen, slik at demo.jsp blir til demo_jsp.java før noe kjøres.
  • ⚙️ Samling: Den genererte kildekoden kompileres til demo_jsp.class, som Tomcat oppbevarer under arbeidskatalogen sin sammen med .java-filen.
  • 🚀 Tre metoder: jspInit() forbereder siden én gang, _jspService() svarer på hver forespørsel, og jspDestroy() frigjør ressurser på slutten.
  • 🚫 Én regel: _jspService() genereres av containeren og må aldri skrives eller overskrives av sideforfatteren.
  • 🗃️ Oppryddingskrok: Overstyring av jspDestroy() er det riktige stedet å lukke databasetilkoblinger og åpne filer.
Les mer

JSPs livssyklusfaser fra oversettelse til destruksjon

Hva er JSPs livssyklus?

JSP livssyklus er definert som oversettelsen av en JSP-side til en servlet, fordi en JSP-side må konverteres til en servlet før den kan behandle tjenesteforespørsler. Livssyklusen starter med opprettelsen av JSP-en og slutter med destruksjonen av servlet-instansen som genereres fra den.

Fordi den genererte klassen er en vanlig servlet, kan alt du allerede vet om servletentracDet gjelder fortsatt. Java Koden som containeren skriver er det som faktisk kjører; JSP-filen er bare kildekoden du vedlikeholder.

Ulike faser av JSP livssyklus

Når nettleseren ber om en JSP, sjekker JSP-motoren først om den trenger å kompilere siden. Hvis JSP-en aldri har blitt kompilert, eller hvis den har blitt endret siden forrige kompilering, kompilerer JSP-motoren siden.

Kompileringsprosessen for en JSP-side involverer tre trinn:

  • Parsing av JSP
  • Gjør om JSP til servlet
  • Kompilere servleten

JSP livssyklusdiagram

JSP-livssyklusen er vist i diagrammet nedenfor, som traclagrer en enkelt side fra kildefilen til klassen som containeren kjører.

JSP-livssyklusdiagram som viser oversettelse, kompilering, lasting, instansiering, initialisering, forespørselsbehandling og destruksjon

Følgende trinn forklarer livssyklusen til JSP:

  1. Oversettelse av JSP-side
  2. Kompilering av JSP-side (kompilering av JSP-siden til _jsp.java)
  3. Klasseinnlasting (_jsp.java konverteres til klassefilen _jsp.class)
  4. Instantiering (et objekt av den genererte servleten opprettes)
  5. Initialisering (jspInit()-metoden kalles av containeren)
  6. Forespørselsbehandling (_jspService()-metoden kalles av containeren)
  7. Destroy (jspDestroy()-metoden kalles av containeren)

Faser i JSP-livssyklusen forklart

La oss se nærmere på hvert av punktene ovenfor.

1) Oversettelse av JSP-siden:

A Java Servlet-filen genereres fra en JSP-kildefil. Dette er det første trinnet i JSP-livssyklusen. I oversettelsesfasen validerer containeren den syntaktiske korrektheten til JSP-siden og taggfilene.

  • JSP-containeren tolker standarddirektivene og -handlingene, og de tilpassede handlingene som refererer til tagbiblioteker (de er alle en del av JSP-siden og er dekket i JSP-elementer veiledning) som brukes på denne JSP-siden.
  • I den billedlige beskrivelsen ovenfor er demo.jsp oversatt til demo_jsp.java i det første trinnet.

La oss ta et eksempel på «demo.jsp» som vist nedenfor:

Demo.jsp

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

Merknad om listen ovenfor: den er gjengitt nøyaktig slik den er publisert, slik at den samsvarer med det genererte servlet-skjermbildet som følger. To stavemåter i den vil ikke kompileres hvis den kopieres ordrett – variabelen er deklarert som demvar men trykket som demovar, og det implisitte utdataobjektet er out med små bokstaver, ikke OutRett begge før du kjører siden selv.

Code Forklaring for Demo.jsp

Code Linje 1: html starttag

Code Linje 2: Hovedtagg

Code Linje 3–4: Titteltag, f.eks. Demo JSP, og avsluttende head-tag

Code Linje 5–6: Scriptlet-tag der variabelen demo initialiseres

Code Linje 7–8: I body-taggen, en tekst som skal skrives ut i utdataene (Antall er: )

Code Linje 9: Scriptlet-taggen der vi prøver å skrive ut variabelen demovar med dens inkrementerte verdi

Code Linje 10–11: Brødtekst og HTML-tagger lukket

Demo JSP-siden konverteres til demo_jsp-servleten som vises i koden nedenfor.

Genererte demo_jsp.java servlet-kildekode produsert fra demo.jsp under oversettelse

Code forklaring for Demo_jsp.java

Code Linje 1: Servlet-klassen demo_jsp utvider den overordnede klassen HttpServlet

Code Linje 2–3: Overstyring av servicemetoden til JSP-en, dvs. _jspService, som har HttpServletRequest- og HttpServletResponse-objekter som parametere.

Code Linje 4: Åpningsmetode

Code Linje 5: Kalling av metoden getWriter() av ​​responsobjektet for å få en utskriftWriter objekt (skriver ut en formatert representasjon av objekter til en tekstutdatastrøm)

Code Linje 6: Kalling av setContentType-metoden til responsobjektet for å angi innholdstypen

Code Linje 7: Bruk av write()-metoden til PrintWriter objekt for å analysere html

Code Linje 8: Initialiserer demovar-variabelen til 0

Code Linje 9: Kalling av write()-metoden til PrintWriter objekt for å analysere teksten

Code Linje 10: Kalling av print()-metoden til PrintWriter objekt for å øke variabelen demovar fra 0 + 1 = 1. Derfor vil utdataene være 1

Code Linje 11: Bruk av write()-metoden til PrintWriter objekt for å analysere html

Utgang:

Nettleseren gjengir deretter telleren, som skjermbildet nedenfor viser.

Nettleserutdata for demo.jsp-utskrift Antall er: 1

  • Her kan du se at utdataene på skjermbildet er 1, fordi demvar initialiseres til 0 og deretter økes til 0 + 1 = 1.

I eksemplet ovenfor,

  • demo.jsp er en JSP der én variabel initialiseres og økes. Denne JSP-en konverteres til servleten (demo_jsp.class) der JSP-motoren laster inn JSP-siden og konverterer den til servlet-innhold.
  • Når konverteringen skjer, konverteres all maltekst til println()-setninger, og alle JSP-elementer konverteres til Java kode.

Dette er hvordan en enkel JSP-side blir oversatt til en servlet-klasse.

RELATERTE ARTIKLER

2) Kompilering av JSP-siden

  • Den genererte Java servlet-filen kompileres til en Java servlet-klasse
  • Oversettelsen av Java kildesiden til implementeringsklassen kan skje når som helst mellom distribusjonen av JSP-siden i containeren og behandlingen av JSP-siden.
  • I den billedlige beskrivelsen ovenfor er demo_jsp.java kompilert til en klassefil demo_jsp.class
  • På Apache Tomcat skrives begge artefaktene under serverens arbeidskatalog, i work/Catalina/localhost/<app>/org/apache/jsp, som er det første stedet man skal se etter når en oversettelsesfeil må diagnostiseres

3) Klasselasting

  • Servlet-klassen som er generert fra JSP-kilden er nå lastet inn i containeren.

4) Instantiering

  • I dette trinnet genereres objektet, dvs. instansen av klassen.
  • Containeren administrerer én eller flere forekomster av denne klassen som svar på forespørsler og andre hendelser. Vanligvis bygges en JSP-container ved hjelp av en servlet-container. En JSP-container er en utvidelse av en servlet-container, ettersom begge containerne støtter JSP og servlets.
  • JspPage-grensesnittet, som leveres av containeren, deklarerer metodene jspInit() og jspDestroy().
  • Det finnes et grensesnitt, HttpJspPage, som betjener HTTP-forespørsler, og det inneholder også tjenestemetoden. Signaturen avhenger av protokollen, og det er derfor containeren genererer den metoden i stedet for å be sideforfatteren om å deklarere den.

5) Initialisering

public void jspInit()
{
	//initializing the code
}
  • jspInit()-metoden initialiserer servlet-instansen som ble generert fra JSP-en, og kalles av containeren i denne fasen.
  • Når instansen er opprettet, kalles init-metoden umiddelbart etter det.
  • Den kalles bare én gang i løpet av en JSP-livssyklus, og metoden for initialisering deklareres som vist ovenfor.

6) Behandling av forespørsel

void _jspservice(HttpServletRequest request HttpServletResponse response)
{
	//handling all request and responses
}
  • _jspService()-metoden kalles av containeren for alle forespørsler som genereres av JSP-siden i løpet av dens livssyklus.
  • For denne fasen må siden gå gjennom alle fasene ovenfor, og først da kan tjenestemetoden kalles.
  • Den sender forespørsels- og svarobjektene
  • Denne metoden kan ikke overstyres, fordi containeren skriver den under oversettelsen
  • Metoden er vist ovenfor. Den er ansvarlig for å håndtere alle HTTP-metoder, dvs. GET, POST og resten.

7) Ødelegg

public void _jspdestroy()
{
            //all clean up code
}
  • jspDestroy()-metoden kalles også av containeren.
  • Denne metoden kalles når containeren bestemmer at den ikke lenger trenger servlet-instansen for å betjene forespørsler.
  • Når kallet til destroy-metoden er gjort, er servleten klar for søppelinnsamling.
  • Dette er slutten på livssyklusen.
  • Vi kan overstyre jspDestroy() når vi utfører opprydding, for eksempel å frigjøre databasetilkoblinger eller lukke åpne filer.

En navnebemerkning verdt å ta med seg videre: fra Jakarta EE 9 og utover lever disse typene i jakarta.servlet.jsp pakke heller enn javax.servlet.jsp, så eldre importer må oppdateres når et program flyttes til en gjeldende server.

Spørsmål og svar

De har samme livssyklus etter oversettelse. En JSP legger til to faser foran, oversettelse og kompilering, som gjør siden om til en servlet-kildefil og -klasse. Fra klassen lastes og utover inneholder servletentract gjelder uendret.

Under serverens arbeidskatalog, i work/Catalina/localhost/ /org/apache/jsp. Både den genererte .java-kildekoden og den kompilerte .class-filen havner der, så home.jsp blir home_jsp.java og home_jsp.class.

Beholderen genererer den fra sideteksten under oversettelsen. Signaturen avhenger av forespørselsprotokollen, så spesifikasjonen utelater den fra JspPage-grensesnittet og forbyr sideforfattere å deklarere den selv.

Den genererte servleten implementerer allerede init() for å lagre ServletConfig, og kaller deretter jspInit(). Sideforfattere overstyrer jspInit() slik at containeroppsettet aldri hoppes over, noe som er akkurat det en håndskrevet init()-overstyring risikerer.

Forkompilering oversetter og kompilerer hver side ved bygge- eller distribusjonstidspunkt i stedet for ved første forespørsel. Den fjerner forsinkelsen ved første treff, avdekker oversettelsesfeil før utgivelse og tillater distribusjon uten en kompilator på serveren.

Den støttes fortsatt som Jakarta Server Pages. Hovedendringen er pakkenavnerommet: fra Jakarta EE 9 ble API-et flyttet fra javax.servlet.jsp til jakarta.servlet.jsp, så eldre importer må skrives om før de kjøres på en nåværende server.

AI-assistenter leser den genererte _jsp.java-stakken trace og tilordner en kompileringsfeil tilbake til den problematiske scriptlet-linjen, som er den vanskeligste delen av oversettelsesfeil. De flagger også scriptlets som hører hjemme i en tag-fil eller en servlet.

Ja. Copilot bruker stillas for skriptletter, JSTL-blokker, skjemahåndtering og matchende servletklasser fra en kommentar. RevSe utdataene for navnerommet i Jakarta-pakken og for skriptletter som skal være uttrykksspråk, siden forslag ofte følger eldre veiledninger.

Oppsummer dette innlegget med: