Всем привет!

Из чулана достали web-приложение и захотели его реанимировать. И возник вопрос

Приложение написано на JSP без ориентации на какой либо конкретный сервер. Для его работы есть три параметра подключения к внешнему сервису. Считается, что параметры ставит админ при деплое. Хранятся сейчас они в web.xml. При обновлении приложения параметры естественно будут затираться. Где лучше хранить подобные параметры, чтобы обновление их не убивало?

Гуление выдало несколько вариантов, из которых следует, что кто что придумал, тот так и делает, да к тому же зависит от сервера...

Здравствуйте, OlegMB, Вы писали:

OMB>Из чулана достали web-приложение и захотели его реанимировать. И возник вопрос

OMB>Приложение написано на JSP без ориентации на какой либо конкретный сервер. Для его работы есть три параметра подключения к внешнему сервису. Считается, что параметры ставит админ при деплое. Хранятся сейчас они в web.xml. При обновлении приложения параметры естественно будут затираться. Где лучше хранить подобные параметры, чтобы обновление их не убивало?

OMB>Гуление выдало несколько вариантов, из которых следует, что кто что придумал, тот так и делает, да к тому же зависит от сервера...

Можно через переменные окружения, проперти файл.
Вообще сейчас часто делают докер имажи и пофиг на редеплой. Надо обновить — сгенерировали новый образ и задеплоили в k8s например. Когда-то давно rpm использовали. Вообще редеплоя надо избегать изо всех сил.

В web.xml прописываем

    <env-entry>
        <description>Time at which import should run. Example: "23:30".</description>
        <env-entry-name>conf/run-import-time</env-entry-name>
        <env-entry-type>java.lang.String</env-entry-type>
    </env-entry>

После этого при деплое эти параметры указываются специфичным для конкретного сервера методом. Например для Tomcat я делаю так: в META-INF war-файла добавляю файл context.xml следующей структуры:

<?xml version="1.0" encoding="UTF-8"?>
<Context>
    <ResourceLink name="conf/run-import-time" global="mkbiicbip-integration/conf/run-import-time" type="java.lang.String"/>
</Context>

А в apache-tomcat-9.0.30\conf\server.xml добавяю конкретные значения для конфигурации (пишу по памяти, но вроде так):

<GlobalNamingResources>
    ...

    <Environment name="mkbiicbip-integration/conf/run-import-time" type="java.lang.String" value="23:30" override="false"/>

В первую очередь это нужно для конфигурации DataSource, но и обычные строковые или числовые значения так тоже можно настраивать. В Java-коде достаётся стандартным способом через JNDI. Вроде это самый правильный с идеологической точки зрения способ конфигурировать war и в принципе достаточно удобный. Например если используется "взрослый" контейнер вроде WebSphere, там при деплое прям в веб-интерфейсе выведутся все конфигурируемые значения и их можно настраивать оттуда без всяких файлов, но и в томкате тоже жить можено.

Здравствуйте, GarryIV, Вы писали:

GIV>Можно через переменные окружения, проперти файл.
Переменные точно не подходят, а проперти файл не перетирается сервером при редеплое приложения?

GIV>Вообще сейчас часто делают докер имажи и пофиг на редеплой. Надо обновить — сгенерировали новый образ и задеплоили в k8s например. Когда-то давно rpm использовали.
Глянул на докер и первый вопрос. А не слишком это тяжелая штука для небольшого приложения в 20-30 jsp-шек для корпоративной среды?

GIV>Вообще редеплоя надо избегать изо всех сил.
Даже если это не публичный сайт и нет требования 24/7?

Здравствуйте, vsb, Вы писали:

vsb>После этого при деплое эти параметры указываются специфичным для конкретного сервера методом. Например для Tomcat я делаю так: в META-INF war-файла добавляю файл context.xml

Если ты внутрь вара пихаешь все равно зачем это через web.xml тащить? Положи тогда уж в application.properties.

Здравствуйте, GarryIV, Вы писали:

vsb>>После этого при деплое эти параметры указываются специфичным для конкретного сервера методом. Например для Tomcat я делаю так: в META-INF war-файла добавляю файл context.xml

GIV>Если ты внутрь вара пихаешь все равно зачем это через web.xml тащить? Положи тогда уж в application.properties.

Почему пихаю внутрь вара? Я пихаю в глобальные настройки томката. context.xml просто связывает локальные настройки и глобальные. В этом и суть, чтобы настройки были в томкате, а в самом приложении не были.

Здравствуйте, OlegMB, Вы писали:

GIV>>Можно через переменные окружения, проперти файл.
OMB> Переменные точно не подходят, а проперти файл не перетирается сервером при редеплое приложения?

Всё перетирается. Для такого подхода делается отдельная фаза деплоя — пишешь скрипт, который сначала распаковывает war-файл и потом перезаписывает в него боевой конфиг (и потом опционально запаковывает). Так, конечно, проще, но деплоить просто закинув файл (или через веб-интерфейс) уже не получится.

Здравствуйте, vsb, Вы писали:

vsb>Почему пихаю внутрь вара?

Сорри, читал по диагонали.

Здравствуйте, OlegMB, Вы писали:

OMB> Переменные точно не подходят, а проперти файл не перетирается сервером при редеплое приложения?

У нас на одном из прошлых мест делали так: при сборке war'а 'application.properties' помещался туда с именем 'application.properties.src'.
А дальше при деплое заботой админа было проверить, какие проперти в src поменялись, добавились, удалились и перенести изменения в сам 'application.properties', не трогая "боевые" настройки.