Файл містить простий HTML з парочкою доповнень. Ось вона, принадність JSP в поєднанні з JSTL і JEL. Зверніть увагу на те, як легко перевірити наявність помилок валідації, використовуючи такі стандартні теги, як<с:if>і .

Атрибут форми реєстрації action вказує на наступний URL: $ (pageContext.request.contextPath) / processcustomer. Це означає, що кожен раз, коли клієнт намагається зареєструватися, дані будуть відправлятися в processcustomer незалежно від URL, за яким доступна форма. Це досягається за рахунок функціональності об'єктів, доступних з JSP-файлу, таких як request.

Скоро ми побачимо, як сервлет зв'язується з URL processcustomer і як він взаємодіє з введеними даними. А поки давайте подивимося на JSP-файл, який відповідає за сторінку вітання:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Дякую за реєстрацію!

Ваші введені дані:

ім'я:$ (Firstname)

Прізвище:$ (Lastname)

Email:$ (Email)

Тепер, коли ми розібралися з відображенням сторінок, наступним кроком буде створення сервлету, відповідального за збір даних клієнта з POST-запитів і підтвердження даних простим способом.

пишемо контролер

Написати сервлет, здатний отримати дані з форми реєстрації, простіше простого. Все, що нам потрібно зробити, - це написати підклас для класу HttpServlet і реалізувати його методи doGet () або doPost () (або обидва, якщо треба). В даному випадку сервлет буде взаємодіяти з даними, які надходять з POST-запитів.

Ось як він виглядає:

@WebServlet (name = "CustomerController", urlPatterns = "/ processcustomer") public class CustomerController extends HttpServlet (@Override protected void doPost (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException (RequestCustomer customer = RequestCustomer.fromRequestParameters (request); customer .setAsRequestAttributes (request); List violations = customer.validate (); if (! violations.isEmpty ()) (request.setAttribute ( "violations", violations);) String url = determineUrl (violations); request.getRequestDispatcher (url ) .forward (request, response);) private String determineUrl (List violations) (if (! violations.isEmpty ()) (return "/";) else (return "/WEB-INF/views/customerinfo.jsp"; )) private static class RequestCustomer (private final String firstName; private final String lastName; private final String email; private RequestCustomer (String firstName, String lastName, String email) (this.firstName = firstName; th is.lastName = lastName; this.email = email; ) Public static RequestCustomer fromRequestParameters (HttpServletRequest request) (return new RequestCustomer (request.getParameter ( "firstname"), request.getParameter ( "lastname"), request.getParameter ( "email"));) public void setAsRequestAttributes (HttpServletRequest request) (request.setAttribute ( "firstname", firstName); request.setAttribute ( "lastname", lastName); request.setAttribute ( "email", email);) public List validate () (List violations = new ArrayList<>(); if (! StringValidator.validate (firstName)) (violations.add ( "Ім'я є обов'язковим полем");) if (! StringValidator.validate (lastName)) (violations.add ( "Прізвище є обов'язковим полем");) if ( ! EmailValidator.validate (email)) (violations.add ( "Email повинен бути правильно сформований");) return violations; )))

Перше, на що тут варто звернути увагу, - використання анотації @WebServlet (name = "CustomerController", urlPatterns = "/ processcustomer"). Вона каже контейнеру сервлету використовувати клас CustomerController для обробки HTTP-запитів за адресою / processcustomer. Того ж ефекту можна досягти шляхом додавання директив зіставлення сервлетів в web.xml, як, але так як ми використовуємо Servlet Specification 3.1 нам немає необхідності вдаватися до такого способу.

Тут ми назвали сервлет CustomerController, так як вважається хорошою практикою використовувати ім'я класу сервлета в якості значення атрибута name анотації @WebServlet. В іншому випадку деякі контейнери не зможуть виконати зіставлення, що призведе до помилки 404.

Сам клас CustomerController виконує кілька простих завдань. По-перше, він збирає введені в форму дані, використовуючи реалізацію інтерфейсу HttpServletRequest, який містить значення, відповідні полях firstname, lastname і email форми. Потім він встановлює ці значення в якості атрибутів запиту, тому їх можна повторно відобразити або у формі, або на сторінці з результатами. Нарешті, валідатори перевіряють правильність введених даних.

Валідатори - це прості класи, які перевіряють певні властивості, наприклад, чи є рядок порожній і виглядає чи email як email. На GitLab автора можна подивитися на їх реалізацію.

Результат валідації впливає на подальший хід подій: якщо дані не валідність, клієнт перенаправляється через об'єкт RequestDispatcher на сторінку реєстрації, де відображаються відповідні помилки. Якщо все в порядку, то відображається сторінка вітання.

Отже, ми створили ціле веб-додаток на Java, яке дозволяє зареєструвати клієнтів за допомогою HTML-форми, базового сервлету і декількох JSP-файлів. Пора його запустити.

запускаємо програму

Для запуску програми потрібно виконати наступні кроки:

IntelliJ IDEA). Коли ви розгорнете проект і запустіть його, повинен запуститися бразуер за замовчуванням з вікном реєстрації.

висновок

Отже, ви придбали всі навички, необхідні для створення власного веб-додатки на Java без необхідності вдаватися до складних фреймворками. Все, що вам потрібно, - Servlet API, технологія начебто JSP для відображення і вбудовані засоби Java. Здорово, правда?

Варто зазначити, що реалізація класу CustomerController підкреслює достоїнства і недоліки сервлетів: з одного боку, він коротко показує, наскільки легко обробляти параметри запиту та відправляти відповіді клієнту в різних форматах. Але ця функціональність має свою ціну: обидві реалізації інтерфейсів HttpServletResponse і HttpServletResponse є звичайними локаторами служб. Не можна сказати, що це погано, оскільки локатори просто містять дані. Однак потрібно пам'ятати, що ці реалізації будуть завжди прив'язані до сервлету.

Сервлети (Servlets) - це java-програми, які виконуються на стороні сервера Web-додатки. Точно так же, як аплети динамічно розширюють функціональні можливості Web-браузера, сервлети динамічно розширюють функціональні можливості Web-сервера. Хоча сервлети можуть обслуговувати будь-які запити, вони зазвичай використовуються для розширення веб-серверів. Для таких додатків технологія Java Servlet визначає HTTP-специфічні сервлет класи. Пакети javax.servlet і javax.servlet.http забезпечують інтерфейси і класи для створення сервлетів.

• Яка структура веб-проекту?

• Що таке контейнер сервлетів? Життєвий цикл сервлета.

Контейнер сервлетов - програма, що управляє життєвим циклом сервлетів.
Життєвий цикл сервлета: ним керує контейнер сервлетів, при першому зверненні до сервлету відбувається його завантаження в пам'ять і викликається метод init (). Протягом роботи програми відбуваються виклики методи service () для обробки запитів клієнта. По завершенню роботи програми викликається метод destroy () і сервлет вивантажується з пам'яті.

• Які завдання, функціональність контейнера сервлетів?

Контейнер сервлетов може працювати як повноцінний самостійний веб-сервер, бути постачальником сторінок для іншого веб-сервера, наприклад Apache, або інтегруватися в Java EE сервер додатків. Забезпечує обмін даними між сервлетом і клієнтами, бере на себе виконання таких функцій, як створення програмного середовища для функціонуючого сервлету, ідентифікацію та авторизацію клієнтів, організацію сесії для кожного з них.

• Чим відрізняється sendRedirect () від forward ()?

Що таке сервлети? Сервлети, фактично, це модулі обробки HTTP і FTP запитів, які використовуються для побудови порталів (web gates).

Основою цих порталів є власне WEB сервер - програма, яка тримає сокет сервера, приймає і передає дані. Найчастіше, для прискорення роботи, сервер буває написаний не на Java, а на будь-якому іншому мовою програмування (наприклад на C ++).

У зв'язці з сервером працює базовий сервлет. Саме йому відправляє сервер дані і від нього ж отримує відповідь, що відправляється клієнтові. Фактично, базовий сервлет є "мозком" сервера. Основна функція цього сервлета - прочитати запит клієнта, розшифрувати його і, в соответствиии з розшифровкою, передати роботу сервлету, відповідальному за цей тип запитуваної інформації. Найчастіше, для досягнення швидкості, роль базового сервлету грає сам сервер. Саме за такою схемою працює, скажімо, Jacarta Tomcat.

На малюнку зображена схема передачі викликів (request) і відповідей (response) між сервером і Сервлетами. Дана схема зображує роботу HTTP сервера, який має кілька JSP сторінок і два ресурси "/ sample1" і "/ sample2", за обробку яких відповідає два сервлету - "Sample1 Servlet" і "Sample2 Servlet" відповідно.

Розберемо покроково те, що зображено на малюнку:

1. клієнт під'єднується до сервера
2. сервер передає запит (request) базового сервлету ( "Basic Servlet")
3. базовий сервлет вичеленяет із запиту URI ресурсу
   • якщо URI вказує на "/ sample1", то запит цілком(Без змін) передається сервлету "Sample1 Servlet", який, в подальшому, і обробляє цей запит
   • якщо URI вказує на "/ sample2", сервер передає запит сервлету "Sample2 Servlet"
   • у всіх інших випадках запит передається модулю "JSP Servlet"
4. сервлет, якому було передано управління, обробляє дані, створює відповідь (response), після чого відповідь відсилається назад базовому сервлету.
5. базовий сервлет, що не обробляючи отримані дані, тут же пересилає їх назад сервера
6. сервер видає дані клієнта

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

інтерфейс Servlet

Об'єднує всі ці модулі то, що вони наскрізним чином пов'язані між собою за допомогою інтерфейсу javax.servlet.Servlet

Подивимося на цей інтерфейс. У ньому зазначено всього 5 методів:

Public void init (ServletConfig config) throws ServletException Цей метод викликається, щоб проінформувати сервлет про те, що він включений як модуль для обслуговування запитів клієнта. Параметр config розділяє інтерфейс javax.servlet.ServletConfig, що несе інформацію про оточення сервера, імені сервлету, початкових параметрах і інших плюшках. Про інтерфейсі javax.servlet.ServletConfig буде розказано трохи далі. Передбачається, що після виклику цієї функції, сервлет акуратно збереже цей config у себе в змінної і видаватиме його за допомогою іншого методу: public ServletConfig getServletConfig () Отримавши системну інформацію за допомогою "getServletConfig ()", сервер може захотіти дізнатися ім'я автора, дату створення, іншу інформацію про сервлет, що і досягається викликом public String getServletInfo ()

Щоб обробити запит і отримати результат його обробки, використовується функція

Public void service (ServletRequest request, ServletResponse response) throws ServletException, java.io.IOException У цій функції коду, який буде обробляти дані, передаються два інструменти: один - для отримання даних від сервера, інший - для відправки результату роботи сервлета. Відповідно це параметри request і response, що розділяють інтерфейси javax.servlet.ServletRequest і javax.servlet.ServletResponse Вся робота з даними ведеться саме через ці інтерфейси, так що далі поговоримо про них докладніше.

Після того, як сервер перестав мати потребу в цьому модулі викликається метод

Public void destroy () який і завершує всі операції з об'єктом сервлету.

інтерфейс ServletConfig

4 методу, імена яких говорять самі за себе, складають суть інтерфейсу javax.servlet.ServletConfig:

Public String getServletName () public ServletContext getServletContext () public String getInitParameter (String name) public java.util.Enumeration getInitParameterNames ()

Думаю, призначення всіх функція зрозуміло, крім

Public ServletContext getServletContext () Цей метод повертає посилання на дуже корисний інструмент для роботи з сервером:

інтерфейс ServletContext

ServletContext - інтерфейс, який визначає доступ до наступних полезнейшим функцій:

Public Object getAttribute (String name) public java.util.Enumeration getAttributeNames () public void setAttribute (String name, Object object) public void removeAttribute (String name) Чотири методи для роботи з атрибутами. Роль аттрибутов виконує будь-який об'єкт будь-якого класу. Мета даних функцій - пересилати між непов'язаними між собою Сервлетами різні об'єкти. public String getInitParameter (String name) public java.util.Enumeration getInitParameterNames () Доступ до параметрів, з якими був запущений сервер. Тут же можуть лежати ім'я хоста, порт і інші корисності. public int getMajorVersion () public int getMinorVersion () Повертає версії Servlet API. public String getMimeType (String file) Повертає MIME тип асоційований з файлом, шлях до якого вказаний у змінній file. Згадайте, як довелося визначати MIME в програмі SimpleWEBServer і оціните зручність! public java.util.Set getResourcePaths () public java.net.URL getResource (String path) throws java.net.MalformedURLException public InputStream getResourceAsStream (String path) Повертає шляху до доступним для сервера ресурсів і самі ресурси у вигляді URL і у вигляді потоків даних. public RequestDispatcher getRequestDispatcher (path) public RequestDispatcher getNamedDispatcher (name) RequestDispatcher - це інструмент для того, щоб переслати запит іншого ресурсу. Ці функції потрібні, щоб отримати об'єкт цього інструменту для зазначених ресурсів. Тобто, скажімо, для того, щоб перенаправити запит сервлету "sample1" з тіла сервлету, можна зробити так: getServletConfig (). GetServletContext (). GetNamedDispatcher ( "sample1"). Forward (request, response);

Власне клас RequestDispatcher включає в себе лише два методи:

Public void forward (ServletRequest request, ServletResponse response) throws ServletException, java.io.IOException public void include (ServletRequest request, ServletResponse response) throws ServletException, java.io.IOException Причому перший - для перенаправлення запиту, а другий - для включення результату роботи викликається сервлету в результат роботи поточного. Наприклад, сервлет 1 друкує слово "test 1", потім викликає include для сервлета два, після чого друкує слово "test 2". Сервлет 2 ж просто друкує слово "and". Результатом роботи сервлета 1 буде рядок "test 1 and test 2". public void log (String msg) Записати щось в лог сервера. public void log (String message, Throwable throwable) Визначити виняток і фразу, яка буде записуватися в лог після отримання цього винятку. public String getRealPath (String path) Перекладає шлях типу "/index.html" в "http: //host/contextPath/index.html" public String getServerInfo () Повертає ім'я сервера. public ServletContext getContext (String uripath) Цей метод дозволяє обмінюватися ServletContext між різними ресурсами одного і того ж сервера. public String getServletContextName () Повертає ім'я сервлета, якому належить даний об'єкт інтерфейсу ServletContect.

інтерфейс ServletRequest

Інтерфейс ServletRequest - це інструмент для отримання параметрів HTTP запиту. Цей інтерфейс має деякі методи, ідентичні за назвою і призначенням з ServletContext:

Public Object getAttribute (String name) public java.util.Enumeration getAttributeNames () public void setAttribute (String name, Object o) public void removeAttribute (java.lang.String name) public String getServerName () public RequestDispatcher getRequestDispatcher (String path)

Оставш методи дозволяють із зручністю працювати з HTTP заголовком запиту:

Public String getCharacterEncoding () public void setCharacterEncoding (String env) throws java.io.UnsupportedEncodingException Робота з кодуванням символів у полях HTTP заголовка. Функції задають метод розшифровки CGI запитів з форми% NN в звичайні символи. Наприклад, який стандарт - KOI8-R, windows-1251 або UTF-8 потрібно застосувати для розшифровки кириличних символів. public int getContentLength () public String getContentType () Читає поля "Content-Length", "Content-Type" з HTTP запиту. public jString getParameter (String name) public java.util.Enumeration getParameterNames () public String getParameterValues ​​(String name) public java.util.Map getParameterMap () Функції для отримання поля з HTTP заголовка і його значення. public ServletInputStream getInputStream () throws java.io.IOException public java.io.BufferedReader getReader () throws java.io.IOException Отримати вхідний потік даних або його "читач". Reader застосовується для читання текстової інформації - він автоматично розшифрує рядки відповідно до заданого charset. Увага!У версії J2EE 1.3 є істотний баг: при розшифровці символу% 25 (символ% в Post і Get запитах) Reader видає помилку (баг помічений на серверах Tomcat 4 і Resign). Можливо, що схожий баг є і з іншими символами. public String getProtocol () Отримати версію HTTP протоколу запиту (наприклад - "HTTP / 1.1"). public String getScheme () Возвращяет ім'я схеми запиту. Наприклад "http", "https", або "ftp". public int getServerPort () public String getRemoteAddr () public String getRemoteHost () public boolean isSecure () Порт сервера, IP адреса клієнта, ім'я хоста клієнта і чи є з'єднання скретним (по протоколу HTTPS) public java.util.Locale getLocale () public java.util.Enumeration getLocales () Бажаний клієнтом мову документа (результат обробки поля "Accept-Language")

інтерфейс ServletResponse

Інтерфейс ServletResponse - це інструмент для відправки даних клієнта. Всі методи даного інструменту служать саме цієї мети:

Public java.lang.String getCharacterEncoding () public void setLocale (java.util.Locale loc) public java.util.Locale getLocale () Перший метод повертає MIME тип кодування (наприклад - UTF8), в якій буде видаватися інформація. Другі два методу теж працюють з charset. Вони вказують на мову використовуваний в документі (наприклад - російська). public ServletOutputStream getOutputStream () throws java.io.IOException Повертає потік виведення даних для сервлета. Цей потік використовується, наприклад, для виведення бінарних файлів. Текстові дані можна виводити за допомогою java.io.Writer: public java.io.PrintWriter getWriter () throws java.io.IOException Цей метод автоматично конвертує рядки в той charset, що зазначений в методі getCharacterEncoding () і getLocale (). public void setContentLength (int len) Цим методом встановлюється значення поля HTTP заголовка "Content-Length" public void setContentType (String type) Метод для відправки MIME типу вмісту документа. Поле HTTP заголовка "Content-Type". public void setBufferSize (int size) public int getBufferSize () public void flushBuffer () throws java.io.IOException public void resetBuffer () Справа в тому, що потік виведення даних є буфферізованним. Це означає, що наступна порція даних буде видана клієнту тільки після заповнення буфера. Зазначені методи дозволяють, відповідно, встановити розмір буферу відправки, отримати його розмір, форматувати відправку вміст буферу клієнту, не чекаючи його заповнення, а так само очистити цей буффер від даних. public boolean isCommitted () Цим методом можна отримати прапор, розпочато чи вже відправка даних клієнта. Прапор буде позитивним, якщо HTTP заголовок відповіді був уже відправлений. public void reset () Якщо HTTP заголовок ще не відправлений, то цей метод "скидає" HTTP заголовок до значень "за замовчуванням".

Зумовлені типи сервлетів

Java Servlet API, крім власне інтерфейсів, так само містить кілька класів сервлетів, які можуть служити основою для ваших програм.

Базовим для всіх цих класів є абстрактний клас javax.servlet.GenericServlet:

Public abstract class GenericServlet implements Servlet, ServletConfig, java.io.Serializable

Як видно з визначення цього класу, він має всі методи інтерфейсів Servlet і ServletConfig. Чи не реалізованим методом залишився тільки

Public abstract void service (ServletRequest req, ServletResponse res) throws ServletException, java.io.IOException який і був оголошений абстрактним.

На базі цього класу був створений інший абстрактний клас - javax.servlet.http.HttpServlet:

Public abstract class HttpServlet extends GenericServlet implements java.io.Serializable

Створено цей клас був відповідно до концепції "ще більше зручностей для програміста" і має багато корисних методів:

Protected void doDelete (HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doGet (HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doHead (HttpServletRequest req, HttpServletResponse resp) throws ServletException, java .io.IOException protected void doOptions (HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doPost (HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doPut (HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doTrace (HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void service (HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void service (ServletRequest req , ServletR esponse res) throws ServletException, java.io.IOException Різні варіанти service (ServletRequest req, ServletResponse res) для різних HTTP методів від DELETE і GET до PUT і TRACE. А щоб зі зручністю отримувати дані по CGI інтерфейс не расшіфровививая заголовок були створені класи HttpServletRequest і HttpServletResponse, що входять разом з HttpServlet в пакет javax.servlet.http protected long getLastModified (HttpServletRequest req) Цей метод повертає час останньої модифікації об'єкта HttpServletRequest. Значення часу він бере з поля "Date" HTTP заголовка запиту. Якщо ж поле не виявлено, то повертає -1.

Відповідно розберемо і інтерфейси HttpServletRequest і HttpServletResponse. Вони є спадкоємцями відповідно ServletRequest і ServletResponse.

HttpServletRequest крім методів, успадкованих від ServletRequest, має так само наступні полезнейшие методи:

Cookie getCookies () Повертає набір куків, надісланих клієнтом серверу.

Клас Cookie, що входить в той же пакет javax.servlet.http, містить всю можливу інформацію про Кука. Найважливішими методами цього класу є

Int getMaxAge () String getName () String getValue () видають, відповідно, скільки ще часу цього куку залишилося жити, ім'я кука і його значення. Так само Cookie (String name, String value) void setValue (String newValue) void setMaxAge (int expiry) для створення кука, установки його значення і максимального віку. long getDateHeader (String name) Повертає дату з HTTP заголовка, якщо така є. int getIntHeader (java.lang.String name) Повертає числове значення поля з ім'ям name з HTTP заголовка запиту String getMethod () Повертає метод HTTP запиту. String getQueryString () String getRequestURI () StringBuffer getRequestURL () Повертає рядок, що міститься в URL документа після символу "?", URI документа і повний URL. HttpSession getSession () HttpSession getSession (boolean create) boolean isRequestedSessionIdFromCookie () boolean isRequestedSessionIdFromURL () boolean isRequestedSessionIdValid () Функції. що дозволяють працювати з таким найважливішим механізмом передачі даних, як сесії.

Сесії необхідні для того, щоб тягати за користувачем дані з сторінки в сторінку. Наприклад, користувач заходить на сторінку (1), де йому відправляються деякі дані для сторінки (2), а та зберігає ще якісь речі для сторінки (3).

Впринципі, на сторінці (1) можна вислати дані користувачеві, потім отримати їх на сторінці (2), додати щось, вислати користувачеві ... Подібним чином доведеться постійно пересилати весь набір даних від клієнта серверу і назад, причому багато разів. Крім того, що така пересилання не завжди зручна, вона ще й пожирає трафік.

Можна так само вчинити інакше - використовувати механізм сесій. Механізм цей працює наступним чином: дані, надіслані користувачем, сервер зберігає в окремому файлі - файлі сесії. З вмістом цього файлу і буде проводитися вся робота по зміні даних. Клієнту ж видається "ключ сесії" (він же Session key, він же Sesseion ID) - унікальний покажчик на файл, який містить дані конкретно для цього користувача. Тепер для того, щоб отримати всі дані, що стосуються цього клієнта, сервера необхідно знати лише ключ сесії. Перевагою цього методу є зручність і швидкість його використання.

Ось і всі основні методи інтерфейсу HttpServletRequest. Повний список методів читайте в документації до Java Servlet API.

Тепер про інтерфейс HttpServletRequest. Основна відмінність класів, які поділяють даний интерфес, в тому, що дані виводяться не відразу. Спочатку відбувається комплектація всіх даних в HTTP відповідь. Відповідь відправляється тільки після завершення роботи HttpServlet.service ().

І так, про методи:

Void addHeader (String name, String value) void addIntHeader (String name, int value) void addDateHeader (String name, long date) Методи додають в HTTP заголовок параметри. Останній метод встановлює параметр "Date". void addCookie (Cookie cookie) Метод додає cookie в заголовок boolean containsHeader (String name) Дозволяє дізнатися, чи містить вже заголовок вказаний параметр. String encodeURL (String url) String encodeRedirectURL (String url) Перший метод кодує символи за допомогою заміни% NN. Другий метод робить те ж саме і викликає void sendRedirect (String location) void setStatus (int sc) void sendError (int sc) void sendError (int sc, String msg) Перший - встановлює код повернення, другі два - посилають повідомлення про помилку. В інтерфейсі задані наступні можливі помилки для параметра sc, що відповідають кодам повернення протоколу HTTP: SC_CONTINUE - Status code (100) SC_SWITCHING_PROTOCOLS - Status code (101) SC_OK - Status code (200) SC_CREATED - Status code (201) SC_ACCEPTED - Status code (202 ) SC_NON_AUTHORITATIVE_INFORMATION - Status code (203) SC_NO_CONTENT - Status code (204) SC_RESET_CONTENT - Status code (205) SC_PARTIAL_CONTENT - Status code (206) SC_MULTIPLE_CHOICES - Status code (300) SC_MOVED_PERMANENTLY - Status code (301) SC_MOVED_TEMPORARILY - Status code (302) SC_SEE_OTHER - Status code (303) SC_NOT_MODIFIED - Status code (304) SC_USE_PROXY - Status code (305) SC_BAD_REQUEST - Status code (400) SC_UNAUTHORIZED - Status code (401) SC_PAYMENT_REQUIRED - Status code (402) SC_FORBIDDEN - Status code (403) SC_NOT_FOUND - Status code (404) SC_METHOD_NOT_ALLOWED - Status code (405) SC_NOT_ACCEPTABLE - Status code (406) SC_PROXY_AUTHENTICATION_REQUIRED - Status code (407) SC_REQUEST_TIMEOUT - Statu s code (408) SC_CONFLICT - Status code (409) SC_GONE - Status code (410) SC_LENGTH_REQUIRED - Status code (411) SC_PRECONDITION_FAILED - Status code (412) SC_REQUEST_ENTITY_TOO_LARGE - Status code (413) SC_REQUEST_URI_TOO_LONG - Status code (414) SC_UNSUPPORTED_MEDIA_TYPE - Status code (415) SC_REQUESTED_RANGE_NOT_SATISFIABLE - Status code (416) SC_EXPECTATION_FAILED - Status code (417) SC_INTERNAL_SERVER_ERROR - Status code (500) SC_NOT_IMPLEMENTED - Status code (501) SC_BAD_GATEWAY - Status code (502) SC_SERVICE_UNAVAILABLE - Status code (503) SC_GATEWAY_TIMEOUT - Status code (504) SC_HTTP_VERSION_NOT_SUPPORTED - Status code (505)

Ось і все, що можна розповісти про HttpServletResponse

Використання сервлетів в WEB додатках

Поговоримо тепер про використання сервлетів в WEB додатках. Для цього я приведу два корисних прикладу, які можуть на практиці стати в нагоді.

Перший приклад показує методи роботи з HttpServlet і висновок вмісту HTML сторінки в стислому вигляді. За ідеєю, HTML сторінка у відповіді браузера виводиться прямим текстом, але, щоб скоротити обсяг даних, що пересилаються, можна використовувати стиснення GZIP. Сучасні браузери (принаймні браузери 4 покоління і вище) підтримують такий метод пересилання текстової інформації і виведуть сторінку так, як ніби-то її і не стискали.

Другий приклад показує, як засобами сервлету можна здійснити безперервний виведення сторінки. Такий тип виведення сторінок може використовуватися, наприклад, в чатах: щоб прочитати нові повідомлення, не потрібно буде кожен раз оновлювати сторінку, нові повідомлення будуть просто з часом докачувати. Потрібно врахувати, що деякі проксі-сервери не підтримують такий вид пересилання даних, але з цим - на жаль - нічого зробити не можна.

Залишилося сказати, що механізм сервлетів дуже пластичний і дозволяє творити такі речі, які могли б вимагати написання окремого WEB сервера (як, наприклад, в разі сервлету докачки). Мінусом роботи сервлетів є низька швидкість першого запуску (сервлет просто компілюється JIT машиною), висока поребленіе пам'яті і недолік всіх програм на Java - низька швидкість роботи з рядками. Остання обставина стає помітно при роботі сервлетів, які приймають текстові дані в POST запитах. POST запит в HttpServlet розміром в 50 кб при парсінгу за допомогою HttpServletRequest.getReader () може на пару хвилин паралізавать роботу сервера. Те саме можна сказати і до інших програм на java.

Наведу два невеликих прикладу:

Якщо взяти невеликі рядки - до 2-3 кб, то відмінності в роботі прикладів несуттєві, якщо ж взяти рядок text розміром хоча б в 10 кб, то в першому випадку програма буде працювати з рядком значно повільніше. Це є особливістю java і є проблемою реалізації функцій класу String. Так що якщо ви хочете написати швидкий сервлет, уникайте роботу з довгими рядками за допомогою класу String, використовуйте, наприклад, клас StringBuffer. Це попередження стосується перш за все до отримання великих текстів з мережі і до обробки локальних файлів (наприклад, в разі текстової бази даних для гостьової книги при великій кількості повідомлень).

Ще одна проблема стосується мультизадачности WEB системи. Не забувайте, що ваш сервлет можуть одночасно запросити відразу кілька користувачів. Часто виникають проблеми синхронізації даних, обміну даними між різними обчислювальними потоками одного і того ж сервлету, а сама часто зустрічається, - це проблема синхронного доступу до файлів та інших іменування ресурсів системи. Наприклад, одна програма відкрила файл на читання, а інша тим часом намагається туди щось писати. В результаті друга програма або отримує виняток, або чекає, поки файл звільниться для запису. У зв'язку з цим хочу звернути вашу увагу: не залишайте за собою незакритих потоків і закривайте потоки, як тільки в них відпала необхідність. Потік, звичайно, закриється пізніше автоматично, але це станеться тільки тоді, коли "сміттяр" до нього добереться, а між тим друга програма все так же не матиме доступу до файлу на запис.

Додатково до мультизадачности хочу відзначити, що за допомогою методів "Object getAttribute (String name)" і "void setAttribute (String name, Object object)" інтерфейсу ServletContext ви можете обмінюватися між Сервлетами даними, в тому числі і синхронізуючими.

Приклад сервлету включає сам сервлет HelloWorld.java і дескриптор додатки web.xml. Сервлет дозволяє формувати сторінку відповіді з використанням кирилиці. Структура прикладу сервлету в IDE Eclipse представлена ​​на наступному скріншоті.

Лістинг прикладу сервлету HelloWorld.java

Наведений нижче код реалізує простий сервлет HelloWorld.java, Який повертає статичну HTML-сторінку браузеру. У прикладі сервлет успадковує властивості HttpServlet, що реалізує інтерфейс Servlet.

Import java.io.IOException; import java.io.OutputStream; import javax.servlet.ServletConfig; import javax.servlet.http.HttpServlet; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class HelloWorld extends HttpServlet (private ServletConfig config; @Override public void init (ServletConfig config) throws ServletException (this.config = config;) @Override public void destroy () () @Override public ServletConfig getServletConfig () (return config;) @Override public String getServletInfo () (return "A Simple Servlet";) public void service (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException (response.setContentType ( "text / html"); String text = " " + "" + " " + "" + "" + "" + "

Здрастуй,% s% s!

При зверненні до сервлету викликається метод service, Який формує сторінку відповіді і передає її в браузер через HttpServletResponse. У перших рядках відповіді сервера визначено заголовок Content-Typeіз зазначенням кодування UTF-8. Додатково в шаблон відповіді підставляються ім'я та по батькові, одержувані з дескриптора додатка web.xml. Тобто, виконується читання параметрів конфігурації сервлета.

Для того, щоб можна було б повертати сторінку з кирилицею, використовується OutputStream. У вихідний потік можна вивести будь-яку інформацію (в нашому прикладі - простий HTML-код).

Лістинг дескриптора додатка web.xml

Servlet Hello World hello example.HelloWorld name Остап mname Ібрагімович hello / hello

У дискриптор додатки web.xmlвизначаються параметри сервлету (найменування servlet-name і клас servlet-class) і параметри ініціалізації (ім'я name, по батькові mname). Дані параметри сервлет читає з використанням ServletConfig.

Для запуску прикладу сервлету з середовища IDE Eclipse необхідно стартувати сервер додатків і в адресному рядку браузера ввести наступний рядок:

Http: // localhost: 8080 / ServletHello / hello

Браузер відобразить нам вітання із зазначенням основного героя творів Ільфа і Петрова.

Для окремої компіляції сервлету можна використовувати командний файл, текст якого для Windows може мати такий вигляд.

SET TOMCAT_LIB = "C: \ Program Files \ Apache Software Foundation \ Tomcat \ common \ lib" SET JAVA_SDK = C: \ Java \ Sun \ SDK \ jdk \ bin \% JAVA_SDK% javac -classpath% TOMCAT_LIB% \ servlet-api. jar * .java

Після компіляції сервлет HelloWorld.classнеобхідно розмістити в директорії WEB-INF / classes / WEB-додатки на сервері Tomcat і зареєструвати в дескрипторі поставки web.xml.

завантажити приклад

Вихідний код прикладу сервлету, розглянутого в тексті сторінки, можна (191 Кб).

Приклад сервлету з використанням графічної бібліотеки Chart.js для динамічного формування сторінки з діаграмами можна подивитися.