【问题标题】:Java Best Practices for Config File Locations配置文件位置的 Java 最佳实践
【发布时间】:2014-06-12 18:42:25
【问题描述】:

在 UNIX 及其衍生版本中,应用程序配置文件位于 /etc/ 下,而它们位于 Windows 和其他系统的其他位置。 Java 背后的理念是“一次编写,到处运行”,理想情况下,应用程序不应该关心它在什么操作系统上。但我希望我的应用程序在启动时加载配置文件,我需要提供一个路径。现在,我正在加载不同的文件位置以关闭操作系统名称,但这并不像是 Java 的最佳实践。我该如何调和呢?

【问题讨论】:

标签: java unix


【解决方案1】:

当我制作游戏/应用程序时,我只是将资源文件夹放在与应用程序相同的路径中。例如在代码中,目录将是“res/config.yml”。在与 jar 相同的文件夹中,放置名为“res”的资源文件夹。然后将文件放入 res 文件中。所以应用程序应该获取文件。

【讨论】:

    【解决方案2】:

    我通常将配置文件放在用户主目录的.<appName>(注意前导点)中,在运行时通过System.getProperty("user.home") 读取该目录。这是 Linux 用户的预期位置,而在 Windows 上,它感觉有点异国情调(与 AppData/LocalAppData/Roaming 等配置文件目录相比),即使它是跨平台工具的极受欢迎的选择。使用当前用户的家意味着您通常不会在文件系统访问权限方面遇到问题,并且首选使用 user.home 而不是自定义属性,因为它是由系统开箱即用提供的(并且仍然可以被覆盖)

    另一种方法是使用安装目录,但是你必须使用指向那个的环境变量,比如$APP_HOME,因为它通常不能在应用程序运行时推断(实际上你可以得到安装通过使用主 ClassLoader 返回的 URL,对于典型的 JAR 部署,目录非常容易,但我认为它是一种 hack,并且认为它不应该被使用)。您的应用程序可以使用System.getenv("APP_HOME") 读取该变量,并且该变量必须由您提供的平台相关脚本设置以启动您的应用程序。这种策略的缺点是当前用户可能没有读取/写入命名目录的权限。

    【讨论】:

      【解决方案3】:

      在我们的应用程序中,我们在每个操作系统上使用不同的位置进行配置。

      在 Linux 上

      /etc/应用程序名

      在 Windows 上

      [使用选定的安装目录]/conf

      我们通过系统属性控制应用程序的外观

      -Dconf.dir=路径

      我不一定认为在这种情况下有正确的答案。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2010-10-31
        • 1970-01-01
        • 2013-02-21
        • 2012-03-09
        • 2017-09-06
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多