Почему при установке tomcat не создаётся инстанс по-умолчанию?

Чот мне кажется, что уже пора.

If you set the properties to different locations, the CATALINA_HOME location contains static sources, such as .jar files, or binary files. The CATALINA_BASE location contains configuration files, log files, deployed applications, and other runtime requirements.

Мне кажется, что есть аналогия между CATALINA_BASE/CATALINA_HOME и двумя стадиями инсталляции при помощи webapp-config. Соответственно, CATALINA_BASE могла бы указывать на место установки приложений, а CATALINA_HOME в /var/www/localhost.

Но с другой стороны, программное обеспечение самого сервера - это не то же самое, что приложения, которые в него загружаются. И вместе они не хранятся. Получается что одной переменной CATALINA_BASE недостаточно, или можно оставить её использование для tomcat, а место установки web-приложений будет известно только утилите webapp-config.

CATALINA_BASE это где сам томкат стоит, а CATALINA_HOME это конкретный инстанс. Это если ты хочешь запускать несколько инстансов, шарящих один томкат. Возможно перепутал между собой эти переменные, но вроде не перепутал. Там ещё надо грамотно всякие sever.xml настроить, чтобы оно заработало как положено.

В целом это всё дурная затея. Делай одну папку, в неё клади томкат, жаву, варку и всё, не надо никаких пакетов. А ещё лучше без томката, спринг умеет в tomcat embedded. Сейчас эти все серверы приложений уже считаются устаревшими.

В целом это всё дурная затея.

Утверждение без доказательств.

Сейчас эти все серверы приложений уже считаются устаревшими.

Мало ли где что считается. Важно ведь - по каким причинам. А причины не указаны.

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

Я вот никак не могу понять: тебе реально нехрен делать или ты троллишь тупостью?

Вы же не объясняете в чём тупость. Поэтому терпите.

Тупость в том, что ты упорно пытаешься притянуть подходы 15-летней давности в 2023 год, и вдобавок постоянно мечешься между технологиями, не пытаясь разобраться в какой-то одной. А еще в том, что используешь неподходящие (при твоем уровне владения) инструменты.

ты упорно пытаешься притянуть подходы 15-летней давности в 2023 год

Старые технологии устаканились, и не будут меняться. Это очень удобно, есть время их изучить. Кроме того, к ним много документации в интернете.

вдобавок постоянно мечешься между технологиями

Вы не называете единственно верную. Точнее каждый называет свою. Поэтому надо все понадкусывать лично.

используешь неподходящие (при твоем уровне владения) инструменты.

NixOS для меня неподходящая, слишком сложная. Я её не использую.

Вы же не объясняете в чём тупость.

У тебя РАС? Сам никак?

Поэтому терпите.

С таким подходом проще забанить.

P.S. И тэги не поставил.

подходы 15-летней давности

Старые технологии устаканились

Зачем ты читаешь жопой? Я сказал «подходы»

Вы не называете единственно верную. Точнее каждый называет свою. Поэтому надо все понадкусывать лично.

Нет единственно верной. Возьми какую-то одну и изучи, твое «поднадкусывание» приведет только к тому, что ты ни одной не поймешь.

NixOS для меня неподходящая, слишком сложная. Я её не использую.

А вот теперь я точно вижу тролля. Пожалуй, подниму вопрос о твоем забане.

Вот из-за таких как ты в Gentoo издохли проекты https://wiki.gentoo.org/wiki/Project:Webapps и другие.

Вахтёры, потому что.

Они издохли потому что

1. ставить веб-приложения system-wide это прекрасный способ затрахаться в ноль и получить нулевой выхлоп (читай выше про древние подходы, когда у приложения не было зависимостей)

2. гента и веб плохо друг другу подходят, мир серверов живет на дебиано-убунтах и rhel/centos

забанить - это хорошо

проблема только в том, что через пару часов этот бан снимают (я сам видел)

такие вот дела тут у вас, модераторов, происходят :(

ps. я понимаю, что он пытается нащупать новое направление в троллинге и вам, модераторам, интересно, что из этого выйдет, но раздражает это направление не только thesis, если честно

ставить веб-приложения system-wide это прекрасный способ затрахаться в ноль и получить нулевой выхлоп (читай выше про древние подходы, когда у приложения не было зависимостей)

Нет разницы между системным софтом и прикладным. Если нельзя ставить приложения в единственном экземпляре, значит надо выкидывать весь подход с пакетными менеджерами

мир серверов живет на дебиано-убунтах и rhel/centos

Как раз Debian с его релизным циклом не подходит для web-приложений. А gentoo подходит, потому что она rolling.

я понимаю, что он пытается нащупать новое направление в троллинге и вам, модераторам, интересно, что из этого выйдет

Нет, не особо интересно, если положить руку на сердце. Но и безусловно резать на подлёте, не дожидаясь возможного перитонита, тоже не хочется.

Также я оставляю вероятность банального РАС, когда человек не понимает, что он делает не так.

Нет разницы между системным софтом и прикладным.

Есть. Сайт - не прикладной софт.

Если нельзя ставить приложения в единственном экземпляре, значит надо выкидывать весь подход с пакетными менеджерами

У тебя всегда безусловно чёрно-белый мир без вариантов?

Сайт - не прикладной софт.

Отличия сайта (точнее web-приложения) в том, что устанавливаются экземпляры для разных пользователей и, возможно, по несколько штук в разные места.

Для обычных приложений такое тоже бывает, например профили в Firefox для разных пользователей, или разные файрфоксы для разных задач (с tor, без tor, и т.д.)

Если пакетный менеджер такое умеет, то он и с web-приложениями справится. Если не умеет, он и с десктопными/системными слажает. В генте второй вариант.

У тебя всегда безусловно чёрно-белый мир без вариантов?

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

Отличия сайта (точнее web-приложения) в том, что устанавливаются экземпляры для разных пользователей и, возможно, по несколько штук в разные места.

Разве что сферического сайта в вакууме.

Если пакетный менеджер такое умеет, то он и с web-приложениями справится.

Ну считаешь - вперёд, реализовывай, только не в формате «няньчитесь со мной и терпите», за это удаление, бан, гроб, кладбище и т.д. То, что ты хочешь - нужно, судя по реальности, чуть ли не тебе одному.

Утверждение без доказательств.

Это моё мнение, как человека, который на жаве 15 лет программирует и с томкатом повозился достаточно.

Мало ли где что считается. Важно ведь - по каким причинам. А причины не указаны.

Причина как раз очевидна - проще всё засунуть в одну кучу, где все компоненты проверены и большинство конфигов умолчательные.

Причина делать по-другому вот уже не очевидна. Это даёт: экономию диска (с десяток мегабайтов). И, наверное, всё.

Самый главный минус, на мой взгляд - настраивать это всё заманаешься. Но если очень хочется - дерзай.

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

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

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

Разве что сферического сайта в вакууме.

Ну что такого ещё у сайта есть? Коннект с СУБД? У некоторых приложений тоже есть.

Нет, потому что это оказалось никому не нужным оверинжинирингом.

Сама идея довольно неплоха, но для её реализации нужно взаимодействовать с девелоперами сторонних webapps и держать в ежовых рукавицах всех причастных к разработке веб-сайта (выстраивать взаимодействие с сервером/сайтом сугубо по твоему регламенту), причём с максимальным уровнем неудобств для довольно посредственного уровня автоматизации и (бесшовного) деплоя. Что совершенно нереально, ибо это возможно только в теории.

Поэтому применяются другие, менее неудобные для всех механизмы.

Ну что такого ещё у сайта есть? Коннект с СУБД? У некоторых приложений тоже есть.

Таки да, это всё же троллинг тупостью.

Эти ваши другие механизмы требуют дополнительного изучения (learning curve), и вместо того, чтобы привести разработку к правилам у нескольких разработчиков, вы заставляете учить это всё на порядок большее количество пользователей/админов.

В общем, trade-off тут есть, но утверждение что лучше одно или другое приведено без доказательств. Просто «так сложилось».

Таки да, это всё же троллинг тупостью.

Отсутствие аргументации, хамство, угроза убийства по УК РФ (выше, где про кладбище).

чтобы привести разработку к правилам у нескольких разработчиков

А, типичный https://xkcd.com/927/, понятно.

угроза убийства по УК РФ (выше, где про кладбище).

Троллинг тупостью 80 уровня.

Делай

И опять.

Странно, до сих пор же нормально было.

спринг умеет

А вот тебе другое мнение:

eclipse, java, сервлеты, packages - помогите план обучения построить (комментарий)

«Все полезные нововведения из Spring перекочевали в Java EE последних версий. Spring больше не нужен.»

Я скажу честно, мне пофиг, спринг или жава ее. Я и то и другое знаю, меня и то и другое бесит. Но факт в том, что в 90% вакансий спринг. Жава ее в вакансиях в 99% случаев это старинные отложения мамонта. Поэтому тут для меня лично предмета спора нет. Библиотек интересных полно. Но люди пользуются спрингом, вот и весь сказ.

спринг умеет в tomcat embedded

современная JavaEE в лице Jakarta тоже так-то нормально пашет на встроенных jersey/jetty.

Сейчас эти все серверы приложений уже считаются устаревшими.

4.2 прям злостное.

проблема только в том, что через пару часов этот бан снимают (я сам видел)

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

Забавно видеть противопоставление JavaEE и Spring. Особенно когда я могу одновременно использовать Spring Boot, JPA и JMS в одном проекте. Как по мне, так это пересекающиеся множества, которые конечно по хорошему бы объединить, но и так работает.

Чего сразу «развлекается»? А Вы пробовали продеплоить sample.war со страницы http://localhost:8080/docs/appdev/sample/sample.war ?

Он деплоится, но не работает, пишет:

jakarta.servlet.ServletException: Ошибка создания экземпляра класса сервлета [mypackage.Hello]
	org.apache.catalina.authenticator.AuthenticatorBase.invoke(Unknown Source)
	org.apache.catalina.valves.ErrorReportValve.invoke(Unknown Source)
	org.apache.catalina.valves.AbstractAccessLogValve.invoke(Unknown Source)
	org.apache.catalina.connector.CoyoteAdapter.service(Unknown Source)
	org.apache.coyote.http11.Http11Processor.service(Unknown Source)
	org.apache.coyote.AbstractProcessorLight.process(Unknown Source)
	org.apache.coyote.AbstractProtocol$ConnectionHandler.process(Unknown Source)
	org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(Unknown Source)
	org.apache.tomcat.util.net.SocketProcessorBase.run(Unknown Source)
	org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(Unknown Source)
	org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(Unknown Source)
	org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Unknown Source)
	java.base/java.lang.Thread.run(Thread.java:833)

Всё потому что они изменили название неймспейса (по требованию Oracle).

Root Cause

java.lang.ClassNotFoundException: javax.servlet.http.HttpServlet

javax.servlet -> jakarta.servlet

А ещё они написали, что сервер должен сам обрабатывать war-архив при загрузке, но этого не происходит. «В 2018 году, проект Java EE был переименован в Jakarta EE, и все его компоненты, включая JSP, были переименованы соответственно»

Пять лет (сейчас 2023, 2023-2018=5) эту ошибку никто то-ли не видит, то-ли ленится исправить.

А ещё они написали, что сервер должен сам обрабатывать war-архив при загрузке, но этого не происходит.

кто «они»?

Пять лет (сейчас 2023, 2023-2018=5) эту ошибку никто то-ли не видит, то-ли ленится исправить.

https://github.com/apache/tomcat/commit/ab35110801998e4f2fa74c62263b0f8030f021d4

Rename «javax.servlet.*» to «jakartax.servlet.*» and fix tests

markt-asf committed on Jan 13, 2020

почти 4 года назад было пофикшено

почти 4 года назад было пофикшено

Было пофикшено что-то другое.

[ebuild   R    ] www-servers/tomcat-10.1.15:10.1::gentoo  USE="-doc* -extra-webapps* -source -test -verify-sig" 21 903 KiB

У меня версия 10.1.15, у неё дата релиза - 2023-10-16
А бага есть по факту.

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

в дистрибутивах рядом с новыми сорцами лежит собранный в незапамятные времена (еще явой 1.5) артефакт

Это что-же получается, в генте артефакты из исходников не собираются?

Он почему-то лежит прям в дереве сорцов томката, вот уже 16 лет как. Скорее всего, система сборки просто не пересобирает уже собранный.

Значит это тест!

А ещё они написали, что сервер должен сам обрабатывать war-архив при загрузке, но этого не происходит.

кто «они»?

Авторы томката в документации на эту фичу.

автодеплой не работает?

закинул томкатовцам багрепорт по sample.war, пусть чинят.

Я не знаю, что такое «автодеплой».

Ты закинул багрепорт без достаточного уважения. А я прочитал правила отправки им багов и поэтому отправлять не стал.

Они писали, что если задеплоить war, то сервер должен во время деплоймента заменить один неймспейс на другой, чтобы всё продолжало работать. Но мы же видим, что не работает. Значит деплой не работает. При чём тут «авто» или не «авто»? Никакой не работает.

Ошибки, конечно, не возникает, во время деплоймента. Но это не значит, что он «работает».

Но мы же видим, что не работает

что делал и что в логах?

Выше всё написано, причём два раза. И что сделал, и что должно было произойти по моему мнению. Это недоделка, поэтому в логах ничего нет. Логично? Логично.

не вижу там «что делал», только куски логов с руганью на javax.

Скачал war-файл как файл, зашел через web в менеджер, закачал war для деплоймента, открыл приложение, увидел текст ошибки (он выше).

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

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

На мой взгляд

так на твой взгляд, или «они написали»?

Они обещают в документации, что всё должно работать

перечитай еще раз, что для этого надо сделать, там написано.

перечитай еще раз, что для этого надо сделать,

Написано там в двух местах два разных утверждения.

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

Ну вот «на мой вздгяд» томкат сам не меняет.

а другое «для старых архивов томкат сам поменяет».

прям так и написано, «деплойте как обычно и все будет норм»? Цитату в студию вместе с источником.

«Tomcat can convert an existing web application from Java EE 8 to Jakarta EE 9 at deployment time using the Apache Tomcat migration tool for Jakarta EE.»

Дальше пару предложений я не читал, а надо было.

«To make use of the feature, the web application should be placed in the Host legacyAppBase folder (by default named webapps-javaee) and they will be converted to an equivalent Jakarta EE web application in the Host appBase folder (by default named webapps).»