Установка Apache Tomcat в ОС Windows. Первоначальная настройка Tomcat и его регистрация в NetBeans

Оставьте комментарий 6,950

Нельзя сказать, чтобы среда разработки Java была сильно популярна на платформе Windows. В большинстве случаем на рынке хостинга присутствуют именно Unix решения с поддержкой Java. Но, тем не менее, разрабатываясь как мультиплатформенный язык программирования, Java ни чуть не хуже работает и на Windows платформе, что безусловно может использоваться как для отладки, так и для хостинга приложений на этой платформа. Дополнительную популярность на платформе Windows язык Java, как это ни странно, приобрел после выхода конкурирующего продукта непосредственно от разработчика Windows. Агрессивная политика Microsoft заставила задуматься многих специалистов о разработке более переносимого кода, который "в случае чего" можно будет портировать на Unix платформу с меньшими потерями.

Я не буду здесь касаться проблем выбора языка разработки, равно как и преимуществ одной платформы над другой. Будем считать, что вам просто понадобилась именно такая конфигурация: Windows+Tomcat.

Подготовительный этап

Разумеется любая настройка сервера начинается с подбора необходимых программных компонент. В нашем случае, все компоненты, кроме собственно ОС являются бесплатными или условно-бесплатными и могут быть успешно скачены из Интерента.

И так нам очевидно потребуется:

Компьютер с Windows

Компьютер с установленной Windows. Здесь и далее я буду рассказывать про Windows 2000 Server, но при этом я не вижу принципиальных сложностей, если вы захотите установить рассматриваемую конфигурацию на любую другую версию Windows. В частности, я по тексту буду упоминать о возможных отличиях в настройке ПО под другие версии ОС.

Если у вас система из NT-семейства, то начните с установки на нее последнего Service Pack (SP). Для NT очевидно потребуется SP6a, а для Windows 2000 как минимум SP2, без установки которого у вас элементарно не заработает Java 1.4.1. Инсталятор Java SDK вас предупредит о необходимости установки SP2 и будет прав, ибо без SP2 он действительно не работает.

Очевидно также, что на вашем компьютере должна стоять подключенная к сети сетевая карта с установленным и настроенным протоколом TCP / IP . В случае ее отсутствия, рекомендую установить и настроить виртуальную сетевую карту, т.н. "Microsoft loopback adapter", драйвер которого входит в дистрибутив Windows 2000.

Java JDK

Java JDK очевидно берется с сайта java.sun.com . На момент написания статьи последней была версия 1.4.1_02. Вам потребуется Java 2 JDK Standard Edition (J2SE).

Разумеется соблазнительно скачать сразу Enterprise Edition (J2EE), но как таковой отдельно этой версии не существует. Реализации классов J2EE есть часть соответствующих серверов приложений. Таким образом с сайта можно скачать лишь спецификацию на J2EE и другие подобные документы.

Далее - не стоит скачивать JRE. Во первых, JRE не включает в себя компилятор javac, то не позволяет разрабатывать приложения (что в общем то логично), а, во-вторых, установке Tomcat требует именно JDK. Это также очевидно, т.к. при работе с файлами JSP именно на Tomcat ложится задача по компиляции JSP в байт-код Java. Другое отличие JRE для Windows состоит в отсутствии в его составе серверной версии библиотек JIT-компилятора (подробнее о JIT – см. ниже). Также отмечу, что JDK самодостаточный комплект библиотек и отдельно JRE не нужен.

Tomcat

Начинаем установку

Надеюсь вы уже установили свежий Service Pack и необходимое число раз перезагрузили компьютер.

Установка Java SDK

При установке Java SDK ни в коем случае не ставьте ее в каталог предлагаемый по умолчанию. Введите каталог, путь которого как можно более короткий, без пробелов и других экзотических символов, например:

C:\j2sdk1.4.1_02

Tomcat

Если вы скачали ZIP-версию дистрибутива, то все что вам нужно, это распаковать ее в созданный для этого каталог, например:

C:\Tomcat

Если вы предпочли exe-версию дистрибутива, также обращаю ваше внимание на необходимость исключить из пути к каталогу пробелы, дабы избежать потом проблем с прописыванием переменных окружения.

Архив может иметь сложную структуру, соответственно вам нужно распаковать его так, чтобы при входе в каталог C:\Tomcat у вас отображались были каталоги bin, common, conf, logs и т.д.

Настраиваем Tomcat

Установка PATH

В принципе, установка PATH для работы Tomcat не обязательна и вы можете пропустить этот шаг, но в случае, если у вас установлено несколько Java JRE, установка PATH даст дополнительную подсказку различным программам, где искать библиотеки Java. В частности, без указания PATH может возникнуть конфликт с родной JVM от Microsoft, которая входит в некоторые версии Windows. Кроме этого, установка PATH потребуется для запуска из командной строки компилятора javac, который вам может потребоваться при дальнейшем тестировании сервера.

Таким образом, убедитесь, что у вас на компьютере работает только одна версия Java-машины и эта именно та версия, которую мы поставили. Для этого введите команду

SET PATH

и убедитесь, что в переменной PATH присутствует ссылка только на один каталог java\bin . В нашем случае это будет C:\j2sdk1.4.1_02\bin . Здесь будьте внимательны, т.к. java может входить в комплект к огромному числу разных программ, в частности, компания IBM и Oracle. Для верности, отредактируйте переменную PATH таким образом, чтобы ссылка на нашу Java была первой с списке. Напомню, что настройка переменных окружения в NT-семействе производится на вкладке Advanced свойств "Моего компьютера".

Проверить правильность настройки PATH можно так: зайдите в каталог C:\j2sdk1.4.1_02\bin и запустите команды java –version и javac из каталога C:\j2sdk1.4.1_02\bin . Затем перейдите куда-нибудь в другой каталог и повторите эти команды. Результат должен быть один и тот же.

Установка переменных окружения Tomcat

Теперь перейдем непосредственно к настройке Tomcat. Для своей работы он требует установки нескольких переменных окружения:

CATALINA_HOME должна указывать на каталог с установленным Tomcat. В нашем случае это C:\Tomcat .
JAVA_HOME должна указывать на каталог с SDK. В нашем случае, это: C:\j2sdk1.4.1_02 . Обратите внимания, что, в отличии от переменной PATH , данная переменная указывает не на каталог bin .

Пожалуйста проверьте правильность установки этих переменных окружения. При неверной установке, tomcat выводит совершенно невразумительное сообщение об ошибке, типа "The system cannot find the file -Djava.endorsed.dirs=.".

Для настройки Tomcat есть еще несколько переменных, но пока они нам не потребуются. Краткое описание этих и других переменных можно посмотреть в файле %CATALINA_HOME%\bin\catalina.bat

Хотелось бы напомнить, если в дальнейшем планируется запускать Tomcat как сервис (службу) Windows NT, нужно создавать и устанавливать системные переменные окружения (System variables), а не пользовательские (User variables). Также стоит напомнить, что для того чтобы установленные переменные вступили в силу, требуется перезапустить приложение, которое планирует их использовать. В нашем случае следует перезапустить sell (или FAR) из которого планируется тестовый запуск Tomcat.

Настройка порта

По умолчанию Tomcat "садиться" на порт 8080. Если этот порт у вас по каким-то причинам занят – найдите соответствующий параметр в файле %CATALINA_HOME%\conf\server.xml и исправьте по вкусу. Этот параметр выглядит приблизительно так:

В частности, если вы не планируете использовать IIS для доступа к Tomcat"у, то можете повесить Tomcat на порт 80 (только не забудьте отключить в этом случае IIS).

Отмечу, что, если порт на который вы устанавливаете Tomcat, занят, то Tomcat не запуститься и даже не оставит ни единого сообщения в log-файле. При этом окошко Tomcat"а закроется сразу после открытия. Аналогичная картина будет также в случае, если одна копия сервера уже запущена и случает указанный порт.

Запуск Tomcat

После того, как все указанные действия проделаны, запустите скрипт %CATALINA_HOME%\bin\startup.bat . У вас должно открыться новое текстовое окно и запуститься Tomcat. Указанный скрипт лучше запускать из командной строки, чтобы у вас была возможность прочитать выводимые сообщения об ошибках.

Для Windows 9x/ME разработчики также рекомендуют в свойствах файлах startup.bat и shutdown.bat установить параметр "Initial environment" на вкладке Memory в значение как минимум 4096. Т.к. в противном случае возможно аварийное завершение сервиса с сообщением "out of environment space". Это видимо связано с обилием переменных окружения, необходимых для работы сервера.

После этого откройте броузер и обратитесь по адресу http://127.0.0.1:8080 . Должен открыться локальный сайт, на котором, кроме прочего, присутствуют тестовые сервлеты и документация к Томкату. Tomcat запускается не сильно быстро, поэтому не торопитесь сразу открывать броузер.

Тюнинг JVM

Компилятор JIT (Just In Time) от Sun предлагает два режима работы – серверный и клиентский. По сути это два различных JIT, вызываемых командой java. В серверном режиме производится более тщательная оптимизация кода. Разумеется за оптимизацию приходится платить большим временем компиляции, но в случае с сервлетами, компиляция производится лишь единожды. Далее класс используется для обслуживания любого количества клиентов безе перекомпиляции. Таким образом для серверных решений Sun рекомендует использовать именно серверный режим JIT.

Из командной строки тот или иной режим запускается посредством указаний ключа -server или -client первым ключом командной строки.

Следующий важный параметр – объем доступной для виртуальной машины памяти (heap size). Секрет состоит в том, что по умолчанию объем максимально выделяемой памяти равняется 64Mb. Разумеется это катастрофически мало для серверного приложения и, запуская систему со значениями по умолчанию, оперирование в памяти с файлами объемом в пару десятков мегабайт будет приводить к останову сервлета с сообщением OutOfMemory.

Для настройки размеров выделяемой памяти служит два ключа: -Xms и -Xmx, которые отвечают за минимальный и максимальный объем соответственно.

Настройка указанных параметров для использования сервером Tomcat производится через еще одну переменную окружения - CATALINA_OPTS . В нашем случае переменная должна выглядеть приблизительно так:

CATALINA_OPTS = -server –Xms64m –Xmx256m

Что настроит серверный JIT, плюс установит выделяемый объем памяти в диапазоне от 64 до 256Mb

Установка Tomcat как сервиса

Для установки сервера как сервиса Windows NT, сайт Jakarta предлагает нам выполнить следующую "простую" команду (что любопытно, без каких либо комментариев):

%CATALINA_HOME%\bin\tomcat.exe -install Apache-Catalina %JAVA_HOME%\jre\bin\server\jvm.dll -Djava.class.path=%CATALINA_HOME%\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar -Dcatalina.home=%CATALINA_HOME% %CATALINA_OPTS% -Xrs -start org.apache.catalina.startup.BootstrapService -params start -stop org.apache.catalina.startup.BootstrapService -params stop -out %CATALINA_HOME%\logs\stdout.log -err %CATALINA_HOME%\logs\stderr.log

Если попытаться разобраться в этой команде, и отобразим контекстную помощь команды tomcat.exe, то мы получим приблизительно следующее описание параметров:

Install service_name jvm_library (jvm_option) -start start_class [-method start_method] [-params (start_parameter)+] [-stop start_class [-method stop_method] [-params (stop_parameter)+]] [-out out_log_file] [-err err_log_file] [-current current_dir] [-path extra_path]

Таким образом мы последовательно указываем:

Имя сервиса, которое будет отображаться в оснастке Services Windows. Имя сервиса используется также для создания имени ключа реестра, поэтому пробелов там быть не должно.
Указание ссылки библиотеки на библиотеку Java-машины с рядом необходимых параметров. Среди которых и параметры указанные нами в переменной CATALINA_OPTS . Собственно эта библиотека и будет загружена как сервис.
Указания на методы запуска и останова сервиса, также с необходимыми параметрами
Ссылки на файлы журналов и ряд других необязательных параметром.

Замечу что, рекомендованный код также использует параметр –Xrs для запуска библиотеки Java-машины. Данный ключ позволяет пользовательским приложениям корректно завершить работу в случае получения процессом сигнала на аварийное завершение. К сожалению, мне не удалось выяснить особенности реализации данного подхода в Windows, как и необходимости принятия каких либо дополнительных мер со стороны разработчика кода.

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

Tomcat.exe -uninstall service_name

где service_name – указанное нами при установке имя сервиса.

Все введенные нами данные аккуратненько размещаются в реестре по адресу:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\

Таким образом мы можем исправить отдельные параметры, не проводя перерегистрацию сервиса. Аналогичным образом мы можем исправить имя, отображаемое в оснастке и дать нашему сервису описание. Для этого, соответственно, служат значения DisplayName и Description указанного ключа.

Отмечу, что ошибка в JDK версии 1.3. приводила к аварийной остановке сервиса при выходе пользователя из системы. Поэтому если вы еще не скачали свежую версию JDK, сейчас самое время это сделать.

Конфигурация собственного Web-узла

По умолчанию Tomcat создает лишь один Web-сайт, плюс сваливает все в один каталог. Такое положение вещей редко подходит даже для тестового сервера. Таким образом проделаем несколько шагов для упорядочивания информации.

Итак, нам нужно создать виртуальный сайт, причем разместить его за пределами каталога сервера. В production сервера, каталоги виртуальных сайтов обычно размещаются на отдельном диске. Для нашего примера, я буду использовать каталог

C:\host1

В каталоге conf сервера Tomcat есть файл server.xml . В этом файле следует найти элемент . Внутри этого элемента по умолчанию описаны два коннектора: один для доступа по протоколу HTTP 1.1 и один для доступа по протоколу AJP 1.3. Первый используется для работы Tomcat"а в роли самостоятельного Web-сервера, а второй потребуется для подключения к IIS. Кроме этого, в теге Service , по умолчанию заданы шаблоны (закомментаринные по умолчанию) для коннекторов подключения по SSL и AJP 1.2.

Полученные запросы коннекторы передают так называемому Engine"у, который в свою очередь анализируют заголовок пакета HTTP и передает управления соответствующему виртуальному сайту.

Для создания виртуального сайта, нам потребуется создать новый тег Host внутри тега Engine.

Следует отметить, что у файла server.xml нет DTD , таким образом вы не сможете проверить корректность отредактированного файла. Таким образом правку файла server.xml следует проводить осторожно. При ошибке в файле server.xml , сервер не запустится, а в каталоге %CATALINA_HOME%/logs/stderr.log появится сообщение об этом.

Итак, определим виртуальный хост следующим образом:

www.host1.loc

Этой строкой мы создадим виртуальный сайт окликающийся по адресам http://host1.loc и с внутренним именем host1.loc. Кроме того мы указываем серверу, автоматически подключать скопированные в каталог appBase приложения и автоматически разворачивать скопированные туда WAR файлы.

Теперь мы можем скопировать в наш каталог приложение примеров (которое по умолчанию размещено в каталоге %CATALINA_HOME%\webapps\examples) и убедится, что оно работает по адресу!http://www.host1.loc/examples/servlets. Разумеется, для тестирования в файле HOSTS операционной системы нужно создать записи вида

195.42.130.28 host1.loc 195.42.130.28 www.host1.loc

Указав IP адреса вашей машины.

Замечу, что если мы обратимся просто по адресу http://www.host1.loc, мы получим ошибку, т.к. к этому адресу у нас не привязано ни одного приложения, а функция autoDeploy может привязывать только приложения с адресами http://www.host1.loc/<имя приложения>.

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

www.host1.loc

Новой строкой мы привязали наше приложение к корню сайта, плюс указали серверу отслеживать модификации файлов приложения и перегружать их при необходимости. Учитывая, что перезапуск сервера происходит сравнительно долго, данная функция крайне полезна при разработке.

Заключение

В полученной конфигурации Tomcat может вполне успешно функционировать как на тестовом, так и на production-сервере. Напомню, что в созданной нами конфигурации сервер самостоятельно обрабатывает HTTP запросы. При небольших и средних нагрузках Tomcat вполне справляется с этой ролью, в случае же больших требований, рекомендуется задействовать Tomcat лишь как контейнер сервлетов, а роль Web-сервера передать IIS или Apache.

Apache Tomcat - это контейнер, который позволяет вам использовать интернет приложения такие, как Java сервлеты и JSP (серверные страницы Java).

Пакеты Tomcat 6.0 в Ubuntu поддерживают два варианта запуска Tomcat. Вы можете установить его как классический одиночный экземпляр на всю систему, который будет запускаться при загрузке системы от имени непривилегированного пользователя tomcat6 . Но вы можете развернуть частные экземпляры, которые будут запускаться с правами вашего собственного пользователя, и вам придется запускать и останавливать их самостоятельно. Второй вариант особенно полезен в контексте сервера разработки, где нескольким пользователям требуется тестировать их собственные частные экземпляры 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).

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

Установка Tomcat

Скачать архив Tomcat отсюда .
Распаковать архив, например, в папку пользователя. ~/apache-tomcat-7.0.42
Открыть программу «Терминал».
Перейти в папку «bin» cd ~/apache-tomcat-7.0.42/bin и установить разрешение на запуск файлов с расширением.sh. sudo chmod +x ./*.sh
Установить переменную окружения 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».
По умолчанию сервер настроен на порт 8080. Чтобы его изменить нужно перейти в папку «conf»: cd ~/apache-tomcat-7.0.42/conf
Открыть там файл «server.xml».
Найти тэг «Connector» где атрибут port равен «8080» и установить атрибут port в нужное Вам значение:
По умолчанию пользователь, имеющий права публикации (deploy) на сервер через веб GUI или через скрипт, отключен. Его нужно прописать в файле «tomcat-users.xml». Для этого нужно перейти в папку «conf»: cd ~/apache-tomcat-7.0.42/conf
Открыть там файл «tomcat-users.xml» и добавить следующее (имя пользователя и пароль можно использовать отличающиеся от приведенных):
Перезагрузить компьютер, чтобы установленная переменная окружения CATALINA_HOME установилась.
Открыть программу «Терминал».
Перейти в папку «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
Запустить браузер и набрать в адресной сроке http://localhost:8080 . Если вы поменяли порт, как было указано в п. 6, то укажите свой порт.
Должна открыться домашняя страница tomcat.
По кнопке «Server status» можно посмотреть статус поднятого сервера. Нужно будет ввести имя пользователя и пароль созданные ранее.
По кнопке «Manager App» можно публиковать (удалять) приложения. Нужно будет ввести имя пользователя и пароль созданные ранее.
Остановка сервера выполняется следующим образом. Перейти в папку «bin» cd ~/apache-tomcat-7.0.42/bin и запустить скрипт «shutdown.sh»
sh shutdown.sh

Регистрация сервера Tomcat в NetBeans

Если была установлена 8 версия Tomcat, то необходимо сделать символьную ссылку на каталог библиотек.
ln -s /Users/XXX/apache-tomcat-8.0.0-RC3/lib /Users/XXX/apache-tomcat-8.0.0-RC3/common/lib
Открыть NetBeans
Меню Сервис->Серверы
В открывшемся окне нажать кнопку «Добавить сервер»
В открывшемся окне выбрать «Apache Tomcat» и нажать кнопку «Далее»
В следующей отображенной панели указать домашнюю папку Tomcat, например "/Users/ХХХ/apache-tomcat-7.0.42"
Указать имя пользователя и пароль, созданные ранее. Нажать кнопку «Далее».
Указать порт, если он был изменен ранее. Нажать кнопку «Готово».
Для проверки можно создать Веб приложение и выбрать в качестве сервера приложений 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

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

Apache Tomcat — это контейнер, который позволяет вам использовать интернет приложения такие, как Java сервлеты и JSP (серверные страницы Java).Пакеты Tomcat 6.0 в Ubuntu поддерживают два варианта запуска Tomcat. Вы можете установить его как классический одиночный экземпляр на всю систему, который будет запускаться при загрузке системы от имени непривилегированного пользователя tomcat6 . Но вы можете развернуть частные экземпляры, которые будут запускаться с правами вашего собственного пользователя, и вам придется запускать и останавливать их самостоятельно. Второй вариант особенно полезен в контексте сервера разработки, где нескольким пользователям требуется тестировать их собственные частные экземпляры Tomcat.

Масштабная установка на всю систему

Linux настройка tomcat

Изменение портов по умолчанию

...

Изменение используемой JVM

JAVA_HOME=/usr/lib/jvm/java-6-sun

Определение пользователей и ролей

Использование стандартных приложений Tomcat

Документация Tomcat

Приложения администрирования Tomcat

Пакет tomcat6-admin содержит два приложения, которые могут быть использованы для администрирования сервера Tomcat через web интерфейс. Для их установки введите следующую команду в терминале:

Sudo apt-get install tomcat6-admin

Доступ к приложению manager по умолчанию защищено: вам надо определить пользователя с ролью «manager» в /etc/tomcat6/tomcat-users.xml для получения к нему доступа.

Второе приложение — это host-manager , которое по умолчанию доступно вам по адресу http://yourserver:8080/host-manager/html . Оно может быть использовано для создания виртуальных хостов динамически.

Доступ к приложению host-manager также закрыто по умолчанию: вам надо определить пользователя с ролью «admin» в /etc/tomcat6/tomcat-users.xml для получения к нему доступа.

Sudo chgrp -R tomcat6 /etc/tomcat6 sudo chmod -R g+w /etc/tomcat6

Приложения примеров Tomcat

Sudo apt-get install tomcat6-examples

Использование пользовательских экземпляров

Tomcat в большей степени используется при разработке и тестировании , когда использование одиночной оболочки на сервере не удовлетворяет требованиям множества пользователей на одной системе. Пакеты Tomcat 6.0 в Ubuntu поставляются с инструментарием, помогающим создать ваши собственные настроенные на пользователя оболочки, позволяя каждому пользователю в системе запускать (без прав суперпользователя) отдельные частные экземпляры, при том, что они будут использовать библиотеки, установленные в системе.

Установка поддержки частных оболочек

Вы можете установить все необходимое для запуска частных оболочек вводом следующей команды в терминале:

Sudo apt-get install tomcat6-user

Создание частного экземпляра

Вы можете создать каталог частной оболочки вводом следующей команды в терминале:

Tomcat6-instance-create my-instance

Настройка вашего частного экземпляра

Вы обнаружите обычные файлы настроек Tomcat для вашего частного экземпляра в подкаталоге conf/. Вы конечно же можете отредактировать файл conf/server.xml для изменения портов по умолчанию, используемых вашим частным экземпляром Tomcat для предотвращения конфликтов с другими экземплярами, которые также могут быть запущены.

Запуск/остановка вашего частного экземпляра

My-instance/bin/startup.sh

Вы можете проверить подкаталог logs/ на предмет обнаружения каких-либо ошибок. Если вы получили ошибкуjava.net.BindException: Address already in use:8080 , это означает, что порт, который вы используете уже занят и вам следует его поменять.