Apache Tomcat 8

Tomcat Setup

Table of Contents

Introduction

There are several ways to set up Tomcat for running on different platforms. The main documentation for this is a file called RUNNING.txt. We encourage you to refer to that file if the information below does not answer some of your questions.

Windows

Installing Tomcat on Windows can be done easily using the Windows installer. Its interface and functionality is similar to other wizard based installers, with only a few items of interest.

• Installation as a service: Tomcat will be installed as a Windows service no matter what setting is selected. Using the checkbox on the component page sets the service as «auto» startup, so that Tomcat is automatically started when Windows starts. For optimal security, the service should be run as a separate user, with reduced permissions (see the Windows Services administration tool and its documentation).
• Java location: The installer will provide a default JRE to use to run the service. The installer uses the registry to determine the base path of a Java 7 or later JRE, including the JRE installed as part of the full JDK. When running on a 64-bit operating system, the installer will first look for a 64-bit JRE and only look for a 32-bit JRE if a 64-bit JRE is not found. If a JRE cannot be found when running on a 64-bit operating system, the installer will look for a 64-bit JDK. Finally, if a JRE or JDK has not been found, the installer will try to use the JAVA_HOME environment variable. It is not mandatory to use the default JRE detected by the installer. Any installed Java 7 or later JRE (32-bit or 64-bit) may be used.
• Tray icon: When Tomcat is run as a service, there will not be any tray icon present when Tomcat is running. Note that when choosing to run Tomcat at the end of installation, the tray icon will be used even if Tomcat was installed as a service.
• Defaults: The defaults used by the installer may be overridden by use of the /C= command line argument. The configuration file uses the format name=value with each pair on a separate line. The names of the available configuration options are:
  • JavaHome
  • TomcatPortShutdown
  • TomcatPortHttp
  • TomcatMenuEntriesEnable
  • TomcatShortcutAllUsers
  • TomcatServiceDefaultName
  • TomcatServiceName
  • TomcatServiceFileName
  • TomcatServiceManagerFileName
  • TomcatAdminEnable
  • TomcatAdminUsername
  • TomcatAdminPassword
  • TomcatAdminRoles

  By using /C=. along with /S and /D= it is possible to perform fully configured unattended installs of Apache Tomcat.

• Refer to the Windows Service How-To for information on how to manage Tomcat as a Windows service.

The installer will create shortcuts allowing starting and configuring Tomcat. It is important to note that the Tomcat administration web application can only be used when Tomcat is running.

Unix daemon

Tomcat can be run as a daemon using the jsvc tool from the commons-daemon project. Source tarballs for jsvc are included with the Tomcat binaries, and need to be compiled. Building jsvc requires a C ANSI compiler (such as GCC), GNU Autoconf, and a JDK.

Before running the script, the JAVA_HOME environment variable should be set to the base path of the JDK. Alternately, when calling the ./configure script, the path of the JDK may be specified using the —with-java parameter, such as ./configure —with-java=/usr/java .

Using the following commands should result in a compiled jsvc binary, located in the $CATALINA_HOME/bin folder. This assumes that GNU TAR is used, and that CATALINA_HOME is an environment variable pointing to the base path of the Tomcat installation.

Please note that you should use the GNU make (gmake) instead of the native BSD make on FreeBSD systems.

Tomcat can then be run as a daemon using the following commands.

When running on Java 9 you will need to additionally specify the following when starting jsvc to avoid warnings on shutdown.

You may also need to specify -jvm server if the JVM defaults to using a server VM rather than a client VM. This has been observed on OSX.

jsvc has other useful parameters, such as -user which causes it to switch to another user after the daemon initialization is complete. This allows, for example, running Tomcat as a non privileged user while still being able to use privileged ports. Note that if you use this option and start Tomcat as root, you’ll need to disable the org.apache.catalina.security.SecurityListener check that prevents Tomcat starting when running as root.

jsvc —help will return the full jsvc usage information. In particular, the -debug option is useful to debug issues running jsvc.

tomcat – коротко для windows

С сайта http://tomcat.apache.org сохраняем zip-архив, и распаковываем его в папку с путём без пробелов и всяких сложных символов, например, «E:\tomcat\apache-tomcat-8.0.15».

Скачиваем последнюю версию JDK с сайта оракл https://www.oracle.com и ставим её тоже в папку с названием без пробелов (если так не сделать, и установить в папку X:\Program Files\. , то затем, когда мы будем править батник, нам придётся неявно указывать имя папки, это не очень хорошо, почему- будет видно дальше.

Открываем «e:\tomcat\apache-tomcat-8.0.15\bin\». Видим много батников и sh сценариев.

Открываем «catalina.bat». Там видим много закомментированных строк с переменными окружения, которые должны быть объявлены, или которые можно объявлять, а можно и нет.

Те переменные, которые должны быть объявлены — это

• set CATALINA_HOME=»e:\tomcat\apache-tomcat-8.0.15″
• set JAVA_HOME=»e:\ProgramFiles\Java\jre1.8.0_25″

причём желательно это сделать в отдельном файле с именем setenv.bat, для этого просто в текстовом редакторе вбиваем эти две строки и сохраняем файл с таким именем в «e:\tomcat\apache-tomcat-8.0.15\bin\»

Примечание: если папка с установленным jre содержит пробелы, то имя должно состоять из максимум шести первых букв реального названия папки, и если такое сочетание по алфавиту в диске первое, то

1, если второе, то

Например, название папки, внутри которой находится jre, “C:\Program Files\JRE”, а кроме того есть папка «C:\places\», тогда вторая строчка в setenv.bat будет

1\Java\jre1.8.0_25″, или
set JAVA_HOME=»e:\P

Естественно, это не очень хорошо, особенно когда у вас две папки “Program Files” и «Program Files (x86)». В таком случае, чтобы проименовать правильно папку с JRE, придётся поэкспериментировать

Пробуем запустить, для этого из текущей директории запускаем cmd.exe, в нём запускаем startup.bat . Это нам даст контроль над тем что происходит. Если всё пошло хорошо, то запустится окно Java-приложения в режиме консоли, в котором после запуска будет написано время старта, если же что-то пошло не так, например, папки в setenv.bat указаны неверно, мы увидим сообщения об ошибках.

Если глобальные переменные сконфигурированы верно, и запустилось окно java – консоли, но какие-то настройки сделаны неверно, то ошибки можно посмотреть в папке «e:\tomcat\apache-tomcat-8.0.15\logs\».

Если пункт 4 выполнен полностью успешно, то в окне браузера можно набрать 127.0.0.1:8080 и в окне будет окно tomcat сервера.

Но если мы захотим войти в настройки Host Manager, и т. д., то нас попросят ввыести логин и пароль. Взять их негде, но в папке conf есть файл tomcat-users.xml, который, если открыть, то сначала кажется правильным, но роли и пользователи там взяты в комментарий . Да и роли, и пользователи там явно неверные. Итак, что же делать.

Для ответа на вопрос, какие роли должны быть, и каких пользоватей назначать, чтобы войти в админку, на страничке 127.0.0.1:8080. Например, про роли manager можно узнать на страничке ttp://127.0.0.1:8080/docs/manager-howto.html, и вместо одного пользователя admin, как было раньше, теперь есть два пользователя: admin-gui и admin-script.

Более подробно про работу с паролями здесь http://127.0.0.1:8080/docs/realm-howto.html

Итак, открываем файл conf\tomcat-user.xml и добавляем там после закомментированного блока с логинами и паролями

Таким образом, мы получим пользователя superadmin с паролем pass.

Tеперь при помощи скриптов shutdown.bat и startup.bat перезапускаем сервер, и можем войти в админку.

можно ещё создать в админке ссылку на хост (Это то же самое, что мы сейчас сделали).

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

TOMCAT_HOME vs CATALINA_HOME

I have been updating some documentation lately (we moved from Apache Tomcat 7 to 8) and noticed references to TOMCAT_HOME . Such as creating an environment variable TOMCAT_HOME . If I’m correct TOMCAT_HOME was pretty much deprecated in version 3 and replaced with CATALINA_HOME and CATALINA_BASE ? However, I couldn’t find any definitive article on this or when to use TOMCAT_HOME over CATALINA_HOME . Certainly I’m not setting both!? Is there any definitive answer on this? Do popular third party applications look for TOMCAT_HOME rather than CATALINA_HOME ?

2 Answers 2

There is no TOMCAT_HOME and there wasn’t any. There is only CATALINA_* — still in Tomcat 9. I assume that Mark Thomas did not touch this for compat reasons.

Don’t invent your own env variables — they will only cause confusion.

Tomcat is split into 2 parts. One part is common to all instances of Tomcat. It contains things like the bin and lib directories.

The other part is replicated per-instance. It contains the work, temp and log directories. And conf, which is where the server.xml that defines what ports a given Tomcat instance uses.

So to run (and start/stop) multiple Tomcat instances, you no longer have CATALINA_HOME and CATALINA_BASE aimed at the same «TOMCAT_HOME» directory, but instead you have one CATALINA_HOME for all the Tomcats and a separate CATALINA_BASE for each Tomcat.

If you are running multiple instances of Tomcat on a single host you should set CATALINA_BASE to be equal to the . /tomcat_instance1 or . /tomcat_instance2 directory as appropriate for each instance and the CATALINA_HOME environment variable to the common Tomcat installation whose files will be shared between the two instances.

tomcat — CATALINA_BASE and CATALINA_HOME variables

I have multiple instances of tomcat 6 running on the same server (Linux) and it works as expected. I am trying to find out what the standard practice is with regards to setting the CATALINA_HOME and CATALINA_BASE variables.

In my tomcat installation, I have setup CATALINA_HOME to point to a «common» folder (say /tomcat6 ) and the CATALINA_BASE variable varies depending on the instance name (say /tomcat_instance1 , /tomcat_instance2 )

My question is this:

• Do I really need two variables?
• Or Can I just have one CATALINA_HOME and do away with CATALINA_BASE (or vice-versa) ?

6 Answers 6

If you are running multiple instances of Tomcat on a single host you should set CATALINA_BASE to be equal to the . /tomcat_instance1 or . /tomcat_instance2 directory as appropriate for each instance and the CATALINA_HOME environment variable to the common Tomcat installation whose files will be shared between the two instances.

The CATALINA_BASE environment is optional if you are running a single Tomcat instance on the host and will default to CATALINA_HOME in that case. If you are running multiple instances as you are it should be provided.

There is a pretty good description of this setup in the RUNNING.txt file in the root of the Apache Tomcat distribution under the heading Advanced Configuration — Multiple Tomcat Instances

CATALINA_HOME vs CATALINA_BASE

If you’re running multiple instances, then you need both variables, otherwise only CATALINA_HOME .

In other words: CATALINA_HOME is required and CATALINA_BASE is optional.

CATALINA_HOME represents the root of your Tomcat installation.

Optionally, Tomcat may be configured for multiple instances by defining $CATALINA_BASE for each instance. If multiple instances are not configured, $CATALINA_BASE is the same as $CATALINA_HOME .

Running with separate CATALINA_HOME and CATALINA_BASE is documented in RUNNING.txt which say:

The CATALINA_HOME and CATALINA_BASE environment variables are used to specify the location of Apache Tomcat and the location of its active configuration, respectively.

You cannot configure CATALINA_HOME and CATALINA_BASE variables in the setenv script, because they are used to find that file.

(4.1) Tomcat can be started by executing one of the following commands:

Multiple Tomcat Instances

In many circumstances, it is desirable to have a single copy of a Tomcat binary distribution shared among multiple users on the same server. To make this possible, you can set the CATALINA_BASE environment variable to the directory that contains the files for your ‘personal’ Tomcat instance.

When running with a separate CATALINA_HOME and CATALINA_BASE , the files and directories are split as following:

• bin — Only: setenv.sh (*nix) or setenv.bat (Windows), tomcat-juli.jar
• conf — Server configuration files (including server.xml)
• lib — Libraries and classes, as explained below
• logs — Log and output files
• webapps — Automatically loaded web applications
• work — Temporary working directories for web applications
• temp — Directory used by the JVM for temporary files>

• bin — Startup and shutdown scripts
• lib — Libraries and classes, as explained below
• endorsed — Libraries that override standard «Endorsed Standards». By default it’s absent.

How to check

The easiest way to check what’s your CATALINA_BASE and CATALINA_HOME is by running startup.sh , for example:

You may also check where the Tomcat files are installed, by dpkg tool as below (Debian/Ubuntu):

Tomcat catalina home windows

Следующий шаг после установки 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.

Элемент, который размещен в элементе Engine, и используется, чтобы связать названия серверной сети с серверами Catalina . Этот элемент будет функционировать должным образом только если виртуальный хост был зарегистрирован в системе DNS соответствующего домена. Одна из самых полезных особенностей элемента Host — возможность содержать элементы Alias, использующиеся для того, чтобы определить названия нескольких сетей.

Cluster

Элемент Cluster используется в Tomcat для того, чтобы обеспечить репликацию контекстных атрибутов, использование WAR, репликацию сессий, и может размещаться в элементе Engine или Host. В них размещаются элементы Manager, Channel, Valve, Deployer и ClusterListener.

Больше информации об этих элементах и о том, как они используются, можно найти на странице Apache Tomcat Configuration. И хотя у этого элемента множество различных конфигураций, стандартной конфигурации будет вполне достаточно, чтобы учесть интересы большинства пользователей при разработке приложения .

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.