〈property name="driverClassName"〉
〈value〉org.postgresql.Driver〈/value〉
〈/property〉
〈property name="url"〉
〈value〉jdbc:postgresql://localhost/test〈/value〉
〈/property〉
〈property name="username"〉
〈value〉postgres〈/value〉
〈/property〉
〈property name="passWord"〉
〈value〉〈/value〉
〈/property〉
〈/bean〉
这个解决方案的问题在于对applicationContext.xml文件的维护。对于初学者来说,设想一下,项目放在源代码版本控制系统中,例如 CVS。下面,假设您希望在网站中添加新的功能,那么就需要在应用程序上下文定义中添加额外的Bean定义。问题是如何在生产服务器上体现这些改变。
通常情况下,应用程序的本地实例不会与活动站点使用同样的数据库,因此applicationContext.xml文件将包括让您能够访问本地数据库的设置。当您想提交在源代码版本库中的改变时,就需要注重这些特定于主机属性的同步性。版本库中的文件最终可能使用本地设置中的配置。假如想在生产服务器上更新配置,就必须手动同步这些属性的值。这是非常枯燥的任务,而且还非常轻易出错。
对于应用程序的每个实例来说,这个问题更加重要。假如有三位开发人员正在使用代码段基址,而且他们使用的是本地的数据库。当您提交更改的时候,他们每个人在本地服务器上更新源代码的时候都必须非常谨慎。他们会手动同步这些更改,然后提交他们的工作。这样一来,版本控制系统对于这些配置文件来说已经毫无用处。假如曾经使用过Spring MVC,那么您应该知道applicationContext.xml是应用程序中的要害组件,因为是它将所有的东西粘合在一起。所以,我们需要一种机制来帮助使应用程序中各项保持有序,这点非常重要。
正如前面所提到的,这是您可能碰到的较简单的配置问题。更难的问题出现在当需要在不同服务器中进行不同的Bean连接的时候。这类问题常会出现在日常软件开发任务中。例如,假如您的产品有一个客户身份验证模块,可以对来自关系数据库或 LDAP服务器中的用户进行身份验证。自然,这一身份验证模块可以使用抽象了特定版本库的Bean进行配置。假如您想改变不同应用程序部署中验证用户的方式,就需要在applicationContext.xml文件中进行不同的Bean连接。这种配置问题常见于在部署中有可配置特性的所有应用程序。