Есть ли какие-то простые способы получать значения с использованием JNDI без приседаний с ручной обработкой контекстов, отловом исключений для не заданных параметров и т.п.?

Интересует для применения в POJO, для которых @Resource вроде как не работает.

Цель: конфигурирование веб-приложений через .xml при наличие опциональных/не задаваемых параметров.

В идеале - класс-помощник, не бросающий исключения по поводу отсутствующих из запрашиваемых параметров, а возвращающий указанные значения по умолчанию.

Имеется в виду использование Jndi Object Factory Bean?
Остальное по указанной ссылке как-то не сильно упрощает жизнь.

standalone сервер
Работает все на tomcat без полноценного AppServer.
Пишется новый функционал, требующий некоторого конфигурирования (указания для конкретного приложения путей в ОС с вспомогательными файлами).
Использование spring допустимо, пока рассматриваются варианты.

WGAПочему-бы тогда не .properties? Если Spring, то вообще удобно.
В одном контейнере может быть запущено несколько однотипных приложений с разными path.
Используются нераспаковываемые war-файлы.
т.е. одно и тоже приложение (реально один war-файл на диске) замаплены через контекст на разные <servername>/path1, <servername>/path2 и т.п.
У каждой копии есть ряд уникальных параметров, задающихся в момент ввода в работу очередной копии и потом меняющихся крайне редко (кол-во копий может изменяться со временем).
Применение JNDI и env entries в server.xml (хоть это и не рекомендуется) вполне удовлетворяют постановке.
Свести все эти копии одного приложения в одно и управлять уже внутри доступом к разным url на данный момент не представляется возможным.

Можете, исходя из этих уточнений, предложить структуру хранения уникальных параметров каждой копии через .properties и/или через Spring?

BlazkowiczА в БД почему нельзя хранить?
БД на данный момент никак не задействована и не входит в требования к серверу.
Приложения обрабатывают большие объемы разнотипных файлов в локальной файловой системе.
Задействовать БД только ради конфигурирования в данный момент не рационально.

WGAЗадеплойте WAR-архив под разными именами, т.е. в разные папки, в каждой папке свой property-файл. В чем проблема-то? Или хочется именно JNDI? Только непонятно, зачем это для standalone-сервера...
JNDI лишь очевидный способ пробросить что-то специфическое для контекста.
Кроме как плодить .properties есть еще варианты?

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

В моем варианте все крайне просто. "Деплой" делается вручную, так всем понятнее:
- Установил Java + Tomcat
- Скопировал .war файл в webapps
- Прописал указанные параметры <Host> в server.xml
- Инструкция по добавлению <Context ...> для каждой копии
Для обновления (происходит раз в 2-3 месяца):
- Скопировал новый .war файл (включающий номер версии) рядом в webapps (старый не удаляем)
- [опционально] Замена в server.xml имени файла у одной копии для тестирования, не понравилось - меняем назад
- Замена по всем контекстам старого имени на новое (смена номера версии в имени файла)
- Рестартовали контейнер

Предложенный вами вариант сильно усложняет процесс и может привести к рассинхронизации версий в копиях

пролетевшийЖелание понятное - разделить приложение и конфигурацию, без распаковки/запаковки war etc. JNDI выглядит привлекательно, но крайне геморойно. Я пользую не properties, а Typesafe config
Спасибо, посмотрю что это. Выглядит вполне работоспособно вроде.
Правда все равно придется с нашей схемой развертывания в конфиг сервера лазить при обновлениях/добавлениях копий.

BlazkowiczТо есть использовать JEE стэк для обработки локальных файлов это рационально, а БД - нет.
JEE вам нахрен вообще упал? Web морда нужна что ли?
Это промышленное legacy-приложение, потихоньку перетаскиваемое на новые рельсы. БД появиться, но позже.
По этому сразу "на вырост" тот самый стек

Blazkowiczcontext.xml можно размещать внутри war. И в нем при сборке прописывать версию. Тогда и context path будет включаить номер версии и не зависеть от имени самого war.
Имеется в виду, что не нужно будет трогать server.xml при обновлении версий?
А как контейнер поймет, какую версию сейчас надо использовать?
Номер версии в имени файла - критичен для контроля выполнения операций админами предприятий.

BlazkowiczКонтейнеру - пофиг, он хостит все активные модули. Он ничего не "использует". Поэтому вопрос я немного не понял.
Сейчас <Host> задан с атрибутами autoDeploy="false" deployOnStartup="false" для контроля тех самых копий.
Пример текущих инструкций по развертыванию/обновлению я привел несколькими сообщениями ранее.
С учетом вашего замечания про версионность с context.xml - какие пункты этой инструкции и как должны видоизмениться (т.е. рассмотрим с точки зрения админа)?

BlazkowiczОстаётся пожелать удачи.
Спасибо!
BlazkowiczЯ не сторонник JEE, учитывая что вы его только начинаете изучать, это ещё больший риск.
Ок, а какой бы вариант вы бы выбрали для задачи:
- Приложение "с web-мордой", данными для которого являются кучка локальных (или расположенных где-то в сети, не важно) файлов.
- Каждая кучка - это тысячи (иногда десятки и сотни тысяч) файлов разных форматов общим объемом несколько (иногда много) гигабайт
- Таких кучек надо обрабатывать N штук одновременно.
- Обработка - поиск данных и формирование отчетов с использованием уже подготовленной индексной информации (данные когда-то, да и сейчас, продолжают формироваться другой промышленной системой).
- Перепаковать эти гигабайты файлов в другой формат - задача, на которую владельцы пойдут только в самый последний момент, да и поменять выходной формат источника нельзя, и процесс перепаковки был бы вечным, так что надо работать с чем есть.

BlazkowiczПросто подсказываю, что context.xml можно хранить внутри .war, и не прописывать руками в server.xml.
Это я знаю, но в server.xml ковыряются только уникальные параметры каждой копии и явное задание этих самых копий.
Ничего общего для всех копий сразу там не задается (это можно было бы сделать, как вы и говорить, через файл внутри war).
Как я уже говорил .war файл всего один на все копии.
BlazkowiczАктивировать\деактивировать модули можно через web админку. Если в приложении утечек в perm gen нет, то это проще чем, руками ковырять тот же server.xml.
На данный момент модуль всего один и админам проще "просто скопировать файл + рестарт контейнера", чем работа с непонятными (им) админками.