Установка переменных окружения 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 и исправьте по вкусу. Этот параметр выглядит приблизительно так:

 

<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080"... />

В частности, если вы не планируете использовать 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\<service_name>

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

 

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

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

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

 

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

 

C:\host1

В каталоге conf сервера Tomcat есть файл server.xml. В этом файле следует найти элемент <Service name="Tomcat-Standalone">. Внутри этого элемента по умолчанию описаны два коннектора: один для доступа по протоколу 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 появится сообщение об этом.

 

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

 

<Host name="host1.loc" debug="0" appBase="C:\host1" unpackWARs="true" autoDeploy="true">

<Alias>www.host1.loc</Alias>

</Host>

Этой строкой мы создадим виртуальный сайт окликающийся по адресам 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/<имя приложения>.

 

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

 

<Host name="host1.loc" debug="0" appBase="C:\host1" unpackWARs="true" autoDeploy="true">

<Alias>www.host1.loc</Alias>

<Context path="" docBase="examples" debug="0" reloadable="true">

</Host>

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

Заключение

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

 

Установка расширения xdebug.

Перво-наперво нам необходимо установить xdebug. Когда была написана эта статья, xdebug был версии 2.0.1. С тех пор PHP APIs могло измениться, вы должны быть уверены, что версия xdebug поддерживается версией PHP, которую вы используете.

xdebug не работает с версиями PHP ниже 4.3, и возможно не будет работать с PHP 6. Но это не есть большая проблема, так как ветка PHP 4 закончила свою жизнь в конце 2007, а PHP 6 возможно не выйдет до конца 2008.

 

Установка в Unix

 

До погружения в возможности xdebug, давайте поговорим об установке. В Unix вы можете попробовать установить xdebug из библиотеки расширений PHP. Данный вид установки не работает на всех системах. Если так происходит в вашей системе, вы должны скомпилировать расширение xdebug из исходников. Но в начале попробуйте установку из PECL:

pecl install xdebug

 

Как было сказано выше, если установка из PECL не работает в вашей системе, вы должны скомпилировать xdebug из исходников. В дополнение к компилятору языка C, у вас должны быть соответствующие версии приложений для сборки (Autoconf, Automake и Libtool). Если их у вас нет, необходимо их установить…

К тому же в PHP есть две необходимые программы phpize и php-config, которые являются частями PHP, они также понадобятся для установки. Если вы не компилировали PHP из исходников, то возможно понадобится установить пакет разработки (php5-dev).

Обратите внимание, что phpize и php-config должны соответствовать используемой версии PHP, поэтому не копируйте их в свою систему из другой. Когда вы убедились, что все необходимые программы присутствуют, вы можете скачать и скомпилировать xdebug:

wget xdebug.org/link.php?url=xdebug201

tar -xzf xdebug-2.0.1.tgz

cd xdebug-2.0.1

phpize

./configure --enable-xdebug --with-php-config=/usr/bin/php-config

make

cp modules/xdebug.so /usr/lib/apache2/modules/xdebug.so

 

Путь к php-config может быть другим в вашей системе. В зависимости от настроек Apache вы должны скопировать xdebug.so в нужный каталог. Однако вместо копирования файла вы можете создать символическую ссылку на него.

 

Установка в Windows

 

Если вы пользуетесь Windows, вы можете скопировать скомпилированную DLL с xdebug.org. Выберете версию PHP, которую вы используете, и кликнете на соответствующей ссылке.

Я рекомендую сохранить скачанную DLL в каталог для расширений ext.

 

Активация расширения xdebug

 

Сейчас у вас есть готовое расширение xdebug, который является либо shared-объектом в Unix или DLL в Windows. Для его активации необходимо добавить запись в php.ini.

Для Windows:

 zend_extension_ts= «c:\php\ext\php_xdebug-2.0.1-5.2.1.dll»

Для Unix:

zend_extension="/usr/lib/apache2/modules/xdebug.so"

 

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

Пожалуйста, обратите внимание, что в примере для Windows мы используем zend_extension_ts, что означает, что загружается потокобезопасное (thread-safe) расширение, в то время как для Unix, мы загружаем непотокобезовпасное расширение. В зависимости от настроек вашей системы, вы должны решать когда вам необходимо то или иное состояние. Если вы не знаете в каком режиме запущен ваш PHP, посмотрите на вкладку Thread Safety в выводе команды phpinfo().

Вы не сможете загружать другие расширения Zend порка работаете с xdebug, потому что они будут использовать тот же внутренний механизм движка Zend, что может привести к проблемам. Не все расширения Zend работают совместно с xdebug. Использовать xdebug предпочтительнее на машине разработчика, чем на продакшене из-за серьезных ограничений. Важное правило не использовать совместно с xdebug другие расширения PHP предназначенные для отладки.

Перестартовав ваш веб-сервер, потому что мы изменили php.ini, посмотрите вывод команды phpinfo() или запустите php -m в командной строке. В каждом из случаев, xdebug должен быть выведен дважды, один раз как расширение PHP, другой раз как расширение Zend.

Будьте осторожны при обновлении PHP с установленным xdebug. Если поменяется внутреннее APIs в версиях PHP, новая версия PHP возможно не запустится или покажет странные ошибки. Если такое произойдет, временно отключите xdebug, дождитесь более новой версии PHP и xdebug и включите xdebug снова.

Для конфигурации xdebug существует несколько переключателей в php.ini, большинство из них имеет разумные значения по умолчанию, поэтому вы не должны беспокоиться о конфигурации xdebug. Мы рассмотрим самые важные параметры конфигурации.

 

Улучшенный вывод var_dump()

 

Давайте посмотрим, один из самых широко используемых методов отладки это вызов функции var_dump(). Нет ничего плохого в использовании var_dump(). Я делаю это все время. Препятствием является то, что для того чтобы произвести отладку, используя эту функцию необходимо модифицировать код программы.

xdebug предоставляет интересную альтернативу использования var_dump() для целей отладки кода, мы рассмотрим это в следующих статьях. Но сейчас вы будете рады слышать, что даже xdebug улучшает работу вашего любимого отладчика var_dump.

Когда загружено расширение xdebug, вывод функции var_dump() автоматически становится намного лучше для улучшения читаемости, скриншот показан ниже:

Вы можете настроить как именно xdebug должен формировать вывод функции var_dump() с помощью различных настроек в php.ini. Во-первых, вы можете изменить длину выводимой строки. Значение по умолчанию 512; более длинные строки обрезаются автоматически.

В зависимости от того выводить ли полностью строку или нет, зависит от ситуации и данных, с которыми вы работаете. Если вы работаете с большими строками, вывод функции var_dump() может быть слишком длинным и трудно читаемым, поэтому идея укорачивания строки выглядит достаточно приятной. В противоположность, если вы работаете со специфическими значениями, вы, скорее всего, заходите увидеть значение полностью.

Для изменения длины строки выводимой xdebug добавьте

xdebug.var_display_max_data=

в php.ini и перезапустите ваш веб-сервер. В качестве альтернативы, вы можете изменить эту настройку в своем скрипте используя функцию ini_set, вы можете добавить

ini_set('xdebug.var_display_max_data',);

в начале вашего скрипта. Проверьте, чтобы вызов ini_set был до первого вызова var_dump(). Конфигурация xdebug во время выполнения избавит вас от перезапуска веб-сервера каждый раз когда вы меняете php.ini и позволит более гибко его настраивать.

Вы также можете контролировать количество элементов массива и свойств объектов, которых будет выводить xdebug. Этого можно достигнуть модифицируя xdebug.var_display_max_children (значение по умолчанию 128). Этого значения будет вполне достаточно для отображения свойств вашего объекта, но если вы работаете с массивами, может быть необходимо увеличить значение…

Если вы работаете с вложенными объектами или массивами, вы можете модифицировать xdebug.var_display_max_depth. Эта настройка имеет значение по умолчанию 3, значит, что отобразиться три измерения в массиве и три уровня вложенности в объекте.

Вы также можете вывести значения суперглобальных переменных, используя функцию xdebug_dump_superglobals(). Так как суперглобальные массивы, особенно $_SERVER, — это массивы, содержащие большое количество значений, вы должны явно указать xdebug какой ключ массива вы хотите видеть. Чтобы сделать это установите xdebug.dump., где это один из следующих имен GET, POST, SERVER, COOKIE, FILES, REQUEST или SESSION. Используйте ключи массивов, которые вы хотите вывести с помощью xdebug в качестве аргументов, если вы хотите выводить несколько значений, то перечислите их через запятую. Вы можете использовать * как шаблон для отображения ключей, который может особенно полезен для вывода $_GET и $_POST.

Используйте

ini_set('xdebug.dump.SERVER', 'HTTP_HOST, SERVER_NAME')

 

в вашем PHP скрипте или настройки xdebug.dump.SERVER=HTTP_HOST, SERVER_NAME в php.ini для отображения значений $_SERVER['HTTP_HOST'] и $_SERVER['SERVER_NAME']. Для отображения всех значений GET, которые были переданы в скрипт, используйте

xdebug.dump.GET=*

По умолчанию xdebug не выводит неопределенные (undefined) переменные. Для того чтобы все же отображать неопределенные переменные, установите параметр xdebug.dump_undefined в On. Я советую установить этот параметр в on.