Лекции 2025. Java. Белая / Ответы на билеты. Java

Технология JavaServer Pages (JSP) была создана для решения ряда проблем и предоставления преимуществ при разработке динамических веб-страниц по сравнению с использованием только сервлетов для генерации HTML.

Основные причины, зачем нужен JSP:

1. Упрощение создания HTML-ориентированного контента:

Проблема с сервлетами: Генерация сложного HTML-кода внутри Javaсервлета с помощью множества вызовов очень громоздка, трудночитаема и подвержена ошибкам. Любое изменение в HTML-разметке требует перекомпиляции Javaкода.

Решение JSP: JSP позволяет писать HTML-код почти так же, как и для статических страниц, и вставлять в него динамические элементы (Java-код, EL, теги) только там, где это необходимо. Это делает процесс разработки вебинтерфейсов более естественным для веб-дизайнеров и разработчиков, знакомых с HTML.

2. Разделение представления (View) и бизнес-логики (Controller/Model):

JSP идеально подходит для роли Представления (View) в архитектурных паттернах, таких как Model-View-Controller (MVC).

Сервлет (Controller) обрабатывает входящий запрос, выполняет бизнес-логику, взаимодействует с Моделью (Model) (JavaBeans, сервисные классы, данные из БД) для получения данных.

Затем сервлет передает эти данные (обычно через атрибуты запроса) на JSPстраницу.

JSP-страница отвечает только за отображение этих данных, используя HTMLразметку, EL и теги JSTL. Она содержит минимальное количество Java-кода (в идеале — вообще без скриптлетов).

Такое разделение улучшает структуру приложения, его тестируемость, поддерживаемость и позволяет разным специалистам (Java-разработчикам и веб-дизайнерам) работать над своими частями более независимо.

3. Повышение продуктивности и удобства для разработчиков интерфейсов:

Веб-дизайнеры могут работать над HTML-структурой и внешним видом JSPстраниц, используя привычные им инструменты, в то время как Javaразработчики фокусируются на бэкенд-логике.

Внесение изменений в HTML-разметку на JSP-странице не требует перекомпиляции Java-классов (если не меняется встроенный Java-код). Контейнер автоматически перетранслирует и перекомпилирует JSP при необходимости.

4. Использование теговых библиотек (Tag Libraries):

JSP поддерживает использование пользовательских тегов и стандартных библиотек тегов, таких как JSTL (JSP Standard Tag Library).

Теги предоставляют XML-подобный синтаксис для выполнения общих задач (циклы, условная логика, форматирование данных, доступ к данным и т.д.) без необходимости писать Java-код (скриптлеты) напрямую в JSP.

Это делает JSP-страницы более чистыми, читаемыми и декларативными.

5. Поддержка JavaBeans:

JSP имеет встроенные действия (например, ,

, ) для легкой интеграции с компонентами JavaBeans, которые могут инкапсулировать данные и некоторую логику.

6. Expression Language (EL):

EL () предоставляет простой и мощный способ доступа к данным, хранящимся в различных областях видимости (page, request, session, application), параметрам запроса, заголовкам, cookies, а также к свойствам JavaBeans и элементам коллекций, без написания Java-кода.

7. Автоматическая компиляция и управление жизненным циклом:

JSP-страницы автоматически транслируются в сервлеты и компилируются контейнером "на лету". Разработчику не нужно явно компилировать JSP. Жизненный цикл сгенерированного сервлета управляется контейнером так же, как и для обычных сервлетов.

В итоге, JSP нужен для того, чтобы:

Сделать разработку динамического веб-контента, ориентированного на HTML, более удобной и эффективной.

Способствовать лучшему разделению логики представления от бизнеслогики.

Позволить веб-дизайнерам и Java-разработчикам более эффективно сотрудничать.

Уменьшить количество Java-кода в слое представления за счет использования EL и теговых библиотек.

Несмотря на появление более современных технологий и фреймворков для построения веб-интерфейсов (например, клиентские MVC-фреймворки типа React, Angular, Vue.js, или серверные шаблонизаторы типа Thymeleaf, FreeMarker), JSP все еще используется во многих существующих Java веб-приложениях и может быть полезен для определенных задач, особенно в сочетании с сервлетами и JSTL.

119. Опишите, как обрабатываются JSP страницы, начиная от запроса к серверу, заканчивая ответом пользователю.

Процесс обработки JSP-страницы включает несколько этапов, которые выполняются контейнером сервлетов (JSP-контейнером). Вот как это происходит:

1. Клиентский запрос (Client Request):

Пользователь (через веб-браузер) запрашивает JSP-страницу, вводя URL в адресную строку или переходя по ссылке (например, ).

Браузер отправляет HTTP-запрос на веб-сервер.

2. Получение запроса контейнером сервлетов:

Веб-сервер (или непосредственно контейнер сервлетов, если он выполняет и функции веб-сервера) получает HTTP-запрос.

Контейнер определяет, что запрошенный ресурс является JSP-страницей (по расширению или по маппингу, если он настроен).

3. Проверка наличия и актуальности скомпилированного сервлета:

Контейнер проверяет, существует ли уже скомпилированный Java-сервлет ( файл), соответствующий этой JSP-странице.

Если сервлет существует, контейнер также проверяет, не был ли исходный файл изменен с момента последней компиляции этого сервлета. Это

делается путем сравнения временных меток файла и сгенерированного файла.

4.Фаза трансляции и компиляции (Translation and Compilation Phase) - если необходимо:

Этот этап выполняется только если:

Это первый запрос к данной JSP-странице.

Или файл был изменен с момента последней компиляции.

Или скомпилированный файл отсутствует.

Шаг 4а: Трансляция (Translation):

JSP-контейнер (часто называемый JSP-движком, например, Jasper в Tomcat) парсит файл.

Он преобразует (транслирует) JSP-код в исходный код Java-сервлета

( файл).

В этом процессе:

Статический HTML/текст из JSP преобразуется в Java-код, который записывает этот текст в (обертку над из

). Например, станет чем-то

JSP-объявления () помещаются на уровень класса сгенерированного сервлета.

JSP-действия () и пользовательские теги преобразуются в вызовы соответствующих Java-классов (обработчиков тегов).

Сгенерированный сервлет обычно наследует

(в Tomcat), который, в свою очередь, наследует . Он будет иметь метод

, который содержит всю логику.

Шаг 4б: Компиляция (Compilation):

Сгенерированный файл сервлета компилируется стандартным Java-компилятором в байт-код ( файл).

Если на этом этапе возникают ошибки компиляции (например, синтаксические ошибки в Java-коде внутри скриптлетов), контейнер обычно возвращает клиенту страницу с сообщением об ошибке компиляции.

5.Загрузка класса сервлета и создание экземпляра (Loading and Instantiation) -

если необходимо:

Если класс сгенерированного сервлета еще не загружен, контейнер загружает его с помощью класслоадера.

Контейнер создает экземпляр этого сервлета (обычно один экземпляр, который используется для обработки всех запросов к этой JSP).

Вызывается метод сгенерированного сервлета (аналог для обычных сервлетов, но определен в интерфейсе ). Этот метод вызывается только один раз.

6. Фаза выполнения (Execution Phase / Request Processing):

Для каждого входящего запроса к JSP-странице контейнер:

Создает новые объекты и (или получает их из пула).

Вызывает метод

сгенерированного сервлета, передавая ему эти объекты.

Внутри :

Инициализируются неявные объекты JSP (такие как ,

, , , , , , ,

).

Выполняется Java-код из скриптлетов и выражений.

Статический HTML-контент записывается в поток вывода (). Обрабатываются JSP-действия и пользовательские теги.

Результатом выполнения является HTTP-ответ (обычно HTML), который формируется в объекте .

7. Отправка ответа клиенту (Sending Response):

После того как метод завершает свою работу, контейнер сервлетов берет сформированный HTTP-ответ из объекта и отправляет его обратно клиенту (браузеру) по сети.

8. Уничтожение (Destruction Phase) - при выгрузке JSP/приложения:

Когда JSP-страница (или все веб-приложение) выгружается контейнером (например, при остановке сервера или приложения), вызывается метод

сгенерированного сервлета. Этот метод вызывается только один раз и предназначен для освобождения ресурсов, захваченных в .

Схема процесса:

HTTP Запрос (например, /mypage.jsp)

Передать запрос для my

Нуж

a

1

2.

HTTP Ответ

Этот процесс (особенно фаза трансляции и компиляции) происходит автоматически и прозрачно для разработчика. Благодаря этому JSP-страницы легко обновлять –

Если клиент попытается напрямую обратиться к , он получит ошибку (обычно 404 Not Found или другую ошибку доступа, в зависимости от сервера).

2. Использование фильтра безопасности (Security Filter):

Можно создать фильтр, который перехватывает все запросы к определенным JSP-страницам (или ко всем JSP, если они не в ) и проверяет, пришел ли запрос напрямую или был перенаправлен (forwarded) с сервлета.

Это более сложный подход и обычно менее предпочтителен, чем размещение в

, так как требует дополнительного кодирования и может быть менее надежным, если логика фильтра некорректна.

Как фильтр может определить "прямой" запрос:

Можно проверять наличие определенных атрибутов запроса, которые устанавливает ваш контроллер перед . Если атрибутов нет, значит, запрос прямой.

Можно проверять заголовок, но он не всегда надежен.

Пример (концептуальный):

```java

// В фильтре

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) res; String requestedUri = request.getRequestURI();

Этот метод сложнее и имеет больше подводных камней, чем простое размещение в .

3. Конфигурация безопасности в (Security Constraints):

Можно использовать ограничения безопасности в для запрета прямого доступа к определенным URL-шаблонам, соответствующим вашим JSP.

Например, можно определить для URL-паттерна, указывающего на JSP, и не определить для него никаких (ролей), что фактически закроет доступ. Однако, это также закроет доступ и для из сервлета, если не настроить это очень хитро (например, через специальные роли для внутреннего использования, что усложняет).

Обычно используется для аутентификации и авторизации, а не просто для скрытия JSP.

Пример (НЕ РЕКОМЕНДУЕТСЯ для простого скрытия JSP, так как может заблокировать и forward):

Этот способ более сложен в настройке для данной цели и может иметь непредвиденные побочные эффекты на доступ через .

Наилучшая практика:

Помещайте все JSP-файлы, которые не должны быть доступны напрямую из браузера, в каталог или его подкаталоги (например, ,

).

Это самый простой, надежный и стандартный способ обеспечить, что доступ к этим JSP будет осуществляться только программно с сервера (например, через

или из сервлета). Контейнер сервлетов автоматически обеспечивает защиту содержимого от прямых клиентских запросов.

121. Какая разница между динамическим и статическим содержимым JSP?

Разница между динамическим и статическим содержимым в JSP-странице заключается в том, как это содержимое обрабатывается и генерируется сервером

перед отправкой клиенту.

Статическое содержимое (Static Content) в JSP:

Что это: Это части JSP-страницы, которые не изменяются от запроса к запросу и отправляются клиенту как есть, без какой-либо обработки или вычислений на сервере (кроме как быть включенными в общий поток вывода).

Любой другой текст, который не является JSP-элементом (директивой, скриптлетом, выражением, действием или тегом библиотеки).

Обработка:

Во время фазы трансляции JSP-страницы в сервлет, статическое содержимое преобразуется в Java-код, который просто записывает этот текст в выходной поток ответа (например, ).

Во время выполнения запроса этот Java-код выполняется, и статический текст отправляется клиенту без изменений.

Характеристики:

Не зависит от параметров запроса, состояния сессии или других динамических факторов.

Быстро обрабатывается, так как не требует вычислений на сервере.

Динамическое содержимое (Dynamic Content) в JSP:

Что это: Это части JSP-страницы, которые генерируются или изменяются на

сервере во время обработки запроса, прежде чем страница будет отправлена клиенту. Их содержимое может зависеть от различных факторов.