Fatal编程技术网
  • java/
  • Java 在JAR中包含属性/配置文件是一种不好的做法吗？

Java 在JAR中包含属性/配置文件是一种不好的做法吗？

java configuration properties jar

Java 在JAR中包含属性/配置文件是一种不好的做法吗？,java,configuration,properties,jar,Java,Configuration,Properties,Jar,例如： MyApp是一个web应用程序，它包含一个属性文件（server.properties），该文件描述应用程序的配置数据（例如服务器名称）。在开发阶段，server.properties位于它自己的IDE项目文件夹中（它的逻辑位置） 现在是时候部署MyApp了。IDE使得jar类文件和支持的配置文件变得非常简单。现在，我们只需将Jar放入适当的web容器中，然后就可以 一周后。。。MyApp使用的服务器配置数据需要更改。哪个更有意义 A.修改ideland中的server.properti

例如：

MyApp是一个web应用程序，它包含一个属性文件（server.properties），该文件描述应用程序的配置数据（例如服务器名称）。在开发阶段，server.properties位于它自己的IDE项目文件夹中（它的逻辑位置）

现在是时候部署MyApp了。IDE使得jar类文件和支持的配置文件变得非常简单。现在，我们只需将Jar放入适当的web容器中，然后就可以

一周后。。。MyApp使用的服务器配置数据需要更改。哪个更有意义

A.修改ideland中的server.properties文件，并生成一个全新的jar文件。重新部署。（这意味着为了简单的配置更改而跳转应用程序）

B.打开已经部署的Jar并修改server.properties文件？（如果缓存了server.properties，则可能必须在MyApp中调用刷新功能…但不需要完整的应用程序跳转。还需要记住修改源server.properties，以便将来部署时不会将server.properties还原为旧的服务器名称）

首先，将server.properties置于jar文件的外部。与B的过程非常相似，只是将配置数据保留在jar外部的细微差别（在开发和生产部署之间引入了不同的路径）

D.其他：

谢谢

我会和d一起去

尝试从.jar外部加载属性文件，如果失败，则加载内置到jar中的属性

这使您可以在每次构建时推出“现成”配置（如果只需一个文件，还可以降低部署的复杂性），同时使覆盖配置成为可能并相当简单。

这取决于具体情况。如果属性文件包含要由应用程序或库的用户更改的数据，则属性文件应位于外部

如果它包含静态数据，而您创建属性文件只是为了避免在源代码中对值进行编码，或者如果文件是本地化字符串，我会将它们留在jar中。至少因为属性文件邀请人们更改值；）

请记住，在J2EE中，不能保证您能够从J2EE环境外部访问文件（没有直接的文件访问）

您必须使用JNDI来指向包含数据的数据源，或者指向部署工件中的属性文件

例如，Websphere默认情况下不允许直接访问文件。

我问了一个类似的问题。我们还没有完全弄清楚。但我们正在研究URL资源。其中属性文件直接从SVN读取。除了属性文件之外，不需要更新任何内容。

通常情况下，代码从测试迁移到生产时应保持不变。这意味着您不能编辑嵌入的配置文件。此外，您可能会遇到需要更改已部署配置的情况，这通常非常麻烦。因此，我们把配置放在罐子外面

对于java EE应用程序，请考虑JNDI或类路径中的属性文件。

我有一个web应用程序，其中的配置是从一个相邻的web应用程序检索的，只是为了将两者分开。事实证明，这要容易得多

在jar中加载属性。然后使用jar-ed属性作为默认值创建一个新属性。然后从罐外装入。这允许选择自定义属性。

我在Web应用程序（WAR）中使用属性文件，但主要用于默认值和或多或少不可变的内容（因为Web应用程序即使可以也不应该更新WAR）

但是，对于像您所说的内容，我使用JNDI。可以将属性定义为web.xml文件中的资源。这样，最坏的情况是更新web.xml，而不是更新应用程序本身

对于某些服务器，有一些方法可以覆盖这些资源值，而根本不涉及战争。例如，在Tomcat中

我通常会为测试、Q/A和生产进行一场战争，并使用Tomcat的上下文xml文件覆盖环境敏感资源。我认为这比构建多个战争或修改战争要好得多，因为我正在测试的应用程序与正在生产的应用程序几乎是相同的。

< P>我认为答案取决于你是否认为你需要对配置文件进行版本控制。（它们可以是生产配置或回归测试配置…）

  • 如果您不需要版本控制，那么带有覆盖属性文件的外部属性文件的选项D是一个不错的选项。选项B和C对stuff-ups更开放，但如果您真的在意，您应该使用版本控制：-）
  • 如果您需要版本控制，选项A将为您提供更多的控制，但如果您有可能进行多个部署，您可能还希望/需要对每个部署的配置进行版本控制。一个例子是分别部署到测试和生产平台
下面是我们如何使用Maven模块和Maven WAR文件“覆盖层”来实现这一点

  • 我们有多个用于Java代码组件的模块。这些是JAR模块
  • 我们有用于静态内容、JSP和核心配置数据（SpringWiring、默认属性）的“BaseWebApp”模块。这是一个WAR模块，因此构建的结果是一个包含上述+所有JAR文件的WAR
  • 每个不同的“站点配置”都是一个WAR模块，其中包含属性、连接文件和内容的特定于站点的覆盖。覆盖使用Maven WAR“覆盖”机制进行描述，并导致从“基础”WAR和覆盖组装新的WAR
    • 所有这些都被检查到版本控制中，您需要进行Maven构建和WAR部署以进行配置更改 
    <!-- try and resolve the config from the filesystem first and then fallback to the classpath -->
<context:property-placeholder location="file:config.properties, classpath:config.properties"
                              ignore-resource-not-found="true"/>

    application.jar
config.properties

    java -jar application.jar

    # This file contains properties that are used to configure the application
database.url=127.0.0.1
database.port=3306
database.user=root
database.pass=p4ssw0rd