Вопрос или проблема
В приобретенном RESTful Spring Boot веб-приложении с некоторыми ограничениями, которое работает корректно с IntelliJ IDEA v2022.02.05, меня попросили запустить проект без нее. Поэтому я начал его в командной строке под Windows 11 Pro.
Apache Tomcat 6.0.53 (с каталогом CATALINA_BASE
Apache Tomcat 6.0.37!) работает безупречно. По крайней мере, это видно в логах. Но, похоже, невозможно провести стандартный тест открытия http://localhost:8080/
(→ HTTP ERROR 404).
Что я пробовал до сих пор?
-
Проверил, кто блокирует порт 8080.
D:\tools\apache-tomcat-6.0.53>netstat -abno | find "8080" TCP 0.0.0.0:8080 0.0.0.0:0 ABHÖREN 22512
Похоже, что в данный момент только Apache Tomcat “слушает” этот порт (ABHÖREN = LISTEN).
-
Проверил, существует ли файл
index.html
в%CATALINA_HOME%\webapps\ROOT
. -
Проверил содержимое файла
index.html
. -
Добавил новый простой HTML файл в
%CATALINA_HOME%\webapps\ROOT
под названиемtest.html
и попытался открытьhttp://localhost:8080/test.html
, но снова получил HTTP ERROR 404.
-
В файле
%CATALINA_HOME%\conf\server.xml
я добавил для теста следующий код:<Context path="" docBase="ROOT" />
:<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> <Context path="" docBase="ROOT" /> <!-- 2025-01-28 SAE: Тест! --> … </Host>
-
Добавил в
%CATALINA_HOME%\webapps\ROOT\WEB-INF
вweb.xml
следующие строки:<welcome-file-list> <!-- 2025-01-28 SAE: Тест! --> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> </welcome-file-list> <!-- 2025-01-28 SAE: Тест! -->
-
Так как предшественник покинул проект, я не знаю, почему Catalina использует директорию
%CATALINA_BASE%
. (Однажды я изменил ее на 6.0.53 в IDE, и проект не смог запуститься.) Чтобы быть уверенным, что Tomcat не использует директориюwebapps
более старой версии, я добавил директориюROOT
туда подwebapps
с тем жеindex.html
из 6.0.53. -
Проверил лог-файл, измененный сегодня, но там нет ошибок или предупреждений. Только то, что вы видите в окне Tomcat на первом изображении выше.
-
Очистил кэш браузера Microsoft Edge (v132.0.2957.127 (официальная сборка, 64 бит)) и попробовал снова.
-
Пробовал обратиться к IP-адресу с помощью Google Chrome (версия 131.0.6778.267 (официальная сборка, 64 бит)). Очистил кэш браузера и попробовал снова.
Когда Apache Tomcat 6.0.53 открывается из командной строки, в окне Tomcat отображается следующее:
31.01.2025 08:14:01 org.apache.catalina.core.AprLifecycleListener init
INFO: Загружена APR-библиотека Apache Tomcat Native 1.2.12 с использованием APR версии 1.5.2.
31.01.2025 08:14:01 org.apache.catalina.core.AprLifecycleListener init
INFO: Возможности APR: IPv6 [true], sendfile [true], фильтры приема [false], случайные [true].
31.01.2025 08:14:01 org.apache.catalina.core.AprLifecycleListener initializeSSL
INFO: OpenSSL успешно инициализирован с версией OpenSSL 1.0.2k 26 Jan 2017
31.01.2025 08:14:02 org.apache.coyote.http11.Http11AprProtocol init
INFO: Инициализация Coyote HTTP/1.1 на http-8080
31.01.2025 08:14:02 org.apache.coyote.ajp.AjpAprProtocol init
INFO: Инициализация Coyote AJP/1.3 на ajp-8009
31.01.2025 08:14:02 org.apache.catalina.startup.Catalina load
INFO: Инициализация обработана за 1030 мс
31.01.2025 08:14:02 org.apache.catalina.core.StandardService start
INFO: Запуск сервиса Catalina
31.01.2025 08:14:02 org.apache.catalina.core.StandardEngine start
INFO: Запуск Servlet Engine: Apache Tomcat/6.0.53
31.01.2025 08:14:02 org.apache.coyote.http11.Http11AprProtocol start
INFO: Запуск Coyote HTTP/1.1 на http-8080
31.01.2025 08:14:02 org.apache.coyote.ajp.AjpAprProtocol start
INFO: Запуск Coyote AJP/1.3 на ajp-8009
31.01.2025 08:14:02 org.apache.catalina.startup.Catalina start
INFO: Запуск сервера завершен за 53 мс
У вас есть идея, в чем может быть причина проблемы при запуске Apache Tomcat напрямую из командной строки?
Какой сайт я должен был проверить, чтобы решить эту проблему?
Правка 1:
- Я попробовал запустить эту версию Tomcat на своем личном ноутбуке. Сначала он отказывался работать. Я установил Java 1.7.0_80 и затем изменил в командной строке
JAVA_HOME
на эту директорию. С этим изменением Tomcat заработал иlocalhost:8080
показал тестовую страницу.
С теми же изменениями на моем рабочем ноутбуке я получаю следующее предупреждение:
Сообщение гласит: “Брандмауэр Windows заблокировал некоторые функции Java(TM) Platform SE binary во всех общественных и частных сетях.” А внизу написано: “(i) Это настройка управляется вашей организацией.”
Я думаю, что проблема может быть связана с брандмауэром, но я не уверен. Я сообщу вам, как только узнаю больше об этом.
Правка 2:
Я работаю на дому и поговорил с нашим экспертом по брандмауэру. Хотя он добавил JVM в список, он все еще не работает здесь через VPN-соединение. Но на моем ноутбуке он работает, и localhost:8080
показывает index.html
в каталоге ROOT
.
.
Ответ или решение
На основе предоставленной информации, давайте разберемся, почему Apache Tomcat 6.0.53 запускается, но доступ к http://localhost:8080/ невозможен.
Теория
Когда мы говорим об Apache Tomcat, важно понимать, что это сервер приложений, который используется для развертывания и управления Java-Servlet и JSP. В вашей текущей ситуации, Tomcat слушает порт 8080, однако 404 ошибка означает, что запрашиваемый ресурс не найден. Это может быть вызвано несколькими причинами:
-
Неправильная структура каталогов: Tomcat ожидает, что приложения будут развернуты в определенной структуре, и любое отклонение от нее может привести к ошибкам.
-
Проблемы с конфигурацией: Файлы конфигурации Tomcat, такие как server.xml и web.xml, контролируют, как сервер обрабатывает запросы. Любая ошибка в них может вызвать отсутствие доступа к ресурсам.
-
Проблемы в сети или безопасности: Брандмауэры и сетевые ограничения могут препятствовать доступу к нужным ресурсам.
Пример
На основании текста, вы выполнили следующие шаги:
- Проверили, что Tomcat слушает порт 8080 и не возник конфликтов с другими процессами.
- Убедились в наличии файлов index.html и test.html в каталоге ROOT под webapps.
- Изменили конфигурационный файл server.xml, добавив директиву
<Context path="" docBase="ROOT" />
. - Очистили кеши браузеров и попробовали другие браузеры для доступа.
Несмотря на принятые меры, доступ по http://localhost:8080/ остается невозможным, что указывает на более глубокую проблему либо с конфигурацией Tomcat, либо с сетевой безопасностью.
Применение
-
Проверка конфигураций:
- Убедитесь, что все пути в server.xml и web.xml корректны и ссылаются на актуальные директории и файлы, особенно учитывая разницу в CATALINA_BASE.
- Проверьте еще раз записи
<Host>
и<Context>
. Убедитесь, что директивы appBase="webapps" и путь в<Context>
настроены верно.
-
Изоляция проблемы:
- Попробуйте временно отключить или настроить брандмауэр, чтобы убедиться, что проблема не в безопасности.
- Убедитесь, что VPN не блокирует локальные сетевые подключения. Попробуйте запустить Tomcat на машине, полностью отключенной от VPN.
-
Совместимость и тестирование:
- Вы также упомянули установку Java 1.7 на вашем ноутбуке. Убедитесь, что на рабочем ноутбуке используется точно такая же версия Java, и что JAVA_HOME настроен корректно.
- Если у вас есть доступ к другой тестовой машине или среды, попробуйте развернуть Tomcat там для изоляции проблемы.
-
Логи и диагностика:
- Проведите анализ всех логов Tomcat, особенно тех, которые генерируются в момент запроса, чтобы выявить все подозрительные записи.
- Используйте инструменты диагностики сети, чтобы проверить, корректно ли отправляются и обрабатываются пакеты данных.
-
Консультирование с администратором сети:
- Поскольку вы работаете из дома, подключение через VPN может иметь ограничения. Проверьте возможность работы с вашим сетевым администратором для решения потенциальных проблем с сетью.
-
Дополнительные ресурсы:
- Посетите документированные ресурсы Apache Tomcat и форумы поддержки. Там вы можете найти некоторые случаи, аналогичные вашему, которые могут предложить новые решения или подходы к устранению проблемы.
Следуя этим шагам, вы должны определить источник проблемы и затем предпринять подходящие действия для восстановления доступа к вашему веб-приложению. Оставайтесь на связи с техподдержкой и другими специалистами, чтобы ускорить процесс устранения неполадок.