какие типы протоколов поддерживает httpservlet

Какие типы протоколов поддерживает httpservlet

There’s almost no reason to override the service method. service handles standard HTTP requests by dispatching them to the handler methods for each HTTP request type (the do XXX methods listed above).

Likewise, there’s almost no reason to override the doOptions and doTrace methods.

Servlets typically run on multithreaded servers, so be aware that a servlet must handle concurrent requests and be careful to synchronize access to shared resources. Shared resources include in-memory data such as instance or class variables and external objects such as files, database connections, and network connections. See the Java Tutorial on Multithreaded Programming for more information on handling multiple threads in a Java program.

Constructor Summary

Method Summary

All Methods Instance Methods Concrete Methods

Modifier and Type	Method and Description
protected void	doDelete (HttpServletRequest req, HttpServletResponse resp)

Methods inherited from class javax.servlet.GenericServlet

Methods inherited from class java.lang.Object

Constructor Detail

HttpServlet

Method Detail

doGet

Overriding this method to support a GET request also automatically supports an HTTP HEAD request. A HEAD request is a GET request that returns no body in the response, only the request header fields.

When overriding this method, read the request data, write the response headers, get the response’s writer or output stream object, and finally, write the response data. It’s best to include content type and encoding. When using a PrintWriter object to return the response, set the content type before accessing the PrintWriter object.

The servlet container must write the headers before committing the response, because in HTTP the headers must be sent before the response body.

Where possible, set the Content-Length header (with the ServletResponse.setContentLength(int) method), to allow the servlet container to use a persistent connection to return its response to the client, improving performance. The content length is automatically set if the entire response fits inside the response buffer.

When using HTTP 1.1 chunked encoding (which means that the response has a Transfer-Encoding header), do not set the Content-Length header.

The GET method should be safe, that is, without any side effects for which users are held responsible. For example, most form queries have no side effects. If a client request is intended to change stored data, the request should use some other HTTP method.

The GET method should also be idempotent, meaning that it can be safely repeated. Sometimes making a method safe also makes it idempotent. For example, repeating queries is both safe and idempotent, but buying a product online or modifying data is neither safe nor idempotent.

If the request is incorrectly formatted, doGet returns an HTTP «Bad Request» message.

getLastModified

Servlets that support HTTP GET requests and can quickly determine their last modification time should override this method. This makes browser and proxy caches work more effectively, reducing the load on server and network resources.

doHead

Receives an HTTP HEAD request from the protected service method and handles the request. The client sends a HEAD request when it wants to see only the headers of a response, such as Content-Type or Content-Length. The HTTP HEAD method counts the output bytes in the response to set the Content-Length header accurately.

If you override this method, you can avoid computing the response body and just set the response headers directly to improve performance. Make sure that the doHead method you write is both safe and idempotent (that is, protects itself from being called multiple times for one HTTP HEAD request).

If the HTTP HEAD request is incorrectly formatted, doHead returns an HTTP «Bad Request» message.

doPost

When overriding this method, read the request data, write the response headers, get the response’s writer or output stream object, and finally, write the response data. It’s best to include content type and encoding. When using a PrintWriter object to return the response, set the content type before accessing the PrintWriter object.

The servlet container must write the headers before committing the response, because in HTTP the headers must be sent before the response body.

Where possible, set the Content-Length header (with the ServletResponse.setContentLength(int) method), to allow the servlet container to use a persistent connection to return its response to the client, improving performance. The content length is automatically set if the entire response fits inside the response buffer.

When using HTTP 1.1 chunked encoding (which means that the response has a Transfer-Encoding header), do not set the Content-Length header.

This method does not need to be either safe or idempotent. Operations requested through POST can have side effects for which the user can be held accountable, for example, updating stored data or buying items online.

If the HTTP POST request is incorrectly formatted, doPost returns an HTTP «Bad Request» message.

doPut

This method does not need to be either safe or idempotent. Operations that doPut performs can have side effects for which the user can be held accountable. When using this method, it may be useful to save a copy of the affected URL in temporary storage.

If the HTTP PUT request is incorrectly formatted, doPut returns an HTTP «Bad Request» message.

doDelete

This method does not need to be either safe or idempotent. Operations requested through DELETE can have side effects for which users can be held accountable. When using this method, it may be useful to save a copy of the affected URL in temporary storage.

If the HTTP DELETE request is incorrectly formatted, doDelete returns an HTTP «Bad Request» message.

doOptions

Allow: GET, HEAD, TRACE, OPTIONS

There’s no need to override this method unless the servlet implements new HTTP methods, beyond those implemented by HTTP 1.1.

doTrace

service

service

Copyright © 1996-2015, Oracle and/or its affiliates. All Rights Reserved. Use is subject to license terms.

Источник

Сервлеты

Клиентский доступ из интернета или корпоративного интранета, конечно же, является легким способом позволить многим получить или предоставить доступ к данным и ресурсам [4].

Традиционно, способ решения таких проблем, как возможность для Интернет клиента обновления базы данных, состояла в создании HTML страницы с текстовыми полями и кнопкой «Submit». Пользователь впечатывал соответствующую информацию в текстовые поля и нажимал кнопку «Submit». Данные передавались вместе с URL, который говорил серверу, что делать с данными, указывая расположение программы Common Gateway Interface (CGI), которую запускал сервер, обеспечивая программу данными, которые она требовала. CGI программа обычна написана на Perl, Python, C, C++ или любом другом языке, который умеет читать стандартный ввод и писать в стандартный вывод. Это все, что предоставлял Web сервер: вызывалась CGI программа и использовались стандартные потоки (или, как возможный вариант для ввода, использовалась переменная окружения) для ввода и вывода. CGI программа отвечала за все остальное. Во-первых, она просматривала данные и решала, является ли их формат корректным. Если нет, CGI программа должна производить HTML страницу для описания проблемы; эта страница передавалась Web серверу (через стандартный вывод из CGI программы), который посылал ее назад пользователю. Пользователь должен был, обычно, вернуться на страницу и попробовать снова. Если данные были корректными, CGI программа обрабатывала данные соответствующим способом, возможно, добавляла их в базу данных. Затем она должна была произвести соответствующую HTML страницу для Web сервера, чтобы он вернул ее пользователю.

Поскольку сервлеты предоставляют великолепное решение для программной поддержки на стороне сервера, они являются одним из наиболее популярных причин перехода на Java. Не только потому, что они предоставляют рабочую среду, которая заменяет CGI программирование (и снижает количество throny CGI проблем), но весь ваш код приобретает портируемость между платформами, получаемую от использования Java, и вы приобретаете доступ ко всему Java API (за исключением, конечно, того, которое производит GUI, такого, как Swing).

Основа сервлета

Архитектура API сервлета основывается на том, что классический провайдер сервиса использует метод service( ), через который все клиентские запросы будут посылаться программным обеспечением контейнера сервлетов, и методы жизненного цикла init( ) и destroy( ), которые вызываются только в то время, когда сервлет загружается и выгружается (это случается редко).

public interface Servlet <
public void init ( ServletConfig config ) throws ServletException;

public ServletConfig getServletConfig () ;

public void service ( ServletRequest req, ServletResponse res )
throws ServletException, IOException;

public String getServletInfo () ;

public void destroy () ;
>

Основное назначение getServletConfig( ) состоит в возвращении объекта ServletConfig, который содержит параметры инициализации и запуска для этого сервлета. getServletInfo( ) возвращает строку, содержащую информацию о сервлете, такую, как автор, версия и авторские права.

Наибольшее удобство атрибутов сервлетного API состоит во внешних объектах, которые вводятся вместе с классом HttpServlet для его поддержки. Если вы взглянене на метод service( ) в интерфейсе Servlet, вы увидите, что он имеет два параметра: ServeltRequest и ServletResponse. Вместе с классом HttpServlet, эти два объекта предназначены для HTTP: HttpServletRequest и HttpServletResponse. Вот простейший пример, который показывает использование HttpServelResponse:

//: c15:servlets:ServletsRule.java
//
import javax.servlet.*;

public class ServletsRule extends HttpServlet <
int i = 0 ; // «постоянство» сервлета

public void service ( HttpServletRequest req, HttpServletResponse res )
throws IOException <
res.setContentType ( «text/html» ) ;
PrintWriter out = res.getWriter () ;
out.print ( » » ) ;
out.print ( «A server-side strategy» ) ;
out.print ( » » ) ;
out.print ( «

Servlets Rule! » + i++ ) ;
out.print ( «

Программа ServletsRule настолько проста, насколько может быть прост сервлет. Сервлет инициализируется только один раз путем вызова его метода init( ), при загрузке сервлета после того, как контейнер сервлетов будет загружен в первый раз. Когда клиент создает запрос к URL, который представлен сервлетом, контейнер сервлетов перехварывает этот запрос и совершает вызов метода service( ) после установки объектов HttpServletRequest и HttpServletResponse.

Основная ответственность метода service( ) состоит во взаимодействии с HTTP запросом, который посылает клиент, и в построении HTTP ответа, основываясь на атрибутах, содержащихся в запросе. ServletsRule манипулирует только объектом ответа, не обращая внимания на то, что посылает клиент.

После установки типа содержимого клиента (которое должно всегда выполнятся прежде, чем будет получен Writer или OutputStream), метод getWriter( ) объекта ответа производит объект PrintWriter, который используется для записи символьных данных ответа (другой вариант: getOutputStream( ) производит OutputStream, используемый для бинарного ответа, который применим для более специализированных решений).

Оставшаяся часть программы просто посылает HTML клиенту (предполагается, что вы понимаете HTML, так что эта часть не объясняется), как последовательность строк. Однако, обратите внимание на включение «счетчика показов», представленного переменной i. Он автоматически конвертируется в строку в инструкции print( ).

Когда вы запустите программу, вы увидите, что значение i сохраняется между запросами к сервлету. Это важное свойство сервлетов: так как только один сервлет определенного класса загружается в контейнер, и он никогда не выгружается (до тех пор, пока контейнер не завершит свою работу, что обычно случается только при перезагрузке серверного компьютера), любые поля сервлета этого класса действительно становятся постоянными объектами. Это значит, что вы можете без усилий сохранять значения между запросами к сервлету, в то время, как в CGI вы должны записывать значения на диск, чтобы сохранить их, что требует большого количества дурацкого окружения для правильного их получения, а в результате получаем не кроссплатформенное решение.

Конечно, иногда Web сервер, а таким образом и контейнер сервлетов, должны перегружаться, как часть ухода или во время пропадания питания. Для предотвращения потери любой постоянной информации методы сервлета init( ) и destroy( ) автоматически вызываются во время загрузки или выгрузки клиента, что дает вам возможность сохранить важные данные во время остановки и восстановления после перезагрузки. Контейнер сервлетов вызывает метод destroy( ) когда он завершает свою работу, так что вы всегда получаете возможность сохранить значимые данные до тех пор, пока серверная машина не будет сконфигурирована разумным способом.

Есть другая особенность при использовании HttpServlet. Этот класс обеспечивает методы doGet( ) и doPost( ), которые приспособлены для CGI «GET» пересылки от клиента и CGI «POST». GET и POST отличаются только деталями в способе пересылки данных, которые лично я предпочитаю игнорировать. Однако, большинство доступной информации, которую я видел, поддерживает создание раздельных методов doGet( ) и doPost( ), вместо единого общего метода service( ), который обрабатывает оба случая. Такое предпочтение кажется достаточно общим, но я никогда не видел объяснения, способного заставить меня поверить в то, что это не является наследием от CGI программистов, которые должны были учитывать имеют ли они дело с методом GET или POST. Так что действуя в духе «делать самые простые вещи, которые только могут работать», [5] я просто буду использовать метод service( ) в этом примере, и позволю этому методу заботится о выборе GET vs. POST. Однако, имейте в виду, что я могу что-то упустить, и что фактически может быть отличная причина для использования методов doGet( ) и doPost( ).

Когда бы форма не отсылалась сервлету, HttpServletRequest посупает со всеми предварительно загруженными данными формы, хранящимися как пары ключ-значение. Если вы знаете имя поля, вы можете просто использовать его напрямую в методе getParameter( ), чтобы найти значение. Вы можете также получить Enumiraton (старая форма Итератора) из имен полей, как показано в следующем примере. Этот пример также демонстрирует как один сервлет может быть использован для воспроизведения страницы, содержащей форму, и для страницы ответа (более хорошее решение вы увидите позже, в разделе о JSP). Если Enumiration пустое, значит нет полей; это означает, что форма не была отправлена. В этом случае производится форма, а кнопка подтверждения будет повторно вызывать тот же самый сервлет. Однако если поля существуют, они будут отображены.

//: c15:servlets:EchoForm.java
// Группа пар имя-значение любой HTML формы
//
import javax.servlet.*;

Your form contained:

Сервлеты и многопоточность (multithreading)

Контейнер сервлетов имеет пул нитей (thread), которые он будет диспетчеризировать для обработки запросов клиентов. Они вполне подходят для случая, когда два клиентских запроса поступают одновременно и должны одновременно обработаться вашим методом service( ). Поэтому метод service( ) должен быть выполнен безопасным для многопоточности способом. Любой доступ к общим ресурсам (файлам, базам данных) должен быть гарантировано использоваться с ключевым словом synchronized.

//: c15:servlets:ThreadServlet.java
//
import javax.servlet.*;

public class ThreadServlet extends HttpServlet <
int i;

Finished » + i++ + «

Также возможно синхронизировать весь сервлет, поместив ключевое слово synchronized перед методом service( ). Фактически, есть только одна причина использовать выражение synchronized, если есть критическая секция в ходе выполнения, которая может быть не выполнена. В этом случае, вы можете предотвратить накладные расходы на каждую синхронизацию в блоке с помощью использования выражения synchronized. С другой стороны, все нити все равно будут ожидать, так что вы можете точно так же синхронизировать весь метод.

Обработка сессий с помощью сервлетов

HTTP является сессионным протоколом, так что вы не можете общаться из одного обращения к серверу с другим обращением, не зависимо от того, одна и та же персона опрашивает ваш сайт, или это полностью разные персоны. Большое усилие было вложено в механизм, который позволяет Web разработчику отслеживать сессии. Компании не смогли бы заниматься электронной коммерцией без отслеживания клиента и элементов, которые он положил в свою корзину покупок, например.

Есть несколько методов отслеживания сессии, но наиболее общим методом состоит в постоянстве «cookies», которые являются внутренней частью стандарта Интернет. HTTP Working Group of the Internet Engineering Task Force вписала cookies в официальный стандарт RFC 2109 (ds.internic.net/rfc/rfc2109.txt или проверьте www.cookiecentral.com).

Класс Cookie

API сервлета (версия 2.0 и следующие) обеспечивают класс Cookie. Этот класс встроен во все детали HTTP заголовков и позволяет устанавливать различные атрибуты cookie. Использование cookie достаточно просто: необходимо позаботиться о добавлении его в объект ответа. Конструктор принимает имя cookie в качестве первого аргумента и значение в качестве второго. Cookie добавляются в объект ответа прежде, чем вы посылаете какое либо содержимое.

Cookie получаются назад с помощью метода getCookies( ) объекта HttpServletRequest( ), который возвращает массив объектов cookie.

Затем вы можете вызвать getValue( ) для каждого cookie, чтобы получить стоку содержимого cookie. В приведенном выше примере метод getValue(«TIJava») произведет строку, содержащую «2002».

Класс Session

Объект сессии сервлета живет на серверной стороне коммуникационного канала; его целью является сбор полезных данных об этом клиенте, таких как перемещение клиента по сайту и взаимодействие с вашим Web сайтом. Эти данные могут относиться к текущей сессии и являться, например, элементами в корзине покупок, или это могут быть такие данные, как информация об авторизации, которая была введена клиентом при первом обращении к вашему Web сайту и поэтому ее не нужно вводить еще раз во время определенного набора транзакций.

Класс Session API сервлета использует класс Cookie, чтобы выполнить эту работу. Однако все объекты Session нуждаются в уникальном идентификаторе определенного рода, хранящемся у клиента и передающемся на сервер. Web сайты могут также использовать другие типы отслеживания сессии, но этот механизм будет более сложным для реализации, так как он не встроен в API сервлета (то есть, вы должны написать его руками, обработав ситуации, когда клиент отключает cookies).

Вот пример, который реализует отслеживание сессии с помощью API сервлета:

//: c15:servlets:SessionPeek.java
// Используем класс HttpSession.
//
import java.io.*;

public class SessionPeek extends HttpServlet <
public void service ( HttpServletRequest req, HttpServletResponse res )
throws ServletException, IOException <
// Получаем объект Session до любой
// посылки клиенту.
HttpSession session = req.getSession () ;
res.setContentType ( «text/html» ) ;
PrintWriter out = res.getWriter () ;
out.println ( » SessionPeek » ) ;
out.println ( » » ) ;
out.println ( «

SessionPeek

» ) ;
out.println ( «Saved Session Data

Session Statistics

» ) ;
out.println ( «Session ID: » + session.getId () + «
» ) ;
out.println ( «New Session: » + session.isNew () + «
» ) ;
out.println ( «Creation Time: » + session.getCreationTime ()) ;
out.println ( » (» + new Date ( session.getCreationTime ()) + «)
» ) ;
out.println ( «Last Accessed Time: » + session.getLastAccessedTime ()) ;
out.println ( » (» + new Date ( session.getLastAccessedTime ())
+ «)
» ) ;
out.println ( «Session Inactive Interval: »
+ session.getMaxInactiveInterval ()) ;
out.println ( «Session ID in Request: » + req.getRequestedSessionId ()
+ «
» ) ;
out.println ( «Is session id from Cookie: »
+ req.isRequestedSessionIdFromCookie () + «
» ) ;
out.println ( «Is session id from URL: »
+ req.isRequestedSessionIdFromURL () + «
» ) ;
out.println ( «Is session id valid: » + req.isRequestedSessionIdValid ()
+ «
» ) ;
out.println ( » » ) ;
out.close () ;
>

public String getServletInfo () <
return «A session tracking servlet» ;
>
> // /:

Внутри метода service( ) метод getSession( ) вызывается для объекта запроса, который возвращает объект Session, ассоциированный с этим запросом. Объект Session не посылается по сети, вместо этого он живет на сервере и ассоциируется с клиентом и его запросом.

getSession( ) существует в двух версиях: без параметра, как использовано здесь, и getSession(boolean). getSession(true) эквивалентно вызову getSession( ). Причина для булевского значения состоит в объявлении состояния, с которым вы хотите создать объект сессии, если он не найден. getSession(true) более желательный вызов, отсюда появилась версия getSession( ).

Объект Session, если он не новый, может дать нам детальную информацию о клиенте, взяв ее из предыдущих визитов. Если объект Session новый, то программа начнет собирать информацию об активности этого клиента в этом визите. Сбор этой информации о клиенте выполняется с помощью методов setAttribute( ) и getAttribute( ) объекта сессии.

Объект Session использует простые пары имя-значение для загрузки информации. Имя является строкой, а значение может быть любым объектом, наследованным от java.lang.Object. SessionPeek следит за там, сколько раз клиент возвращался назад во время этой сессии. Это выполняется с помощью объекта Integer, называемого sesspeek.cntr. Если име не найдено, создается Integer со значением равным единице, в противном случае Integer создается с инкрементированным значением по сравнению с предыдущим сохраненным Integer. Новый Integer помещается в объект Session. Если вы используете тот же самый ключ в вызове setAttribute( ), то новый объект переписывает старый. Инкрементированный счетчик используется для отображения количества визитов клиента во время этой сессии.

getAttributeNames( ) имеет отношение к getAttribute( ) и setAttribute( ); он возвращает перечисление имен объектов, которые включены в объект Session. Цикл while в SessionPeek показывает этот метод в действии.

Вы можете удивиться, как долго хранится объект Session. Ответ зависит от контейнера сервлетов, который вы используете; обычно, по умолчанию, это 30 минут (1800 секунд), что вы можете увидеть из вызова метода getMaxInactiveInterval( ) в ServletPeek. Тесты могут воспроизводить разные результаты в зависмиости от контейнера сервлетов. Иногда объект Session может храниться всю ночь, но я никогда не видел случая, когда объект Session исчезал в течение времени меньшего, чем указано в интервале не активности. Вы можете попробовать путем установки интервала не активности с помощью метода setMaxInactiveInterval( ) в значение 5 секунд и посмотреть, останется ли ваш объект Session или он будет очищен в соответствующее время. Это может стать атрибутом, который вы захотите исследовать при выборе контейнера сервлетов.

Запуск примеров сервлета

Если вы еще не работали с Сервером приложений, который обрабатывает сервлеты Sun и JSP технологию для вас, вы можете загрузить Tomcat реализацию Java сервлетов и JSP, которая является бесплатной реализацией с открытыми исходниками, санкционированная Sun. Tomcat можно найти на jakarta.apache.org.

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

Заключение

Это была только короткая интродукция в сервлеты; есть целые книги, посвещенные этой теме. Однако это введение должно дать вам достаточно мыслей, чтобы начать. Кроме того, многие мысли следующего раздела имеют обратную совместимость с сервлетами.

Источник

Учебник по сервлетам – Java

Учебник по сервлетам. Учебник по сервлетам Java для начинающих. CGI против сервлета. Пример Проекта Входа в Сервлет. Иерархия Сервлетов. Сервлет 3 Аннотации, Атрибуты

Учебник по сервлетам

Учебник по сервлету направлен на предоставление более подробной информации о сервлете java, основных интерфейсах в API сервлета Java, аннотациях сервлета 3.0, жизненном цикле сервлета, и в конце мы создадим простое приложение для примера сервлета входа.

Учебник по сервлетам – Обзор

Сервлет-это управляемая сервером Java EE технология для создания веб-приложений на java. Пакеты javax.servlet и javax.servlet.http предоставляют интерфейсы и классы для написания наших собственных сервлетов.

В большинстве случаев доступ к веб-приложениям осуществляется по протоколу HTTP, и именно поэтому мы в основном расширяем класс HttpServlet.

Общий интерфейс шлюза (CGI)

До внедрения Java Servlet API технология CGI использовалась для создания динамических веб – приложений. Технология CGI имеет множество недостатков, таких как создание отдельного процесса для каждого запроса, код, зависящий от платформы (C, C++), высокое использование памяти и низкая производительность.

CGI против сервлета

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

Иерархия API сервлетов

javax.сервлет.Сервлет является базовым интерфейсом API сервлета. Существуют некоторые другие интерфейсы и классы, о которых мы должны знать при работе с сервлетами. Также в спецификациях Servlet 3.0 API servlet ввел использование аннотаций, а не всю конфигурацию сервлета в дескрипторе развертывания. В этом разделе мы рассмотрим важные интерфейсы API сервлетов, классы и аннотации, которые мы будем использовать в дальнейшем при разработке нашего приложения. На приведенной ниже диаграмме показана иерархия API сервлетов.

Интерфейс Сервлета

Интерфейс ServletConfig

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

Важными методами интерфейса ServletConfig являются:

Интерфейс ServletContext

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

Некоторые из важных методов ServletContext являются:

Примечание : В идеале имя этого интерфейса должно быть ApplicationContext, потому что оно предназначено для приложения и не относится к какому-либо сервлету. Также не путайте его с контекстом сервлета, переданным в URL-адресе для доступа к веб-приложению.

Интерфейс ServletRequest

Интерфейс ServletRequest используется для предоставления информации о запросе клиента сервлету. Контейнер сервлета создает объект ServletRequest из запроса клиента и передает его методу servlet service() для обработки.

Некоторые из важных методов интерфейса ServletRequest являются:

Интерфейс ответа сервлету

Интерфейс ServletResponse используется сервлетом при отправке ответа клиенту. Контейнер сервлета создает объект ServletResponse и передает его методу servlet service (), а затем использует объект response для создания HTML-ответа для клиента.

Некоторые из важных методов в HttpServletResponse являются:

Интерфейс диспетчера запросов

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

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

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

Класс GenericServlet

Одним из важных методов в классе GenericServlet является метод без аргумента init (), и мы должны переопределить этот метод в нашей программе сервлета, если нам нужно инициализировать некоторые ресурсы перед обработкой любого запроса от сервлета.

Класс HttpServlet

HttpServlet-это абстрактный класс, который расширяет GenericServlet и обеспечивает основу для создания веб-приложений на основе HTTP. Существуют методы, определенные для переопределения подклассами для различных методов HTTP.

Атрибуты Сервлета

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

Аннотации в сервлете 3

До сервлета 3 все отображение сервлета и его параметры инициализации использовались для определения в web.xml, это было неудобно и более подвержено ошибкам, когда в приложении огромное количество сервлетов.

Сервлет 3 представил использование аннотаций java для определения сервлета, фильтра и прослушивателя сервлетов и параметров инициализации.

Некоторые из важных аннотаций сервлета являются:

Примечание: Мы рассмотрим фильтры и прослушиватели сервлетов в будущих статьях, в этой статье мы сосредоточимся на изучении базовых интерфейсов и классов API сервлетов.

Пример входа в сервлет Java

Теперь мы готовы создать наш пример сервлета входа в систему, в этом примере я буду использовать простой HTML, JSP и сервлет, который будет проверять подлинность учетных данных пользователя. Мы также увидим использование параметров инициализации ServletContext, атрибутов, параметров инициализации ServletConfig и функции RequestDispatcher, включая() и использование функции sendRedirect ().

Наш окончательный Динамический веб-проект будет выглядеть так, как показано на рисунке ниже. Я использую Eclipse и Tomcat для приложения, процесс создания динамического веб-проекта представлен в Веб-приложениях Java учебник.

Вот наша HTML-страница входа в систему, мы поместим ее в список файлов приветствия в web.xml так что, когда мы запустим приложение, оно откроет страницу входа в систему.

Если вход в систему будет успешным, пользователю будет представлена новая страница JSP с сообщением об успешном входе в систему. Код страницы JSP выглядит так, как показано ниже.

Вот это web.xml файл дескриптора развертывания, в котором мы определили параметры инициализации servletcontext и страницу приветствия.

Вот наш последний класс сервлета для аутентификации учетных данных пользователя, обратите внимание на использование аннотаций для конфигурации сервлета и параметров инициализации ServletConfig.

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

Это все для руководства по сервлетам для начинающих, в следующем уроке мы рассмотрим Управление сеансами, фильтры сервлетов и прослушиватели.

Источник