在一个单独的Java项目中保留属性文件的最佳方法或最佳实践是什么？

我有一个单独的项目，具体如下：

• a） 业务层（包含所有核心Java类和一些配置（服务等）），以及
• b） 表示层（包含基于Spring webflow的所有web结构，以及其中的所有配置文件。因此，在开发过程中，我们在

  java/main/src

  中的

  resource.properties.*

  包下有几个属性文件，在

  web-INF/conf

  下的web结构中还有其他属性

  WEB-INF/i18n

  （这是屏幕上的标签消息）…因此我的问题如下：

• 将属性文件保留在

  java/main/src

  在以后将在

  类下的包下
  webapp？中的文件夹

• 哪种方法是最好的离开所有 属性文件放在一个位置，比如说

  WEB-INF/configurations

  ？或者 将业务层的一些属性文件保留在一个位置，并保留一些 是否将演示层中的属性文件放置在其他位置
• 哪种方法是以最佳方式获得此属性的最佳方法 安装webapp？，在JAR文件中交付属性，然后 将其包含在WAR或EAR中？允许我们动态修改 并在不部署整个应用程序的情况下将其包括在战争中……或者哪种方法是实现这一点的最佳方法或常用方法

---

我认为最好有一个单独的源文件夹“resources”，并将所有属性文件保留在那里。这还可以确保属性文件不会与源代码混淆。

我发现将属性分为两类很有帮助：

用于方便地更改应用程序外观和行为的属性

环境特定设置的属性（例如开发与生产）

类别#1可以在任何有意义的地方嵌入到您的WAR文件中。在

WEB-INF/classes

中是一个流行的地方，但将它们放入

META-INF

in jar文件中也可以很好地工作。选择一个您喜欢的标准并坚持它是值得的。底线是，这些文件在开发过程中会发生更改；它们不会改变ged在部署后，并在系统释放时保持不变

---

类别#2应始终与可部署属性分开。理想情况下，特定于环境的属性应仅在更改时部署。它实际上是一种配置管理（CM）决定他们的居住地。开发人员需要提供这些配置文件的基本版本，CM应在将其部署到特定环境（QA、PRE-PROD、PROD）时对其进行编辑。在授权职责的情况下（例如，SOX适用的情况下），属性文件的生产版本不应该被开发人员触摸或看到这些文件中的大多数由开发人员维护，并保存在不合适的源代码管理中。

您是否使用Maven或Ant之类的构建工具？我们使用jenkins和Ant进行编译…感谢Charles的评论！。在类别#2中，我们使用单独的配置层为每个环境包含相同的属性，使用jenkins覆盖ose。当稍后发布的配置管理想要交付和更改配置（属性文件）时，会出现问题如果您将所有属性文件分散在不同的位置，那么这将是一个很难遵循的过程。因此，如果我们有一个单独的配置项目，只有属性文件，则应在最佳实践下工作？Charles对此有何经验？感谢advAh。您有第三类：应用程序自定义这是由开发人员提供的，由客户在部署时设置。我最喜欢的方法是在可部署文件之外使用属性文件，但确保可以设置的任何内容都有合理的默认值。如果文件不存在，或者没有设置特定选项，则应用程序仍然可以工作。这很容易做到：有一个默认情况下为内部属性文件。外部文件的位置可以在JVM选项中使用系统属性设置。这将最大限度地减少CM影响。这有帮助吗？确切地说，Charles，我们有一些属性，可以配置URL后端（服务）、应用程序配置等。）这些都是由spring属性实现调用的…如果我理解正确，您的方法是在可部署的外部使用外部JAR或WAR，并将应用程序指向JVM opts以正确恢复属性？…这将比JVM opts使用JNDI更好？您知道JNDI是否有效吗？ThanksPretty close。我是just谈论的是一个简单的属性平面文件，而不是一个包装在JAR中的文件。这使客户可以轻松管理这些文件。我猜使用JNDI查找文件是一种选择，但这似乎会使事情变得过于复杂。如果您可以根据可用数据确定目录，您可以指定一个特定的目录并查看所有

.properties

文件。例如，如果您在JBOSS下运行，您可以使用

System.getProperty（“JBOSS.home”）

，然后将

/properties

钉在上面并查看。谢谢，再见……那么您是指

src/main/java/resources

还是

src/main/resources

？