如何区分应用程序中的测试和生产属性？
我们正在开发一个大型的J2ee电子销售解决方案。 它有很多集成：CMS，ERP，邮件服务器等。所有这些系统分为测试和生产环境。
我们需要将我们的应用程序部署到具有测试配置的测试服务器，并且当部署到我们的生产服务器时，它应该使用生产配置。 我们如何让我们的应用程序选择正确的属性？
到目前为止我们尝试过的是：
我们所有的属性文件都包含测试属性和生产属性
test.mvxapi.server = SERV100TS test.mvxapi.username = user test.mvxapi.password =密码 test.mvxapi.port = 6006 test.mvxapi.cono = 600 mvxapi.server = SERV10001 mvxapi.username = user mvxapi.password =密码 mvxapi.port = 6001 mvxapi.cono = 100
读取这些属性的Util有一个开关：isTest（），它以“test”为键前缀。
public String getProperty（String property）
{
return properties.getProperty（prefix +“”+ property）;
}
该开关由我们的构建服务器创建的另一个属性设置。 构建.EAR时，我们的生产服务器的脚本将（输入到build.xml）“isProduction = true”注入到system.properties中。
我不确定这是最好的方法。 如果由于某种原因，“isProduction = false”被错误地提交给我们的生产环境，那么一切都是松散的。
我已经读过人们在服务器上本地拥有属性。 但我们真的不想让文件传播开来。 我们有生产服务器集群。 确保每个服务器都具有正确的属性文件似乎不是故障安全的
您要避免的是在EAR中包含配置文件，问题在于您需要针对不同环境使用不同的EAR，并且更改配置文件需要重建。
而是将相同的 EAR部署到每个服务器，但使用不同的URL资源配置每个服务器。 iow，将JNDI URL资源添加到您部署到该资源的配置文件的所有服务器上。 如果您只读取了对repo的SVN访问权限，则在svn repo上创建配置文件，或者通过URL访问任何repo。 这里很酷的是，所有配置都是集中的，因此管理它们很容易。
我所做的（通过使用spring进行自定义）确保JNDI URL资源是可选的。 所以，如果它在那里，应用程序将使用它，如果没有，它将不会。 该应用程序启动是否存在。 这样，即使在没有可用的JNDI资源的情况下运行，该应用仍然有效（例如开发环境）。
您部署了EAR？ 然后放入JNDI中所需的属性。
我不能说这是否是最好的方式，但是，我们所做的是包括一个客户端和服务器jar，它相应地容纳了属性。 然后我们将这些jar包含在EAR文件中。 因此，在我们的构建过程中，我们为我们部署的环境包含适当的（QA，TEST，PROD）jar。
缺点是我们必须管理三套环境jar，构建团队必须小心不要部署不正确的环境jar。 事实上，曾经有一次我们在我们的QA环境中部署了一个PROD jar并且QA数据正在投入生产….是的，这很糟糕，并且是一个非常糟糕的清理工作。
我将关注这个讨论，因为我经常想知道如何让这个过程变得更好/更安全。 伟大的post+1
在以前的J2EE项目中，我们一直在这样做。 构建过程（一个ant脚本）将正确的配置文件放在一起，将它们添加到某个jar中，然后将其放入EAR文件中，用于生产环境，测试，培训，QA等。
EAR文件的文件名包含目标环境的名称，因此基本上不可能将文件部署到错误的环境中。 如果我们为目标156p2（工厂156，生产环境2）构建，这将是EAR文件的文件名的一部分，而ant将包括config_156p2.xml。 如果目标不正确，则EAR文件的名称将是错误的，并且作为最后的故障保护，部署它的人会注意到。
构建文件必须包含这个：一个ant目标，为每个环境启动构建，这将设置一个属性，告诉ant要包含哪个配置文件。
然后，EAR文件之间的唯一区别是配置文件。 其他一切都是一样的。 当然，有可能某人可能为某个环境的配置文件写了错误的值。 然而，在实践中，这种情况在几年内从未发生过，即使是一些非常初级的开发人员和大约15个目标环境（不同国家的不同测试，QA，培训和生产服务器）。
我们的项目中有3个用于此目的的文件夹，每个文件夹包含配置文件（文件夹之间的文件名相同）：
- personal：包含测试db，server等的路径
- test：包含与同事共享的服务器的路径
- 制作：包含……你猜对了
当我构建我的项目时，我在Intellij Idea项目构建中添加了适合的配置文件，在desidered模块中，这基本上意味着我在项目结构中添加了不同的文件夹，但是因为文件名是相同的，所以更改只是配置文件属性。