Лучшая практика? JNDI, Hibernate и Tomcat

У меня есть веб-приложение, размещенное на tomcat, которое использует спящий режим для общения с базой данных.

Я смотрю на то, как я могу упростить настройку при переходе от разработки к тестированию и производству.

Я видел много упоминаний JNDI, и на первый взгляд это кажется хорошей идеей. Вы настраиваете ресурс jndi для каждого экземпляра tomcat, и веб-контекст просто использует его.

Однако после дальнейшего изучения кажется, что для того, чтобы иметь JNDI, мне нужно, чтобы все мои объекты базы данных + спящий режим находились в файлах библиотеки tomcat, чтобы это работало. Для меня это звучит пугающе, но что, если я захочу развернуть другой контекст, использующий другую версию гибернации?

Кроме того, я не просто меняю боль от обслуживания конфигурации на боль от поломок, вызванных несоответствиями между установленными классами ресурсов jndi и классами в моем контексте.

В идеале я думаю, что я хочу просто сказать в tomcat. Существует база данных с именем X, она находится на этом сервере и имеет этого пользователя/пароль.

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

Привет, Питер


person Programming Guy    schedule 19.04.2011    source источник


Ответы (1)


Вы немного спутали вещи, я думаю.

JNDI — это просто имя, присвоенное пулу источников данных. Этот источник данных использует драйвер JDBC, который находится в глобальном пути к классам Tomcat, но это единственный общий ресурс во всей установке.

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

Все спящие JAR-файлы, а также любые другие JAR-файлы должны быть упакованы в WAR. Они «видимы» только в WAR, поэтому у вас может быть несколько приложений, использующих конфликтующие версии библиотек, развернутых на одном и том же Tomcat.

Не нужно загрязнять каталог lib/ Tomcat. Это плохая практика, как вы правильно заметили.

person Vladimir Dyuzhev    schedule 19.04.2011
comment
Поэтому инструкции здесь (community.jboss.org/wiki/) — плохая идея. ? - person Programming Guy; 19.04.2011
comment
Кроме того, предполагая, что я могу решить, как создать свою фабрику сеансов как нечто, взаимодействующее с источником данных jndi, как мне решить проблему моей среды разработки с использованием mysql и test/prod с использованием SQLServer? - person Programming Guy; 19.04.2011
comment
Инструкции о том, как использовать SessionFactory через JNDI. Другими словами, как разделить Hib SF между несколькими приложениями. Я не вижу, насколько это полезно, поэтому мой совет — делиться только необходимым минимумом, то есть источником данных. - person Vladimir Dyuzhev; 19.04.2011
comment
Вы используете разные даже не версии, а СУБД в dev и prod? Ну... это настоящее приключение, а? Что вы можете сделать, так это поместить hibernate.cfg.xml в глобальный путь к классам Tomcat. Остальные файлы останутся в WAR. - person Vladimir Dyuzhev; 19.04.2011
comment
Хм, а теперь идея. Можно отказаться от имени по умолчанию и назвать его mycontext-hibernate.cfg.xml. Я отчитаюсь и дам вам знать, как я иду. - person Programming Guy; 19.04.2011