По той же причине, по которой вы бы использовали JNDI для чего-либо, - для переноса конфигурации из приложения в среду развертывания.
С JNDI вы в основном говорите: «Для этого приложения требуется SessionFactory; его имя должно быть X», и вы довольны, если на сервере приложений настроен SessionFactory с именем X. Этот вид экстернализации имеет несколько привлекательных преимуществ:
Вы можете использовать совершенно разные конфигурации на разных машинах (производственная среда и QA используют Oracle, разработчики используют HSQL, ...).
Вам не нужно информировать процесс сборки о конфигурациях (не более ant war_for_qa или обойти с профилями Maven).
У вас нет соблазна проверять конфигурации в управлении версиями, и поэтому ваш пароль к действующей базе данных не будет известен каждому временному, интерну, консультанту или бывшему сотруднику, который когда-либо имел (или будет иметь!) Доступ в хранилище.
Ваши инструкции по установке / настройке не будут включать такие элементы, как «для настройки входа в базу данных, отредактируйте файл foo.properties в файле WAR», что неизбежно приведет к перезаписи конфигураций на рабочем сервере в худшем случае Возможный момент, потому что системный администратор, который работал все выходные, развернул неотредактированную WAR, потому что кофе закончился в воскресенье днем.
JNDI просто является «стандартным» способом выполнения этой экстернализации в Java, что означает, что новым разработчикам / администраторам не потребуется двухдневного обучения, чтобы изучить особенности вашей собственной домашней системы конфигурации, которая действительно это довольно умно, но есть эта странная ошибка, в которую никто не хочет вникать, потому что она действительно странная и в любом случае у нее довольно простой обходной путь, & c.
Похожие: Какова цель JNDI?