- относно работата в мрежа
- за софтуерната архитектура
- за HTTP/HTTPS
- относно основите на Maven
- относно сървлети (писане на просто уеб приложение)

Съдържание:
- Какво е сервлет контейнер?
- Как се използват сервлет контейнерите?
- Инсталиране и стартиране на Tomcat
- Разполагане на приложение в Tomcat
- Използване на HTTPS instead of HTTP
- Генериране на сертификат
- Конфигуриране на сървъра
- Динамично генериране на HTML страници
- Алтернативи на Tomcat
Какво е сервлет контейнер?
Това е програма, която работи на сървър и може да взаимодейства със сървлетите, които създадохме. С други думи, ако искаме да стартираме нашето уеб приложение на сървър, първо разполагаме сервлет контейнер и след това поставяме сервлети в него. Работният процес е прост: когато клиентът има достъп до сървъра, контейнерът обработва неговата заявка, определяйки кой сървлет трябва да я обработи, и след това предава заявката.
Как се използват сервлет контейнерите?
В допълнение към заявките за маршрутизиране, контейнерът за сървлети изпълнява и други функции:- Той динамично генерира HTML страници от JSP файлове.
- Той криптира/декриптира HTTPS съобщения.
- Той осигурява ограничен достъп за администриране на сървлети.
Инсталиране и стартиране на Tomcat
-
За да инсталирате Tomcat, просто разархивирайте изтегления архив в желаната директория.
-
Моля, обърнете внимание, че Tomcat изисква Java version 8 or по-нова, за да стартира и работи. Проверете дали променливата на средата JAVA_HOME препраща към текущата version на JDK.
-
След това трябва да конфигурирате потребителски достъп до Tomcat . Това става във file tomcat-users.xml, който се намира в папката conf.
В Tomcat има четири предварително зададени роли:
- manager-gui — Достъп до графичния интерфейс и pageта за състояние
- manager-script — Достъп до текстовия интерфейс и pageта за състояние
- manager-jmx — Достъп до JMX и pageта за състояние
- manager-status — Достъп само до pageта със състоянието
Вътре в тага <tomcat-users> ние изрично посочваме тези роли и ги присвояваме на нашия потребител:
<role rolename="manager-gui"/> <role rolename="manager-script"/> <role rolename="manager-jmx"/> <role rolename="manager-status"/> <user username="user" password="password" roles="manager-gui, manager-script, manager-jmx, manager-status"/>
Сега всичко е готово за стартиране!
-
В папката bin стартирайте file startup.bat (startup.sh на Linux).
-
След няколко секунди отворете връзката http://localhost:8080/ във вашия браузър. Ще видите графично табло:
Ако видите подобно меню, Tomcat работи.
-
Ако не работи, проверете ръчно променливите на средата JAVA_HOME и CATALINA_HOME:
- JAVA_HOME — Това трябва да препраща към текущата version на Java 8+.
- CATALINA_BASE — Това трябва да препраща към Tomcat or да липсва (не трябва да препраща към друга version на Tomcat).
Разполагане на приложение в Tomcat
Успяхме да стартираме Tomcat, така че сега е време да внедрим няHowъв проект в него. Нека използваме сървлетите от предишната статия . MainServlet:
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.io.PrintWriter;
@WebServlet("/hello")
public class MainServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
HttpSession session = req.getSession();
Integer visitCounter = (Integer) session.getAttribute("visitCounter");
if (visitCounter == null) {
visitCounter = 1;
} else {
visitCounter++;
}
session.setAttribute("visitCounter", visitCounter);
String username = req.getParameter("username");
resp.setContentType("text/html");
PrintWriter printWriter = resp.getWriter();
if (username == null) {
printWriter.write("Hello, Anonymous" + "
");
} else {
printWriter.write("Hello, " + username + "
");
}
printWriter.write("Page was visited " + visitCounter + " times.");
printWriter.close();
}
}
IndexServlet:
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
@WebServlet("/")
public class IndexServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
resp.sendRedirect(req.getContextPath() + "/hello");
}
}
Преди да внедрим, трябва да опаковаме нашите сървлети във WAR файл. Maven обикновено се използва за това, но за да създадете WAR файл, имате нужда от файл web.xml, който има картографиране за всички сървлети. Използвахме новата анотация @WebServlet, за да напишем сървлетите, така че нямаме файл web.xml. За щастие, IDEA може да свърши мръсната работа instead of нас, като опакова нашия проект във WAR файл. За да направите това, отворете структурата на проекта (Ctrl+Shift+Alt+S) -> Артефакти -> Изберете желания WAR файл -> Поставете отметка в квадратчето до „Включване в изграждането на проекта“ -> Щракнете върху „OK“. 

-
Използване на графичния интерфейс
За да направите това, следвайте тази връзка: http://localhost:8080/manager/html . Tomcat трябва да поиска потребителско име и парола.
Ако сте следвали заедно с мен до този момент, тогава потребителското име е "потребител", а паролата е "парола" .
След като влезете успешно, ще видите Tomcat Web Application Manager. Разделът „Приложения“ вече съдържа 5 applications — това са помощни програми на Tomcat, които улесняват работата с Tomcat. Те могат да бъдат изтрити в бъдеще.
По-долу е разделът „Внедряване“. Тук можете да изберете WAR архива за внедряване. Нека въведем ръчно пътя и контекста:
Щракнете върху „Разполагане“ и виждаме, че нашето приложение се е появило в секцията „Приложения“:
Използвайки графичния интерфейс на Tomcat, можем да спрем, рестартираме и изтрием сесия, Howто и да зададем продължителността на сесията. При внедряването ние посочихме контекста /demo, което означава, че нашето приложение е достъпно чрез http://localhost:8080/demo . Провери го. Всичко трябва да работи.
-
Чрез файловата система
За да разположите приложението по този начин, трябва да отворите директорията, в която Tomcat е разархивиран. След това отидете в папката "webapps". Тук ще намерите помощните програми, които вече сме срещали:
Всичко, което се изисква, е да преместим нашия файл servlet.war тук.
Изчакваме няколко секунди и след това виждаме, че се е появила нова папка "servlet". Това означава, че нашето приложение е внедрено. Отидете до интерфейса на Application Manager на http://localhost:8080/manager/ . Тук виждаме, че нашето приложение е разгърнато в /servlet контекста:
Когато се разположи по този начин, контекстът се присвоява автоматично въз основа на името на разгърнатия WAR файл. За да промените контекста, можете да преименувате новосъздадената папка, която съдържа приложението, но преди да направите това, трябва да премахнете WAR file. В противен случай Tomcat ще преразпредели приложението с името на архива.
Както можете да видите, разполагането на applications в Tomcat е много по-лесно, отколкото може да изглежда. Но другите му функции също са лесни за използване. Да проверим.
Използване на HTTPS instead of HTTP
Ако си спомняте, разгледахме разликата между HTTP и HTTPS в отделна статия . HTTPS е същият протокол като HTTP, но криптира данните, които се предават. От страна на клиента браузърът е отговорен за криптирането, но ние трябва да осигурим криптирането от страна на сървъра. Тъй като Tomcat приема и насочва HTTP заявки, има смисъл да му се делегира криптиране. За да направим това, ние трябва:- Генерирайте самоподписан сертификат
- Направете допълнителни настройки на сървъра
Генериране на сертификат
Независимо от versionта, JDK включва голям брой помощни програми. Един от тях е keytool . Това е инструмент за генериране и работа с ключове за криптиране. За да го използвате, от командния ред отидете в директорията C:\\Program Files\\Java\\jdk1.8.0_181\\bin и изпълнете командата keytool -genkey -alias tomcat -keyalg RSA .- keytool — Името на помощната програма, която изпълняваме с опции на командния ред
- -genkey — Посочва, че искаме да генерираме нов ключ
- -alias tomcat — Създаване на ключов псевдоним
- -keyalg RSA — Изберете RSA като алгоритъм за генериране на ключ

Конфигуриране на сървъра
Сега, когато сертификатът е готов, трябва да коригираме настройките на сървъра, а именно SSL конектора. Това се прави във file server.xml, който се намира в apache-tomcat-9.0.30/conf/ . В него намираме блокове като този:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
type="RSA" />
</SSLHostConfig>
</Connector>
и поставяме нашата конфигурация до тях:
<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
keystoreFile="C:\Users\user\.keystore" keystorePass="mypass"
clientAuth="false" sslProtocol="TLS"/>
Присвояваме най-новите стойности на параметрите keystoreFile и keystorePass, запазваме file и след това рестартираме Tomcat, като използваме файловете shutdown.bat и startup.bat. Сега сървърът е готов да обработва HTTPS заявки. Адресът се промени съвсем малко: https://localhost:8443/demo/hello . Когато щракнете върху връзката, ще получите предупреждение за надеждността на сертификата, което не е изненадващо. Както казахме малко по-рано, трябва да използвате услугите на един от сертифициращите органи, за да получите нормален сертификат. Но засега постигнахме целта си: приложението работи с HTTPS протокол и това е важно!
Динамично генериране на HTML страници
Сега ще продължим нашия преглед на сървлет контейнерите, като разгледаме друга функция: динамично генериране на HTML страници. Представете си перфектен свят, в който instead of скучен статичен HTML code можете да пишете Java code, като използвате променливи, цикли, масиви и други езикови конструкции. Успяхте ли да си го представите? Добрата новина е, че нещо подобно съществува. Лошата новина е, че не постига напълно тази фантазия. Ако не сте се досетor, говорим за JavaServer Pages (JSP). Накратко, това е технология, която ви позволява да вмъквате части от Java code в HTML page. Вярно е, че този Java code все още се преобразува в HTML, преди да бъде изпратен на клиента, но този HTML ще бъде динамично генериран, като се вземат предвид различни фактори. Например, можете да използвате условни изрази и да връщате различно съдържание в зависимост от дадено condition. Примерна JSP page:
<%@ page language="java"" %>
<html>
<head>
<title>JSP</title>
</head>
<body>
<%
String firstName="name";
String secondName="surname";
if (firstName.equals("name")){
out.print("Hello: "+firstName+"<br>");
}
if (firstName.equals("name") && secondName.equals("surname"))
{
out.print("Hello, my dear friend! <br>");
}
else
{
out.print("I don't know you. Go away! <br>");
}
%>
</body>
</html>
Можете да прочетете повече за JSP тук. В края на краищата, тази статия не е за JSP — тук сме, за да говорим за сервлет контейнери! И така, защо споменахме JSP? Просто е: контейнерът на сървлет е това, което преобразува Java codeа от JSP в HTML. Когато сървлетът ще върне JSP съдържание като отговор, контейнерът взема бележка и първо го преобразува в удобна за браузър HTML page, преди да изпрати такова съдържание на клиента. Днес има много аналози на технологията JSP — Thymeleaf, FreeMarket, Mustache и други. Всички те работят по подобен начин. Кое от тях да изберете за вашата работа е въпрос на вкус. Това се отнася и за избора на контейнер за сервлети. В тези примери използвахме Tomcat, най-често срещаният контейнер, но някои проекти използват други контейнери. Струва си да прегледате накратко най-популярните и да помислите How се различават от Tomcat.
Алтернативи на Tomcat
-
GlassFish е контейнер с отворен code, чиято разработка се поддържа от Oracle.
За разлика от Tomcat, той е пълноценен уеб сървър, който освен със сървлети може да работи и с други компоненти от JavaEE framework. Това каза, че използва много повече RAM. Има по-голяма гъвкавост при фина настройка на сървъра, което усложнява използването му. Трябва да се използва при разработване на applications върху рамката JavaEE.
-
WildFly беше известен преди като JBoss . Освен това е с отворен code. Разработен е от Red Hat. Името беше променено, за да се избегне объркване с друг от продуктите на компанията - JBoss Enterprise Application Platform.
Подобно на GlassFish, WildFly е пълноценен уеб сървър. Между другото, под капака, WildFly използва Tomcat като контейнер за сървлети. За разлика от GlassFish, WildFly е по-лек и лесен за конфигуриране.
-
Jetty , Howто и предишните, е с отворен code. Разработен е от Eclipse.
Подобно на Tomcat, това е прост контейнер за сервлети, без поддръжка за всички компоненти на рамката JavaEE. В същото време е по-лек и дори може да се стартира на мобилен телефон. Стартира и спира бързо и мащабира добре. За разлика от Tomcat, той има по-малка общност и база от знания.
-
WebLogic е лицензиран софтуер, който трябва да бъде закупен преди употреба. Принадлежи на Oracle.
Има малко по-широка функционалност от Tomcat. Може да работи с FTP протокола. Но не е толкова гъвкав при разработване и тестване на applications.
-
WebSphere (WebSphere Application Server, за да бъдем точни) е платен софтуер. Разработен е от IBM. Подобно на WildFly и GlassFish, това е пълен сървър за applications. Но има по-удобен интерфейс за конфигуриране, плюс висока надеждност при работа.
Неговите недостатъци включват факта, че използва много ресурси и отнема много време за стартиране и спиране, което не е много удобно при разработването на малки проекти.
GO TO FULL VERSION