Лучшая практика? JNDI, Hibernate и Tomcat - PullRequest
1 голос
/ 19 апреля 2011

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

Я смотрю на то, как я могу облегчить задачу настройки при переходе с dev наtest and to prod.

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

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

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

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

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

Приветствия, Питер

1 Ответ

2 голосов
/ 19 апреля 2011

Полагаю, вы немного запутались.

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

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

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

Нет необходимости загрязнять каталог lib / Tomcat. Как вы правильно заметили, это плохая практика.

...