我目前正在开发一个j2ee项目，该项目已经处于测试阶段一段时间了。现在，我们只是在解决部署过程中的一些问题。具体来说，战争中嵌入了许多文件（某些 xml 文件和 .properties），这些文件需要部署不同的版本，具体取决于您是在开发、测试还是生产环境中。诸如日志级别，连接池等内容。
所以我想知道这里的开发人员如何构建他们部署Webapp的过程。您是否将尽可能多的配置卸载到应用程序服务器？在部署之前，是否以编程方式替换设置文件？在构建过程中选择一个版本？手动编辑战争？
另外，您在通过应用程序服务器的静态库提供依赖项方面走了多远，您自己在战争中投入了多少？所有这一切都只是为了了解目前常见（或最好）做法的一些想法。
我认为，如果属性是特定于计算机/部署的，那么它们就属于计算机。如果我要把事情包装成一场战争，它应该是可以放弃的，这意味着没有特定于它正在运行的机器的东西。如果战争中有与机器相关的属性，这个想法就会被打破。
我喜欢做的是用一个 properties.example 文件构建一个项目，每台机器都有一个 .properties，它位于战争可以访问的地方。
另一种方法是让蚂蚁任务，例如开发战争，阶段战争，生产战争，并将项目的属性集部分纳入战争构建中。我不太喜欢这样，因为作为项目构建的一部分，您最终会在单个服务器上拥有诸如文件位置之类的东西。
我在一个单独的服务器团队为我们的应用程序执行 QA 和生产服务器的配置的环境中工作。每个应用程序通常部署在 QA 中的两台服务器上，在生产环境中部署在三台服务器上。我的开发团队发现，最好通过在战争（或耳朵）中放置尽可能多的配置来最小化服务器上所需的配置量。这使得服务器配置更容易，并且还最大限度地减少了服务器团队错误配置服务器的可能性。
我们没有特定于计算机的配置，但我们有特定于环境的配置（Dev、QA 和 Production）。我们在 war 文件中存储了按环境命名的配置文件（例如 dev.properties、qa.properties、prod.properties）。我们在服务器 VM 的 java 命令行上放置一个 -D 属性来指定环境 （例如.java -Dapp.env=prod ...）。应用程序可以查找 app.env 系统属性，并使用它来确定要使用的属性文件的名称。
我想如果你有少量特定于机器的属性，那么你也可以将它们指定为-D属性。Commons Configuration 提供了一种将属性文件与系统属性组合在一起的简单方法。
我们在服务器上配置连接池。我们对每个环境的连接池进行相同的命名，只需将分配给每个环境的服务器指向相应的数据库即可。应用程序只需知道一个连接池名称。
