Простейшее web-приложение на Java на сервере Tomcat. Установка Apache Tomcat в ОС Windows

В статье рассказывается о том, как поднять на своем компьютере локальный java сервер и прописать простейшее web-приложение.

Tomcat нужен для работы Java сервера с применением сервлетов . Если грубо говоря, то сервелеты это аналог тех же php скриптов. На сервер Tomcat от клиентов приходят запросы. В зависимости от них сервер запустит те или иные сервелеты, которые сформируют ответы в виде текстовых файлов. Чаще всего это html страницы.

Установка JDK

Для работы современных версий Android Studio или IntelliJ IDEA не нужно производить дополнительные действия, чтобы программы могли найти JDK и запускать java приложения. Но мы будем на данный момент компилировать сервлеты вручную, так что для удобства мы пропишем путь к папке JDK в системную переменную Path в Windows. Ниже приведена инструкция для Windows 10.

У меня JDK находится в папке C:\Program Files\Java\jdk1.8.0_121\bin .

Кликните правой кнопкой по иконке Этот компьютер и перейдите в Свойства .

Внимание! Не вздумайте удалять всё содержимое переменной Path . Иначе у операционной системы возникнут очень большие проблемы. Вы должны дописать в эту переменную нужный путь.

Установка Apache Tomcat

Скачиваем установочный файл.

Устанавливаем Tomcat.

Эти компоненты должны быть выбраны.

Для учебных целей можно параметры оставить по умолчанию.

После этого в трее должен появится значок запущенного сервиса.

В папке webapps создадим папку с названием web-приложения. Допустим, testingapp .

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

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

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

Установить Java-окружение из пакета OpenJDK.
Установить Tomcat.
Запустить Tomcat и проверить его работу по адресу http://localhost:8080.
Написать JSP-страницу test.jsp, выводящую произвольную строку.
Написать сервлет test, выводящий произвольную строку.
Написать стартовую страницу index.html, содержащую ссылки на страницу test.jsp и сервлет test.

Установка Java и Tomcat

1. Установка Java Development Kit (JDK)

Для работы Tomcat требуется установленное окружение для разработки Java-приложений (Java Development Kit, JDK). Проверить, какая версия установлена в системе можно, например, так:

В приведенном примере в системе установлена (символ i (nstalled)) версия 1.7 OpenJDK - свободного комплекта разработки, полностью совместимого с Sun (Oracle) JDK.

Если ни один из доступных пакетов не установлен, то его следует установить:

Aag@stilo:~> zypper in java-1_7_0-openjdk* .... // процесс установки

Проверить результаты установки можно так, как было указано выше.

Узнать путь, где размещается среда исполнения Java можно из переменной окружения $JAVA_HOME:

Aag@stilo:~> echo $JAVA_HOME /usr/lib64/jvm/jre

А узнать номер установленной (и используемой) версии JDK можно так:

Aag@stilo:~> java -version java version "1.7.0_09" OpenJDK Runtime Environment (IcedTea7 2.3.3) (suse-3.16.1-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

2. Установка Tomcat

Установка Tomcat и связанных с ним пакетов из репозитария производится обычным образом:

Aag@stilo:~> zypper in tomcat* Чтение установленных пакетов... // aag: список сокращен и может отличаться от приведенного Будут установлены следующие НОВЫЕ пакеты: jakarta-commons-dbcp-tomcat jakarta-commons-pool-tomcat5 tomcat tomcat-admin-webapps tomcat-docs-webapp tomcat-servlet-3_0-api tomcat-webapps ... Полный размер загрузки: 7,2 M. После операции будет использовано дополнительно 43,6 M. Продолжить? [да/нет]:

После подтверждения, необходимые пакеты будут загружены и установлены. При этом, в системе будут созданы следующие подкаталоги (дефолтная установка в OpenSuSE 12.2, фактическое размещение зависит от дистрибутива и версии ОС и версии самого Tomcat):

/usr/share/tomcat/bin: управляющие скрипты;
/etc/tomcat/conf: конфигурационные файлы (server.xml, web.xml, context.xml, tomcat-users.xml);
/usr/share/java/tomcat/lib: jar-файлы, используемые всеми расширениями Tomcat и веб-приложениями;
/var/log/tomcat: log-файлы;
/srv/tomcat/webapps: каталог, содержащий веб-приложения (сервлеты и JSP);
/var/cache/tomcat/work: рабочий каталог Tomcat, который используется, в первую очередь, при преобразовании JSP-страниц в сервлеты;
/var/cache/tomcat/temp: временные файлы.

В каталоге /usr/share/tomcat будут, также, размещены симлинки на указанные каталоги. Путь к основному каталогу Tomcat можно записать в переменную окружения $CATALINA_HOME (export CATALINA_HOME="/usr/share/tomcat/").

3. Запуск и остановка сервера

Если установка прошла успешно, то можно попробовать запустить Tomcat:

Aag@stylo:~> $CATALINA_HOME/bin/catalina.sh start

Скрипт catalina.sh используется для ручного запуска и остановки сервера Tomcat. Для автоматического запуска можно использовать скрипт service (service tomcat start|stop|restart), предварительно следует указать уровни запуска, на которых будет стартовать демон tomcat (см. chkconfig)

Catalina - название компонента Tomcat, реализующего непосредственно функции контейнера сервлетов. Это название использовалось в ранних версиях (до Tomcat5) для всего продукта. Другими компонентами в составе системы являются Coyote, который осуществляющий поддержку транспорта по протоколу HTTP 1.1 и Jasper, предназначенный для обработки JSP (анализа JSP-файлов и компиляции их в Java-код, который затем передается для обработки с помощью Catalina).

Работающий сервер веб-приложений будет ожидать входящие подключения на порт 8080. Это можно проверить, если в адресной строке браузера набрать http://localhost:8080 (рис. 1).

Рис. 1. Дефолтная стартовая страница сервера Apache Tomcat

Остановить Tomcat, запущенный вручную, можно так:

Aag@stylo:~> $CATALINA_HOME/bin/catalina.sh stop

Настройка сервера Tomcat

Для настройки сервера Tomcat используются следующие конфигурационные XML-файлы , размещенные в каталоге $CATALINA_HOME/conf/:

server.xml: Общие настройки сервера (порты, виртуальные хосты и проч.).
web.xml: Параметры, общие для ВСЕХ веб-приложений на текущем сервере. Настройки отдельных веб-приложений задаются в их собственных файлах /WEB-INF/web.xml (здесь можно провести аналогию с использованием файла.htaccess в Apache).
context.xml: Общие настройки управления контентом.
tomcat-users.xml: Список пользователей и групп (ролей).

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

conf/server.xml - Изменение номера порта

По умолчанию Tomcat использует для приема входящих подключений TCP-порт 8080, а также порты 8009 и 8005:

Aag@stilo:~> netstat -tuaev --numeric-ports | grep tomcat tcp 0 0 localhost:8005 *:* LISTEN tomcat 20539 tcp 0 0 *:8009 *:* LISTEN tomcat 20533 tcp 0 0 *:8080 *:* LISTEN tomcat 20524

Эти порты могут быть изменены на другие, не используемые другими сетевыми сервисами, путем их изменения в файле conf/server.xml. Чтобы, например, заставить Tomcat работать на порту 8081, нужно найти в файле conf/server.xml указанную ниже строку и поменять значение атрибута port на требуемое (8081), затем перезапустить сервер:

... ...

Для developer-сервера можно использовать любой непривилегированный порт. Для production-сервера стоит использовать порт 80, который является стандартным для HTTP-серверов.

conf/web.xml - Включение листинга каталогов

Для установки отображения списка файлов в каталогах (листинга), нужно поменять значение атрибута listings с ложного (false) на истинное (true) в блоке настроек сервлета по умолчанию ("default"-servlet) в файле conf/web.xml. Это бывает полезным при разработке и отладке веб-приложений, но не рекомендуется использовать на production-сервере по соображениям безопасности.

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

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

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

reloadable="true" > ...

conf/tomcat-users.xml - Управление пользователями и ролями

Для управления пользователями, которые могут управлять сервером Tomcat, предназначен файл conf/tomcat-users.xml. Чтобы создать, например, пользователя manager, который сможет управлять веб-приложениями через графическую оболочку (предопределенная роль manager-gui), нужно добавить в этот файл запись вида:

Разработка и распространение веб-приложений под управлением Tomcat

Рассмотрим несколько примеров использования Tomcat для разработки веб-приложений на Java . Здесь мы не будем акцентировать внимание на коды программ как таковые, поскольку этому посвящена отдельная дисциплина — «Объектно-ориентированное программирование на языке Java ».

Создание структуры каталогов и размещение веб-страниц

Все веб-приложения размещаются в каталоге webapps (/srv/tomcat/webapps). Каждое приложение размещается в собственном, одноименном, каталоге с определенной вложенной структурой (webapps/youappname/WEB-INF/classes). Для нового веб-приложения (например, myapp) эту структуру можно создать, например, так:

// WEB-INF - предопределенное и регистрозависимое имя каталога aag@stilo:~> sudo mkdir -p /srv/tomcat/webapps/myapp/WEB-INF/classes

Назначение созданных каталогов следующее:

myapp: Корневой каталог веб-приложения. Здесь размещаются HTML-страницы и прочие ресурсы (таблицы стилей (CSS), изображения, клиентские скрипты (javascript), JSP и т.п.), доступные веб-клиентам.
myapp/WEB-INF: Этот каталог, недоступный веб-пользователям, содержит описание веб-приложения и его параметры в файле web.xml.
myapp/WEB-INF/classes: В этом каталоге размещаются все файлы Java-классов сервлетов.

Поместим в корневой каталог создаваемого веб-приложения файл index.html следующего содержания:

После перезапуска сервера к создаваемому веб-приложению можно будет обратиться по адресу http://localhost:8080/myapp/(рис. 2).

Рис. 2. Отображение статических страниц

Java Server Pages

Java Server Pages (JSP) - динамические веб-страницы, содержащие, помимо HTML-разметки, инструкции на языке Java (подобно PHP или ASP). Такие ресурсы размещаются и используются так же, как и статические ресурсы. Пример JSP приведен в листинге 1, а результат на рис. 3.

Листинг 1. Пример разметки JSP

Рис. 3. Вывод JSP-страниц

Примечание: Если при обращении к JSP-странице вы получаете сообщение об ошибке вида:
org.apache.jasper.JasperException: java.lang.IllegalStateException: No output folder.... ,
это скорее всего означает, что каталог tomcat/work не доступен для записи. Используйте команду chmod -R a+w tomcat/work для установки разрешений или chown для смены владельца.

Сервлеты

Все сервлеты (серверные приложения на Java) размещаются в подкаталоге WEB-INF/classes/. Рассмотрим использование сервлетов на примере приложения, выводящего некоторую информацию о сервере (листинг 1).

Листинг 1. Исходный код Java-сервлета

// Сохранить как /srv/tomcat/webapps/myapp/WEB-INF/classes/MyServlet.java import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class MyServlet extends HttpServlet { @Override public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { // установить MIME-type и кодировку ответа response.setContentType("text/html; charset=UTF8"); PrintWriter out = response.getWriter(); // Отправка веб-страницы try { out.println(""); out.println("Servlet sample"); out.println(""); out.println("

Запрошенный ресурс: " + request.getRequestURI() + "

"); out.println("

Протокол: " + request.getProtocol() + "

"); out.println("

Адрес сервера: " + request.getRemoteAddr() + "

"); out.println(""); } finally { out.close(); // Всегда закрывать Writer } } }

Следующий этап - компиляция. Это можно сделать из той среды разработки, которую вы используете (Eclipse, NetBeans, IntelliJ и т.п.) или из командной строки. В случае использования openJDK и Tomcat 7 это будет выглядеть примерно так:

Aag@stylo:~> javac -classpath /usr/share/tomcat/lib/tomcat-servlet-3.0-api.jar:classes /srv/tomcat/webapps/myapp/WEB-INF/classes/MyServlet.java

В результате компиляции в каталоге WEB-INF/classes будет создан файл MyServlet.class. Теперь нужно сконфигурировать Tomcat для его использования.

Настройка доступа к сервлету

С точки зрения пользователя сервлет - это обычный веб-ресурс, адресуемый URI и обращение к сервлету выполняется через адресную строку браузера. Однако, чтобы сервлет стал доступным для клиентов, необходимо выполнить его настройку в файле WEB-INF/web.xml веб-приложения. Структура этого файла для рассматриваемого примера будет примерно такой:

aboutServer MyServlet aboutServer /about

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

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

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

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

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

Молодые программисты часто задают вопрос: а зачем нужны зачастую довольно тяжелые и дорогие промышленные сервера приложений (такие как JBoss AS , Oracle WebLogic , IBM WebSphere AS ), если у нас есть замечательный легковесный фреймворк Spring и контейнер сервлетов Apache TomCat . Попробуем на него ответить. Сразу замечу, речь сейчас не идет об архитектуре приложения! Не важно, используете вы EJB или нет. Предположим, у вас приложение на Spring Framework и стоит вопрос, на чем его запускать. Итак, какие дополнительные сервисы предлагает нам сервер приложений.

Пулы соединений с БД . Да, у TomCat тоже есть пул соединений, но каковы его возможности? Может ли он периодически тестировать доступность СУБД и обновлять соединения в случае восстановления после сбоев? Умеет ли он делать замену прав доступа? Грубо говоря, подключаемся к БД под пользователем в зависимости от того, кто аутентифицировался в нашем приложении, если часть логики вынесена на уровень СУБД, то это бывает полезно. Может ли пул соединений Tomcat балансировать нагрузку между несколькими базами данных (например, в случае Oracle RAC ), а так же определять, что вот эти узлы RAC умерли и теперь к ним не нужно пытаться подключаться, а затем понять, что они снова доступны и теперь их тоже можно использовать? В конце концов, может ли ваш пул соединений защитить от некорректного кода в приложении, которое по недосмотру не возвращает соединения, просто отбирая его после какого-то таймаута?

JMS . Если вы хотите использовать очереди в вашем приложении, развернутом на TomCat , то придется отдельно еще поднимать сервера очередей сообщений. В случае сервера приложений, очереди как правило доступны их коробки. Вместе с очередями доступны так же следующие вещи: кластеризация - вы можете строить распределенные очереди, расположенные сразу на нескольких серверах, что существенно увеличивает масштабируемость и доступность вашего приложения, миграция - в случае падения одного из серверов, его очереди автоматически перемещаются на другой, сохраняя необработанные сообщения. В некоторых серверах приложений поддерживается Unit-of-Order - гарантированный порядок обработки сообщений, удовлетворяющих некоторым критериям, очень часто при интеграции бывает полезен.

JTA . Те самые распределенные транзакции. Кто-то их понимает и использует, кто-то считает слишком тяжелыми. Как правило это так, они слишком тяжелые, но если вам нужно обеспечить согласованность данных в СУБД, разнесенных по разным углам нашей необъятной, или в СУБД и очереди, то без таких транзакций будет трудно. Суть распределенных транзакций в том, что мы не коммитим ни в одну из БД, пока не убедимся, что все БД, участвующие в транзакции, смогут принять наши данные. Тем самым мы избегаем проблемы “с одного счета в одном банке деньги списали, а на другой - в другом банке - не зачислили - сработало ограничение целостности”.

Безопасность . Современные сервера приложений предоставляют множество различных провайдеров безопасности. Доступны различные провайдеры аутентификации, вы можете хранить ваших пользователей во множестве мест: во встроенном LDAP -сервере, в базе данных, во внешнем LDAP -сервере, в различных Internet-directory - специализированных приложениях для управления правами доступа. Возможны следующие сценарии: на работу наняли человека, добавили его в , там запустился процесс раздачи прав, который выдал человеку права на все ресурсы вашего предприятия и теперь каждый сервер приложений в вашей компании (а их может быть очень много) видит эти права, так как подключен к этой Internet-directory/Access-manager . Доступно разделение пользовательской сессии между приложениями: мы аутентифицировались в одном приложении - нам уже не нужно аутентифицироваться в другом. Так же доступна реализация Single-Sign-On : вы делаете один из серверов базой для хранения пользователей, все другие сервера при аутентификации пользователя обращаются к этой базе. Реализуется SSO посредством Security Assertion Markup Language (SAML) 1/2 или посредством Simple and Protected Negotiate (SPNEGO) и Kerberos для Windows -клиентов. Возможна авторизация посредством протокола eXtensible Access Control Markup Language (XACML) , позволяющего описывать довольно сложные политики (например, приложение доступно пользователю только в рабочее время). Опять же все данные возможности работают в кластерном окружении. Впрочем, стоит отметить, что с помощью Spring Security и Apache Shiro можно реализовать большинство из них, но вам придется “тянуть” эти реализации за каждой вашей программой, в то время как в сервере приложений они доступны из коробки.

Масштабируемость и высокая доступность . Да, для TomCat мы можем настроить кластеризацию, но она будет довольно примитивной. Мы не сможем сделать передачу пользовательской сессии из одного центра обработки данных (ЦоД) в другой через Интернет, мы не сможем эффективно настроить репликацию сессий на большом кластере, состоящем из 40-50 экземпляров сервера приложений. В случае сбоев, мы не сможем обеспечить миграцию экземпляров сервера на другую машину и т.д. Так же в TomCat нет механизмов автоматического мониторинга и реакции на ошибки: мы не можем автоматически перезапустить экземпляр сервера, если на нем зависло 10 потоков, мы не можем автоматически отправить письмо администратору при переполнении пула соединений и т.д.

Управляемость . В случае большого кластера TomCat у нас нет единого центра управления, т.н. AdminServer и аналога NodeManager’ а. Мы не сможем одновременно запустить на старт 50 экземпляров сервера. Мы не можем посмотреть состояние экземпляров, посмотреть сколько у нас обработчиков на той или иной очереди, на том или ином сервере, сколько создано соединений с той или иной БД, какие из них можно убить, какие в данный момент выполняются транзакции, какие ресурсы в них задействованы и т.д. Конечно, можно все сделать “за три минуты на скриптах, ну как в Линуксе принято”, но результат будет плачевный.

Скриптовый язык . Кстати о скриптах, большинство промышленных серверов приложений содержат утилиты для выполнения скриптов как правило на языке Python , Пользоваться данными утилитами одно удовольствие. Администратор может описать в виде скрипта все шаги для подготовке к развертыванию сколь угодно большого приложения, таким образом запуск в продуктив или обновление займет сравнительно немного времени. С помощью таких скриптов можно создавать источники данных (представьте себе сервисную шину, подключенную к 120 экземплярам БД), JMS -очереди, менеджеры потоков, создавать новые экземпляры серверов и добавлять их в кластер, выполнять остановку и запуск серверов, их миграцию.

Административный канал и развертывание в промышленном режиме . Некоторые сервера приложений позволяют включить так называемый административный канал - отдельный порт, защищенный SSL , запросы по которому имеют приоритет. Таким образом, даже если ваш сервер завис, вы сможете на него зайти и посмотреть, какие транзакции выполняются и какие потоки висят. Но у данного канала есть и другое применение. При обновлении приложения вам не нужно выключать старую версию! Вы можете добавить на сервер новую версию приложения в административном режиме - пользователи продолжают работать со старой, а по административному каналу доступна новая, соответственно мы можем выполнить последнее тестирование перед запуском, проверить все ли у нас правильно развернулось. Затем мы окончательно публикуем приложение, при этом пользователи, уже имеющие сессию, продолжают работать со старой версией, чтобы не потерять данные. Новые пользователи аутентифицируются на новой версии. Тем самым мы обновляем приложение без его простоя, что очень важно для критических систем.

Как мы видим, сервисов, предоставляемых промышленными серверами приложений, довольно много. Возникает вполне закономерный вопрос, а почему сервлет-контейнер TomCat такой популярный? Здесь есть несколько соображений:

В первую очередь, цена. За все хорошее нужно платить, за отличное платить еще больше, особенно, если мы хотим доступ к технической поддержке и патчам. К примеру, сервер приложений Oracle WebLogic в базовой комплектации стоит $10 000/processor (под processor здесь понимается одно ядро, умноженное на т.н. core factor ). Не каждый заказчик может себе позволить такое решение.

Не всем приложениям нужны вышеперечисленные сервисы, а иногда разработчики не умеют ими пользоваться. Например, если у нас простая учетная система, работающая с одной БД, то нам не нужны распределенные транзакции. С другой стороны, масштабирование. Приложение может следовать всем Java EE спецификациям, но при этом не быть масштабируемым. Простой пример: приложение читает из БД измененные записи (которые пишутся с помощью триггеров в отдельную табличку) и передает их в другую БД. При этом авторы как-то забыли про блокировки. Если мы запустим данную программу на кластере, то у нас каждая запись будет обрабатываться N -раз, по числу экземпляров TomCat в кластере. Такая масштабируемость нам не нужна. Аналогичные соображения можно привести и для других сервисов.

Простота и легкость освоения. Вообще администратор сервера приложений это отдельная профессия, такая же как и администратор баз данных. Это не просто линукс-админ. Посмотрим еще раз на список сервисов и задумаемся как долго нужно изучать возможности выбранного сервера приложений по их реализации и настройке. Курсы по администрированию IBM WebSphere или Oracle WebLogic могут стоить десятки тысяч рублей.

Сварим кашу из топора сами. Бывают ситуации, когда это необходимо. Не всегда есть смысл ждать патча, исправляющего какие-то критические для нашего приложения ошибки. Гораздо быстрее просто подменить версию библиотеки. Правда зачастую это можно сделать и на сервере приложений, добавив библиотеку к нашему приложению и настроив загрузчик классов. Причем современные сервера содержат в себе утилиты для поиска ошибок в иерархии загрузчиков.

Отдельно отметим причины популярности Spring Framework как на TomCat’ е, так и на промышленных серверах приложений и немного их прокомментируем:

Исторические причины. Почему Spring Framework , а не EJB ? Ну потому что я в 88-м году программировал на С++ , фигня этот ваш С++ . Да, действительно EJB 1.1 и EJB 2.x были очень тяжелы для освоения и для использования, но времена меняются. Опять же, начиная с Java EE 6 , появился легковесный IoC -контейнер - CDI . Зачем тянуть в свое приложение сотни мегабайт библиотек, которые будут существенно замедлять процесс развертывания, если можно использовать готовые и довольно качественные реализации, предоставленные производителем сервера приложений? На самом деле иногда есть зачем.

Баланс между завязкой на конкретном производителе и переносимостью. Да, EJB это часть спецификации Java EE , причем наиболее сложная, сложнее только J2CA и по хорошему приложения, написанные для одного сервера, должны работать на другом. На практике это не всегда так. Зачастую для эффективного использования всех возможностей сервера приложений приходится в коде вызывать его API , а это уже делает приложение непереносимым. Правда, справедливости ради, с каждой новой версией Java EE таких завязок становится все меньше. С другой стороны, даже без явных завязок на API части стандарта могут быть реализованы разными серверами по своему, например, один сервер будет закрывать EntityManagerFactory при остановке приложения, другой - нет. Реализации иерархии загрузчиков классов так же могут отличаться.

При этом, явная завязка на Spring Framework тоже имеет свои минусы. Это такая же завязка на производителе, как и решение использовать только WebLogic . Но если с WebLogic хоть и со скрипом мы сможем уйти, то со Spring Framework скорее всего нет. Что будет, если завтра ведущие разработчики решат оставить свое детище и все дружно перейти в Oracle ? Впрочем, думаю, что вероятность такого сценария не высока.

Отдельно стоит отметить поддержку Spring Framework со стороны разработчиков серверов приложений. Например, в Oracle WebLogic можно включить отдельную страницу в консоли администрирования для каждого построенного на данном фреймворке приложения. На странице будет отображено дерево бинов и показаны их свойства. Так же доступны бины самого сервера и упрощена разработка MBean ’ов. Помимо этого, Spring Framework прозрачно интегрируется в кластерное окружение, а Spring Security может использовать подсистему безопасности сервера приложений.

В заключение хочется отметить, что выбор платформы для приложения это довольно нетривиальная инженерная задача, в которой должна учитываться масса факторов. Это и соотношение стоимости разработки к стоимости поддержки (при этом нужно учитывать, что разработка может идти год, а использоваться ПО может десяток лет), стоимость самих серверов приложений, ваши отношения с вендором, т.к. несмотря на высокую номинальную стоимость зачастую предоставляются скидки под 80%. Учитывайте вашу и вашей команды квалификацию в конце концов. Ну и не нужно быть ретроградом, если вы в 2001-м писали на EJB и с тех пор смотреть на них не можете, то это еще не повод отказываться от этой замечательной технологии и реализующих ее серверов приложений, но даже если вы гуру Spring Framework , подумайте, может быть для него на промышленном сервере тоже найдется место?

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

Установка Tomcat

Скачать архив 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

На протяжении всего времени изучения и освоения Java, я старался разобраться и научиться программировать/писать Window Application. Но, если честно, поразмыслив на досуге, решил все-таки сменить вектор обучения: решил освоить Servlet -ы и податься в облака Web -программирование. Для работы /изучения сервлетов нам понадобится веб-сервер Apache Tomcat .
Apache Tomcat - программа-контейнер сервлетов, написанная на языке Java и реализующая спецификацию сервлетов и спецификацию JavaServer Pages (JSP), которые являются стандартами для разработки веб-приложений на языке Java.

Tomcat позволяет запускать веб-приложения, содержит ряд программ для самоконфигурирования.

Tomcat используется в качестве самостоятельного веб-сервера, в качестве сервера контента в сочетании с веб-сервером Apache HTTP Server, а также в качестве контейнера сервлетов в сервере приложений JBoss.

Другими словами без Tomcat при написании сервлетов нам не обойтись.

Когда-то в одном из своих постов на блоге я уже писал про установку и настройку Apache Tomcat, но хотелось бы рассмотреть эту тему более подробно и детально.

В данной статье хотелось бы более подробно рассмотреть настройку и установку Tomcatдля ОС Windows. Настройку Apache Tomcat для ОС Linux вынесу в отельную статью. Материал по данной тематике огромный, поэтому этот пост будет добавляться/обновляться по мере изучения и освоения Tomcat.

Итак, понеслось....
Для начала нам необходимо скачать TomCat с официального сайта разработчиков . Описание доступных версий TomCat можно посмотреть на данной страничке . На момент написания статьи последней стабильной версией была 7.0.14 .
Приведу прямые ссылки для скачивания данной версии:
Рассмотрим вариант установки Tomcat при помощи исполняемого файла, который установит Tomcat в качестве службы Windows и TomCat будет запускаться при старте системы. После скачивания установщика запускаем его и отвечаем на простые вопросы:вначале соглашаемся с лицензионным соглашением, затем выбираем тип установки (полный, выборочный, нормальный, минимальный) - я выбрал полный. Дальше установщик запросит у нас некоторую конфигурацию: порт подключения (по умоланию 8080):

Настройки Apache TomCat

Это означает, что для запуска Tomcat в командной строке броузера нам нужно будет вводить адрес вида: https://localhost:8080 Значение порта подключения можно оставить по умолчанию, но если у нас на компьютере или сервере будет использоваться в качестве Web-сервера только Tomcat , то значение порта можно поставить равное 80 . Следовательно строка ввода адреса в браузере будет выглядеть просто https://localhost (без указания порта). Укажем порт 80. В последствие данное значение можно будет изменить вручную в настройках сервера (файл server.xml ).
Далее указываем свой логин и пароль. Роли оставим указанные по умолчанию: admin-gui, manager-gui . Далее указываем путь к установленной jdk на нашем компьютере. И в завершение указываем путь куда устанавливать TomCat и нажимаем Install.
После завершения установки оставляем галочку "Запустить TomCat ":

Завершение установки TomCat

Нажав кнопку Finish , мы увидим окно запуска TomCat в качестве сервиса ОС Windows:
Теперь наступила пора проверить работоспособность сервера TomCat: для этого в сроке ввода адреса в нашем любимом браузере вводим команду:
https://localhost:8080 В результате, если все прошло гладко, откроется домашняя страница TomCat:

Домашняя страница Apache TomCat на нашем localhost

Часть информации и документации на открывшейся страничке localhost будет дублируется с официального сайта.
Кроме того, установленный сервер TomCat будет доступен пользователям Вашей локальной сети - никаких дополнительных настроек делать не нужно.
На этом данный вид установки TomCat можно считать завершенным.

Теперь коротко рассмотрим другой вариант установки и запуска: из архива. Итак.. после скачивания архива для соответствующей архитектуры Winsows распаковываем его в любое удобное для нас место, например D:/Java/apache-tomcat-7.0.14/ Запускаем командную строку Windows и переходим в папку: D:/Java/apache-tomcat-7.0.14/bin/ - в данной папке находятся исполняемые файлы для TomCat. Для установки TomCat в качестве службы Windows вводим команду:
service.bat install Более подробную информацию по установке можно почитать на данной страничке .
Запускать TomCat можно при помощи команды
startup.bat Остановить сервер можно при помощи команды команды:
shutdown.bat Не забываем предварительно добавить системные переменные: CATALINA_HOME и JAVA_HOME . Выглядеть они будут примерно так:
JAVA_HOME: c:\Program Files\Java\jdk1.6.0_18\
CATALINA_HOME: D:/Java/apache-tomcat-7.0.14

Собственно на этом установка Apache TomCat закончена. Информация о дополнительной настройке и использовании TomCat будет чуть позже.