Почему связывают, в спящем режиме SessionFactory к ресурсу JNDI?

Я бы сказал, по той же причине, по которой вы бы использовали JNDI для чего-либо - перенос конфигурации из приложения в среду развертывания.

Используя JNDI, вы в основном говорите, что «этому приложению требуется SessionFactory ; и его имя должно быть X», и вы довольны, пока сервер приложений имеет вызываемый SessionFactory X настроен. Такой вид экстернализации имеет несколько привлекательных преимуществ:

1. Вы можете использовать совершенно разные конфигурации на разных машинах (производственная и QA использует Oracle, разработчики используют HSQL, ...).

2. Вам не нужно сообщать процессу сборки о конфигурациях (больше не нужно ant war_for_qa или возиться с профилями Maven).

3. У вас нет соблазна проверять конфигурации в системе контроля версий, поэтому ваш действующий пароль базы данных не будет известен каждому временному специалисту, стажеру, консультанту или бывшему сотруднику, который когда-либо имел (или будет иметь!) Доступ к репозиторию .

4. Ваши инструкции по установке / настройке не будут включать такие пункты, как «настроить вход в базу данных, отредактировать файл foo.properties в файле WAR», что неизбежно приведет к перезаписи конфигурации на производственном сервере в самый неподходящий момент, потому что Системный администратор, проработавший все выходные, развернул неотредактированную WAR, потому что в воскресенье днем ​​закончился кофе.

JNDI является «стандартным» способом выполнения этой экстернализации в Java, а это означает, что новым разработчикам / администраторам не потребуется двухдневное обучение, чтобы изучить особенности вашей собственной самодельной системы конфигурации, которая на самом деле довольно умен, но имеет эту странную ошибку, в которую никто не хочет вникать, потому что она действительно странная, и в любом случае у нее есть довольно простой обходной путь и т. д.

По теме: Какова цель JNDI?