Apache Tomcat

Следващият раздел се отнася конкретно за „Apache Tomcat“.

Първоначална инициализация на услугата чрез падащите менюта

Предоставените версии на Tomcat са стандартните – това са версиите, достъпни на официалния уебсайт на Apache Tomcat.
Промените, които са направени в тях, са само в конфигурационните файлове:

conf/context.xml
conf/logging.properties
conf/server.xml

Ако даден файл бъде променен, оригиналът се запазва с разширение .orig, например conf/server.xml.orig. Това се прави, за да могат промените лесно да бъдат проследени от вас или от оператор.

Версии на Tomcat

Има предварително конфигурирани версии на Tomcat, които могат да бъдат избрани при инициализиране на услугата MyAppServer.

Ако имате нужда, можете да стартирате всяка версия на Tomcat. Ако необходимата версия все още не е налична на вашия хостинг сървър, можете да я качите.

Забележка: Препоръчително е да спрете услугата, преди да промените версиите.

Когато инициализирате услугата с версии на JVM/Tomcat от падащите менюта, за вас се създава директория със следната структура:

my_appserv/apache-tomcat-9.0.41/
my_appserv/default -> apache-tomcat-9.0.41

Тук default е символна връзка към apache-tomcat-9.0.41. За да стартирате персонализирана версия на Tomcat, можете да създадете структура като тази:

my_appserv/apache-tomcat-9.0.41/
my_appserv/apache-tomcat-10.0.3/
my_appserv/default -> apache-tomcat-10.0.3

В този пример старата версия на Tomcat се запазва, а символната връзка default се пренасочва към новата версия.

Имайте предвид, че стандартните скриптове за стартиране и спиране на услугата start/stop може да не работят с някои версии на Tomcat. Тези скриптове за стартиране/спиране също са символни връзки:

my_appserv/bin/start -> /scm/plesk-myappserv/bin/user-start.sh
my_appserv/bin/stop -> /scm/plesk-myappserv/bin/user-stop.sh

Ако по някаква причина те не работят, можете да замените символните връзки с вашите персонализирани start/stop скриптове. Уверете се, че сте разгледали какво правят стандартните скриптове, тъй като може да е добра идея да базирате модификациите си на тях. Например, стандартният bin/start:

генерира conf/server.xml.lhs_generated
стартира watchdog, който уведомява SystemD за успешното стартиране на услугата и изпълнява задачите на WatchDog (мониторинг за поддържане на връзката)

Модификации на Tomcat

Както вероятно вече сте се досетили – всички персонализирани модификации на Tomcat са разрешени. Например, можете:

да поставите JAR файлове директно в директорията на Tomcat lib, ако това е необходимо (например от кода ви за пул на връзки към базата данни, дефиниции на ресурси и т.н.),
да модифицирате скриптовете за стартиране и конфигурациите на Tomcat
да добавяте/изтривате/заменяте файлове на Tomcat
и т.н.

При инициализиране на услугата чрез падащите менюта Tomcat е предварително конфигуриран по следния начин:

conf/server.xml -> server.xml.lhs_generated
conf/server.xml.lhs_generated

Скриптът bin/start генерира файла server.xml.lhs_generated, който се базира на домейните с активирана поддръжка на MyAppServer и приложенията, които се намират в тяхната директория.

Ако е необходимо, можете да замените символната връзка conf/server.xml с модифицирания файл server.xml, от който се нуждаете.

Версии на JVM

Има предварително конфигурирани версии на JVM, които могат да бъдат избрани при инициализиране на услугата MyAppServer. Вашият Tomcat инстанс след това е предварително конфигуриран да използва избраната версия на JVM.

Ако обаче имате нужда, можете да стартирате всякаква версия на JVM. Ако тя не е налична на вашия хостинг сървър, можете да я качите и да редактирате следните файлове:

my_appserv/envdir/JAVA_HOME
my_appserv/envdir/JAVA_OPTS

По подразбиране това са символни връзки, така че може да се наложи да ги премахнете и да създадете нови файлове на тяхно място.

Уверете се, че сте посочили пълния (абсолютен) път към JVM, а не относителен.

Модификации на JVM

Можете да качите своя собствена JVM и да я модифицирате според нуждите си.
Модификации на глобалните JVM (тези, които са предварително инсталирани на сървъра) не са разрешени.

Моля, имайте предвид, че някои модификации може да бъдат забранени от закона – например, използването на силна криптография не е разрешено в някои страни. От вас зависи да спазвате такива ограничения.

Тип или брой на разгърнатите приложения

Можете да изпълнявате колкото Java уеб приложения пожелаете.
Всички Java фреймворкове могат да се използват и се поддържат.

Това частна JVM ли е?

Това, което предлага тази услуга, може да се счита за частна JVM или частен Tomcat . Всъщност тя предлага повече от това, което другите включват в тези термини, тъй като My App Server е проектиран да бъде много гъвкав и може да изпълнява всичко, а не само предварително дефинирани версии на JVM/Tomcat .

Мениджър за сигурност на Tomcat

Мениджърът за сигурност на Tomcat НЕ е активиран в конфигурацията по подразбиране, тъй като неговата политика за сигурност по подразбиране налага някои ограничения, които пречат на някои приложения да работят правилно.

Ако вашето приложение препоръчва използването на мениджър за сигурност, можете да го активирате и да персонализирате политиката за сигурност.

DocumentRoot и appBase

Tomcat нарича кореновата директория на домейн или поддомейн „application base“ (конфигурационна опция appBase на елемента Host в server.xml).

Apache HTTPd я нарича „document root“ (конфигурационна опция DocumentRoot).

В стандартната конфигурация на My App Server Tomcat и Apache HTTPd виртуалните хостове сочат към една и съща директория, така че DocumentRoot и appBase са едно и също нещо.

Забележка: Това описание се отнася за немодифицираната конфигурация на My App Server. Можете свободно да модифицирате услугата според нуждите си.

Къде да поставите вашите уеб приложения за Tomcat

Уеб приложенията на Tomcat трябва да се поставят директно в DocumentRoot.

За основния домейн на абонамента DocumentRoot по подразбиране сочи към директорията /httpdocs.

Ето един пример.
Да приемем, че имате поддомейн docs.mydomain.com, насочен към директорията /docs със следната структура:

/docs/WEB-INF
/docs/app1/WEB-INF
/docs/app2/WEB-INF

С тази структура ще бъдат създадени следните контексти на приложения:

docs.mydomain.com/
docs.mydomain.com/app1/
docs.mydomain.com/app2/

Всеки контекст на Tomcat представлява отделно уеб приложение със свои собствени класове, библиотеки, JSP файлове и т.н. Например:

/docs/app1/META-INF/context.xml
/docs/app1/WEB-INF/web.xml
/docs/app1/WEB-INF/lib/jar1.jar
/docs/app1/WEB-INF/lib/jar2.jar
/docs/app1/WEB-INF/classes/Class1.class
/docs/app1/WEB-INF/classes/package1/subpackage1/OtherClass.class

Сканер на контекста на приложението

Сканерът по подразбиране създава нов Context за всяка директория, която:

е разположена директно в DocumentRoot (поддиректория от първо ниво на DocumentRoot )
съдържа поддиректория от първо ниво, наречена WEB-INF
има име, което се валидира като контекстен път

Пример е даден в разделите по-горе.

Приложения Manager и HostManager Tomcat

Те не са активирани по подразбиране.

Ако имате нужда от тях, можете да ги активирате по един от следните начини:

редактиране на server.xml или
копиране на приложенията във вашия DocumentRoot

Може да се наложи да направите някои промени и в конфигурационните файлове на приложението. Например, данните за вход в conf/tomcat_users.xml и ограниченията за достъп в META-INF/context.xml на приложението. Необходимите промени зависят от избраната версия на Tomcat и от версията на приложението, която сте получили.

WAR файлове

WAR е съкращение от Web application ARchive .

WAR файловете трябва да бъдат разархивирани, за да бъдат разгърнати. Например, съдържанието на test.war трябва да бъде поставено в директория с име test.

Забележка: Това описание е за немодифицираната конфигурация на My App Server. Можете свободно да модифицирате услугата според нуждите си.

Можете да предоставите персонализиран server.xml, за да поддържате разгръщания от WAR файлове.

Въпреки че Tomcat може да стартира приложение директно от WAR, без да го разпакова, ние силно препоръчваме да не използвате такава конфигурация, тъй като е много вероятно това да доведе до значително влошаване на производителността.

Tomcat може автоматично да разпакова вашите WAR файлове, ако зададете unpackWARs=„true“ за съответния Host .

Конфигурация на хоста по подразбиране

Всеки елемент Host в конфигурационния файл server.xml на Tomcat е конфигуриран по подразбиране по следния начин:

deployXML=„true“ - поддържат се персонализации в META-INF/context.xml
deployOnStartup=„false“ - Не извършвайте откриване на приложения при стартиране. Разполагат се само приложенията, конфигурирани в server.xml.
autoDeploy=„false“ - Няма разгръщане на нови приложения, поставени в appBase, докато Tomcat работи.
unpackWARs=„false“ - Не извличайте WAR файлове автоматично

Това са настройки, подходящи за производствена употреба.

Както вече беше споменато, можете да предоставите свой собствен server.xml, ако например настоявате да се разгръщат от WAR файлове.

Логи на Tomcat

Логите на Tomcat могат да бъдат намерени в директорията my_appserv/default/logs:

catalina.out - STDOUT и STDERR на скрипта за стартиране се пренасочват към този лог
catalina.stop - STDOUT и STDERR на скрипта за спиране се пренасочват към този лог
watchdog.log - STDOUT и STDERR на WatchDog се пренасочват към този лог

Разгръщане на нови уеб приложения

Спрете услугата
Качете приложението си
Стартирайте услугата

Ако качите приложението си, докато услугата работи, съдържанието му може да бъде достъпно чрез контекста ROOT.

Презареждане на приложения

Tomcat може да засече някои промени автоматично. Например нови или актуализирани JSP или клас файлове. Обикновено той решава кои файлове са актуализирани, като проверява тяхното време на модификация . Например, ако страница JSP има по-ново време на модификация от съответния й предварително компилиран клас файл, Tomcat я компилира отново.

Ако някои промени не бъдат засечени, може да се наложи да рестартирате услугата.
Имайте предвид, че някои промени може да бъдат игнорирани дори при рестартиране на Tomcat. Ако това се случи, може да искате да включите опцията „Почистване на работната директория при стартиране на услугата“ и да опитате отново да рестартирате.

Съответствия на Servlet/филтри

Когато поддръжката на My App Server е включена за даден домейн, към фронтенда на Apache HTTPd се добавят персонализирани правила, за да се препращат всички заявки към JSP файлове към бекенд сървъра чрез протокола AJP.

Типичните уеб приложения обаче изискват допълнителни съответствия. Например съответствия за Servlets или Filters.

За да работят съответствията на вашето приложение както се очаква, трябва да се направят две неща:

Както обикновено, те трябва да бъдат дефинирани във вашето приложение (например в WEB-INF/web.xml или чрез анотация)
Фронтендът на Apache HTTPd трябва да бъде конфигуриран да ги препраща към бекенда Tomcat.

Втората стъпка се извършва чрез файлове .htaccess. Ето един пример. Да приемем, че имате следния контекст:

http://docs.mydomain.com/app1/

и това уеб приложение има:

/docs/app1/WEB-INF/web.xml

който съдържа:

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    
<url-pattern>/myservlet/action1</url-pattern>
</servlet-mapping>

Трябва да създадете файла:

/docs/.htaccess

който съдържа:

RewriteEngine On
RewriteRule ^app1/myservlet/action1$ ajp://mas-YOUR_SYS_USERNAME/app1/myservlet/action1 [NE,P,L]

Можете също така да насочите всички заявки за уеб приложението app1 към Tomcat по следния начин:

RewriteEngine On
RewriteRule ^app1/(.*)$ ajp://mas-YOUR_SYS_USERNAME/app1/$1 [NE,P,L]

Или дори можете да пренасочите всички заявки за този поддомейн към Tomcat бекенда:

RewriteEngine On
RewriteRule ^(.*)$ ajp://mas-YOUR_SYS_USERNAME/$1 [NE,P,L]

Четене/запис/изтриване на файлове във файловата система

Трябва да бъдете особено внимателни, когато използвате относителни пътища. Те могат да бъдат относителни към нещо различно от това, което очаквате.

За да проверите относителна пътека, можете да поставите код като този например в test.jsp:

<%@page contentType="text/plain; charset=UTF-8" pageEncoding="UTF-8"%>
<%
java.io.File f = new java.io.File(„.“);
out.println( „path: “ + f.getAbsolutePath() );
%>

Директориите, които виждате, когато влизате чрез FTP или в Plesk File Manager, са относителни спрямо началната директория на абонамента.

Ето пример за абсолютен път:

/var/www/vhosts/mydomain.com/docs/WEB-INF/uploads/file1.txt

Ако срещнете:

java.security. AccessControlException: достъп отказан (java.io.FilePermission /SOME/PATH)

обичайните причини са:

Грешни пътища
Грешни разрешения на файловата система

На файл или директория може да са премахнати необходимите разрешения за четене/запис/изпълнение.
Можете да управлявате правата чрез Plesk Файлов мениджър или командата chmod.

Java mail

За да изпращате имейли от вашето уеб приложение Tomcat, можете да използвате следните настройки:

Име на хост: localhost
TCP порт: 25
Потребителско име: [email protected]
Парола: паролата на пощенската кутия

Може да се наложи да поставите mail.jar и activation.jar в папката WEB-INF/lib на вашето уеб приложение, в зависимост от използваната от вас реализация на пощенския API.

Свързване с база данни от вашето уеб приложение Tomcat

Ето един пример за MySQL, който можете да поставите например в test.jsp:

<%@page language="java" import="java.sql.*" contentType="text/plain; charset=UTF-8" pageEncoding="UTF-8"%>
<%
Class.forName( „com.mysql.jdbc.Driver“ );
java.sql.Connection con = DriverManager.getConnection(
    „jdbc:mysql://localhost/DBNAME“,
    „USERNAME“,
    „PASSWORD“
);
out.println( con.toString() );
%>

Драйверът за MySQL трябва да бъде поставен в WEB-INF/lib на вашето уеб приложение.

Пулиране на връзки към базата данни

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

Просто затворете връзките с базата данни, когато приключите с тях, и ги отворете отново, когато е необходимо.

Обхватът на заявката е отличен период на живот за връзка с базата данни.

Бъдете особено внимателни при повторно използване на връзки от пула, тъй като RDBMS може да е конфигурирана да прекъсва неактивните връзки и може да срещнете:

java.sql.SQLException: Не се допускат операции след затваряне на връзката