JSP életciklus: Fázisok és ábra magyarázata

⚡ Okos összefoglaló

A JSP életciklus leírja, hogyan fordít le egy konténer egy oldalt servletté, hogyan fordítja le azt, hogyan tölti be az osztályt, hogyan hoz létre egy példányt, hogyan inicializálja azt, hogyan szolgálja ki az összes kérést a generált szolgáltatás metóduson keresztül, és végül hogyan semmisíti meg azt.

  • 🔄 Hét fázis: A fordítás, fordítás, osztálybetöltés, példányosítás, inicializálás, kérésfeldolgozás és megsemmisítés ebben a rögzített sorrendben fut.
  • 📄 Fordítás: A konténer validálja az oldalt, majd ír egy Java forrásfájl, így a demo.jsp fájlból demo_jsp.java lesz, mielőtt bármi is végrehajtódna.
  • 🇧🇷 Összeállítás: A generált forráskód demo_jsp.class fájllá fordul, amelyet a Tomcat a munkakönyvtárában tárol a .java fájl mellett.
  • 🚀 Három módszer: A jspInit() egyszer készíti elő az oldalt, a _jspService() minden kérésre válaszol, a jspDestroy() pedig a végén felszabadítja az erőforrásokat.
  • ???? Egy szabály: A _jspService() függvényt a konténer generálja, és az oldal szerzője soha nem írhatja vagy írhatja felül.
  • 🗃️ Takarítóhorog: A jspDestroy() felülbírálása a megfelelő hely az adatbázis-kapcsolatok lezárására és a fájlok megnyitására.

JSP életciklus fázisai a fordítástól a megsemmisítésig

Mi a JSP életciklusa?

JSP életciklus egy JSP oldal servletté fordítását jelenti, mivel egy JSP oldalt servletté kell alakítani, mielőtt feldolgozhatná a szolgáltatáskéréseket. Az életciklus a JSP létrehozásával kezdődik, és az abból generált servlet példány megsemmisítésével ér véget.

Mivel a generált osztály egy átlagos szervlet, minden, amit a szervlet con-ról már tudsz,tractovábbra is érvényes. A Java A konténer által írt kód az, ami valójában lefut; a JSP fájl csak a forráskód, amit karbantartasz.

A JSP életciklusának különböző fázisai

Amikor a böngésző JSP-t kér, a JSP motor először ellenőrzi, hogy le kell-e fordítania az oldalt. Ha a JSP-t még soha nem fordították le, vagy ha az utolsó fordítás óta módosult, akkor a JSP motor lefordítja az oldalt.

Egy JSP oldal fordítási folyamata három lépésből áll:

  • A JSP elemzése
  • A JSP servletté alakítása
  • A szervlet összeállítása

JSP életciklus diagram

A JSP életciklusát az alábbi ábra szemlélteti, amely a következőket tartalmazza: tracegyetlen oldalt tartalmaz a forrásfájltól egészen a konténer által végrehajtott osztályig.

JSP életciklus-diagram, amely bemutatja a fordítást, fordítást, betöltést, példányosítást, inicializálást, kérésfeldolgozást és megsemmisítést

A következő lépések ismertetik a JSP életciklusát:

  1. A JSP oldal fordítása
  2. JSP oldal fordítása (a JSP oldal fordítása _jsp.java fájlba)
  3. Osztálybetöltés (a _jsp.java fájlt _jsp.class osztályfájllá alakítja)
  4. Instantiáció (a generált servlet egy objektuma létrejön)
  5. Inicializálás (a jspInit() metódust a konténer hívja meg)
  6. Kérésfeldolgozás (a _jspService() metódust a konténer hívja meg)
  7. Destroy (a jspDestroy() metódust a konténer hívja meg)

A JSP életciklusának fázisai ismertetve

Nézzük meg részletesebben a fenti pontokat.

1) A JSP oldal fordítása:

A Java A servlet fájl egy JSP forrásfájlból generálódik. Ez a JSP életciklusának első lépése. A fordítási fázisban a konténer ellenőrzi a JSP oldal és a tag fájlok szintaktikai helyességét.

  • A JSP konténer értelmezi a szabványos direktívákat és műveleteket, valamint a címkekönyvtárakra hivatkozó egyéni műveleteket (ezek mind a JSP oldal részét képezik, és a JSP elemek oktatóanyag), amelyet ezen a JSP oldalon használunk.
  • A fenti képi leírásban a demo.jsp fájlt az első lépésben demo_jsp.java fájllá alakítjuk.

Vegyünk egy példát a „demo.jsp” fájlra, ahogy az alább látható:

Demo.jsp

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

Megjegyzés a fenti listához: pontosan a közzétett formában kerül reprodukálásra, hogy megfeleljen az alábbi generált servlet képernyőképnek. Két helyesírási hiba nem fordul le, ha szó szerint másolja – a változót a következőképpen deklarálják: demvar de nyomtatva demovar, és az implicit kimeneti objektum a következő: out kisbetűvel, nem OutJavítsa ki mindkettőt, mielőtt saját maga futtatná az oldalt.

Code A Demo.jsp magyarázata

Code 1. sor: html kezdőcímke

Code 2. sor: Címke

Code 3–4. sor: Cím, pl. Demo JSP, és záró head címke

Code 5–6. sor: A Scriptlet tag, amelyben a demo változó inicializálódik

Code 7–8. sor: A törzscímkében egy szöveg kerül kiírásra a kimeneten (a számláló értéke: ).

Code 9. sor: Scriptlet tag, ahol megpróbáljuk kinyomtatni a demovar változót a növekvő értékével

Code 10–11. sor: A törzs és a HTML-címkék lezárva

A Demo JSP oldalt a lenti kódban látható demo_jsp servletté alakítjuk.

A demo.jsp-ből fordítás közben generált demo_jsp.java servlet forráskód

Code Demo_jsp.java magyarázata

Code 1. sor: A demo_jsp szervlet osztály kiterjeszti a HttpServlet szülő osztályt.

Code 2–3. sor: A JSP service metódusának, azaz a _jspService-nek a felülbírálása, amelynek paraméterei a HttpServletRequest és a HttpServletResponse objektumok.

Code 4. sor: Nyitási mód

Code 5. sor: A get metódus meghívásaWriter() a válaszobjektumban a Print lekéréséhezWriter objektum (az objektumok formázott reprezentációját nyomtatja ki egy szöveges kimeneti adatfolyamba)

Code 6. sor: A válaszobjektum setContentType metódusának meghívása a tartalomtípus beállításához

Code 7. sor: A Print write() metódusának használataWriter HTML-elemzésre szolgáló objektum

Code 8. sor: A demovar változó inicializálása 0-ra

Code 9. sor: A Print write() metódusának meghívásaWriter objektum a szöveg elemzéséhez

Code 10. sor: A Print függvény print() metódusának meghívásaWriter objektumot a demovar változó 0 + 1 = 1 közötti növelésére. Ezért a kimenet 1 lesz

Code 11. sor: A Print write() metódusának használataWriter HTML-elemzésre szolgáló objektum

output:

A böngésző ezután megjeleníti a számlálót, ahogy az alábbi képernyőképen is látható.

A demo.jsp böngésző által kiadott nyomtatási számláló: 1

  • Itt látható, hogy a képernyőképen a kimenet 1, mivel a demvar inicializálása 0-ra történik, majd 0 + 1 = 1-re növekszik.

A fenti példában

  • A demo.jsp egy JSP, ahol egy változó inicializálódik és növekszik. Ez a JSP servlettté (demo_jsp.class) alakul, ahol a JSP motor betölti a JSP oldalt és servlet tartalommá alakítja.
  • Amikor a konverzió megtörténik, az összes sablonszöveg println() utasítássá alakul, és az összes JSP elem is ilyenné alakul. Java kód.

Így fordítható le egy egyszerű JSP oldal servlet osztályba.

2) A JSP oldal összeállítása

  • A generált Java a servlet fájl egy Java szervlet osztály
  • A fordítás Java A forrásoldalnak a megvalósítási osztályába való átvitele bármikor megtörténhet a JSP oldal konténerbe telepítése és a JSP oldal feldolgozása között.
  • A fenti képi leírásban a demo_jsp.java fájlt egy demo_jsp.class osztályfájlba fordítjuk.
  • Az Apache Tomcat rendszeren mindkét műtermék a szerver munkakönyvtárába kerül, a következőbe: work/Catalina/localhost/<app>/org/apache/jsp, ami az első hely, ahol keresni kell, ha fordítási hibát kell diagnosztizálni

3) Osztálybetöltés

  • A JSP forrásból generált servlet osztály most betöltődik a konténerbe.

4) Példányosítás

  • Ebben a lépésben generálódik az objektum, azaz az osztály példánya.
  • A konténer a kérésekre és egyéb eseményekre válaszul kezeli az osztály egy vagy több példányát. Egy JSP konténert jellemzően egy servlet konténer segítségével építenek fel. A JSP konténer a servlet konténer kiterjesztése, mivel mindkét konténer támogatja a JSP-t és a servleteket.
  • A konténer által biztosított JspPage interfész deklarálja a jspInit() és a jspDestroy() metódusokat.
  • Létezik egy HttpJspPage interfész, amely HTTP kéréseket szolgál ki, és tartalmazza a service metódust is. Az aláírása a protokolltól függ, ezért a konténer generálja ezt a metódust ahelyett, hogy az oldal szerzőjét kérné meg a deklarálására.

5) Inicializálás

public void jspInit()
{
	//initializing the code
}
  • A jspInit() metódus inicializálja a JSP-ből generált servlet példányt, amelyet a konténer hív meg ebben a fázisban.
  • Miután a példány létrejött, az init metódus közvetlenül ezután meghívódik.
  • Egy JSP életciklusa során csak egyszer hívódik meg, és az inicializáláshoz használt metódust a fent látható módon deklaráljuk.

6) Kérelem feldolgozása

void _jspservice(HttpServletRequest request HttpServletResponse response)
{
	//handling all request and responses
}
  • A _jspService() metódust a konténer hívja meg a JSP oldal által az életciklusa során generált összes kérésre.
  • Ebben a fázisban az oldalnak a fenti összes fázison át kell mennie, és csak ezután hívható meg a service metódus.
  • Átadja a kérés és válasz objektumokat
  • Ez a metódus nem felülírható, mert a konténer a fordítás során írja ki.
  • A metódus fent látható. Ez felelős az összes HTTP metódus kezeléséért, azaz a GET, POST és a többi.

7) Pusztítsd el

public void _jspdestroy()
{
            //all clean up code
}
  • A jspDestroy() metódust a konténer is meghívja.
  • Ezt a metódust akkor hívja meg a konténer, amikor úgy dönt, hogy már nincs szüksége a servlet példányra a kérések kiszolgálásához.
  • Miután a destroy metódus meghívásra került, a servlet készen áll a szemétgyűjtésre.
  • Ez az életciklus vége.
  • A jspDestroy() függvényt felülbírálhatjuk bármilyen takarítási művelet végrehajtása során, például adatbázis-kapcsolatok bontásakor vagy megnyitott fájlok bezárásakor.

Egy elnevezési megjegyzés, amit érdemes továbbvinni: Jakarta EE 9-től kezdve ezek a típusok a következő területen élnek: jakarta.servlet.jsp csomag helyett javax.servlet.jsp, így a régebbi importálásokat frissíteni kell, amikor egy alkalmazást áthelyeznek egy aktuális szerverre.

GYIK

Ugyanazt az életciklust képviselik a fordítás után. Egy JSP két fázist ad hozzá elejére, a fordítást és a fordítást, amelyek a lapot servlet forrásfájllá és osztállyá alakítják. Az osztály betöltésétől kezdve a servlet contracváltozatlanul érvényes.

A szerver munkakönyvtárában, a work/Catalina/localhost/ mappában /org/apache/jsp. Mind a generált .java forráskód, mind a lefordított .class fájl ide kerül, így a home.jsp fájlból home_jsp.java és home_jsp.class lesz.

A konténer a lap törzséből generálja a fordítás során. Az aláírása a kérési protokolltól függ, így a specifikáció kihagyja a JspPage interfészből, és megtiltja az oldal szerzőinek, hogy maguk deklarálják.

A létrehozott servlet már implementálja az init() függvényt a ServletConfig tárolásához, majd meghívja a jspInit() függvényt. Az oldal készítői felülírják a jspInit() függvényt, így a konténer beállítása soha nem marad ki, ami pontosan az, amit egy kézzel írott init() felülírás kockáztat.

Az előfordítás minden oldalt a build vagy a deployment idején fordít le és állít össze, nem pedig az első kérésre. Eltávolítja az első találat miatti késleltetést, a kiadás előtt felszínre hozza a fordítási hibákat, és lehetővé teszi a telepítést fordítóprogram nélkül a szerveren.

Továbbra is Jakarta Server Pages néven támogatott. A fő változás a csomagnévtér: a Jakarta EE 9-ről az API javax.servlet.jsp-ről jakarta.servlet.jsp-re költözött, így a korábbi importálásokat át kell írni, mielőtt egy jelenlegi szerveren futtatnák.

A mesterséges intelligencia asszisztensek beolvassák a generált _jsp.java veremfájlt tracés a fordítási hibát visszavezetik a hibás scriptlet sorra, ami a fordítási hibák legnehezebb része. Emellett megjelölik azokat a scriptleteket is, amelyek egy tagfájlba vagy egy servletbe tartoznak.

Igen. A Copilot scriptleteket, JSTL blokkokat, űrlapkezelést és servlet osztályok egyeztetését végzi egy megjegyzésből. RevTekintse meg a jakarta csomagnévtér és a kifejezésnyelvnek megfelelő szkriptletek kimenetét, mivel a javaslatok gyakran régebbi oktatóanyagokat követnek.

Foglald össze ezt a bejegyzést a következőképpen: