50 Servlet Интервью Вопросы и ответы

Чем отличается веб-сервер от сервера приложений?

Ответственность веб-сервера заключается в обработке HTTP-запросов от клиентских браузеров и ответе HTML-ответом. Веб-сервер понимает язык HTTP и работает по протоколу HTTP.
Веб-сервер Apache является своего рода веб-сервером, и у нас есть специальные контейнеры, которые могут выполнять сервлеты и JSP, известные как контейнеры сервлетов, например Tomcat.
Серверы приложений предоставляют дополнительные функции, такие как поддержка Enterprise JavaBeans, поддержка JMS Messaging, управление транзакциями и т. Д. Таким образом, мы можем сказать, что сервер приложений представляет собой веб-сервер с дополнительными функциями, помогающими разработчикам корпоративных приложений.

Какой метод HTTP неидемпотентен?

HTTP-метод называется идемпотентным, если он каждый раз возвращает один и тот же результат. Методы HTTP GET, PUT, DELETE, HEAD и OPTIONS являются идемпотентными, и мы должны реализовать наше приложение, чтобы эти методы всегда возвращали один и тот же результат. HTTP-метод POST является неидемпотентным методом, и мы должны использовать метод post при реализации чего-то, что меняется с каждым запросом.

Например, чтобы получить доступ к HTML-странице или изображению, мы должны использовать GET, потому что он всегда будет возвращать один и тот же объект, но если нам нужно сохранить информацию о клиенте в базе данных, мы должны использовать метод POST. Идемпотентные методы также известны как безопасные методы, и мы не заботимся о повторяющемся запросе от клиента о безопасных методах.

В чем разница между методом GET и POST?

• GET — безопасный метод (идемпотент), где POST — неидемпотентный метод.
• Мы можем отправлять ограниченные данные методом GET, и они отправляются в URL запроса заголовка, тогда как мы можем отправлять большой объем данных с помощью POST, потому что это часть тела.
• Метод GET небезопасен, поскольку данные отображаются в URL-адресе, и мы можем легко добавить их в закладки и снова отправить аналогичный запрос, POST безопасен, поскольку данные отправляются в теле запроса, и мы не можем добавить их в закладки.
• GET — это метод HTTP по умолчанию, в то время как нам нужно указать метод как POST для отправки запроса методом POST.
• Гиперссылки на странице используют метод GET.

Что такое MIME Type?

Заголовок ответа «Content-Type» известен как MIME-тип. Сервер отправляет MIME-тип клиенту, чтобы он знал тип отправляемых им данных. Это помогает клиенту в рендеринге данных для пользователя. Некоторые из наиболее часто используемых типов MIME — это text / html, text / xml, application / xml и т. Д.

Мы можем использовать метод ServletContext getMimeType (), чтобы получить правильный MIME-тип файла и использовать его для установки типа содержимого ответа. Это очень полезно при загрузке файла через сервлет с сервера.

Какие преимущества сервлета перед CGI?

Технология сервлетов была введена для преодоления недостатков технологии CGI.

• Сервлеты обеспечивают лучшую производительность, чем CGI, с точки зрения времени обработки и использования памяти, поскольку сервлеты используют преимущества многопоточности, и для каждого запроса создается новый поток, что быстрее, чем загрузка создания объекта для каждого запроса с CGI.
• Сервлеты, независимые от платформы и системы, веб-приложение, разработанное с помощью Servlet, может быть запущено на любом стандартном веб-контейнере, таком как серверы Tomcat, JBoss, Glassfish, и в операционных системах, таких как Windows, Linux, Unix, Solaris, Mac и т. Д.
• Сервлеты надежны, потому что контейнер заботится о жизненном цикле сервлета, и нам не нужно беспокоиться об утечках памяти, безопасности, сборке мусора и т. Д.
• Сервлеты обслуживаемы, а кривая обучения мала, потому что все, что нам нужно, — это бизнес-логика нашего приложения.

Какие общие задачи выполняет Servlet Container?

Контейнеры сервлетов также известны как веб-контейнеры, например Tomcat. Некоторые из важных задач контейнера сервлетов:

• Поддержка связи : Servlet Container обеспечивает простой способ связи между веб-клиентом (браузерами) и сервлетами и JSP. Из-за контейнера нам не нужно создавать сокет сервера, чтобы прослушивать любой запрос от веб-клиента, анализировать запрос и генерировать ответ. Все эти важные и сложные задачи выполняются контейнером, и все, что нам нужно сосредоточиться, — это бизнес-логика для приложений.
• Управление жизненным циклом и ресурсами : Контейнер сервлетов заботится об управлении жизненным циклом сервлета. Из загрузки сервлетов в память, инициализации сервлетов, вызова методов сервлетов и их уничтожения. Контейнер также предоставляет утилиту, такую ​​как JNDI для пула ресурсов и управления ими.
• Поддержка многопоточности : контейнер создает новый поток для каждого запроса к сервлету и предоставляет им объекты запроса и ответа для обработки. Таким образом, сервлеты не инициализируются для каждого запроса и экономят время и память.
• Поддержка JSP: JSP не похожи на обычные классы java, но каждый JSP в приложении компилируется контейнером и преобразуется в сервлет, а затем контейнер управляет ими, как и другие сервлеты.
• Разное Задача : Контейнер сервлетов управляет пулом ресурсов, выполняет оптимизацию памяти, выполняет сборщик мусора, предоставляет конфигурации безопасности, поддержку нескольких приложений, горячее развертывание и ряд других задач за сценой, которые облегчают жизнь разработчика.

Что такое объект ServletConfig?

javax.servlet.ServletConfig используется для передачи информации о конфигурации сервлету. Каждый сервлет имеет свой собственный объект ServletConfig, и контейнер сервлета отвечает за создание экземпляра этого объекта. Мы можем предоставить параметры инициации сервлета в файле web.xml или с помощью аннотации WebInitParam. Мы можем использовать метод getServletConfig (), чтобы получить объект ServletConfig сервлета.

Что такое объект ServletContext?

Интерфейс javax.servlet.ServletContext обеспечивает доступ к параметрам веб-приложения к сервлету. ServletContext является уникальным объектом и доступен всем сервлетам в веб-приложении. Когда мы хотим, чтобы некоторые параметры инициализации были доступны для нескольких или всех сервлетов в веб-приложении, мы можем использовать объект ServletContext и определять параметры в web.xml, используя элемент <context-param>. Мы можем получить объект ServletContext с помощью метода getServletContext () ServletConfig. Контейнеры сервлетов также могут предоставлять объекты контекста, которые являются уникальными для группы сервлетов и привязаны к определенной части пространства имен пути URL хоста.

ServletContext улучшен в Servlet Specs 3, чтобы представить методы, с помощью которых мы можем программно добавлять прослушиватели, фильтры и сервлет в приложение. Он также предоставляет некоторые служебные методы, такие как getMimeType () , getResourceAsStream () и т. Д.

В чем разница между ServletConfig и ServletContext?

Некоторые из различий между ServletConfig и ServletContext:

• ServletConfig — это уникальный объект для каждого сервлета, тогда как ServletContext — это уникальный объект для полного приложения.
• ServletConfig используется для предоставления параметров инициализации сервлету, тогда как ServletContext используется для предоставления параметров инициализации уровня приложения, которые могут использовать все остальные сервлеты.
• Мы не можем устанавливать атрибуты в объекте ServletConfig, тогда как мы можем устанавливать атрибуты в ServletContext, которые другие сервлеты могут использовать в своей реализации.

Что такое диспетчер запросов?

Интерфейс RequestDispatcher используется для пересылки запроса другому ресурсу, который может быть HTML, JSP или другим сервлетом в том же приложении. Мы также можем использовать это для включения содержимого другого ресурса в ответ. Этот интерфейс используется для связи между сервлетами в том же контексте.

В этом интерфейсе определены два метода:

1. void forward (запрос ServletRequest, ответ ServletResponse) — перенаправляет запрос из сервлета в другой ресурс (сервлет, файл JSP или файл HTML) на сервере.
2. void include (запрос ServletRequest, ответ ServletResponse) — включает в ответ содержимое ресурса (сервлет, страница JSP, файл HTML).

Мы можем получить RequestDispatcher в сервлете, используя метод ServletContext getRequestDispatcher (String path). Путь должен начинаться с / и интерпретируется относительно текущего корневого контекста.

Можем ли мы получить PrintWriter и ServletOutputStream как в сервлете?

Мы не можем получить экземпляры PrintWriter и ServletOutputStream в одном методе сервлета, если мы вызываем оба метода; getWriter () и getOutputStream () в ответе; мы получим java.lang.IllegalStateException во время выполнения с сообщением, так как для этого ответа уже был вызван другой метод.

Какая польза от классов-обёрток сервлета?

HTTP-сервлет сервлета предоставляет два класса-оболочки — HttpServletRequestWrapper и HttpServletResponseWrapper . Эти классы-обертки предназначены для того, чтобы помочь разработчикам в индивидуальной реализации типов запросов и ответов сервлета. Мы можем расширить эти классы и переопределить только определенные методы, которые нам нужно реализовать для пользовательских объектов запросов и ответов. Эти классы не используются в обычном программировании сервлетов.

Что такое интерфейс SingleThreadModel?

Интерфейс SingleThreadModel был предоставлен для обеспечения безопасности потоков и гарантирует, что никакие два потока не будут выполняться одновременно в методе обслуживания сервлета. Однако SingleThreadModel не решает все проблемы безопасности потоков. Например, атрибуты сеанса и статические переменные по-прежнему могут быть доступны для нескольких запросов в нескольких потоках одновременно, даже если используются сервлеты SingleThreadModel. Также он устраняет все преимущества поддержки многопоточности сервлетов, поэтому этот интерфейс устарел в Servlet 2.4.

Нужно ли переопределять метод service ()?

Когда контейнер сервлета получает запрос клиента, он вызывает метод service (), который, в свою очередь, вызывает методы doGet (), doPost () на основе HTTP-метода запроса. Я не вижу ни одного варианта использования, где мы хотели бы переопределить метод service (). Цель метода service () — перенаправить запрос в соответствующие реализации HTTP-метода. Если нам необходимо выполнить некоторую предварительную обработку запроса, мы всегда можем использовать фильтры сервлетов и прослушиватели.

Это хорошая идея, чтобы создать конструктор сервлетов?

Мы можем определить конструктор для сервлета, но я не думаю, что он будет полезен, потому что у нас не будет доступа к объекту ServletConfig, пока сервлет не будет инициализирован контейнером. В идеале, если нам нужно инициализировать любой ресурс для сервлета, мы должны переопределить метод init (), где мы можем получить доступ к параметрам инициации сервлета, используя объект ServletConfig.

В чем разница между GenericServlet и HttpServlet?

GenericServlet — это независимая от протокола реализация интерфейса Servlet, тогда как HttpServlet — это реализация протокола HTTP. В большинстве случаев мы используем сервлет для создания веб-приложения, поэтому мы расширяем класс HttpServlet. Класс HttpServlet расширяет GenericServlet, а также предоставляет некоторые другие методы, специфичные для протокола HTTP.

Что такое меж сервлетная связь?

Когда мы хотим вызвать другой сервлет из методов службы сервлета, мы используем механизмы связи между сервлетами. Мы можем вызвать другой сервлет, используя методы RequestDispatcher forward () и include (), и предоставить дополнительные атрибуты в запросе для другого использования сервлета.

Что такое атрибуты сервлета и их область действия?

Атрибуты сервлета используются для связи между сервлетами, мы можем устанавливать, получать и удалять атрибуты в веб-приложении. Существует три области действия атрибутов сервлета: область запроса, область сеанса и область приложения.

Интерфейсы ServletRequest, HttpSession и ServletContext предоставляют методы для получения / установки / удаления атрибутов из области запроса, сеанса и приложения соответственно.

Атрибуты сервлета отличаются от параметров инициализации, определенных в web.xml для ServletConfig или ServletContext.

Как мы называем один сервлет из другого сервлета?

Мы можем использовать метод RequestDispatcher forward () для пересылки обработки запроса другому сервлету. Если мы хотим включить другой выход сервлета в ответ, мы можем использовать метод RequestDispatcher include ().

Как мы можем вызвать другой сервлет в другом приложении?

Мы не можем использовать RequestDispatcher для вызова сервлета из другого приложения, потому что он специфичен для приложения. Если нам нужно перенаправить запрос к ресурсу в другом приложении, мы можем использовать метод ServletResponse sendRedirect () и предоставить полный URL-адрес другого сервлета. Это отправляет ответ клиенту с кодом ответа 302 для пересылки запроса на другой URL. Если нам также необходимо отправить некоторые данные, мы можем использовать файлы cookie, которые будут частью ответа сервлета и будут отправлены в запросе другому сервлету.

В чем разница между ServletResponse sendRedirect () и RequestDispatcher методом forward ()?

1. RequestDispatcher forward () используется для пересылки того же запроса другому ресурсу, тогда как ServletResponse sendRedirect () представляет собой двухэтапный процесс. В sendRedirect () веб-приложение возвращает клиенту ответ с кодом состояния 302 (перенаправление) с URL-адресом для отправки запроса. Отправленный запрос является совершенно новым запросом.
2. forward () обрабатывается внутренне контейнером, тогда как sednRedirect () обрабатывается браузером.
3. Мы должны использовать forward () при доступе к ресурсам в том же приложении, потому что это быстрее, чем метод sendRedirect (), который требует дополнительного сетевого вызова.
4. В браузере forward () реальный ресурс обработки не знает, и URL-адрес в адресной строке остается тем же, а в sendRedirect () URL-адрес в адресной строке изменяется на перенаправленный ресурс.
5. forward () нельзя использовать для вызова сервлета в другом контексте, в этом случае мы можем использовать только sendRedirect ().

Какие фазы жизненного цикла сервлета?

Мы знаем, что Servlet Container управляет жизненным циклом Servlet, существует четыре фазы жизненного цикла сервлета.

1. Загрузка класса сервлета — Когда контейнер получает запрос на сервлет, он сначала загружает класс в память и вызывает его конструктор по умолчанию без аргументов.
2. Инициализация класса сервлета. После загрузки класса сервлета контейнер инициализирует объект ServletContext для сервлета, а затем вызывает его метод init, передавая объект конфигурации сервлета. Это место, где класс сервлета трансформируется из обычного класса в сервлет.
3. Обработка запросов — как только сервлет инициализирован, он готов обрабатывать клиентские запросы. Для каждого запроса клиента контейнер сервлета порождает новый поток и вызывает метод service (), передавая ссылку на объект запроса и ответа.
4. Удаление из службы — когда контейнер останавливается или мы останавливаем приложение, контейнер сервлета уничтожает класс сервлета, вызывая его метод destroy ().

Каковы методы жизненного цикла сервлета?

Жизненный цикл сервлета состоит из трех методов:

1. public void init (ServletConfig config) — этот метод используется контейнером для инициализации сервлета, этот метод вызывается только один раз в жизненном цикле сервлета.
2. public void service (запрос ServletRequest, ответ ServletResponse) — этот метод вызывается один раз для каждого запроса, контейнер не может вызывать метод service (), пока не будет выполнен метод init ().
3. public void destroy () — Этот метод вызывается один раз, когда сервлет выгружается из памяти.

почему мы должны переопределять только метод no-agrs init ().

Если нам нужно инициализировать некоторый ресурс, прежде чем мы хотим, чтобы наш сервлет обрабатывал клиентские запросы, мы должны переопределить метод init (). Если мы переопределим метод init (ServletConfig config), то первый оператор должен быть super (config), чтобы убедиться, что сначала вызывается метод init суперкласса init (ServletConfig config). Вот почему GenericServlet предоставляет другой вспомогательный метод init () без аргумента, который вызывается в конце метода init (ServletConfig config). Мы всегда должны использовать этот метод для переопределения метода init (), чтобы избежать каких-либо проблем, поскольку мы можем забыть добавить вызов super () в перезаписывающий метод init с аргументом ServletConfig.

Что такое кодировка URL?

URL-кодирование — это процесс преобразования данных в форму CGI, чтобы они могли без проблем перемещаться по сети. Кодировка URL удаляет пробелы и заменяет специальные символы на escape-символы. Мы можем использовать java.net.URLEncoder.encode (String str, String unicode) для кодирования строки. Декодирование URL — это обратный процесс кодирования, и мы можем использовать java.net.URLDecoder.decode (String str, String unicode) для декодирования закодированной строки. Например, «Данные Панкаджа» кодируются как «Данные Панкаджа% 27s +».

В чем разница между encodeRedirectUrl и encodeURL?

HttpServletResponse предоставляет метод для кодирования URL в гиперссылках HTML, чтобы экранировать специальные символы и пробелы и добавлять идентификатор сессии в URL. Он ведет себя подобно методу кодирования URLEncoder с дополнительным процессом для добавления параметра jsessionid в конце URL-адреса.

Однако HttpServletResponse encodeRedirectUrl () метод используется специально для кодирования URL перенаправления в ответ.

Поэтому, когда мы предоставляем поддержку перезаписи URL, для гиперссылок в ответе HTML мы должны использовать метод encodeURL (), тогда как для URL перенаправления мы должны использовать метод encodeRedirectUrl ().

Что такое дескриптор развертывания?

Дескриптор развертывания — это файл конфигурации для веб-приложения с именем web.xml, который находится в каталоге WEB-INF. Контейнер сервлетов использует этот файл для настройки сервлетов веб-приложений, параметров конфигурации сервлетов, параметров инициализации контекста, фильтров, прослушивателей, страниц приветствия и обработчиков ошибок.

С помощью аннотаций сервлета 3.0 мы можем удалить много беспорядка из web.xml, настроив сервлеты, фильтры и прослушиватели с помощью аннотаций.

Как убедиться, что сервлет загружен при запуске приложения?

Обычно контейнер сервлета загружает сервлет по первому клиентскому запросу, но иногда, когда сервлет тяжелый и требует времени для загрузки, мы можем захотеть загрузить его при запуске приложения. Мы можем использовать элемент load-on-startup с конфигурацией сервлета в файле web.xml или использовать переменную loadSnStartup аннотации WebServlet, чтобы указать контейнеру загрузить сервлет при запуске системы.

Значение load-on-startup должно быть int, если оно равно 0 или отрицательному целому числу, то контейнер сервлета будет загружать сервлет на основе запросов и требований клиента, но если он положительный, то контейнер загружает его при запуске приложения.

Если существует несколько сервлетов со значением загрузки при запуске, равным 1,2,3, то сервлет с более низким целым значением будет загружен первым.

Как получить фактический путь сервлета на сервере?

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

Как получить информацию о сервере в сервлете?

Мы можем использовать приведенный ниже фрагмент кода, чтобы получить информацию о сервлете в сервлете через объект контекста сервлета.

Как получить IP-адрес клиента в сервлете?

Мы можем использовать request.getRemoteAddr() чтобы получить IP-адрес клиента в сервлете.

Каковы разные способы аутентификации сервлета?

Контейнер сервлетов предоставляет различные способы аутентификации сервлетов на основе входа:

1. Базовая аутентификация HTTP
2. Дайджест-аутентификация HTTP
3. HTTPS-аутентификация
4. Форма входа в систему : стандартная форма HTML для аутентификации, преимущество в том, что мы можем изменить макет страницы входа в систему в соответствии с требованиями нашего приложения, а не использовать встроенные механизмы входа HTTP.