在我的公司，我们使用Weblogic（取决于版本6.1到11g之间的任何安装）。
现在，我们将特定于环境的变量嵌入到我们的耳朵，罐子和战争中。这甚至包括我们有这样的weblogic.xml文件：
<working-dir>/opt/bea/wl61/server/domains/deploy/prod3/temp/work</working-dir>
这意味着我们必须为每个环境重建相同的罐子，耳朵和战争。而且，如果环境发生变化，我们必须重建和重新部署战争，耳朵和罐子。您可以想象我们在构建和发布管理方面遇到的问题（这是我的工作）。
在我的上一个位置，我们使用了JBoss，并以某种方式能够创建通用和可部署的耳朵。我希望Hudson能够构建一个开发人员可以用于测试的耳朵。然后，同样的耳朵可以在他们的环境，UAT，升级和生产中传递给我们的QA团队。
我们可以做到这一惊人的壮举，因为我们将JBoss配置为寻找属性文件OUTSIDE或耳朵本身。有一个config目录是deploy目录的兄弟，它包含任何所需的属性文件。是否可以设置Weblogic来做同样的事情？
我们需要一种方法来完成最少的代码更改。我已经检查了源代码，当我们指定在属性文件中加载值时，我们不指定目录名称。因此，我们可以通过某种CLASSPATH想法来实现这一点。
我知道这些属性必须存在于某个地方，但我更喜欢它是否可以在环境中配置，也许可以通过相对于deploy目录的路径来完成。无论您使用何种系统，我都希望使用相同的ear，jar和war文件：Windows PC桌面，Linux，Mac或Solaris服务器。
最棘手的问题是我们的weblogic.xml嵌入路径。该路径可以相对于deploy目录而不是系统的根目录吗？
正如我之前所说，我是构建经理，所以就每个人而言，这是我的头痛，而不是他们的问题。如果部署不顺利， Finger'o Blame 可以直接指向我。
为了完成这项工作，我必须能够找到一个对我们来说很容易实现的解决方案。我们无法重写所有内容并改变一切。否则，我无法让其他团队这样做。毕竟，这是我的问题而不是他们的问题。我们需要一些编码变化最小（最好没有）的东西，以及我们的Weblogic设置中的最小变化。我想要的是在我们软件的3.4版本中，我们采用旧的时尚环境特定方式，但在版本3.5中，我们可以以环境中立的方式进行部署，并在我们的部署环境中进行最小的更改。
答案 0 :(得分：1)
我能感受到你的痛苦 - 我在几家公司经历了同样的过程。您有几个选项可以从当前设置中获得显着改进：
1）修改CLASSPATH以使用覆盖ear文件中所有内容的外部目录/属性文件。这很容易实现，但如果没有适当的标准/治理，就会失控。
2）使用部署计划来定义特定于环境的变量。但是，直到WebLogic 9.2才会引入部署计划。
3）将所有环境特定文件滚动到自己的jar中。所有环境都指向同一个文件，但它会根据您的构建过程构建不同的内容。优点 - 包含所有道具，易于移动等的单个文件。缺点 - 无法动态更改属性并强制从JVM重新加载。
可能存在基于存储库的其他选项。恕我直言，所有这些工作或多或少相同 - 这是一个过程，并强制执行它，以防止问题。