小编典典
我更喜欢第三种方法,该方法从 user1016403描述的方法1和方法2 中获得最大的收益。
方法3
1. 将数据库属性保存在 server.xml
2. server.xml从Web应用程序引用数据库属性META-INF/context.xml
方法3的好处
尽管出于安全原因第一点很有用,但第二点对于从Web应用程序引用服务器属性值也是有用的,即使服务器属性值会发生变化。
此外,将服务器上的资源定义与Web应用程序的使用脱钩可以使这种配置在具有各种复杂性的组织之间可扩展,其中不同的团队在不同的层/层上工作:如果管理员共享相同的资源,则服务器管理员团队可以在不与开发人员团队冲突的情况下工作每个资源的开发人员的JNDI名称。
方法3的实施
定义JNDI名称jdbc/ApplicationContext_DatabaseName。
使用类似这样的声明jdbc/ApplicationContext_DatabaseName在Tomcat的各种属性和值server.xml:
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"/>
jdbc/ApplicationContext_DatabaseName通过属性META-INF/context.xml中java:comp/env/指定的应用程序专用JNDI上下文从网络应用程序链接的name属性:
最后,为了使用JNDI资源,请jdbc/DatabaseName在Web应用程序的部署描述符中指定JNDI名称:
DatabaseName's Datasource
jdbc/DatabaseName
javax.sql.DataSource
Container
在Spring上下文中:
jndi-name="jdbc/DatabaseName"
expected-type="javax.sql.DataSource" />
方法3的缺点
如果JNDI名称被更改,则必须同时编辑和server.xml和,META-INF/context.xml并且必须进行部署。但是,这种情况很少见。
方法3的变化
一个Web应用程序使用的许多数据源
只需将配置添加到Tomcat的server.xml:
...
META-INF/context.xml通过属性中java:comp/env/指定的应用程序专用JNDI上下文添加链接Web应用程序name:
...
最后,在Web应用程序的部署描述符中添加JNDI资源使用情况:
DatabaseName1's Datasource
jdbc/DatabaseName1 ...
DatabaseName2's Datasource
jdbc/DatabaseName2 ...
...
在Spring上下文中:
jndi-name="jdbc/DatabaseName1" ... />
jndi-name="jdbc/DatabaseName2" ... />
...
同一台服务器上的许多Web应用程序使用的许多数据源
只需将配置添加到Tomcat的server.xml:
...
其他配置应该可以从以前的变化情况中得出。
同一服务器上许多Web应用程序使用的同一数据库的许多数据源
在这种情况下,Tomcat的server.xml配置如下:
最终出现在两个不同的Web应用程序中,META-INF/context.xml 例如:
像:
所以有人可能会担心的是,同样name="jdbc/DatabaseName"是抬起头,然后使用由部署在同一服务器上的两个不同的应用程序:这不是一个问题,因为jdbc/DatabaseName是一个应用程序私有JNDI上下文java:comp/env/,因此ApplicationContextX 使用java:comp/env/不能(根据设计)查找链接到的资源global="jdbc/ApplicationContextY_DatabaseName"。
当然,如果你放心而又不用担心,可以使用其他命名策略,例如:
像:
2020-04-17