Проект, который реализует спецификацию контейнера сервлетов и спецификацию JavaServer Pages (JSP). Используется в качестве самостоятельного сервера веб-приложений, в качестве сервера контента в связке с веб-сервером Apache, а также в качестве контейнера сервлетов в серверах приложений JBoss и GlassFish.
В лабораторной работе предполагается установка и настройка Tomcat в качестве сервера веб-приложений под управлением ОС OpenSuSE 12.2.
Цель работы: Установить и произвести базовую настройку Apache Tomcat в качестве сервера веб-приложений.
Задания к работе
- Установить Java-окружение из пакета OpenJDK.
- Установить Tomcat.
- Запустить Tomcat и проверить его работу по адресу http://localhost:8080.
- Написать JSP-страницу test.jsp, выводящую произвольную строку.
- Написать сервлет test, выводящий произвольную строку.
- Написать стартовую страницу index.html, содержащую ссылки на страницу test.jsp и сервлет test.
Установка Java и Tomcat
1. Установка Java Development Kit (JDK)
Для работы Tomcat требуется установленное окружение для разработки Java-приложений (Java Development Kit, JDK). Проверить, какая версия установлена в системе можно, например, так:
Aag@stilo:~> zypper se java | grep "runtime" -i // фильтрация избыточной информации i | java-1_7_0-openjdk | Java runtime environment based on OpenJDK 7 and IcedTea 7 | пакет | java-1_7_0-openjdk | Java runtime environment based on OpenJDK 7 and IcedTea 7 | пакет с исходным кодом
В приведенном примере в системе установлена (символ i (nstalled)) версия 1.7 OpenJDK - свободного комплекта разработки, полностью совместимого с Sun (Oracle) JDK.
Если ни один из доступных пакетов не установлен, то его следует установить:
Aag@stilo:~> zypper in java-1_7_0-openjdk* .... // процесс установки
Проверить результаты установки можно так, как было указано выше.
Узнать путь, где размещается среда исполнения Java можно из переменной окружения $JAVA_HOME:
Aag@stilo:~> echo $JAVA_HOME /usr/lib64/jvm/jre
А узнать номер установленной (и используемой) версии JDK можно так:
Aag@stilo:~> java -version java version "1.7.0_09" OpenJDK Runtime Environment (IcedTea7 2.3.3) (suse-3.16.1-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
2. Установка Tomcat
Установка Tomcat и связанных с ним пакетов из репозитария производится обычным образом:
Aag@stilo:~> zypper in tomcat* Чтение установленных пакетов... // aag: список сокращен и может отличаться от приведенного Будут установлены следующие НОВЫЕ пакеты: jakarta-commons-dbcp-tomcat jakarta-commons-pool-tomcat5 tomcat tomcat-admin-webapps tomcat-docs-webapp tomcat-servlet-3_0-api tomcat-webapps ... Полный размер загрузки: 7,2 M. После операции будет использовано дополнительно 43,6 M. Продолжить? [да/нет]:
После подтверждения, необходимые пакеты будут загружены и установлены. При этом, в системе будут созданы следующие подкаталоги (дефолтная установка в OpenSuSE 12.2, фактическое размещение зависит от дистрибутива и версии ОС и версии самого Tomcat):
- /usr/share/tomcat/bin: управляющие скрипты;
- /etc/tomcat/conf: конфигурационные файлы (server.xml, web.xml, context.xml, tomcat-users.xml);
- /usr/share/java/tomcat/lib: jar-файлы, используемые всеми расширениями Tomcat и веб-приложениями;
- /var/log/tomcat: log-файлы;
- /srv/tomcat/webapps: каталог, содержащий веб-приложения (сервлеты и JSP);
- /var/cache/tomcat/work: рабочий каталог Tomcat, который используется, в первую очередь, при преобразовании JSP-страниц в сервлеты;
- /var/cache/tomcat/temp: временные файлы.
В каталоге /usr/share/tomcat будут, также, размещены симлинки на указанные каталоги. Путь к основному каталогу Tomcat можно записать в переменную окружения $CATALINA_HOME (export CATALINA_HOME="/usr/share/tomcat/").
3. Запуск и остановка сервера
Если установка прошла успешно, то можно попробовать запустить Tomcat:
Aag@stylo:~> $CATALINA_HOME/bin/catalina.sh start
Скрипт catalina.sh используется для ручного запуска и остановки сервера Tomcat. Для автоматического запуска можно использовать скрипт service (service tomcat start|stop|restart), предварительно следует указать уровни запуска, на которых будет стартовать демон tomcat (см. chkconfig)
Catalina - название компонента Tomcat, реализующего непосредственно функции контейнера сервлетов. Это название использовалось в ранних версиях (до Tomcat5) для всего продукта. Другими компонентами в составе системы являются Coyote, который осуществляющий поддержку транспорта по протоколу HTTP 1.1 и Jasper, предназначенный для обработки JSP (анализа JSP-файлов и компиляции их в Java-код, который затем передается для обработки с помощью Catalina).
Работающий сервер веб-приложений будет ожидать входящие подключения на порт 8080. Это можно проверить, если в адресной строке браузера набрать http://localhost:8080 (рис. 1).
Рис. 1. Дефолтная стартовая страница сервера Apache Tomcat
Остановить Tomcat, запущенный вручную, можно так:
Aag@stylo:~> $CATALINA_HOME/bin/catalina.sh stop
Настройка сервера Tomcat
Для настройки сервера Tomcat используются следующие конфигурационные XML-файлы , размещенные в каталоге $CATALINA_HOME/conf/:
- server.xml: Общие настройки сервера (порты, виртуальные хосты и проч.).
- web.xml: Параметры, общие для ВСЕХ веб-приложений на текущем сервере. Настройки отдельных веб-приложений задаются в их собственных файлах /WEB-INF/web.xml (здесь можно провести аналогию с использованием файла.htaccess в Apache).
- context.xml: Общие настройки управления контентом.
- tomcat-users.xml: Список пользователей и групп (ролей).
Внимание: Прежде чем вносить какие-либо изменения в эти файлы, стоит сделать их резервные копии. Также следует обращать внимание на комментарии, которыми снабжены эти файлы.
conf/server.xml - Изменение номера порта
По умолчанию Tomcat использует для приема входящих подключений TCP-порт 8080, а также порты 8009 и 8005:
Aag@stilo:~> netstat -tuaev --numeric-ports | grep tomcat tcp 0 0 localhost:8005 *:* LISTEN tomcat 20539 tcp 0 0 *:8009 *:* LISTEN tomcat 20533 tcp 0 0 *:8080 *:* LISTEN tomcat 20524
Эти порты могут быть изменены на другие, не используемые другими сетевыми сервисами, путем их изменения в файле conf/server.xml. Чтобы, например, заставить Tomcat работать на порту 8081, нужно найти в файле conf/server.xml указанную ниже строку и поменять значение атрибута port на требуемое (8081), затем перезапустить сервер:
...
Для developer-сервера можно использовать любой непривилегированный порт. Для production-сервера стоит использовать порт 80, который является стандартным для HTTP-серверов.
conf/web.xml - Включение листинга каталогов
Для установки отображения списка файлов в каталогах (листинга), нужно поменять значение атрибута listings с ложного (false) на истинное (true) в блоке настроек сервлета по умолчанию ("default"-servlet) в файле conf/web.xml. Это бывает полезным при разработке и отладке веб-приложений, но не рекомендуется использовать на production-сервере по соображениям безопасности.
...
conf/context.xml - Установка автоматической перезагрузки страниц
Имеется возможность заставить Tomcat выполнять автоматическую перезагрузку после изменения кода. Нужно добавить атрибут reloadable со значением "true" в элемент
conf/tomcat-users.xml - Управление пользователями и ролями
Для управления пользователями, которые могут управлять сервером Tomcat, предназначен файл conf/tomcat-users.xml. Чтобы создать, например, пользователя manager, который сможет управлять веб-приложениями через графическую оболочку (предопределенная роль manager-gui), нужно добавить в этот файл запись вида:
Разработка и распространение веб-приложений под управлением Tomcat
Рассмотрим несколько примеров использования Tomcat для разработки веб-приложений на Java . Здесь мы не будем акцентировать внимание на коды программ как таковые, поскольку этому посвящена отдельная дисциплина — «Объектно-ориентированное программирование на языке Java ».
Создание структуры каталогов и размещение веб-страниц
Все веб-приложения размещаются в каталоге webapps (/srv/tomcat/webapps). Каждое приложение размещается в собственном, одноименном, каталоге с определенной вложенной структурой (webapps/youappname/WEB-INF/classes). Для нового веб-приложения (например, myapp) эту структуру можно создать, например, так:
// WEB-INF - предопределенное и регистрозависимое имя каталога aag@stilo:~> sudo mkdir -p /srv/tomcat/webapps/myapp/WEB-INF/classes
Назначение созданных каталогов следующее:
- myapp: Корневой каталог веб-приложения. Здесь размещаются HTML-страницы и прочие ресурсы (таблицы стилей (CSS), изображения, клиентские скрипты (javascript), JSP и т.п.), доступные веб-клиентам.
- myapp/WEB-INF: Этот каталог, недоступный веб-пользователям, содержит описание веб-приложения и его параметры в файле web.xml.
- myapp/WEB-INF/classes: В этом каталоге размещаются все файлы Java-классов сервлетов.
Поместим в корневой каталог создаваемого веб-приложения файл index.html следующего содержания:
После перезапуска сервера к создаваемому веб-приложению можно будет обратиться по адресу http://localhost:8080/myapp/(рис. 2).
Рис. 2. Отображение статических страниц
Java Server Pages
Java Server Pages (JSP) - динамические веб-страницы, содержащие, помимо HTML-разметки, инструкции на языке Java (подобно PHP или ASP). Такие ресурсы размещаются и используются так же, как и статические ресурсы. Пример JSP приведен в листинге 1, а результат на рис. 3.
Листинг 1. Пример разметки JSP
Рис. 3. Вывод JSP-страниц
Примечание: Если при обращении к JSP-странице вы получаете сообщение об ошибке вида:
org.apache.jasper.JasperException: java.lang.IllegalStateException: No output folder.... ,
это скорее всего означает, что каталог tomcat/work не доступен для записи. Используйте команду chmod -R a+w tomcat/work для установки разрешений или chown для смены владельца.
Сервлеты
Все сервлеты (серверные приложения на Java) размещаются в подкаталоге WEB-INF/classes/. Рассмотрим использование сервлетов на примере приложения, выводящего некоторую информацию о сервере (листинг 1).
Листинг 1. Исходный код Java-сервлета
// Сохранить как /srv/tomcat/webapps/myapp/WEB-INF/classes/MyServlet.java import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class MyServlet extends HttpServlet { @Override public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { // установить MIME-type и кодировку ответа response.setContentType("text/html; charset=UTF8"); PrintWriter out = response.getWriter(); // Отправка веб-страницы try { out.println(""); out.println("
Запрошенный ресурс: " + request.getRequestURI() + "
"); out.println("Протокол: " + request.getProtocol() + "
"); out.println("Адрес сервера: " + request.getRemoteAddr() + "
"); out.println(""); } finally { out.close(); // Всегда закрывать Writer } } }Следующий этап - компиляция. Это можно сделать из той среды разработки, которую вы используете (Eclipse, NetBeans, IntelliJ и т.п.) или из командной строки. В случае использования openJDK и Tomcat 7 это будет выглядеть примерно так:
Aag@stylo:~> javac -classpath /usr/share/tomcat/lib/tomcat-servlet-3.0-api.jar:classes /srv/tomcat/webapps/myapp/WEB-INF/classes/MyServlet.java
В результате компиляции в каталоге WEB-INF/classes будет создан файл MyServlet.class. Теперь нужно сконфигурировать Tomcat для его использования.
Настройка доступа к сервлету
С точки зрения пользователя сервлет - это обычный веб-ресурс, адресуемый URI и обращение к сервлету выполняется через адресную строку браузера. Однако, чтобы сервлет стал доступным для клиентов, необходимо выполнить его настройку в файле WEB-INF/web.xml веб-приложения. Структура этого файла для рассматриваемого примера будет примерно такой:
В такой конфигурации сервлет из файла MyServlet.class
будет выполняться при обращении по адресу /myapp/about
. Для КАЖДОГО сервлета должна быть описана пара
Для того, чтобы изменения вступили в силу, требуется перезапустить сервер. Результат выполнения сервлета приведен на рис. 4.
Рис. 4. Выполнение сервлета
Подробную информацию о всех возможностях сервера Tomcat можно получить из документации, которая устанавливается вместе с сервером и доступна по адресу http://localhost:8080/docs/ или на официальном сайте проекта: http://tomcat.apache.org/ .
Постоянный адрес этой страницы:
Следующий шаг после установки Tomcat - выбрать базовые настройки. Этот процесс разбит на два этапа, которые детально описаны в этой статье. Первый - редактирование файлов настроек XML , второй - выбор соответствующих переменных для среды.
Файлы настроек XML
Два самых важных файла настроек, чтобы запустить Tomcat, называются.xml и web.xml. По умолчанию они размещены в TOMCAT-HOME/conf/server.xml и TOMCAT-HOME/conf/web.xml, соответственно.
Не выполняйте одни и те же настройки дважды. Try Tcat - профили сервера, которые позволяют сохранять общие настройки и применять их к нескольким экземплярам Tomcat в один клик.
SERVER.XML
Файл server.xml - главный файл настроек Tomcat. Элементы server.xml относятся к пяти базовым категориям:
- Элементы верхнего уровня (Top Level Elements)
- Соединители или коннекторы (Connectors)
- Контейнеры (Containers)
- Встраиваемые компоненты (Nested Components)
- Глобальные настройки (Global Settings)
У всех элементов из этих категорий имеется множество атрибутов, которые позволяют точно определить функциональные возможности. Чаще всего если необходимо внести какие-то существенные изменения в установку Tomcat, как, например, изменить число портов, приходится редактировать файл server.xml.
На сайте Apache’s Tomcat Documentation содержится достаточно информации, но нет некоторых сведений о настройках элементов. В этой статье все это освещено.
Элементы верхнего уровня
Server (сервер)
Этот элемент определяет отдельный сервер Tomcat и содержит элементы конфигурации Logger и ContextManager. К тому же, элемент Server поддерживает атрибуты “port”, “shutdown” и “className”. Атрибут порт используется для того, чтобы уточнить, через какой порт должны выполняться команды shutdown (отключения). Атрибут shutdown задает командную строку для отдельного порта, чтобы спровоцировать отключение. Атрибут className - реализацию класса Java, которая должна использоваться.
Service (сервис)
Это элемент, который можно поместить в элемент Server; он содержит один или несколько компонентов Connector, у которых один общий компонент Engine. Главная функция этого компонента - задать эти компоненты как один сервис. Название сервиса, который будет появляться в логах, определяется с помощью атрибута “name” (элемент Service).
Connectors (соединители)
Размещая один или несколько соединителей (connector) в теге Service, вы тем самым позволяете системе перенаправить запросы из этих портов в один компонент Engine для обработки. Tomcat позволяет определить соединители HTTP и AJP.
HTTP- соединитель
Этот элемент представляет HTTP/1.1 Connector и обеспечивает Catalina автономным функционалом веб-сервера. Это означает, что в дополнение к выполнению сервелатов и JSP -страниц, Catalina способен прослушивать специфические TCP-порты для запросов. Настраивая HTTP-коннекторы, обращайте внимание на атрибуты “minSpareThreads”, “maxThreads” и “acceptCount”.
Атрибут “maxThreads” особенно важен. Он контролирует максимальное число тредов, которые можно создать для управления запросами. Если будет установлено слишком малое значение, запросы будут застревать в серверном сокете, что может спровоцировать отказ в соединении. Эта проблема устраняется во время тестирования.
AJP-соединитель
Данный элемент является соединителем, который обеспечивает связь с протоколом AJP. Главная роль элемента в том, чтобы помочь Tomcat работать в связке с Apache.
Контейнеры
С помощью этих элементов Catalina направляет запросы в корректный обрабатывающий аппарат.
Context
Этот элемент представляет определенное веб-приложение и содержит данные о пути, по которому определяются запросы для соответствующих ресурсов приложения. Catalina получает запрос и пытается сопоставить самый длинный URI с контекстным путем определенного элемента Context до тех пор, пока не найдется корректный элемент, который бы обслуживал запрос.
У элемента Context может быть максимум один встроенный экземпляр на один элемент из вспомогательных элементов Loader, Manager , Realm, Resources и WatchedResource.
Хотя Tomcat позволяет определять элементы Context в “TOMCAT-HOME/conf/server.xml”, этого лучше избегать, поскольку эти главные настройки нельзя перезагрузить без перезагрузки Tomcat.
Engine
Этот элемент используется в связке с одним или несколькими соединителями, которые размещены в элементе Service. Элемент Engine может использоваться только в случае если он размещен в элементе Service, и только один элемент Engine разрешен в элементе Service. Обращайте внимание на атрибут “defaultHost”, который задает элемент Host.
Последний отвечает за обслуживание запросов для названий хостов на сервере, которые не настраиваются в server.xml. Название этого атрибута должно совпадать с названием одного из элементов Host, которые размещены в элементе Engine. Также важно выбрать уникальное, логичное название для каждого из элементов Engine, используя атрибут “name”. Если один элемент Server в вашем файле server.xml включает несколько элементов Service, потребуется выбрать уникальное название для каждого элемента Engine.
Host
Элемент, который размещен в элементе Engine, и используется, чтобы связать названия серверной сети с серверами Catalina . Этот элемент будет функционировать должным образом только если виртуальный хост был зарегистрирован в системе DNS соответствующего домена. Одна из самых полезных особенностей элемента Host - возможность содержать элементы Alias, использующиеся для того, чтобы определить названия нескольких сетей.
Cluster
Nested Components
Эти элементы размещаются внутри
элементов container, чтобы задать дополнительные функциональные возможности.
Listeners
Эти элементы можно поместить внутрь элементов Server, Engine, Host или Context. Они указывают на компонент, который производит определенное действие при специфическом событии.
У большинства компонентов есть атрибуты className, чтобы выбрать разные реализации элемента. Существует ряд дополнительных реализаций Listener, не только дефолтных. Все эти реализации требуют, чтобы элемент Listener размещался в определенном элементе Server.
И крайне важно настроить этот атрибут корректно. Доступные на текущий момент реализации содержатся в APR Lifecycle Listener, Jasper Listener, Server Lifecyle Listener, Global Resources Lifecyle Listener, JMX Remote Lifecycle Listener и в JRE Memory Leak Prevention Listener.
Global Naming Resources
Этот элемент используется, чтобы определить ресурсы Java Naming and Directory Interface для специфического Server, отличного от любых контекстов веб-приложения JNDI. Если нужно, вы можете задать характеристики JNDI resource lookup для
Результаты этого метода эквивалентны добавлению элементов
Realm
Этот элемент размещается в любом элементе Container и задает базу данных, содержащую имена пользователей, пароли и роли для Container. При размещении внутри элемента Host или Engine, характеристики, заданные в элементе Realm, передаются всем контейнерам нижнего уровня по умолчанию.
Важно корректно установить атрибут “className” этого элемента, поскольку существует множество реализаций. Эти реализации используются, чтобы сделать доступным Catalina другим системам управления безопасностью пользователей (например, JDBC , JNDI или DataSource).
Resources
У этого элемента только одно предназначение - направить Catalina в статические ресурсы, которые используются вашими веб-приложениями. Эти ресурсы включают классы, HTML и JSP файлы. Использование этого элемента предоставляет Catalina доступ к файлам, содержащимся в других местах, помимо файловой системы (filesystem), таким как ресурсы, которые содержатся в архивах WAR или базах данных JDBC.
Важно помнить, что это техника предоставления веб-приложениям доступа к ресурсам, которые содержатся вне файловой системы, может использоваться только, если приложение не требует непосредственного доступа к ресурсами, которые хранятся в файловой системе.
Valve
Компоненты Valve размещаются внутри элементов Engine, Host и Context, с их помощью добавляются специальные функциональные возможности в конвейер, обрабатывающий запросы. Это очень разносторонний элемент. Существует множество различных типов элементов Valve - от аутентификаторов до фильтров и исправлений ошибок WebDAV. Многие из этих типов Valve размещаются только внутри специальных элементов.
Web.XML
Файл web.xml содержит информацию, которая используется для конфигурации компонентов ваших веб-приложений. Задавая конфигурацию Tomcat в первый раз, вы можете задать servlet-mapping для центральных компонентов, таких как JSP. В Tomcat этот файл функционирует так же, как описано в спецификации Servlet.
Единственное отличие в том, как Tomcat обрабатывает этот файл: есть опция задать с помощью TOMCAT-HOME/conf/web.xml значения по умолчанию для всех контекстов. Если используется такой метод, базовой конфигурацией будет служить TOMCAT-HOME/conf/web.xml, который может переписать специфические для приложения файлы WEB-INF/web.xml.
Другие важные файлы конфигурации
Есть и другие важные файлы. Список ролей, пользователей и паролей, которые UserDatabaseRealm использует для аутентификации, их можно найти в tomcat-users.xml. Если нужен доступ к другим административным инструментам, которые присутствуют в Tomcat, вы можете отредактировать файл и добавить доступ администратора и менеджера.
Стандартные настройки контекста вашей установки Tomcat могут быть изменены в файле context.xml. Файл catalina.policy, который заменяет файл java.policy (с избранным JDK), содержит настройки разрешения для элементов Tomcat. Вы можете редактировать этот файл вручную или же с помощью policytool.
Переменные среды
Если Tomcat настраивается в первый раз, понадобится изменить несколько переменных среды, чтобы они соответствовали вашим требованиям.
JAVA_OPTS
С помощью этой переменной изменяется размер heap size of the JVM . Установить соответствующие значения для этой переменной крайне важно при размещении нового приложения, которому может понадобиться определенный размер динамической памяти для корректной работы. Подобрав соответствующие значения для этих настроек, вы сможете уменьшить число OOME-сообщений.
CATALINA_HOME
Эта переменная задает место установки Tomcat. Скрипты автозапуска в Tomcat будут пытаться определить значение этой переменной, но лучше просто установить корректное значение, чтобы избежать сложностей.
CATALINA_OPTS
Переменная, которая используется для установки различных специфических опций в Tomcat.
Apache Tomcat — это контейнер, который позволяет вам использовать интернет приложения такие, как Java сервлеты и JSP (серверные страницы Java).Пакеты Tomcat 6.0 в Ubuntu поддерживают два варианта запуска Tomcat. Вы можете установить его как классический одиночный экземпляр на всю систему, который будет запускаться при загрузке системы от имени непривилегированного пользователя tomcat6 . Но вы можете развернуть частные экземпляры, которые будут запускаться с правами вашего собственного пользователя, и вам придется запускать и останавливать их самостоятельно. Второй вариант особенно полезен в контексте сервера разработки, где нескольким пользователям требуется тестировать их собственные частные экземпляры Tomcat.
Масштабная установка на всю систему
Linux настройка tomcat
Изменение портов по умолчанию
Изначально Tomcat 6.0 запускает HTTP соединитель (connector) на порту 8080 и AJP соединитель на порту 8009. Вы можете захотеть изменить эти порты для избежания конфликтов с другими серверами на системе. Это делается изменением следующих строк в /etc/tomcat6/server.xml:
...Изменение используемой JVM
По умолчанию Tomcat предпочитает использовать OpenJDK-6, затем пробует JVM от Sun (Oracle), а затем иные JVM. Если у вас установлено несколько JVM, вы можете определить какая из них будет использоваться, установив JAVA_HOME в /etc/default/tomcat6:
JAVA_HOME=/usr/lib/jvm/java-6-sun
Определение пользователей и ролей
Пользователи, пароли и роли (группы) могут быть определены централизованно в секции Servlet. Для Tomcat 6.0 это настраивается в файле /etc/tomcat6/tomcat-users.xml:
Использование стандартных приложений Tomcat
Tomcat поставляется с приложениями, которые вы можете установить для документирования, администрирования или демонстрационных целей.
Документация Tomcat
Пакет tomcat6-docs содержит документацию Tomcat 6.0, упакованную в качестве интернет приложения, которое доступно по умолчанию по адресу http://yourserver:8080/docs . Вы можете его установить следующей командой в терминале: sudo apt-get install tomcat6-docs
Приложения администрирования Tomcat
Пакет tomcat6-admin содержит два приложения, которые могут быть использованы для администрирования сервера Tomcat через web интерфейс. Для их установки введите следующую команду в терминале:
Sudo apt-get install tomcat6-admin
Первое из них это приложение manager , которое по умолчанию доступно по адресу http://yourserver:8080/manager/html . Оно в первую очередь используется для получения статуса сервера и перезапуска web приложений.
Доступ к приложению manager по умолчанию защищено: вам надо определить пользователя с ролью «manager» в /etc/tomcat6/tomcat-users.xml для получения к нему доступа.
Второе приложение — это host-manager , которое по умолчанию доступно вам по адресу http://yourserver:8080/host-manager/html . Оно может быть использовано для создания виртуальных хостов динамически.
Доступ к приложению host-manager также закрыто по умолчанию: вам надо определить пользователя с ролью «admin» в /etc/tomcat6/tomcat-users.xml для получения к нему доступа.
По соображениям безопасности пользователь tomcat6 по умолчанию не может писать в каталог /etc/tomcat6. Некоторые возможности в этих приложениях администрирования (разработка приложений, создание виртуальных хостов) требуют права записи на этот каталог. Если вы хотите пользоваться этими возможностями, выполните следующее для предоставления группе tomcat6 необходимых прав:
Sudo chgrp -R tomcat6 /etc/tomcat6 sudo chmod -R g+w /etc/tomcat6
Приложения примеров Tomcat
Пакет tomcat6-examples содержит два приложения, которые могут быть использованы для тестирования или демонстрации возможностей сервлетов и JSP, которые по умолчанию вы можете найти по адресу http://yourserver:8080/examples . Вы можете установить их следующей командой в терминале:
Sudo apt-get install tomcat6-examples
Использование пользовательских экземпляров
Tomcat в большей степени используется при разработке и тестировании , когда использование одиночной оболочки на сервере не удовлетворяет требованиям множества пользователей на одной системе. Пакеты Tomcat 6.0 в Ubuntu поставляются с инструментарием, помогающим создать ваши собственные настроенные на пользователя оболочки, позволяя каждому пользователю в системе запускать (без прав суперпользователя) отдельные частные экземпляры, при том, что они будут использовать библиотеки, установленные в системе.
Существует возможность запускать общий и частные экземпляры в параллель, до тех пор пока они не используют одни и те же TCP порты.
Установка поддержки частных оболочек
Вы можете установить все необходимое для запуска частных оболочек вводом следующей команды в терминале:
Sudo apt-get install tomcat6-user
Создание частного экземпляра
Вы можете создать каталог частной оболочки вводом следующей команды в терминале:
Tomcat6-instance-create my-instance
Это создаст новый каталог my-instance со всеми необходимыми подкаталогами и сценариями. Вы можете, например, установить свои общие библиотеки в подкаталог lib/ и развернуть свои приложения в подкаталоге webapps/. По умолчанию никакие приложения не разворачиваются.
Настройка вашего частного экземпляра
Вы обнаружите обычные файлы настроек Tomcat для вашего частного экземпляра в подкаталоге conf/. Вы конечно же можете отредактировать файл conf/server.xml для изменения портов по умолчанию, используемых вашим частным экземпляром Tomcat для предотвращения конфликтов с другими экземплярами, которые также могут быть запущены.
Запуск/остановка вашего частного экземпляра
Вы можете стартовать свой частный экземпляр, набрав следующую команду в терминале (подразумевается, что ваш экземпляр расположен в каталоге my-instance):
My-instance/bin/startup.sh
Вы можете проверить подкаталог logs/ на предмет обнаружения каких-либо ошибок. Если вы получили ошибкуjava.net.BindException: Address already in use:8080 , это означает, что порт, который вы используете уже занят и вам следует его поменять.
Вы можете остановить свой экземпляр, используя следующую команду в терминале (подразумевается, что ваш экземпляр все еще находится в каталоге my-instance).
Молодые программисты часто задают вопрос: а зачем нужны зачастую довольно тяжелые и дорогие промышленные сервера приложений (такие как JBoss AS , Oracle WebLogic , IBM WebSphere AS ), если у нас есть замечательный легковесный фреймворк Spring и контейнер сервлетов Apache TomCat . Попробуем на него ответить. Сразу замечу, речь сейчас не идет об архитектуре приложения! Не важно, используете вы EJB или нет. Предположим, у вас приложение на Spring Framework и стоит вопрос, на чем его запускать. Итак, какие дополнительные сервисы предлагает нам сервер приложений.
- Пулы соединений с БД . Да, у TomCat тоже есть пул соединений, но каковы его возможности? Может ли он периодически тестировать доступность СУБД и обновлять соединения в случае восстановления после сбоев? Умеет ли он делать замену прав доступа? Грубо говоря, подключаемся к БД под пользователем в зависимости от того, кто аутентифицировался в нашем приложении, если часть логики вынесена на уровень СУБД, то это бывает полезно. Может ли пул соединений Tomcat балансировать нагрузку между несколькими базами данных (например, в случае Oracle RAC ), а так же определять, что вот эти узлы RAC умерли и теперь к ним не нужно пытаться подключаться, а затем понять, что они снова доступны и теперь их тоже можно использовать? В конце концов, может ли ваш пул соединений защитить от некорректного кода в приложении, которое по недосмотру не возвращает соединения, просто отбирая его после какого-то таймаута?
- JMS . Если вы хотите использовать очереди в вашем приложении, развернутом на TomCat , то придется отдельно еще поднимать сервера очередей сообщений. В случае сервера приложений, очереди как правило доступны их коробки. Вместе с очередями доступны так же следующие вещи: кластеризация - вы можете строить распределенные очереди, расположенные сразу на нескольких серверах, что существенно увеличивает масштабируемость и доступность вашего приложения, миграция - в случае падения одного из серверов, его очереди автоматически перемещаются на другой, сохраняя необработанные сообщения. В некоторых серверах приложений поддерживается Unit-of-Order - гарантированный порядок обработки сообщений, удовлетворяющих некоторым критериям, очень часто при интеграции бывает полезен.
- JTA . Те самые распределенные транзакции. Кто-то их понимает и использует, кто-то считает слишком тяжелыми. Как правило это так, они слишком тяжелые, но если вам нужно обеспечить согласованность данных в СУБД, разнесенных по разным углам нашей необъятной, или в СУБД и очереди, то без таких транзакций будет трудно. Суть распределенных транзакций в том, что мы не коммитим ни в одну из БД, пока не убедимся, что все БД, участвующие в транзакции, смогут принять наши данные. Тем самым мы избегаем проблемы “с одного счета в одном банке деньги списали, а на другой - в другом банке - не зачислили - сработало ограничение целостности”.
- Безопасность . Современные сервера приложений предоставляют множество различных провайдеров безопасности. Доступны различные провайдеры аутентификации, вы можете хранить ваших пользователей во множестве мест: во встроенном LDAP -сервере, в базе данных, во внешнем LDAP -сервере, в различных Internet-directory - специализированных приложениях для управления правами доступа. Возможны следующие сценарии: на работу наняли человека, добавили его в , там запустился процесс раздачи прав, который выдал человеку права на все ресурсы вашего предприятия и теперь каждый сервер приложений в вашей компании (а их может быть очень много) видит эти права, так как подключен к этой Internet-directory/Access-manager . Доступно разделение пользовательской сессии между приложениями: мы аутентифицировались в одном приложении - нам уже не нужно аутентифицироваться в другом. Так же доступна реализация Single-Sign-On : вы делаете один из серверов базой для хранения пользователей, все другие сервера при аутентификации пользователя обращаются к этой базе. Реализуется SSO посредством Security Assertion Markup Language (SAML) 1/2 или посредством Simple and Protected Negotiate (SPNEGO) и Kerberos для Windows -клиентов. Возможна авторизация посредством протокола eXtensible Access Control Markup Language (XACML) , позволяющего описывать довольно сложные политики (например, приложение доступно пользователю только в рабочее время). Опять же все данные возможности работают в кластерном окружении. Впрочем, стоит отметить, что с помощью Spring Security и Apache Shiro можно реализовать большинство из них, но вам придется “тянуть” эти реализации за каждой вашей программой, в то время как в сервере приложений они доступны из коробки.
- Масштабируемость и высокая доступность . Да, для TomCat мы можем настроить кластеризацию, но она будет довольно примитивной. Мы не сможем сделать передачу пользовательской сессии из одного центра обработки данных (ЦоД) в другой через Интернет, мы не сможем эффективно настроить репликацию сессий на большом кластере, состоящем из 40-50 экземпляров сервера приложений. В случае сбоев, мы не сможем обеспечить миграцию экземпляров сервера на другую машину и т.д. Так же в TomCat нет механизмов автоматического мониторинга и реакции на ошибки: мы не можем автоматически перезапустить экземпляр сервера, если на нем зависло 10 потоков, мы не можем автоматически отправить письмо администратору при переполнении пула соединений и т.д.
- Управляемость . В случае большого кластера TomCat у нас нет единого центра управления, т.н. AdminServer и аналога NodeManager’ а. Мы не сможем одновременно запустить на старт 50 экземпляров сервера. Мы не можем посмотреть состояние экземпляров, посмотреть сколько у нас обработчиков на той или иной очереди, на том или ином сервере, сколько создано соединений с той или иной БД, какие из них можно убить, какие в данный момент выполняются транзакции, какие ресурсы в них задействованы и т.д. Конечно, можно все сделать “за три минуты на скриптах, ну как в Линуксе принято”, но результат будет плачевный.
- Скриптовый язык . Кстати о скриптах, большинство промышленных серверов приложений содержат утилиты для выполнения скриптов как правило на языке Python , Пользоваться данными утилитами одно удовольствие. Администратор может описать в виде скрипта все шаги для подготовке к развертыванию сколь угодно большого приложения, таким образом запуск в продуктив или обновление займет сравнительно немного времени. С помощью таких скриптов можно создавать источники данных (представьте себе сервисную шину, подключенную к 120 экземплярам БД), JMS -очереди, менеджеры потоков, создавать новые экземпляры серверов и добавлять их в кластер, выполнять остановку и запуск серверов, их миграцию.
- Административный канал и развертывание в промышленном режиме . Некоторые сервера приложений позволяют включить так называемый административный канал - отдельный порт, защищенный SSL , запросы по которому имеют приоритет. Таким образом, даже если ваш сервер завис, вы сможете на него зайти и посмотреть, какие транзакции выполняются и какие потоки висят. Но у данного канала есть и другое применение. При обновлении приложения вам не нужно выключать старую версию! Вы можете добавить на сервер новую версию приложения в административном режиме - пользователи продолжают работать со старой, а по административному каналу доступна новая, соответственно мы можем выполнить последнее тестирование перед запуском, проверить все ли у нас правильно развернулось. Затем мы окончательно публикуем приложение, при этом пользователи, уже имеющие сессию, продолжают работать со старой версией, чтобы не потерять данные. Новые пользователи аутентифицируются на новой версии. Тем самым мы обновляем приложение без его простоя, что очень важно для критических систем.
Как мы видим, сервисов, предоставляемых промышленными серверами приложений, довольно много. Возникает вполне закономерный вопрос, а почему сервлет-контейнер TomCat такой популярный? Здесь есть несколько соображений:
- В первую очередь, цена. За все хорошее нужно платить, за отличное платить еще больше, особенно, если мы хотим доступ к технической поддержке и патчам. К примеру, сервер приложений Oracle WebLogic в базовой комплектации стоит $10 000/processor (под processor здесь понимается одно ядро, умноженное на т.н. core factor ). Не каждый заказчик может себе позволить такое решение.
- Не всем приложениям нужны вышеперечисленные сервисы, а иногда разработчики не умеют ими пользоваться. Например, если у нас простая учетная система, работающая с одной БД, то нам не нужны распределенные транзакции. С другой стороны, масштабирование. Приложение может следовать всем Java EE спецификациям, но при этом не быть масштабируемым. Простой пример: приложение читает из БД измененные записи (которые пишутся с помощью триггеров в отдельную табличку) и передает их в другую БД. При этом авторы как-то забыли про блокировки. Если мы запустим данную программу на кластере, то у нас каждая запись будет обрабатываться N -раз, по числу экземпляров TomCat в кластере. Такая масштабируемость нам не нужна. Аналогичные соображения можно привести и для других сервисов.
- Простота и легкость освоения. Вообще администратор сервера приложений это отдельная профессия, такая же как и администратор баз данных. Это не просто линукс-админ. Посмотрим еще раз на список сервисов и задумаемся как долго нужно изучать возможности выбранного сервера приложений по их реализации и настройке. Курсы по администрированию IBM WebSphere или Oracle WebLogic могут стоить десятки тысяч рублей.
- Сварим кашу из топора сами. Бывают ситуации, когда это необходимо. Не всегда есть смысл ждать патча, исправляющего какие-то критические для нашего приложения ошибки. Гораздо быстрее просто подменить версию библиотеки. Правда зачастую это можно сделать и на сервере приложений, добавив библиотеку к нашему приложению и настроив загрузчик классов. Причем современные сервера содержат в себе утилиты для поиска ошибок в иерархии загрузчиков.
Отдельно отметим причины популярности Spring Framework как на TomCat’ е, так и на промышленных серверах приложений и немного их прокомментируем:
- Исторические причины. Почему Spring Framework , а не EJB ? Ну потому что я в 88-м году программировал на С++ , фигня этот ваш С++ . Да, действительно EJB 1.1 и EJB 2.x были очень тяжелы для освоения и для использования, но времена меняются. Опять же, начиная с Java EE 6 , появился легковесный IoC -контейнер - CDI . Зачем тянуть в свое приложение сотни мегабайт библиотек, которые будут существенно замедлять процесс развертывания, если можно использовать готовые и довольно качественные реализации, предоставленные производителем сервера приложений? На самом деле иногда есть зачем.
- Баланс между завязкой на конкретном производителе и переносимостью. Да, EJB это часть спецификации Java EE , причем наиболее сложная, сложнее только J2CA и по хорошему приложения, написанные для одного сервера, должны работать на другом. На практике это не всегда так. Зачастую для эффективного использования всех возможностей сервера приложений приходится в коде вызывать его API , а это уже делает приложение непереносимым. Правда, справедливости ради, с каждой новой версией Java EE таких завязок становится все меньше. С другой стороны, даже без явных завязок на API части стандарта могут быть реализованы разными серверами по своему, например, один сервер будет закрывать EntityManagerFactory при остановке приложения, другой - нет. Реализации иерархии загрузчиков классов так же могут отличаться.
- При этом, явная завязка на Spring Framework тоже имеет свои минусы. Это такая же завязка на производителе, как и решение использовать только WebLogic . Но если с WebLogic хоть и со скрипом мы сможем уйти, то со Spring Framework скорее всего нет. Что будет, если завтра ведущие разработчики решат оставить свое детище и все дружно перейти в Oracle ? Впрочем, думаю, что вероятность такого сценария не высока.
- Отдельно стоит отметить поддержку Spring Framework со стороны разработчиков серверов приложений. Например, в Oracle WebLogic можно включить отдельную страницу в консоли администрирования для каждого построенного на данном фреймворке приложения. На странице будет отображено дерево бинов и показаны их свойства. Так же доступны бины самого сервера и упрощена разработка MBean ’ов. Помимо этого, Spring Framework прозрачно интегрируется в кластерное окружение, а Spring Security может использовать подсистему безопасности сервера приложений.
В заключение хочется отметить, что выбор платформы для приложения это довольно нетривиальная инженерная задача, в которой должна учитываться масса факторов. Это и соотношение стоимости разработки к стоимости поддержки (при этом нужно учитывать, что разработка может идти год, а использоваться ПО может десяток лет), стоимость самих серверов приложений, ваши отношения с вендором, т.к. несмотря на высокую номинальную стоимость зачастую предоставляются скидки под 80%. Учитывайте вашу и вашей команды квалификацию в конце концов. Ну и не нужно быть ретроградом, если вы в 2001-м писали на EJB и с тех пор смотреть на них не можете, то это еще не повод отказываться от этой замечательной технологии и реализующих ее серверов приложений, но даже если вы гуру Spring Framework , подумайте, может быть для него на промышленном сервере тоже найдется место?
