有没有可用于简化配置改变型材跨多个环境的Java Web应用程序的任何模式或最佳实践。 例如JDBC网址，SOAP端点，等等
由于一些背景知识，以帮助澄清我的问题，我有几个大的Java Web应用程序的工作，期间通过6个不同的环境中任何给定的发布周期举措; 开发，集成，质量保证，性能和最终部署到多个生产服务器。 在每一个环境中，配置需要改变。 现在，每个部署的大多数配置更改手动完成这既耗时又开到错误。
有没有办法采取人工干预这一过程的？
Answer 1:
我倾向于使用.NET更多最近的工作，所以我的Java是相当生疏。 我敢肯定，这将在任何语言的工作一点点调整。
我们使用.NET配置系统，使我们能够结合使用环境和/或应用程序特定设置一个更全局配置的扩展。 配置系统用于每个机器标识为dev的，β，或生产（默认值）的全局设置。 一组以载入的文件，并从最后文件中的设置会覆盖之前加载的文件中定义的任何设置。 文件被加载顺序如下：
- 全局设置
- 应用程序特定设置
- 具体的应用环境覆盖
的所有文件都在源控制，并且由于环境的应用程序运行在计算机上所定义; 因为除非机器配置的标识为“测试版”，将无法访问“测试版”的配置，我们可以促进所有的配置文件，而不用担心无意中指向我们的生产应用到开发数据库。
Answer 2:
我很惊讶，没有人提到的Jakarta Commons的配置API（ http://commons.apache.org/configuration/ ）来回答这个问题。 它可以让你有文件（或其他配置来源，如XML，JNDI，JDBC等）的层次结构。 这就是杰里米Seghi在谈论它让你同时拥有默认值和当地的覆盖，以及一个好办法。
最好的部分是，它是一个测试工作的解决方案，这样你就不必自己去手艺的东西。
Answer 3:
下面是我用或遇到了一些可能的做法。 结合这些通常需要在实践中。
建设当那些默认配置文件替换变量值
这里有一个如何这可以使用Apache Ant来完成的例子。 Ant属性（ ${var.name}可以与生成配置文件控制：
<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>
好事是，你得到了在构建时的不同配置的精细控制。 什么是坏的是，该系统往往变得非常复杂和艰难，如果你使用这种方法广泛用于大量不同配置的维护。 此外，具有打造那些默认配置，也意味着更慢的开发周期。
在Web应用程序启动时代里面的战争从conf下的变量
这是使用Spring框架时，我通常会做，哪怕只有一个possble配置，得到的关注点分离的好处。 借助于Spring，你可以在web应用启动与PlaceholderPropertyConfigurer更换Spring上下文内的conf值。 在这种情况下，你必须反正选择合适的配置，可以配置例如在编译时间。
相较于构建时更换，很容易暂时操纵值未压缩的Web应用程序，如果需要的话。 当然，webapp的需要，如果你改变什么，以重新启动，并手动更改也不会在Web应用程序的重新部署依然存在。 春天也仅限于Spring上下文，所以这并不”工作例如在web.xml中 （但其在web.xml中的变量可能应该无论如何避免，因为它的局限性）。
从预先定义的文件中读取本地的conf
这种做法可能是建立一个最简单的：刚刚创造一个配置文件路径，例如$HOME/mywebapp/conf.properties ，让你的web应用程序在启动时莫名其妙地阅读。
这里的好处是，你不必建造/部署web应用程序时，关心的conf。 无论如何，你应该有一个可以再由当地的conf覆盖一些明智的conf默认值。
其在数据库中的conf
这是压倒一切的conf参数的最灵活的解决方案，而且还可以得到在某些情况下复杂。 具有在一个表中的conf name和value列应适用于大多数情况下。
当然，你不能配置在数据库表中的JDBC连接URL，但这是为DB连接已经建立之后，影响web应用程序的操作简单的文本/数字的conf一个很好的解决方案。 为了避免性能下降，请确保您以某种方式缓存的conf如果将经常访问的。
额外的做法
正如kgiannakakis指出，这也有助于建立某种形式的配置诊断页为您的应用程序。
Answer 4:
这在很大程度上要依赖于哪些选项的Web应用程序服务器给你。 我们有多个环境JBoss的不同JDBC的URL，JNDI名称仍然在所有服务器，只是在本地实例上的配置发生变化一样，所以没有去从内部版本错误。
我想简单的答案是，最好的做法是外部的配置，并保持了良好的文件在地方与每个服务器的正确的设置，并在网络应用程序读取配置。 外化和阅读的确切性质将取决于具体的配置和应用程序服务器上。
编辑：这些配置并不存在的战争（在我们的例子耳），这样，他们就不会被覆盖的部分。
Answer 5:
起初拥有所有的配置设置在一个地方经常改变。 这真的很难，如果你需要设置JNDI，编辑数据库值和修改属性文件，所有在同一时间，以完成配置。 更希望是最简单的编辑，也更容易验证一切设置正确的媒介。 我要说的是属性文件是最好的解决方案。 您可以轻松编辑它们，你只需要通过他们咋一看看到一切正常。 如果您选择属性文件，仔细地为他们选择一个标准的位置，并指定一个环境变量的路径。
它还帮助，如果你有一个简单的测试，验证一切都正确设置。 例如，你可以有一个显示的配置参数，并执行一些基本的测试，如尝试连接到数据库或远程服务器测试页。
Answer 6:
你想要什么的很好的例子是用来缝或Grails的（Rails中借来的）。 有轮廓，由三个：PROD，开发，测试，但您可以定义，如果你想要更多。
在Seam项目打造的是使用Ant文件来完成。 该内容可以改变Eeach文件是为每一个配置如数据源，SQL脚本或属性文件中定义。
import-dev.sql
import-prod.sql
import-test.sql
当蚂蚁文件与choosen谱运行，相应的文件被认为和配置文件名称是从文件名截断。
下面的代码片段，你可以在你的目标放在
<copy tofile="${war.dir}/WEB-INF/classes/import.sql"
file="${basedir}/resources/import-${profile}.sql"/>
JDBC URL，驱动程序名称可以（与配置文件名称为后缀的课程）被外部化到属性文件
<filterset id="persistence">
<filter token="transactionManagerLookupClass" value="${transactionManagerLookupClass}"/>
<copy tofile="${war.dir}/WEB-INF/classes/META-INF/persistence.xml"
file="${basedir}/resources/META-INF/persistence-${profile}.xml">
<filterset refid="persistence"/>
</copy>
或性的判定值可以传递到命令行ant构建的呼叫。 这是简短的例子什么是煤层完成。
另一种选择是使用Maven的 。 在Maven的方式，通过属性，并通过做配置文件 ，但你也可以使用独立的模块分割配置并创建与主功能的模块。 Maven的资源和配置文件的典型应用案例是对多个数据库运行配置，部署服务器等，甚至当你想为不同厂商的配置，但Maven的是不是一个问题更难:)
使用maven配置文件的很好的例子是这篇文章的形式卡洛斯·桑切斯博客 。
综上所述，我强烈推荐将查找蚂蚁/缝的Maven的参数化（配置文件）。 这些解决方案具有另一个优势：Ant或Maven脚本可以在CI服务器（如运行哈德森 ），同时，让运行/测试的所有配置文件。
Answer 7:
您可以使用组件配置格局您所选择的语言
它在POSA书描述（我认为，在第4卷）
（在Java中可以使用公共配置组件）。
Answer 8:
有几种可能的方式来处理这个：
使用属性文件，如你这样做，但补充说，用于选择通过定义环境值（例如本地主机的主机名）之间的映射到属性文件名来加载使用的属性文件中的“元属性”文件。
把你的属性到数据库，并定义为是你的web应用程序拿起资源在应用程序服务器的数据库连接的属性表。
不要把属性文件在你的.war或的.ear，而是创建一个包含每个目标主机的属性文件属性 - deployhost.jar档案。 通过将其加入到类路径适当.jar文件到部署的Web应用内结合（通过在每web的应用程序中的应用程序服务器的配置的共享库为例。）
只有第一个这些在不必更新你的配置源，并建立新的当你的目标系统被重新命名部署文件的费用进行部署时并不需要额外的手动步骤。
我敢肯定，很多variantions对这些和你的方法是可能的，什么是最好的选择取决于你的情况。
Answer 9:
我们做什么工作得很好。
在启动时，我们的程序读取硬编码的路径中的配置文件。 比方说，它是：
/config/fun_prog/config.xml
每个项目都有不同的硬编码路径（FunProgram是fun_prog，超级服务器是sup_serv，等等），所以我们不必担心他们走了对方。
该XML文件是由我们创建一个小的配置图书馆阅读。 XML文件包含数据库连接信息，通常邮件服务器配置数据，电子邮件地址发送通知，是否应该在测试模式下，对外服务的URL等操作
所以，当我们需要做出改变，我们复制配置文件，编辑我们想要的东西，并重新启动程序。 因为我们有一个标准的服务器设置，任何程序都可以通过只复制围绕这些文件（和neccessary httpd.conf中修修补补）被部署在任何服务器上。
这不是幻想，但它工作得很好。 这是非常简单的了解，增加新的配置选项，备份和编辑。 适用于所有平台（UNIX是显而易见的Windows转换路径开始/到C：\因此它可以不修改也在场）。
我们的工作站基本运行相同的软件服务器，只是在配置文件中的一些变化。
Answer 10:
请看看这个网址： http://issues.apache.org/jira/browse/CONFIGURATION-394
这是我们正在寻找它的配置框架是Apache Commons Configuration也之上的东西，必须支持并发问题，JMX问题和大多数商店（如属性文件，.xml文件或PreferencesAPI）。
什么weblogic的团队提供“管理控制台”是野趣它通过它，你可以对配置，以便在注册的侦听器被通知事务（原子）的更新。
Apache的人坚持认为，这个项目是出于共享配置的范围，也许！
我已经附上简单的配置框架，拿来看吧。
文章来源: Java Web Application Configuration Patterns
