LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

1

https://packages.gentoo.org/packages/www-servers/tomcat

Нет USE-флагов для установки примеров скриптов запуска (что-то вроде USE=«systemd», USE=«sysvinit»)

$ equery files tomcat | grep "\.service"  
$ 

В некоторых других серверах есть USE-флаг vhosts, если он не установлен, то проводится настройка по-умолчанию. Если установлен - оставляется на усмотрение пользователя.

Ещё есть USE=«http2» (поддержка HTTP/2). И в tomcat она есть, но конфигурирование почему-то делается для HTTP-1.1.

Там ещё есть скрипт внутри
/usr/share/tomcat-10.1/gentoo/tomcat-instance-manager.bash
мне непонятно, почему этот скрипт не умеет показывать уже сконфигурированные инстансы. И вообще почему он сделан отдельным скриптом, а не как eselect-модуль.

Типа:
emerge app-eselect/eselect-tomcat
eselect tomcat list

Чего я хочу добиться? Если я хочу сделать пакет для web-приложения (например на Java), то такой пакет может иметь зависимость от tomcat. Пакет tomcat-та должен подтянуться и установиться с какими-то разумными умолчаниями (и стать запускаемым). А внутри моего билда я должен сконфигрурировать приложение при помощи webapp-config. А tomcat не готов!

★★★★

Последнее исправление: Dimez (всего исправлений: 2)

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.

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

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

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

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от vbr

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

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

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

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

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

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

leave ★★★★★
()
Ответ на: комментарий от leave

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

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

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

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

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

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

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

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

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

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

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

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

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

leave ★★★★★
()
Ответ на: комментарий от Shushundr

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

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

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

leave ★★★★★
()
Ответ на: комментарий от Dimez

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

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

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

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

d00fy ★★★
()
Последнее исправление: d00fy (всего исправлений: 1)
Ответ на: комментарий от leave

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

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

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

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

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от d00fy

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

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

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

Dimez ★★★★★
()
Ответ на: комментарий от Shushundr

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

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

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

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

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

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

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

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

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

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

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

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

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

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

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

Dimez ★★★★★
()
Ответ на: комментарий от Shushundr

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

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

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

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

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

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

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

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

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

vbr ★★★★
()
Ответ на: комментарий от Shushundr

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

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

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

Dimez ★★★★★
()
Последнее исправление: Dimez (всего исправлений: 1)
Ответ на: комментарий от Shushundr

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

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

Dimez ★★★★★
()
Последнее исправление: Dimez (всего исправлений: 1)
Ответ на: комментарий от Dimez

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

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

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от vbr

спринг умеет

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

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

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

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

vbr ★★★★
()
Ответ на: комментарий от vbr

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

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

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

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

arkhnchul ★★★
()
Последнее исправление: arkhnchul (всего исправлений: 1)
Ответ на: комментарий от d00fy

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

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

arkhnchul ★★★
()
Ответ на: комментарий от vbr

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

WatchCat ★★★★★
()
Ответ на: комментарий от arkhnchul

Чего сразу «развлекается»? А Вы пробовали продеплоить 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) эту ошибку никто то-ли не видит, то-ли ленится исправить.

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

А ещё они написали, что сервер должен сам обрабатывать 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 года назад было пофикшено

arkhnchul ★★★
()
Ответ на: комментарий от arkhnchul

почти 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
А бага есть по факту.

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от Shushundr

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

arkhnchul ★★★
()
Ответ на: комментарий от arkhnchul

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

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от arkhnchul

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

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

кто «они»?

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от arkhnchul

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

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

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

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

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от arkhnchul

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от arkhnchul

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

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

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

На мой взгляд

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

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

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

arkhnchul ★★★
()
Ответ на: комментарий от arkhnchul

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

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

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

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

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от arkhnchul

«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).»

Shushundr ★★★★
() автор топика