Я віддаю перевагу третьому підходу, який бере найкраще з
Підходу 1 та Підходу 2, описаного користувачем1016403 .
Підхід 3
- Збережіть властивості бази даних на
server.xml
- посилання на
server.xml
властивості бази даних із веб-програмиMETA-INF/context.xml
Підхід до 3 переваг
Хоча перший пункт корисний з міркувань безпеки, другий пункт корисний для посилання на значення властивостей сервера з веб-програми, навіть якщо значення властивостей сервера будуть змінюватися.
Більше того, відокремлення визначень ресурсів на сервері від їх використання веб-додатком робить таку конфігурацію масштабованою для організацій різної складності, де різні команди працюють на різних рівнях / рівнях: команда адміністраторів сервера може працювати, не конфліктуючи з командою розробників, якщо адміністратор поділяє те саме Ім'я JNDI із розробником для кожного ресурсу.
Впровадження підходу 3
Визначте назву JNDI jdbc/ApplicationContext_DatabaseName
.
Оголосіть jdbc/ApplicationContext_DatabaseName
різні властивості та значення в Tomcat, server.xml
використовуючи щось подібне:
<GlobalNamingResources>
<Resource name="jdbc/ApplicationContext_DatabaseName" auth="Container" type="javax.sql.DataSource"
username="dbUsername" password="dbPasswd"
url="jdbc:postgresql://localhost/dbname"
driverClassName="org.postgresql.Driver"
initialSize="5" maxWait="5000"
maxActive="120" maxIdle="5"
validationQuery="select 1"
poolPreparedStatements="true"/>
</GlobalNamingResources/>
Пов’яжіть jdbc/ApplicationContext_DatabaseName
властивості 'з веб-програми META-INF/context.xml
за допомогою приватного контексту JNDI, java:comp/env/
зазначеного в name
атрибуті:
<Context path="/ApplicationContext" ... >
<!--
"global" attribute links to GlobalNamingResources in the ${catalina.base}/conf/server.xml (server administrator team)
"name" attribute is relative to the application-private JNDI context java:comp/env/ and is looked up from the java web application (application developer team)
-->
<ResourceLink global="jdbc/ApplicationContext_DatabaseName" name="jdbc/DatabaseName" type="javax.sql.DataSource"/>
</Context>
Нарешті, для того, щоб використовувати ресурс JNDI, вкажіть ім’я JNDI jdbc/DatabaseName
у дескрипторі розгортання веб-програми:
<resource-ref>
<description>DatabaseName's Datasource</description>
<res-ref-name>jdbc/DatabaseName</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
а у весняному контексті:
<jee:jndi-lookup id="DatabaseNameDataSource"
jndi-name="jdbc/DatabaseName"
expected-type="javax.sql.DataSource" />
Підходимо до 3 недоліків
Якщо ім'я JNDI буде змінено, тоді потрібно буде відредагувати і the, server.xml
і the, і META-INF/context.xml
буде потрібно розгортання; проте цей сценарій є рідкісним.
Підійдіть до 3 варіацій
Багато джерел даних, що використовуються однією веб-програмою
Просто додайте конфігурації до Tomcat server.xml
:
<GlobalNamingResources>
<Resource name="jdbc/ApplicationContext_DatabaseName1" ... />
<Resource name="jdbc/ApplicationContext_DatabaseName2" ... />
...
</GlobalNamingResources/>
Додайте посилання на веб-програму META-INF/context.xml
за допомогою приватного контексту JNDI, java:comp/env/
зазначеного в name
атрибуті:
<Context path="/ApplicationContext" ... >
<ResourceLink global="jdbc/ApplicationContext_DatabaseName1" name="jdbc/DatabaseName1" ... />
<ResourceLink global="jdbc/ApplicationContext_DatabaseName2" name="jdbc/DatabaseName2" ... />
...
</Context>
Нарешті, додайте використання ресурсів JNDI в дескрипторі розгортання веб-програми:
<resource-ref>
<description>DatabaseName1's Datasource</description>
<res-ref-name>jdbc/DatabaseName1</res-ref-name> ...
</resource-ref>
<resource-ref>
<description>DatabaseName2's Datasource</description>
<res-ref-name>jdbc/DatabaseName2</res-ref-name> ...
</resource-ref>
...
а у весняному контексті:
<jee:jndi-lookup id="DatabaseName1DataSource"
jndi-name="jdbc/DatabaseName1" ... />
<jee:jndi-lookup id="DatabaseName2DataSource"
jndi-name="jdbc/DatabaseName2" ... />
...
Багато джерел даних, що використовуються багатьма веб-програмами на одному сервері
Просто додайте конфігурацію до Tomcat's server.xml
:
<GlobalNamingResources>
<Resource name="jdbc/ApplicationContextX_DatabaseName1" ... />
<Resource name="jdbc/ApplicationContextX_DatabaseName2" ... />
<Resource name="jdbc/ApplicationContextY_DatabaseName1" ... />
<Resource name="jdbc/ApplicationContextY_DatabaseName2" ... />
...
</GlobalNamingResources/>
інші конфігурації слід вивести з попереднього варіаційного випадку.
Багато джерел даних до однієї бази даних використовуються багатьма веб-програмами на одному сервері
У такому випадку server.xml
конфігурації Tomcat, такі як:
<GlobalNamingResources>
<Resource name="jdbc/ApplicationContextX_DatabaseName" ... />
<Resource name="jdbc/ApplicationContextY_DatabaseName" ... />
закінчується двома різними веб-додатками, META-INF/context.xml
такими як:
<Context path="/ApplicationContextX" ... >
<ResourceLink global="jdbc/ApplicationContextX_DatabaseName" name="jdbc/DatabaseName" ... />
</Context>
і подобається:
<Context path="/ApplicationContextY" ... >
<ResourceLink global="jdbc/ApplicationContextY_DatabaseName" name="jdbc/DatabaseName" ... />
</Context>
тому когось може турбувати той факт, що одне і те ж name="jdbc/DatabaseName"
шукають, а потім використовують два різні додатки, розгорнуті на одному сервері: це не проблема, оскільки jdbc/DatabaseName
це приватний контекст JNDI для програми java:comp/env/
, тому ApplicationContextX
, використовуючиjava:comp/env/
неможливо (за проектом) шукайте ресурс, на який пов’язано global="jdbc/ApplicationContextY_DatabaseName"
.
Звичайно, якщо ви почуваєтесь більш спокійно без цього занепокоєння, ви можете використовувати іншу стратегію іменування, наприклад:
<Context path="/ApplicationContextX" ... >
<ResourceLink global="jdbc/ApplicationContextX_DatabaseName" name="jdbc/applicationXprivateDatabaseName" ... />
</Context>
і подобається:
<Context path="/ApplicationContextY" ... >
<ResourceLink global="jdbc/ApplicationContextY_DatabaseName" name="jdbc/applicationYprivateDatabaseName" ... />
</Context>
<Resource name="jdbc/ApplicationContextX_DatabaseName" ... /> <Resource name="jdbc/ApplicationContextY_DatabaseName" ... />
Якби ресурси були пулами з'єднань, чи отримали б ви це два окремі пули, по одному на веб-програму? Тоді як якщо б я зв’язав обидва веб-додатки з одним ресурсом, то був би лише один пул підключень, правильно? Будь-які причини віддавати перевагу одному перед іншим? (окремі пули з'єднань БД - один на веб-додаток проти одного пулу з'єднань, спільний для всіх веб-додатків)? Дякую.