JSP livscyklus: Faser og diagram forklaret

Af: James Hartman James Hartman
Hours Opdateret

⚡ Smart opsummering

JSP's livscyklus beskriver, hvordan en container oversætter en side til en servlet, kompilerer den, indlæser klassen, opretter en instans, initialiserer den, behandler alle anmodninger via den genererede servicemetode og til sidst ødelægger den.

  • 🔄 Syv faser: Oversættelse, kompilering, klasseindlæsning, instantiering, initialisering, anmodningsbehandling og destruktion kører i den faste rækkefølge.
  • 📄 Oversættelse: Containeren validerer siden og skriver derefter en Java kildefilen, så demo.jsp bliver til demo_jsp.java, før noget udføres.
  • 🇧🇷 Samling: Den genererede kildekode kompileres til demo_jsp.class, som Tomcat opbevarer i sin arbejdsmappe sammen med .java-filen.
  • 🚀 Tre metoder: jspInit() forbereder siden én gang, _jspService() besvarer hver anmodning, og jspDestroy() frigiver ressourcer til sidst.
  • 🚫 Én regel: _jspService() genereres af containeren og må aldrig skrives eller overskrives af sideforfatteren.
  • 🗃️ Oprydningskrog: Overstyring af jspDestroy() er det korrekte sted at lukke databaseforbindelser og åbne filer.
Læs mere

JSP livscyklusfaser fra oversættelse til destruktion

Hvad er JSP's livscyklus?

JSP livscyklus defineres som oversættelsen af ​​en JSP-side til en servlet, fordi en JSP-side skal konverteres til en servlet, før den kan behandle serviceanmodninger. Livscyklussen starter med oprettelsen af ​​JSP'en og slutter med destruktionen af ​​den servlet-instans, der genereres ud fra den.

Fordi den genererede klasse er en almindelig servlet, kan alt, hvad du allerede ved om servlet'en,tracDet gælder stadig. Java Den kode, som containeren skriver, er det, der rent faktisk kører; JSP-filen er kun den kildekode, du vedligeholder.

Forskellige faser af JSP livscyklus

Når browseren beder om en JSP, kontrollerer JSP-motoren først, om den skal kompilere siden. Hvis JSP'en aldrig er blevet kompileret, eller hvis den er blevet ændret siden den sidste kompilering, kompilerer JSP-motoren siden.

Kompileringsprocessen for en JSP-side involverer tre trin:

  • Parsing af JSP
  • Forvandler JSP til servlet
  • Kompilere servlet

JSP livscyklusdiagram

JSP'ens livscyklus er vist i diagrammet nedenfor, som tracer en enkelt side fra kildefilen til den klasse, som containeren udfører.

JSP-livscyklusdiagram, der viser oversættelse, kompilering, indlæsning, instantiering, initialisering, anmodningsbehandling og destruktion

Følgende trin forklarer JSP's livscyklus:

  1. Oversættelse af JSP-side
  2. Kompilering af JSP-side (kompilering af JSP-siden til _jsp.java)
  3. Klasseindlæsning (_jsp.java konverteres til klassefilen _jsp.class)
  4. Instantiering (et objekt af den genererede servlet oprettes)
  5. Initialisering (jspInit()-metoden kaldes af containeren)
  6. Anmodningsbehandling (metoden _jspService() kaldes af containeren)
  7. Destroy (jspDestroy()-metoden kaldes af containeren)

Faser i JSP-livscyklussen forklaret

Lad os se nærmere på hvert af ovenstående punkter.

1) Oversættelse af JSP-siden:

A Java Servlet-filen genereres fra en JSP-kildefil. Dette er det første trin i JSP'ens livscyklus. I oversættelsesfasen validerer containeren den syntaktiske korrekthed af JSP-siden og tag-filerne.

  • JSP-containeren fortolker standarddirektiverne og -handlingerne samt de brugerdefinerede handlinger, der refererer til tagbiblioteker (de er alle en del af JSP-siden og er dækket i JSP elementer tutorial) brugt på denne JSP-side.
  • I den billedlige beskrivelse ovenfor er demo.jsp oversat til demo_jsp.java i første trin.

Lad os tage 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>

Bemærkning til ovenstående liste: Den gengives præcis som udgivet, så den matcher det genererede servlet-skærmbillede, der følger. To stavemåder i den vil ikke kompileres, hvis den kopieres ordret — variablen erklæres som demvar men udskrives som demovar, og det implicitte outputobjekt er out med små bogstaver, ikke OutRet begge dele, før du selv kører siden.

Code Forklaring til Demo.jsp

Code Linje 1: html starttag

Code Linje 2: Hovedtag

Code Linje 3-4: Titeltag, f.eks. Demo JSP, og afsluttende headtag

Code Linje 5-6: Scriptlet-tag, hvor variablen demo initialiseres

Code Linje 7 – 8: I body-tagget, en tekst der skal udskrives i outputtet (Count is: )

Code Linje 9: Scriptlet-tag, hvor vi forsøger at udskrive variablen demovar med dens inkrementerede værdi

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

Demo JSP-siden konverteres til servlet'en demo_jsp, som vist i koden nedenfor.

Genereret demo_jsp.java servlet-kildekode produceret fra demo.jsp under oversættelse

Code forklaring til Demo_jsp.java

Code Linje 1: Servlet-klassen demo_jsp udvider den overordnede klasse HttpServlet

Code Linje 2 – 3: Tilsidesættelse af servicemetoden for JSP'en, dvs. _jspService, som har HttpServletRequest- og HttpServletResponse-objekter som parametre.

Code Linje 4: Åbningsmetode

Code Linje 5: Kald af metoden getWriter() af responsobjektet for at få en udskriftWriter objekt (udskriver en formateret repræsentation af objekter til en tekstoutputstrøm)

Code Linje 6: Kald af setContentType-metoden for responsobjektet for at indstille indholdstypen

Code Linje 7: Brug af write()-metoden i PrintWriter objekt til at parse html

Code Linje 8: Initialisering af demovar-variablen til 0

Code Linje 9: Kald af write()-metoden i PrintWriter objekt til at analysere teksten

Code Linje 10: Kald af print()-metoden i PrintWriter objekt for at øge variablen demovar fra 0 + 1 = 1. Derfor vil outputtet være 1

Code Linje 11: Brug af write()-metoden i PrintWriter objekt til at parse html

Output:

Browseren gengiver derefter tælleren, som skærmbilledet nedenfor viser.

Browseroutput af demo.jsp-udskrivning Antal er: 1

  • Her kan du se, at outputtet på skærmbilledet er 1, fordi demvar initialiseres til 0 og derefter øges til 0 + 1 = 1.

I ovenstående eksempel

  • demo.jsp er en JSP, hvor én variabel initialiseres og øges. Denne JSP konverteres til servlet'en (demo_jsp.class), hvor JSP-motoren indlæser JSP-siden og konverterer den til servlet-indhold.
  • Når konverteringen sker, konverteres al skabelontekst til println()-sætninger, og alle JSP-elementer konverteres til Java kode.

Sådan oversættes en simpel JSP-side til en servlet-klasse.

RELATEREDE ARTIKLER

2) Kompilering af JSP-siden

  • Den genererede Java servlet-filen kompileres til en Java servlet-klasse
  • Oversættelsen af Java kildesiden til dens implementeringsklasse kan ske når som helst mellem implementeringen af ​​JSP-siden i containeren og behandlingen af ​​JSP-siden.
  • I den billedlige beskrivelse ovenfor er demo_jsp.java kompileret til en klassefil demo_jsp.class
  • På Apache Tomcat er begge artefakter skrevet under serverens arbejdsmappe, i work/Catalina/localhost/<app>/org/apache/jsp, hvilket er det første sted at se, når en oversættelsesfejl skal diagnosticeres

3) Klasseindlæsning

  • Servlet-klassen, der er genereret fra JSP-kildekoden, er nu indlæst i containeren.

4) Instantiering

  • I dette trin genereres objektet, dvs. klassens instans.
  • Containeren administrerer en eller flere instanser af denne klasse som svar på anmodninger og andre hændelser. Typisk bygges en JSP-container ved hjælp af en servlet-container. En JSP-container er en udvidelse af en servlet-container, da begge containere understøtter JSP og servlets.
  • JspPage-grænsefladen, som leveres af containeren, deklarerer metoderne jspInit() og jspDestroy().
  • Der er en grænseflade, HttpJspPage, som håndterer HTTP-anmodninger, og den indeholder også servicemetoden. Dens signatur afhænger af protokollen, hvilket er grunden til, at containeren genererer den metode i stedet for at bede sideforfatteren om at deklarere den.

5) Initialisering

public void jspInit()
{
	//initializing the code
}
  • Metoden jspInit() initialiserer den servlet-instans, der blev genereret fra JSP'en, og kaldes af containeren i denne fase.
  • Når instansen er oprettet, kaldes init-metoden umiddelbart efter det.
  • Den kaldes kun én gang i løbet af en JSP-livscyklus, og metoden til initialisering deklareres som vist ovenfor.

6) Behandling af anmodning

void _jspservice(HttpServletRequest request HttpServletResponse response)
{
	//handling all request and responses
}
  • Metoden _jspService() kaldes af containeren for alle anmodninger, der rejses af JSP-siden i løbet af dens livscyklus.
  • I denne fase skal siden gennemgå alle ovenstående faser, og først derefter kan servicemetoden kaldes.
  • Den sender anmodnings- og svarobjekterne
  • Denne metode kan ikke tilsidesættes, fordi containeren skriver den under oversættelsen
  • Metoden er vist ovenfor. Den er ansvarlig for at håndtere alle HTTP-metoder, dvs. GET, POST og resten.

7) Ødelæg

public void _jspdestroy()
{
            //all clean up code
}
  • Metoden jspDestroy() kaldes også af containeren.
  • Denne metode kaldes, når containeren beslutter, at den ikke længere har brug for servlet-instansen til at servicere anmodninger.
  • Når kaldet til destroy-metoden er foretaget, er servlet'en klar til garbage collection.
  • Dette er afslutningen på livscyklussen.
  • Vi kan tilsidesætte jspDestroy(), når vi udfører en oprydning, f.eks. når vi frigiver databaseforbindelser eller lukker åbne filer.

En navngivningsbemærkning, der er værd at videreføre: fra Jakarta EE 9 og fremefter lever disse typer i jakarta.servlet.jsp pakke snarere end javax.servlet.jsp, så ældre importer skal opdateres, når en applikation flyttes til en nuværende server.

Ofte Stillede Spørgsmål

De har den samme livscyklus efter oversættelse. En JSP tilføjer to faser foran, oversættelse og kompilering, som omdanner siden til en servlet-kildefil og -klasse. Fra klasseindlæsning og fremefter består servlet'en aftract gælder uændret.

Under serverens arbejdsmappe, i work/Catalina/localhost/ /org/apache/jsp. Både den genererede .java-kildekode og den kompilerede .class-fil lander der, så home.jsp bliver til home_jsp.java og home_jsp.class.

Containeren genererer den fra sideteksten under oversættelsen. Dens signatur afhænger af anmodningsprotokollen, så specifikationen udelader den fra JspPage-grænsefladen og forbyder sideforfattere at deklarere den selv.

Den genererede servlet implementerer allerede init() til at gemme sin ServletConfig og kalder derefter jspInit(). Sideforfattere tilsidesætter jspInit(), så containeropsætning aldrig springes over, hvilket er præcis, hvad en håndskrevet init()-tilsidesættelse risikerer.

Prækompilering oversætter og kompilerer hver side ved bygge- eller implementeringstidspunktet i stedet for ved den første anmodning. Det fjerner forsinkelsen ved første forsøg, afslører oversættelsesfejl før udgivelsen og tillader implementering uden en compiler på serveren.

Den understøttes fortsat som Jakarta Server Pages. Den primære ændring er pakkenavneområdet: fra Jakarta EE 9 er API'en flyttet fra javax.servlet.jsp til jakarta.servlet.jsp, så ældre importer skal omskrives, før de køres på en nuværende server.

AI-assistenter læser den genererede _jsp.java-stak trace og knytter en kompileringsfejl tilbage til den problematiske scriptlet-linje, hvilket er den sværeste del af oversættelsesfejl. De markerer også scriptlets, der hører hjemme i en tag-fil eller en servlet.

Ja. Copilot scaffolder scriptlets, JSTL-blokke, formularhåndtering og matchende servlet-klasser fra en kommentar. RevSe outputtet for jakarta-pakkenavnerummet og for scriptlets, der burde være udtrykssprog, da forslag ofte følger ældre vejledninger.

Opsummer dette indlæg med: