Java Web应用程序配置模式

Question

是否有任何模式或最佳实践可用于简化跨多个环境的Java Web应用程序的配置配置文件更改.例如JDBC URL,SOAP端点等.

作为帮助澄清我的问题的一些背景知识,我使用了几个大型的Java Web应用程序,这些应用程序在任何给定的发布周期中都可以通过6个不同的环境; 开发,集成,QA,性能并最终部署到多个生产服务器.在每个环境中,配置都需要更改.目前,每个部署的大多数配置更改都是手动完成的,这既费时又容易出错.
有没有办法从这个过程中进行人工干预？

Answer 1

我很惊讶没有人引用Jakarta Commons Configuration API(http://commons.apache.org/configuration/)来回答这个问题.它允许您拥有文件层次结构(或其他配置源,如XML,JNDI,JDBC等).这就是Jeremy Seghi所说的,它为你提供了一个很好的方法来同时拥有默认值和本地覆盖.

最好的部分是它是经过测试的工作解决方案,因此您不必自己制作工具.

Answer 2

我最近倾向于使用.NET,所以我的Java相当生疏.我很确定这可以用任何语言进行一些调整.

我们使用.NET配置系统的扩展,允许我们将环境和/或应用程序特定设置与更全局的配置结合使用.配置系统使用全局设置,每台计算机将其标识为开发,测试或生产(默认).按顺序加载的一组文件,最后一个文件中的设置将覆盖先前加载的文件中定义的任何设置.文件按以下顺序加载:

1. 全局设置
2. 特定应用设置
3. 特定于应用程序的环境覆盖

所有文件都在源代码控制中,并且由于在应用程序运行的机器上定义了环境; 因为它不会访问"beta"配置,除非机器配置将其标识为"beta",我们可以提升所有配置文件,而不必担心无意中将我们的生产应用程序指向开发数据库.

Answer 3

以下是我使用或遇到过的一些可能的做法.在实践中通常需要结合这些.

在构建时用conffiles替换变量值

这是一个如何使用Apache Ant完成此操作的示例.${var.name}可以使用构建配置文件控制Ant属性():

<filterset id="variables.to.replace">
    <filter token="APPNAME" value="${app.name}"/>
    <filter token="WEBAPP-PATH" value="${webapp.path}"/>
    <filter token="ENCRYPT-ALGORITHM" value="${encrypt.algorithm}"/>
    <filter token="ERROR-MAILTO" value="${error.mailTo}"/>
    <!--...-->
</filterset>

<!-- Then, when building & copying the conf, replace the variables: -->
<copy todir="${properties.target.dir}">
    <!-- env specific conf files -->
    <fileset dir="${basedir}/env/${run.env}/webapp/WEB-INF/classes" />
    <filterset refid="variables.to.replace"/>
</copy>

好处是你可以在构建时很好地控制不同的配置.糟糕的是,如果将这种方法广泛用于大量不同的配置,系统往往会变得非常复杂并且难以维护.此外,必须构建配置也意味着更慢的开发周期.

在webapp启动时用war里面的变量代替

这就是我在使用Spring Framework时通常所做的事情,即使只有一个可能的配置,也可以获得关注点分离的好处.使用Spring,您可以在webapp启动时在Spring上下文中使用PlaceholderPropertyConfigurer替换conf值.在这种情况下,您必须选择正确的配置,例如可以在构建时配置.

与替换构建时间相比,如果需要,可以更轻松地临时操作未压缩的Web应用程序中的值.当然,如果您更改任何内容,则需要重新启动Web应用程序,并且手动更改将不会在Web应用程序重新部署中持续存在.Spring也仅限于Spring上下文,因此这不会在web.xml中起作用(但由于其局限性,因此无论如何都应该避免在web.xml中使用变量).

从预定义的文件中读取本地conf

这种方法可能是最容易设置的方法:只需创建一个配置文件路径,例如$HOME/mywebapp/conf.properties,让你的webapp在启动时以某种方式读取它.

这里的好处是,在构建/部署webapp时,您不必关心conf.无论如何,你应该有一些合理的conf默认值,然后可以被本地conf覆盖.

将conf放在数据库中

这是覆盖conf参数的最灵活的解决方案,但在某些情况下也会变得复杂.将conf放在带有name和value列的表中应该适用于大多数情况.

当然,您无法在数据库表中配置JDBC连接URL,但这对于简单的文本/数字配置是一个很好的解决方案,它会在设置数据库连接后影响webapp的操作.为了避免性能损失,请确保以某种方式缓存conf,如果它经常被访问.

额外的做法

正如kgiannakakis所指出的,它还有助于为您的应用设置某种配置诊断页面.

Answer 4

这很大程度上取决于Web应用程序服务器为您提供的选项.我们有多个具有不同JDBC URL的JBoss环境,所有服务器上的JNDI名称保持不变,只是本地实例上的配置发生了变化,因此从构建到构建没有任何问题.

我想简短的回答是,最佳做法是外部化配置并使用每个服务器的正确设置保留一个好的文件,并让Web应用程序读取该配置.外化和读取的确切性质将取决于特定的配置和应用程序服务器.

编辑:这些配置不作为战争的一部分存在(在我们的案例中是耳朵),它们不会被覆盖.