grails/外部配置/grails.config.locations - 绝对路径文件“不存在”？

发布于 2024-09-25 00:02:54 字数 1050 浏览 3 评论 0原文

我正在尝试使用 Grails 的内置机制在部署的 WAR 文件之外加载外部配置文件（*.groovy 和 *.properties）。该文档暗示这只是使用适当的 classpath: 或 file: 路径设置 grails.config.locations 的情况。

我已将 Config.groovy 配置为：

String externalConfigLocation = System.getProperty("SYSTEM_PROPERTY_KEY")
if (!grails.config.locations || !(grails.config.locations instanceof List)) {
    grails.config.locations = []    
}
if (classpathExternalConfigLocation) {
    String pathToResource = "\"file:${basedir}" + File.separator + externalConfigLocation+"\""

    print "Loading external configuration file: ${pathToResource}\n"
    grails.config.locations &lt;&lt; pathToResource
}

但是这不起作用，错误消息指示文件“不存在”。但是，打印存储在 grails.config.locations 中的绝对路径表明确实如此。我尝试了一些组合：

classpath:configurationFile.properties
file:c:\path_to_file\configurationFile.properties
c:\path_to_file\configurationFile.properties

但在所有这些情况下都找不到该文件。

很奇怪-建议赞赏。或者关于如何调试的建议。

原文

I'm trying to use Grails' built-in mechanism for loading external configuration files (*.groovy and *.properties) outside the deployed WAR file. The documentation implies this is just a case of setting grails.config.locations with the appropriate classpath: or file: paths.

I've configured Config.groovy with:

String externalConfigLocation = System.getProperty("SYSTEM_PROPERTY_KEY")
if (!grails.config.locations || !(grails.config.locations instanceof List)) {
    grails.config.locations = []    
}
if (classpathExternalConfigLocation) {
    String pathToResource = "\"file:${basedir}" + File.separator + externalConfigLocation+"\""

    print "Loading external configuration file: ${pathToResource}\n"
    grails.config.locations << pathToResource
}

However this hasn't worked, with error messages indicating the file "Does not exist". However, printing the absolute path stored in grails.config.locations indicates it does. I have tried some combinations:

classpath:configurationFile.properties
file:c:\path_to_file\configurationFile.properties
c:\path_to_file\configurationFile.properties

but in all these cases the file can't be found.

Very strange - advise appreciated. Or suggestions on how to debug.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

唐婉 2024-10-02 00:02:54

这是我通常做的事情：

grails.config.locations = ["classpath:${appName}-config.groovy",
                           "file:./${appName}-config.groovy"]
if (System.properties["${appName}.config.location"]) {
   grails.config.locations << "file:" + System.properties["${appName}.config.location"]
}

这让我可以在开发时在项目根目录中放置一个文件以在本地自定义属性（使用 file: location），并在部署为 war 时在服务器的类路径中放置一个文件。 Tomcat 的 lib 文件夹位于其类路径中，因此如果您使用 Tomcat，那么这是放置文件的好地方。通过将应用程序名称放入文件中，您可以拥有多个配置文件，而无需它们相互干扰。

请务必将本地配置文件添加到 svn:ignore 或 .gitignore，这样您就不会将其签入源代码管理中。然后，每个开发人员都可以拥有自己的设置（或仅使用默认设置），而不会影响其他开发人员。

这是外部化数据库密码和其他生产值的好方法。应用程序部署者（最好不是开发人员）管理文件及其内容，这可以避免将密码签入源代码管理。 IMO 比使用 JNDI 好得多。

This is what I usually do:

grails.config.locations = ["classpath:${appName}-config.groovy",
                           "file:./${appName}-config.groovy"]
if (System.properties["${appName}.config.location"]) {
   grails.config.locations << "file:" + System.properties["${appName}.config.location"]
}

This lets me put a file in the project root to customize properties locally when developing (using the file: location) and a file in the server's classpath when deployed as a war. Tomcat's lib folder is in its classpath so that's a good place to put files if you're using Tomcat. By putting the app name in the file you can have multiple config files without them stepping on each other.

Be sure to add the local config file to svn:ignore or .gitignore so you don't check it into source control. Each developer can then have their own settings (or just use the defaults) without affecting the others.

This is a great way to externalize database passwords and other production values. The app deployer (ideally not a developer) manages the file and its contents and this avoids checking in passwords into source control. Much better than using JNDI IMO.

回复收藏 0 原文