Жизнен цикъл на JSP: Обяснение на фазите и диаграмата

⚡ Умно обобщение

Жизненият цикъл на JSP описва как контейнерът преобразува страница в сървлет, компилира я, зарежда класа, създава екземпляр, инициализира го, обслужва всяка заявка чрез генерирания метод на услугата и накрая я унищожава.

  • 🔄 Седем фази: Преводът, компилацията, зареждането на класове, създаването на инстанции, инициализацията, обработката на заявки и унищожаването се изпълняват в този фиксиран ред.
  • 📄 Превод: Контейнерът валидира страницата, след което записва Java изходния файл, така че demo.js става demo_jsp.java преди каквото и да е изпълнение.
  • компилация: Този генериран изходен код се компилира в demo_jsp.class, който Tomcat съхранява в работната си директория, заедно с .java файла.
  • ???? Три метода: jspInit() подготвя страницата веднъж, _jspService() отговаря на всяка заявка, а jspDestroy() освобождава ресурси накрая.
  • 🚫 Едно правило: _jspService() се генерира от контейнера и никога не трябва да бъде записвана или презаписвана от автора на страницата.
  • 🗃️ Кука за почистване: Преименяването на jspDestroy() е правилното място за затваряне на връзките към базата данни и отваряне на файлове.

Фази на жизнения цикъл на JSP от превода до унищожаването

Какво е жизненият цикъл на JSP?

JSP жизнен цикъл се дефинира като преобразуване на JSP страница в сървлет, защото JSP страницата трябва да бъде преобразувана в сървлет, преди да може да обработва заявки за услуги. Жизненият цикъл започва със създаването на JSP и завършва с унищожаването на генерирания от него екземпляр на сървлета.

Тъй като генерираният клас е обикновен сървлет, всичко, което вече знаете за сървлета, може да...tracвсе още се прилага. Java Кодът, който контейнерът записва, е това, което всъщност се изпълнява; JSP файлът е само изходният код, който поддържате.

Различни фази на жизнения цикъл на JSP

Когато браузърът поиска JSP, JSP енджинът първо проверява дали е необходимо да компилира страницата. Ако JSP никога не е бил компилиран или е бил модифициран след последната компилация, тогава JSP енджинът компилира страницата.

Процесът на компилиране на JSP страница включва три стъпки:

  • Разбор на JSP
  • Превръщане на JSP в сървлет
  • Компилиране на сервлета

Диаграма на жизнения цикъл на JSP

Жизненият цикъл на JSP е изобразен на диаграмата по-долу, която tracпредава една страница от изходния файл до класа, който контейнерът изпълнява.

Диаграма на жизнения цикъл на JSP, показваща транслация, компилация, зареждане, създаване на инстанции, инициализация, обработка на заявки и унищожаване

Следните стъпки обясняват жизнения цикъл на JSP:

  1. Превод на JSP страница
  2. Компилация на JSP страница (компилация на JSP страницата в _jsp.java)
  3. Зареждане на класове (_jsp.java се конвертира във файла с клас _jsp.class)
  4. Създаване на инстанция (създава се обект на генерирания сървлет)
  5. Инициализация (методът jspInit() се извиква от контейнера)
  6. Обработка на заявки (методът _jspService() се извиква от контейнера)
  7. Унищожаване (методът jspDestroy() се извиква от контейнера)

Обяснение на фазите от жизнения цикъл на JSP

Нека разгледаме по-подробно всяка от горните точки.

1) Превод на JSP страницата:

A Java Сървлет файлът се генерира от JSP изходен файл. Това е първата стъпка от жизнения цикъл на JSP. Във фазата на транслация контейнерът валидира синтактичната коректност на JSP файловете със страница и тагове.

  • JSP контейнерът интерпретира стандартните директиви и действия, както и персонализираните действия, препращащи към библиотеки с тагове (всички те са част от JSP страницата и са разгледани в JSP елементи урок), използван на тази JSP страница.
  • В илюстративното описание по-горе, demo.jsp е преведено на demo_jsp.java в първата стъпка.

Нека вземем пример за „demo.jsp“, както е показано по-долу:

Demo.jsp

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

Забележка относно горния списък: Възпроизведен е точно както е публикуван, така че да съответства на генерираната екранна снимка на сървлета, която следва. Две от думите в него няма да се компилират, ако бъдат копирани дословно — променливата е декларирана като demvar но отпечатано като demovar, а имплицитният изходен обект е out с малки букви, не OutКоригирайте и двете, преди сами да стартирате страницата.

Code Обяснение за Demo.jsp

Code Ред 1: начален html таг

Code Ред 2: Етикет на заглавието

Code Ред 3 – 4: Таг за заглавие, например Demo JSP, и затварящ таг заглавие

Code Ред 5 – 6: Таг на скриптлет, в който е инициализирана променливата demo

Code Ред 7 – 8: В тага body, текст, който ще бъде отпечатан в изхода (Count е: )

Code Ред 9: Таг на скриптлет, където се опитваме да отпечатаме променливата demovar с нейната увеличена стойност

Code Ред 10 – 11: Затворени са етикетите за тяло и HTML

Демо JSP страницата се конвертира в сървлета demo_jsp, показан в кода по-долу.

Генериран е изходен код на сървлет demo_jsp.java, създаден от demo.js по време на транслацията

Code обяснение за Demo_jsp.java

Code Ред 1: Класът на Servlet demo_jsp разширява родителския клас HttpServlet

Code Ред 2 – 3: Преопределяне на метода на услугата на JSP, т.е. _jspService, който има обекти HttpServletRequest и HttpServletResponse като параметри

Code Ред 4: Метод на отваряне

Code Ред 5: Извикване на метода getWriter() на обекта response, за да се получи PrintWriter обект (отпечатва форматирано представяне на обекти в текстов изходен поток)

Code Ред 6: Извикване на метода setContentType на обекта response за задаване на типа съдържание

Code Ред 7: Използване на метода write() на PrintWriter обект за парсиране на html

Code Ред 8: Инициализиране на променливата demovar на 0

Code Ред 9: Извикване на метода write() на PrintWriter обект за анализиране на текста

Code Ред 10: Извикване на метода print() на PrintWriter обект да увеличи променливата demovar от 0 + 1 = 1. Следователно, изходът ще бъде 1

Code Ред 11: Използване на метода write() на PrintWriter обект за парсиране на html

Изход:

След това браузърът изобразява брояча, както е показано на екранната снимка по-долу.

Изходът на браузъра за отпечатване на demo.js Count е: 1

  • Тук можете да видите, че на екранната снимка изходът е 1, защото demvar е инициализиран на 0 и след това е увеличен до 0 + 1 = 1

В горния пример,

  • demo.jsp е JSP, където една променлива е инициализирана и инкрементирана. Този JSP се конвертира в сървлет (demo_jsp.class), където JSP енджинът зарежда JSP страницата и я конвертира в съдържание на сървлет.
  • Когато се осъществи преобразуването, целият текст на шаблона се преобразува в println() оператори и всички JSP елементи се преобразуват в Java код.

Ето как една проста JSP страница се превежда в сервлет клас.

2) Компилация на JSP страницата

  • Генерираният Java сървлет файлът се компилира в Java клас на сървлет
  • Преводът на Java Прехвърлянето на изходната страница към нейния клас на имплементация може да се случи по всяко време между разполагането на JSP страницата в контейнера и обработката ѝ.
  • В илюстративното описание по-горе, demo_jsp.java е компилиран във файл с клас demo_jsp.class
  • В Apache Tomcat и двата артефакта са записани в работната директория на сървъра, в work/Catalina/localhost/<app>/org/apache/jsp, което е първото място, където трябва да се търси, когато трябва да се диагностицира грешка в превода

3) Зареждане на класове

  • Класът на сървлета, генериран от JSP изходния код, вече е зареден в контейнера.

4) Инстанция

  • В тази стъпка се генерира обектът, т.е. екземплярът на класа.
  • Контейнерът управлява един или повече екземпляри от този клас в отговор на заявки и други събития. Обикновено JSP контейнерът се изгражда с помощта на контейнер за сървлети. JSP контейнерът е разширение на контейнер за сървлети, тъй като и двата контейнера поддържат JSP и сървлети.
  • Интерфейсът JspPage, който се предоставя от контейнера, декларира методите jspInit() и jspDestroy().
  • Съществува интерфейс HttpJspPage, който обслужва HTTP заявки и съдържа и метода service. Неговата сигнатура зависи от протокола, поради което контейнерът генерира този метод, вместо да поиска от автора на страницата да го декларира.

5) Инициализация

public void jspInit()
{
	//initializing the code
}
  • Методът jspInit() инициализира екземпляра на сървлет, генериран от JSP, и се извиква от контейнера в тази фаза.
  • След като инстанцията е създадена, методът init се извиква веднага след това
  • Извиква се само веднъж по време на жизнения цикъл на JSP, а методът за инициализация е деклариран, както е показано по-горе.

6) Обработка на заявка

void _jspservice(HttpServletRequest request HttpServletResponse response)
{
	//handling all request and responses
}
  • Методът _jspService() се извиква от контейнера за всички заявки, генерирани от JSP страницата по време на нейния жизнен цикъл.
  • За тази фаза страницата трябва да премине през всички горепосочени фази и едва тогава може да се извика методът на услугата.
  • Той предава обектите за заявка и отговор
  • Този метод не може да бъде презаписан, защото контейнерът го записва по време на транслацията.
  • Методът е показан по-горе. Той е отговорен за обработката на всички HTTP методи, т.е. GET, POST и останалите.

7) Унищожи

public void _jspdestroy()
{
            //all clean up code
}
  • Методът jspDestroy() също се извиква от контейнера
  • Този метод се извиква, когато контейнерът реши, че вече не се нуждае от екземпляра на сървлета за обслужване на заявки.
  • След като се извика методът destroy, сървлетът е готов за събиране на боклука.
  • Това е краят на жизнения цикъл.
  • Можем да презапишем jspDestroy(), когато извършваме почистване, като например освобождаване на връзки към базата данни или затваряне на отворени файлове.

Едно именуване, което си струва да се отбележи: от Джакарта EE 9 нататък тези типове живеят в jakarta.servlet.jsp пакет, а не javax.servlet.jsp, така че по-старите импортирания трябва да се актуализират, когато приложението се премести на текущ сървър.

Въпроси и Отговори

Те имат един и същ жизнен цикъл след транслацията. JSP добавя две фази отпред, транслацията и компилацията, които превръщат страницата в изходен файл на сървлет и клас. От зареждането на класа нататък сървлетът може да...tract се прилага непроменен.

В работната директория на сървъра, в work/Catalina/localhost/ /org/apache/jsp. Както генерираният .java изходен код, така и компилираният .class файл се намират там, така че home.js става home_jsp.java и home_jsp.class.

Контейнерът го генерира от тялото на страницата по време на транслацията. Сигнатурата му зависи от протокола за заявка, така че спецификацията го изключва от интерфейса на JspPage и забранява на авторите на страници да го декларират сами.

Генерираният сървлет вече имплементира init(), за да съхрани своя ServletConfig, след което извиква jspInit(). Авторите на страници презаписват jspInit(), така че настройката на контейнера никога да не се пропуска, което е точно това, което рискува ръчно написано презаписване на init().

Предкомпилацията превежда и компилира всяка страница по време на изграждане или внедряване, вместо при първата заявка. Тя премахва забавянето при първо попадение, откроява грешки при превода преди пускането на продукта и позволява внедряване без компилатор на сървъра.

Остава поддържан като Jakarta Server Pages. Основната промяна е пространството от имена на пакети: от Jakarta EE 9 API-то се премести от javax.servlet.jsp на jakarta.servlet.jsp, така че импортирането от стари версии трябва да бъде пренаписано преди изпълнение на текущ сървър.

AI асистентите четат генерирания стек _jsp.java trace и свързват грешка при компилация обратно към проблемния ред на скриптлета, което е най-трудната част от грешките при превода. Те също така маркират скриптлети, които принадлежат към файл с тагове или сървлет.

Да. Copilot създава скриптлети, JSTL блокове, обработка на формуляри и съпоставяне на класове на сървлети от коментар. RevВижте резултата за пространството от имена на пакета jakarta и за скриптлетите, които трябва да са език за изрази, тъй като предложенията често следват по-стари уроци.

Обобщете тази публикация с: