Меню
ГлавнаяИгры

Tomcat примеры. Установка Apache Tomcat. Добавление юзера tomcat

Следующий шаг после установки 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 для и в данном элементе, определив их и связав с помощью .

Результаты этого метода эквивалентны добавлению элементов в файл приложения “/WEB-INF/web.xml”. Если используете эту технику, проверьте, что вы определили дополнительные параметры, которые необходимы, чтобы задать и настроить объект-фабрику и свойства.

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.

В сегодняшнем посте рассмотрим весь процесс компиляции tomcat из исходников, а затем его настроим и запустим. Эксперимент будем проводить на linux ubuntu на примере tomcat 7 .
Первый вопрос который может появится, что тут сложного? А второй, зачем вообще его компилировать из исходников, если можно взять уже готовый бинарный дистрибутив? Ну во-первых это вообще интересно как этот tomcat собирать из исходников, а во-вторых все кто когда-либо имел дело с установкой tomcat , вся его установка сводилась к скачиванию бинарного дистрибутива и его запуском, то есть выполнением скрипта ./startup.sh , а в виндовс мире так там вообще все еще проще, там инсталятор создает ярлыки запуск в меню start . Тут же мы пройдем через все шаги от скачивания исходников, до более или менее тонкой настройки tomcat .

Для этого поста на понадобится:

  1. JRE — виртуальная java-машина на которой выполняется tomcat .
  2. Apche ant — инструмент для сборки приложений
  3. Исходники tomcat — это просто непонятный для машины текст, который ничем не отличается от текста этого поста (в смысле тоже состоит из символов), и который надо преобразовать в бинарный код, понятный машине.

Добавление юзера tomcat

Начнем с того, что добавим пользователя tomcat который будет ответственен за веб-сервер tomcat , то есть администратора веб-сервера tomcat . Для чего он нужен? Он нужен для того, чтобы только он мог запускать и останавливать сервер, плюс только он может (вместе с рутом) изменять конфигурацию сервера.

sudo useradd -d /home/tomcat -U tomcat

ключ -d означает домашняя директория, ключ -U имя пользователя.
После того как юзер tomcat создан зададим ему пассворд:

sudo passwd tomcat Введите новый пароль UNIX: Повторите ввод нового пароля UNIX: passwd: пароль успешно обновлён

Теперь сделаем юзера tomcat сюдоером:

sudo adduser tomcat sudo Добавляется пользователь «tomcat» в группу «sudo» ... Добавление пользователя tomcat в группу sudo Готово.

Чтобы проверить, что юзер tomcat стал сюдоером можно открыть файл /etc/group и найти в нем строку: sudo:x:27:#####,#####,tomcat
Или переключиться в юзера tomcat и ввести команду (как переключаться в другого юзера, чуть дальше):

sudo whoami

Если команда sudo whoami вернет root значит юзер tomcat стал сюдоером. Поясню почему команда whoami возвращает рута , а не tomcat , потому что когда запускается какая-нибудь команда с sudo , это значит, что она запускается от имени рута , соответственно команда sudo whoami запускается как рут и результат будет пользователь рут .
Теперь создадим домашний каталог для юзера tomcat :

sudo mkdir /home/tomcat

И назначим владельца каталога юзера tomcat :

sudo chown tomcat /home/tomcat

Теперь переключимся в пользователя tomcat и перейдем в его домашний каталог:

su tomcat Пароль: cd

Скачавание исходников tomcat

В предыдущем шаге мы создали юзера tomcat и перешли в его домашний каталог. Теперь создадим в его домашнем каталоге каталог downloads и перейдем в него:

mkdir downloads cd downloads

Теперь переходим на сайт http://tomcat.apache.org/download-70.cgi для скачивания исходников, которые можно найти в самом низу страницы в разделе Source Code Distributions и скачайте их в каталог downloads который мы только что создали.
Измените владельца этого архива на tomcat (если надо):

sudo chown tomcat apache-tomcat-7.0.54-src.tar.gz password for tomcat:

Разпакуйте архив в текущий каталог:

tar xvzf apache-tomcat-7.0.54-src.tar.gz

а архив можно удалить:

rm apache-tomcat-7.0.54-src.tar.gz

Установка apache-ant

Компилировать tomcat будем с помощью сборщика apache-ant . Заходим на сайтapache-ant и скачиваем дистрибутив в каталог downloads . На момент написания поста, последний был 1.9.4 .
Распакуем его в текущий каталог:

tar xvzf apache-ant-1.9.4-bin.tar.gz

Переместим его в общий каталог /usr/bin

sudo cp apache-ant-1.9.4-bin.tar.gz /usr/bin

Теперь добавим этот путь в переменную окружения PATH для того:

PATH=/usr/bin/apache-ant-1.9.4:$PATH

Удаляем архив и распакованный каталог из каталога downloads :

rm -rf apache-ant*

Ключ -r нужен для того, чтобы каталог apache-ant-1.9.4-bin был удален рекурсивно, а ключ -f чтобы linux не выводила предупреждение, что архив apache-ant-1.9.4-bin.tar.gz защищенный.
Теперь проверим, что apache-ant видим:

ant -version Apache Ant(TM) version 1.9.4 compiled on April 29 2014

Если ответ такой, то значит переходим к компиляции tomcat , если нет, то еще раз пройдите через шаг Установка apache-ant .

Компиляция tomcat

И так каталог с исходниками tomcat скачен и распакован, apache ant настроен, теперь заходим в каталог с исходниками tomcat :

cd apache-tomcat-7.0.54-src.tar.gz

открываем на редактирование файл build.properties.default :

build.properties.default

# ----- Default Base Path for Dependent Packages ----- # Please note this path must be absolute, not relative, # as it is referenced with different working directory # contexts by the various build scripts. base.path=/usr/share/java #base.path=C:/path/to/the/repository #base.path=/usr/local

Ищем в нем строчку #base.path=/usr/local , раскомментируем ее и изменим путь на /home/tomcat/downloads/tomcat (строчка 7):

build.properties.default

# ----- Default Base Path for Dependent Packages ----- # Please note this path must be absolute, not relative, # as it is referenced with different working directory # contexts by the various build scripts. base.path=/usr/share/java #base.path=C:/path/to/the/repository base.path=base.path=/home/tomcat/downloads/tomcat

Что мы сейчас сделали? Мы указали каталог, куда билдскрипт будет скачивать необходимые для сборки исходники. Затем переименуем файл в build.properties :

mv build.properties.default build.properties

И теперь мы дошли до компиляции tomcat . Сначала очистим каталог:

ant clean clean-depend

и с компилируем tomcat командой ant -Dno.build.dbcp=true :

ant -Dno.build.dbcp=true

Если в все было сделано правильно, то билд должен вернуть BUILD SUCCESSFUL :

Build: Compiling 31 source files to /home/tomcat/downloads/apache-tomcat-7.0.54-src/output/jdbc-pool/classes warning: bootstrap class path not set in conjunction with -source 1.5 warning: source value 1.5 is obsolete and will be removed in a future release warning: target value 1.5 is obsolete and will be removed in a future release warning: To suppress warnings about obsolete options, use -Xlint:-options. 4 warnings Building jar: /home/tomcat/downloads/apache-tomcat-7.0.54-src/output/jdbc-pool/tomcat-jdbc.jar Copying 1 file to /home/tomcat/downloads/apache-tomcat-7.0.54-src/output/build/lib BUILD SUCCESSFUL Total time: 23 seconds

если это так, то поздравляю, компиляция tomcat прошла успешно, и его билд должен появится в каталоге output/build .

Настройка tomcat

После того как tomcat успешно с компилирован, теперь под настроем его чуть-чуть. Сначала перенесем его в более приемлемый каталог, пусть это будет каталог bin где юзер tomcat будет складывать все свои бинарные приложения.
Создадим каталог bin в домашнем каталоге юзера tomcat :

mkdir bin

Теперь перенесем с компилированный tomcat в каталог bin :

cp -r /home/tomcat/downloads/apache-tomcat-7.0.54-src/output/build /home/tomcat/bin

Напоминаю сам tomcat с компилирован в каталог build .
Далее перейдем в каталог /home/tomcat/bin и переименуем каталог build на что-то по понятней, например на apache-tomcat-7 :

mv build apache-tomcat-7

По умолчанию все веб-приложения помещаются в каталог webapps каталога {$CATALINA_HOME} . Мы создадим отдельный каталог куда будут помещаться веб-приложения, чтобы в сам каталог {$CATALINA_HOME} не заходить без надобности, так как файлы веб-приложения могут меняться относительно часто в отличие от файлов самого контейнера сервлетов.
Перейдем в домашний каталог юзера tomcat и создадим каталоге с таким же именем webapps :

cd mkdir webapps

Теперь самое важное, у нас есть каталог веб-сервера /home/tomcat/bin/apache-tomcat-7 и есть каталог /home/tomcat/webapps куда будут помещаться веб приложения. Ограничим к ним доступ до юзера tomcat :

sudo chmod -R 700 /home/tomcat/bin/apache-tomcat-7 password for tomcat: sudo chmod -R 700 /home/tomcat/webapps

Теперь пропишем путь к каталогу, в который будем помещать все вэб-приложения, в конфигурационном файле сервера server.xml . Перейдем в каталоге bin/apache-tomcat-7/conf , где хранятся все файлы конфигурации сервера, и откроем на редактирование файл server.xml . В теге Host поменяем значение атрибута appBase с webapps на /home/tomcat/webapps (строчка 124):

server.xml

Теперь добавим админку, с помощью которой юзеры смогут деплоить веб приложения, но для них юзер tomcat должен выдать соответствующие права. Но юзер tomcat выдаст себе права. Для этого переходим в каталог conf :

cd /home/tomcat/bin/apache-tomcat-7/conf

и открываем на редактирование файл tomcat-users.xml .
Раскомментируем последние пять тегов, и добавим роли для usrename tomcat :

  • manager
  • manager-gui
  • admin-gui

    • Строчка 31:

    tomcat-users.xml

    Теперь удалим юзера tomcat из группы sudo . Зачем это делать? Затем, что sudo детям не игрушка, нам нужно было назначить юзера tomcat сюдоером, чтобы не переключаться постоянно в сюдоера, если нам надо было установить права на каталог где будут лежать веб-приложения и проч. Но а теперь, когда уже все сделано и мы точно знаем, что юзер tomcat не будет заниматься никакими другими админискими задачами кроме как запускать/останавливать сервер и настройку этого сервера, то и не зачем ему быть сюдоером. Для этого перейдем в другого сюдоера, и выполним от имени того другого сюдоера команду:

    sudo gpasswd -d tomcat sudo Удаление пользователя tomcat из группы sudo

    Здесь у команды gpasswd ключ -d означает удалить юзера tomcat из группы sudo .
    И последнее что осталось нам сделать это скопировать все веб-приложения из каталога /home/tomcat/bin/apache-tomcat-7/webapps в наш созданный каталог /home/tomcat/webapps :

    cp -r /home/tomcat/bin/apache-tomcat-7/webapps/* /home/tomcat/webapps

    Запуск веб-сервера tomcat

    Все готово для запуска веб-сервера tomcat . Перейдем в каталог /home/tomcat/bin/apache-tomcat-7/bin и запустим скрипт ./startup.sh :

    Cd /home/tomcat/bin/apache-tomcat-7/bin ./startup.sh Using CATALINA_BASE: /home/tomcat/bin/apache-tomcat-7 Using CATALINA_HOME: /home/tomcat/bin/apache-tomcat-7 Using CATALINA_TMPDIR: /home/tomcat/bin/apache-tomcat-7/temp Using JRE_HOME: /usr/java Using CLASSPATH: /home/tomcat/bin/apache-tomcat-7/bin/bootstrap.jar:/home/tomcat/bin/apache-tomcat-7/bin/tomcat-juli.jar Tomcat started.

    Проверим, что tomcat запущен, для этого перейдем по линке http://localhpst:8080 и должна появится стартовая страница tomcat :

    Теперь зайдем в админку, жмем на батон

    Проект, который реализует спецификацию контейнера сервлетов и спецификацию JavaServer Pages (JSP). Используется в качестве самостоятельного сервера веб-приложений, в качестве сервера контента в связке с веб-сервером Apache, а также в качестве контейнера сервлетов в серверах приложений JBoss и GlassFish.
    В лабораторной работе предполагается установка и настройка Tomcat в качестве сервера веб-приложений под управлением ОС OpenSuSE 12.2.

    Цель работы: Установить и произвести базовую настройку Apache Tomcat в качестве сервера веб-приложений.

    Задания к работе

    1. Установить Java-окружение из пакета OpenJDK.
    2. Установить Tomcat.
    3. Запустить Tomcat и проверить его работу по адресу http://localhost:8080.
    4. Написать JSP-страницу test.jsp, выводящую произвольную строку.
    5. Написать сервлет test, выводящий произвольную строку.
    6. Написать стартовую страницу 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-сервере по соображениям безопасности.

    ... default org.apache.catalina.servlets.DefaultServlet debug 0 listings true 1 ...

    conf/context.xml - Установка автоматической перезагрузки страниц

    Имеется возможность заставить Tomcat выполнять автоматическую перезагрузку после изменения кода. Нужно добавить атрибут reloadable со значением "true" в элемент файла conf/context.xml. Это весьма полезно в процессе разработки и отладки сервлетов, но, опять же, не рекомендуется в готовом продукте.

    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("Servlet sample"); 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 веб-приложения. Структура этого файла для рассматриваемого примера будет примерно такой:

    aboutServer MyServlet aboutServer /about

    В такой конфигурации сервлет из файла MyServlet.class будет выполняться при обращении по адресу /myapp/about . Для КАЖДОГО сервлета должна быть описана пара и , связанная по элементу .

    Для того, чтобы изменения вступили в силу, требуется перезапустить сервер. Результат выполнения сервлета приведен на рис. 4.

    Рис. 4. Выполнение сервлета

    Подробную информацию о всех возможностях сервера Tomcat можно получить из документации, которая устанавливается вместе с сервером и доступна по адресу http://localhost:8080/docs/ или на официальном сайте проекта: http://tomcat.apache.org/ .

    Постоянный адрес этой страницы:

    Молодые программисты часто задают вопрос: а зачем нужны зачастую довольно тяжелые и дорогие промышленные сервера приложений (такие как 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 , подумайте, может быть для него на промышленном сервере тоже найдется место?

    Мне необходимо было настроить и запустить Tomcat на Mac OS X (Mountain Lion) и зарегистрировать данный сервер приложений (контейнер сервлетов) в NetBeans.
    Для того чтобы это сделать, я выполнил следующие пункты.

    Установка Tomcat
    1. Скачать архив Tomcat отсюда .
    2. Распаковать архив, например, в папку пользователя. ~/apache-tomcat-7.0.42
    3. Открыть программу «Терминал».
    4. Перейти в папку «bin» cd ~/apache-tomcat-7.0.42/bin и установить разрешение на запуск файлов с расширением.sh. sudo chmod +x ./*.sh
    5. Установить переменную окружения CATALINA_HOME. Для того чтобы она сохранилась не на время сессии в терминале, а постоянно, нужно ее прописать в файле «launchd.conf».
      Создать/открыть файл (пример приведен с помощью редактора vi, но можно использовать любой другой, например emacs): sudo vi /etc/launchd.conf
      Перейти в режим вставки: «клавиша s».
      Записать туда текст: setenv CATALINA_HOME /Users/ХХХ/apache-tomcat-7.0.42
      XXX - это имя вашего пользователя, если вы сохранили tomcat в папку пользователя как было указано в п.2, если нет, то укажите путь к папке, куда вы сохранили tomcat.
      Закрыть режим вставки «клавиша Esc».
      Перейти в режим команды «клавиша:».
      Сохранить файл, команда «wq».
    6. По умолчанию сервер настроен на порт 8080. Чтобы его изменить нужно перейти в папку «conf»: cd ~/apache-tomcat-7.0.42/conf
      Открыть там файл «server.xml».
      Найти тэг «Connector» где атрибут port равен «8080» и установить атрибут port в нужное Вам значение:
    7. По умолчанию пользователь, имеющий права публикации (deploy) на сервер через веб GUI или через скрипт, отключен. Его нужно прописать в файле «tomcat-users.xml». Для этого нужно перейти в папку «conf»: cd ~/apache-tomcat-7.0.42/conf
      Открыть там файл «tomcat-users.xml» и добавить следующее (имя пользователя и пароль можно использовать отличающиеся от приведенных):
    8. Перезагрузить компьютер, чтобы установленная переменная окружения CATALINA_HOME установилась.
    9. Открыть программу «Терминал».
    10. Перейти в папку «bin» cd ~/apache-tomcat-7.0.42/bin и запустить скрипт «startup.sh»
      sh startup.sh
      Должно отобразиться в терминале примерно следующее (в зависимости от ваших настроек системы): Using CATALINA_BASE: /Users/ХХХ/apache-tomcat-7.0.42 Using CATALINA_HOME: /Users/ХХХ/apache-tomcat-7.0.42 Using CATALINA_TMPDIR: /Users/ХХХ/apache-tomcat-7.0.42/temp Using JRE_HOME: /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home Using CLASSPATH: /Users/ХХХ/apache-tomcat-7.0.42/bin/bootstrap.jar:/Users/XXX/apache-tomcat-7.0.42/bin/tomcat-juli.jar
    11. Запустить браузер и набрать в адресной сроке http://localhost:8080 . Если вы поменяли порт, как было указано в п. 6, то укажите свой порт.
    12. Должна открыться домашняя страница tomcat.
    13. По кнопке «Server status» можно посмотреть статус поднятого сервера. Нужно будет ввести имя пользователя и пароль созданные ранее.
    14. По кнопке «Manager App» можно публиковать (удалять) приложения. Нужно будет ввести имя пользователя и пароль созданные ранее.
    15. Остановка сервера выполняется следующим образом. Перейти в папку «bin» cd ~/apache-tomcat-7.0.42/bin и запустить скрипт «shutdown.sh»
      sh shutdown.sh
    Регистрация сервера Tomcat в NetBeans
    1. Если была установлена 8 версия Tomcat, то необходимо сделать символьную ссылку на каталог библиотек.
      ln -s /Users/XXX/apache-tomcat-8.0.0-RC3/lib /Users/XXX/apache-tomcat-8.0.0-RC3/common/lib
    2. Открыть NetBeans
    3. Меню Сервис->Серверы
    4. В открывшемся окне нажать кнопку «Добавить сервер»
    5. В открывшемся окне выбрать «Apache Tomcat» и нажать кнопку «Далее»
    6. В следующей отображенной панели указать домашнюю папку Tomcat, например "/Users/ХХХ/apache-tomcat-7.0.42"
    7. Указать имя пользователя и пароль, созданные ранее. Нажать кнопку «Далее».
    8. Указать порт, если он был изменен ранее. Нажать кнопку «Готово».
    9. Для проверки можно создать Веб приложение и выбрать в качестве сервера приложений Apache Tomcat. После чего запустить его из NetBeans. Данное приложение развернется автоматически в Tomcat-е и запуститься в браузере, например под таким адресом: http://localhost:8090/WebApplication1 (обычно по умолчанию шаблон веб приложения содержит страничку jsp с текстом «Hello World!»).
    Примечание
    Это не относится к настройке Tomcat или регистрации сервера Tomcat в NetBeans, но некоторые приложения ищут java в папке /bin, а в Mac OS X java устанавливается в другие папки, но при этом есть символьная ссылка на java в папке /usr/bin.
    Таким образом нужно сделать еще одну символьную ссылку на java.
    sudo ln -s /usr/bin/java /bin/java