Tomcat: умный котег для Java-программиста

Помня свое обязательство рассказать про написанный на Java и для Java веб-сервер Tomcat, начать хотел бы с такого понятия, как сервлет. Появилось оно в конце 90-х, когда популярность Java была, можно сказать, в зените и в ходу у веб-разработчиков были апплеты. Они представляли собой встраиваемые в html-странички "приложеньица", умевшие примерно то же, что нынешние Flash и AJAX. Java всегда стремилась проникнуть во все сферы программирования, так что написанные на этом языке программки, исполняемые на стороне сервера и призванные заменить популярные тогда perl-скрипты (CGI) не заставили себя долго ждать. Сначала их "прикручивали" к веб-серверам любительскими способами (вот ссылка, датируемая 1998 годом для интересующихся историей Java). Потом фирма Sun, идя навстречу пожеланиям трудящихся, разработала Servlets API, позволяющее создавать на стороне сервера сколь угодно сложные и при этом удобно организованные обработчики веб-запросов.

Сервлет написать очень просто (см., например, здесь). Но нужен еще сервер, который эти сервлеты содержит и управляет их жизненным циклом. Им и является Tomcat. Написан он на Java, разработан в недрах сообщества Apache. Взять его можно, например, здесь. Последняя версия - 6.018 и нужно отметить, что уж с год, наверно, этот продукт не обновлялся. Видимо, это связано с вытеснением "котега" такими продуктами, как JBoss или даже такими новомодными вещами, как Google Servlets Engine (на которой, если не ошибаюсь, построен сервис Gmail). И все-таки Tomcat - очень популярное, достаточно легкое в освоении и полноценное с точки зрения веб-серверного функционала решение для тех, кто предан своему языку программирования и не хочет дополнительно пудрить себе мозги такими вещами, как PHP (чур меня, чур!).

Tomcat поддерживает работу на уровне сессий, умеет взаимодействовать практически с любыми базами данных, обрабатывать JSP (html-страницы с встроенными кусками компилируемого "на лету" java-кода на манер PHP, ASP и т.п.), полноценно работает по https . Короче говоря, как устанавливать.

Скачав архив, распакуйте его... куда-нибудь. Я использую особый каталог в домашней директории и, кстати говоря, всегда запускаю Tomcat не от имени пользователя root, а от имени обычного пользователя (например, tomcat).  Вся настройка сводится к тому, что вы выясняете, где у вас "живет" Java и прописываете этот путь в переменную окружения JAVA_HOME. Я устанавливаю Java (JDK или JRE) в каталог /opt/java/sun. Следовательно, настройка Tomcat у меня заключается в добавлении в начало файла bin/setclasspath.sh (относительно каталога, куда распакован Tomcat) строки

JAVA_HOME=/opt/java/sun

В том же томкатовском каталоге bin лежат скрипты для запуска (./startup.sh) и остановки (./shutdown.sh) сервера. Кстати говоря, там же есть и версии для "виндусятников" (startup.bat и shutdown.bat), поскольку Tomcat'у, как и любому Java-приложению абсолютно пофиг на какой платформе работать. Итак, переходим в каталог bin распакованного дистрибутива, правим setclasspath.sh и вводим ./startup.sh. После этого в браузере можно ввести http://localhost:8080 и увидеть корневую страничку локального Tomcat'а со ссылками на документацию, примеры и даже панель администратора (http://localhost:8080/manager), с которой можно управлять отдельными веб-приложениями, видеть сколько соединений с сервером установлено и т.д. Правда, войти с первого раза в панеть не получится: Tomcat попросит вас сначала настроить один конфигурационный файлик (прописать логин/пароль для доступа), но это так просто, что пусть останется маленьким "домашним заданием".

Структура каталогов Tomcat такова:

Про bin мы уже поговорили; в conf, понятное дело, - конфигурационные файлы, в которых по первости нет нужды ничего менять; в libs - библиотеки (например, драйвера для связи с базами данных); в logs - логи (самый главный в процессе отладки - catalana.out, в него попадают все сообщения об ошибках и всевозможные отладочные System.out.println(...)); temp и work - системные каталоги, куда Tomcat пишет какую-то свою информацию и человеку там вообще делать нечего. А вот webapps - это как раз то место, куда программист выкладывает свои веб-приложения. Выкладывать их можно в виде WAR-архивов (отличаются от Jar-архивов только наличием в них конфигурационного файла WEB-INF/web.xml). Обнаружив такой архив, Tomcat его самостоятельно распаковывает и запускает веб-приложение (совокупность html-страничек, а также сервлетов и jsp). Можно закидывать веб-приложения и напрямую, тупым копированием (иногда, правда, приходится перезапускать Tomcat, чтобы он увидел новые каталоги внутри webapps). Безымянное "корневое" веб-приложение сервера находится в каталоге webapps/ROOT.

Предыдущие ораторы делали акцент на подключении баз данных к веб-приложениям. В случае Java-сервлетов считаю такой экскурс совершенно излишним. Тот, кто умеет пользоваться JDBC, без труда подключит к своим сервлетам любую базу данных, а JDBC - это отдельная песня, которую в двух строках не расскажешь.

В заключение хочу поделиться тонкостью, которая не лежит на поверхности, но рано или поздно начинающий пользователь Tomcat с ней сталкивается. Когда нужно организовать доменное имя, требуется, чтобы веб-сервер работал на 80-м порту, а Tomcat по умолчанию работает на 8080. Можно, конечно, переконфигурировать, но огда придется запускать нашего котега от имени пользователя root, что нежелательно. Решение - прописать в файрволе следующее правило:

iptables -t nat -A PREROUTING -d 10.1.21.21 -p tcp --dport 80 -j REDIRECT --to-ports 8080

Это если, конечно, на 80-м порту не болтается у вас стандартный Apache, что, кстати, очень даже не исключено: два веб-сервера вполне могут мирно уживаться на одном хосте. Их можно просто разнести по разным сетевым интерфейсам (если таковых больше чем один).

Ну типа и всё. Если есть вопросы - велкам к нашим полкам!